Don’t automate the mess. Find the handover first.

Follow one record from beginning to end

A process diagram can look orderly while the real work travels through inboxes, spreadsheets and private messages. Begin with one recent, appropriately anonymized example and follow it. Where did it start? Who touched it? When did someone wait? What information was added or corrected?

Take an illustrative customer request. A message arrives, someone labels it, another person checks eligibility and a third person schedules the next step. If the request is incomplete, it circles back. The sequence is straightforward; the conditions around each transfer are where much of the uncertainty lives.

Map five things, in plain language

Your first map does not need specialist software. Five columns are enough: trigger, input, decision, output and owner. Add a separate note for exceptions. Use verbs that someone can observe, such as check the address or ask for the missing document. Avoid descriptions such as process intelligently.

The map should explain what accepted work looks like. If two people disagree on whether a task is done, that is an operating decision to resolve. An AI system cannot make the disagreement disappear by producing an answer more quickly.

• Trigger: the event that starts the work.
• Input: the information available and its source.
• Decision: the rule or judgment required.
• Output: the artifact or action the next step needs.
• Owner: the person accountable when it fails.

Look at the spaces between the boxes

Many improvement opportunities sit between recognizable tasks. The team may know how to review a document but have no agreed way to request a replacement. They may know how to book an appointment but not who owns a reschedule. A system can make those gaps more visible without being allowed to resolve all of them.

Mark waiting time separately from handling time. Record repeated requests for the same information. Note where a person retypes a field and where another person verifies it. Sometimes the right fix is to standardize the intake form or choose one source of truth. Those changes can make later automation simpler and more reliable.

Design the unhappy path alongside the happy one

For every automated step, write down at least one plausible failure. A document is unreadable. A service is unavailable. Two records look like the same customer. The receiving system rejects the update. Decide whether the workflow should retry, request clarification, or stop and ask someone.

For a pilot, visible stopping is often preferable to an invisible workaround. Give the exception a reason, an owner and the information needed to resolve it. Do not allow a generic failed status to become another queue that the operator must investigate from scratch. The exception itself is part of the product.

Choose the smallest change that improves the whole flow

Once the map is clear, choose a bounded intervention. You might collect required fields at intake, prepare a review packet, or update a second system after an approved change. Identify the downstream beneficiary: who receives better information, and what can they do with it?

Test with a representative set of cases and record the differences. Include empty fields, duplicate requests and a deliberate pause. If the workflow cannot stop safely, it is not ready to own a meaningful business action.

Use the downloadable worksheet to map the current flow and the proposed one side by side. Keep the original version. It gives you a reference for evaluating what changed, and a practical route back if the pilot creates more work than it removes.