Start small. Fix a workflow people actually repeat.

1. Follow a real piece of work.

Start with a recent example rather than a diagram of how the process is supposed to work. Trace an enquiry, support request, or internal report from its arrival to its final destination. Ask who touches it, what they copy, which decisions they make, and where it waits.

Write down the actual trigger and the point at which the work is complete. If those boundaries are unclear, the first useful step may be clarifying the process rather than automating it. Ask the people performing the work to confirm the map.

2. Choose a bounded, repeatable candidate.

Look for work that happens often enough to observe, uses reasonably consistent inputs, and has a clear result. A good first candidate might create a record from a validated form and notify its owner. A broad instruction to automate sales is too open-ended to test.

Consider the exceptions before choosing. If most requests require a different interpretation, narrow the scope to one category. Keep unusual cases on the existing manual path until you understand them.

• A named owner can explain what a correct result looks like.
• Representative examples are available for testing.
• A failed run can be spotted and handled without losing the request.

3. Record the starting point.

Observe a representative period and note request volume, time spent on handling, waiting time, and common corrections. Separate active work from elapsed time: a task can take minutes to process but wait hours for an owner.

Choose one primary outcome, such as reducing duplicate entry or making ownership visible sooner. Keep supporting measures for quality and exceptions so that faster processing does not hide extra rework downstream.

4. Run a limited pilot.

Define which inputs qualify for the pilot, who reviews the output, and how the team returns to the existing process. Use sample records first, then a limited real scope once the owner has approved the behavior.

Review completed runs and failed runs together. Check for duplicate records, missing information, and notifications that arrive without enough context. A technically successful run is not useful if the receiving person still has to reconstruct the request.

5. Expand only after the handoff works.

Document the trigger, destination, owner, and recovery steps. Agree who will notice when an integration changes and who can pause the workflow. Then compare the pilot with the baseline.

The next step may be another connected task, a better input form, or fewer unnecessary notifications. Expand around a proven process rather than adding complexity simply because the tools allow it.