Process Mapping Before AI Automation: A Worked Example

Before adding an AI agent, map one piece of work from its trigger to an observable result. Record the input, decision, owner, handoff and exception at each step. The useful question is: could another person follow this record without guessing who acts next?

A list of tools does not answer that question. Start with how the work happens today, including messages, waiting and corrections. Draw a proposed version separately so an intended improvement does not get mistaken for the current process.

Define the boundary before choosing software

Take an internal equipment request. For this exercise, the map starts when a request arrives and ends when the requester acknowledges the approved collection instructions, or the responsible person records a refusal. Physical collection, return and purchasing are outside this map.

This is a fictional planning exercise, not a customer case, a working IliciLabs application or a tested automation. Its rules and states are proposals to adapt with the people doing the work.

IBM’s process-mapping overview describes identifying stakeholders, the start and end of the process, and validating the map with participants. Use that approach to reconstruct a recent case in your own organisation before proposing changes. Keep confidential records in your approved systems; use anonymised examples when discussing a project externally.

A completed map: from request to acknowledged instructions

Assume request EQ-17 asks for a projector for a workshop but omits the collection date. Here is a proposed map; each output is something the next role can check.

Step and owner	Input and decision	Output or exception
Operations receives the request	Request reference, equipment and collection date. Is a required field missing?	EQ-17 stays awaiting information. Operations asks for the date; it does not invent one.
Operations checks availability	The requester supplies a date. Operations checks the equipment register for that date.	Record the register reference and check time. A conflict goes to the equipment custodian; it is not a confirmed allocation.
Equipment custodian decides	The request and availability check are available. Does the custodian approve this request?	Record the decision, decision time and any conditions. A refusal has a reason; approval alone is not a sent instruction.
Operations prepares the handoff	Use the approved decision to prepare collection instructions for the requester.	Record the instruction version and delivery outcome. Failed delivery stays with Operations; it does not become acknowledged.
Requester acknowledges	The requester confirms receipt of the current instructions.	Record the acknowledgement reference and close this map as instructions acknowledged. Without it, keep the handoff open.

In this design, Operations remains responsible for the open handoff until acknowledgement. The equipment custodian owns the allocation decision. Agree a follow-up interval and a backup person rather than silently passing an unanswered task between teams.

A swimlane diagram can make those role changes visible. Lucidchart’s swimlane guide describes placing tasks in the lane of the responsible role and using arrows for the flow between roles. You can sketch the same role boundaries on paper; the worksheet below is a starting record, not a requirement to buy a diagramming tool.

Copy this record for one step in your process

Fill this in for every step, then connect the outputs to the next inputs. A blank entry is a question to resolve with the team.

• Boundary: starts when ___; finishes when ___; excludes ___.
• Trigger and case reference: ___ happens; this case is identified by ___.
• Input and source: required fields ___; authoritative record ___; checked at ___.
• Action and decision: ___ performs ___; the rule or approval needed is ___.
• Output: the next person receives ___, with evidence at ___.
• Handoff: current owner ___; receiving role ___; acceptance is recorded by ___.
• Exception: if ___, hold at ___; ___ resolves it; resume after ___.
• Follow-up: review unresolved work after ___; backup role ___.
• Measure: record work time ___ and waiting time ___ separately; count corrections using ___.

Do not treat the person performing a task and the person accountable for its outcome as interchangeable. Microsoft’s roles guidance explains this distinction in its RACI example. For a small map, write the roles plainly and agree who answers for the result; a full matrix is optional.

Walk through the awkward cases before building

Ask the people involved to apply the proposed record to these cases. Record the expected result and any unanswered question. These are suggested checks, not tests already performed.

• Missing date: EQ-17 waits for information. No availability or approval is inferred.
• Conflicting record: the register shows an existing allocation. The custodian resolves the conflict before approval.
• Repeated request: the same reference arrives again. Compare it with the existing case before creating another allocation; an ambiguous match needs review.
• Unaccepted handoff: instructions were delivered, but no acknowledgement arrives. Keep the case open with its follow-up owner.
• Delivery error: preserve the decision and instruction version. Check the delivery record before retrying; an uncertain outcome must not be treated as either confirmed failure or receipt.

If participants disagree about the result, fix the rule or ownership first. Also ask whether the proposed process can remove a redundant re-entry instead of automating it.

Choose the next intervention from the map

In this example, checking whether a date field is empty can use a fixed rule. Summarising a free-text request could be an AI-assisted draft, with the original request available to its reviewer. Approval and acknowledgement remain explicit human actions in the proposed design. No AI step is needed merely to move a clearly defined status.

Use the automation decision matrix to examine those choices. For the narrower problem of extracted documents moving into review and export, see the document-workflow guide; it addresses a different layer of the process.

To discuss a bounded project, bring the current map, an anonymised normal case, an exception, the systems involved and the unresolved decisions to the AdarisTech business AI automation. First agree what completion means and how it will be checked. Any expected time saving remains a hypothesis until comparable real work has been measured.