How to automate my current workflow

Follow one real item from start to finish

Choose a completed request, order or project and reconstruct its journey. Ask the people who handled it what they received, what they checked and what they passed on. Then inspect a delayed or corrected case. The difference often reveals the work missing from a tidy process diagram.

For each step, record the owner, source system, start condition, output and typical waiting time. Avoid collecting private customer details when an anonymised example will explain the process. Microsoft’s process-map documentation shows how activity, transition and timing views can help examine a process; a simple shared table can also be enough for a first review.

Separate the work from the delay

A ten-minute task may spend two days waiting in an inbox. Automating the ten minutes alone will not remove that delay. Identify whether the next person lacks information, does not know the work is ready or has no agreed deadline to act.

Define handoff conditions explicitly. “Ready for setup” might require an accepted scope, a project owner and an approved start date. A workflow should not move the item forward simply because a file was uploaded. The receiving person needs a complete, current package.

Worked example: enquiry to project setup

In an illustrative service business, an enquiry arrives, a coordinator gathers details, a specialist confirms scope and an administrator opens a project. The current delay occurs when the administrator receives a message saying “go ahead” without the final scope or owner.

The first automation can prepare a setup request only after those required fields are present. It creates a draft project checklist, attaches the approved scope and assigns a review. Pricing and contractual acceptance remain with the responsible people. This is a proposed process pattern, not a claim about a completed client project.

Choose the smallest useful change

Keep stable parts of the process in place. If the team already uses a task board, connect to that board rather than introducing a second one. Replace a repeated transfer or completeness check before trying to automate every decision.

Use a stable work-item ID across the connected systems. Store the current status and links to the source evidence. If two applications disagree, define which owns each field. A project date should not bounce endlessly between tools because both treat their copy as authoritative.

Test without creating duplicate work

Run sample cases through a test destination or a mode that prepares outputs without sending them. Compare the proposed result with the current process. Include a changed scope, a reopened request, a duplicate event and a failed connection. Confirm that a later edit invalidates any approval tied to an older version.

Before cutover, choose which items use the new route. For example, only new requests after an agreed time may enter it while existing work finishes in the old process. Make that boundary visible to the team. A recovery plan should explain how to pause new runs and resume incomplete items without repeating completed actions.

Watch the handoff after launch

Measure end-to-end completion time as well as active effort. Track incomplete handoffs, corrections, duplicate records and unattended exceptions. Ask the receiving person whether the new output is easier to use. Review the first representative set of cases before widening the scope.

Document the workflow in language the team understands: what starts it, what it changes, what it never decides and who responds when it stops. The most useful next improvement comes from observed friction in the running process, not from adding more automated steps for their own sake.

Your ready-to-use checklist

Make the next step clear.

Sources and notes

Sources checked on October 19, 2026.

• Microsoft: understand a process map

  Explains activity, transition, timing and rework views in process mining.