How to map a business workflow before building software

Software does not remove a vague process. It gives the vagueness a user interface.

Before choosing a CRM, commissioning an admin platform or automating a handoff, map what really happens. The useful map is not the official procedure on a slide. It is the path work takes on a busy Tuesday when information is missing and the usual approver is away.

Pick one outcome and two boundaries

Name the workflow as a completed outcome: "turn an accepted quote into a scheduled job," not "sales-to-ops integration."

Set a clear start and finish. For example:

• start: customer accepts the quote;
• finish: crew, equipment and time are confirmed and the customer is notified.

Without boundaries, the exercise becomes a map of the entire company.

Observe the work

Interviewing is helpful, but people omit familiar details. Watch several real cases and collect the artefacts: forms, emails, spreadsheets, labels, calendar entries and messages.

Ask:

• What triggers this step?
• Who performs it and who can substitute?
• What information do they need?
• Where does that information come from?
• What decision is made?
• What record changes?
• How does the next person know it is ready?
• What happens when the normal case fails?

The UK Government Service Manual recommends mapping the whole user problem, including steps outside the organization's own service, so that teams do not optimize one touchpoint while leaving the wider task broken. GOV.UK Service Manual

Draw the current state in lanes

Use one lane per actor or system. Put the steps in time order. Mark:

• manual entry;
• decisions;
• waits and queues;
• handoffs;
• duplicate records;
• system changes;
• approvals;
• exceptions and rework.

Keep the first version plain. Boxes, arrows and notes are enough. If the diagram needs its own legend and a trained facilitator to read it, it will not survive contact with the team.

Add data to the map

For each critical field, record:

This exposes a common problem: several spreadsheets each behave as the source of truth for the same thing.

Measure friction before proposing automation

For a sample of real cases, measure elapsed time, active staff time, error rate, rework and volume. A ten-minute task repeated twice a month may not deserve software. A two-minute task repeated 4,000 times might.

Also record consequence. A rare permissions error can matter more than hours of routine copying.

Map exceptions deliberately

Ask staff for the last five cases that went wrong. Examples might include a duplicate customer, an expired quote, missing tax status, an unavailable technician or a refund after partial delivery.

Software designed only for the happy path pushes exceptions into private notes and side spreadsheets. Identify which exceptions can be prevented, which need a guided resolution and which should remain a human decision.

Design the future state after the evidence

Now remove unnecessary steps, clarify ownership and test whether a policy can be simplified. Automate only after that.

For each proposed automation, state:

• trigger;
• required input;
• business rule;
• output and destination;
• permission;
• failure behaviour;
• human owner;
• audit record;
• way to reverse or correct it.

Discovery is meant to understand the problem and constraints before committing to a solution. GOV.UK's guidance explicitly warns teams not to start discovery with a preconceived solution. GOV.UK discovery guidance

Validate with the people in the lanes

Walk through the map with frontline staff, a manager and whoever handles exceptions. Use a recent real case. Ask each person to point out what is missing or idealized.

The deliverable is not the diagram. It is a shared, testable description of work: who decides, which data matters, where failure appears and what improvement would be worth building.

Source check

Government service-design guidance supports whole-problem mapping, discovery and experience maps. The detailed fields in this article are an implementation template, not a mandated notation or standard.

Sources

• GOV.UK Service Manual: Map a user's whole problem
• GOV.UK Service Manual: Creating an experience map
• GOV.UK Service Manual: How the discovery phase works
• 18F: De-risking custom technology projects