Map the workflow before you automate the work

Choose a narrow process with a visible finish

"Automate operations" is too broad to map usefully. "Turn an approved quotation into a delivery-ready project" has a clear beginning and an observable outcome. Set the boundary so the team can agree what belongs inside the first version. Adjacent processes can remain manual while the central handoff becomes dependable.

Microsoft’s planning guidance starts with the business problem, users and objectives rather than treating automation itself as the goal. Apply that principle by writing a short problem statement. For example: accepted work reaches delivery without the information needed to schedule it. That statement is more useful than a requirement to connect two applications.

Map the work people actually do

Ask someone to walk through a recent example from start to finish. Include email, spreadsheets, informal approvals and the small checks that experienced staff perform without mentioning them. The official procedure may describe an ideal route while the actual work depends on a person noticing that something is missing.

For each step, record the input, responsible person, system used and output. Mark waiting time separately from hands-on time. A process can contain only ten minutes of administration and still take several days because nobody knows the next handoff has arrived. Automating typing will not necessarily resolve the delay.

Make decisions and exceptions visible

Draw the branch points in plain language. Is the request complete? Does it need approval? Is the customer already in the system? Every branch needs a destination, including "not enough information". A map that contains only successful cases leaves the most demanding work outside the design.

Use Microsoft’s process-mapping and automation-opportunity guidance as a technical reference, but keep the initial workshop accessible. A shared whiteboard is enough when the goal is agreement. Process-mining software can later help investigate recorded activity; it cannot supply missing business ownership or explain every informal decision.

A practical mapping exercise

Imagine a distributor whose approved quotes are manually copied into a project tracker. During mapping, the team discovers that product availability is checked after the customer has already been promised a date. The most useful improvement is moving the availability check earlier, not simply copying the quote faster.

The revised workflow validates required information, requests the availability check and only then creates the delivery task with a confirmed target date. Incomplete requests return to a named sales owner. This hypothetical example illustrates a common design lesson: process order can matter more than the number of steps automated.

Use this workshop checklist

Keep the first session focused on one representative case and one difficult exception. Ask participants to distinguish what must happen from what has merely become habit. Record unresolved policy decisions rather than allowing the future automation to make them accidentally.

• Name the event that starts the process and the evidence that finishes it.
• List each input, owner, system and handoff.
• Separate working time, waiting time and avoidable rework.
• Describe exception routes and who resolves them.
• Remove unnecessary steps before deciding which actions to automate.
• Choose one measurable outcome and a realistic pilot boundary.

Turn the map into a buildable brief

Capture one baseline before changing the process. Count a sample of completed cases, note how often information is returned for correction and estimate where the elapsed time accumulates. You do not need a perfect measurement system. You need enough evidence to compare the pilot with the problem you originally set out to solve.

For each proposed automated action, specify the information required, the permission needed and the consequence of failure. Mark decisions that remain human. The resulting brief should let someone explain the process without opening the automation tool. If it depends on unexplained arrows, it is not yet specific enough.

Finally, ask the people who will receive the output to review the design. An automation can delight the person handing work over while creating confusion downstream. The best first build makes one complete journey easier to understand, operate and recover, giving the business a sound foundation for the next improvement.