Map a recurring workflow before buying software

Choose a trigger and a finished outcome

Write a start and finish that someone can observe. “Manage enquiries” is too broad for a first map. “A website enquiry arrives; the enquirer receives an agreed next step and a named internal owner” is more manageable. A boundary keeps the discussion focused without pretending the workflow has no connection to wider work.

Ask what the person receiving the outcome needs to achieve. The GOV.UK Service Manual describes mapping the wider journey, including connections across different people and channels, to understand where a service breaks down. For a small-business exercise, use that perspective to check whether your chosen finish is meaningful to the recipient, rather than just an internal box tick.

Reconstruct what happened in recent cases

Ask the people involved to walk through a few ordinary examples and one awkward exception. Use the records you already hold appropriately: timestamps, task notes, messages and completed documents. Avoid putting client details on an open wall or sharing a whole inbox for the sake of the exercise.

Describe the actual sequence before proposing a better one. People often say “we check the information” when the real process is that one person asks a question in a message and another person remembers to respond. Capture that handover. Include work done outside the main system, because that is often where assumptions and extra checking sit.

• What started this particular example?
• Who acted, and what information did they use?
• Where did work wait, move backwards or get repeated?
• How did the next person know it was their turn?
• What evidence showed the intended outcome had been reached?

Give actions, decisions and waiting their own space

Use a short verb phrase for each action, such as “check request details” or “prepare draft response”. Put a decision in a separate card and record who makes it. Show different routes when the answer changes the next step. You do not need specialist diagram symbols if the team can read the map consistently.

Place waiting points between the actions. Note whether the work is waiting for information, approval or capacity. These are different problems: an incomplete form might need a better request, while an approval queue might need an agreed decision window. Record uncertainties as questions rather than filling them with a guessed process.

Look for a specific source of friction

Read the map from start to finish with the people who carry out the work. Mark duplicated entry, missing information, unclear ownership and decisions that return repeatedly to the owner. Look at the exception route as well as the ordinary one. A tidy main path is not enough if frequent exceptions are handled entirely from memory.

In a fictional workshop-booking example, the organiser copies attendee details from email into a list, then asks the trainer which session has space. The difficulty might be a missing shared capacity record rather than a need for a larger project platform. A current map helps separate that narrow information gap from unrelated frustrations.

Choose one problem that you can describe as an event and consequence: “the trainer confirms capacity only after the draft invitation is prepared, so invitations are rewritten”. This is a better improvement target than “communication could be better”.

Try one change before redesigning everything

Agree a small revised sequence, its owner and the cases you will use to try it. For the workshop example, the change could be to check the maintained capacity record before preparing the invitation. State what you expect to observe: fewer invitations prepared for sessions that cannot accept the booking.

Keep a brief note of what happened, including new difficulties. Do people know which record is current? Who updates capacity when a cancellation arrives? A change is not ready for routine use just because the diagram looks cleaner. Check the handovers in real work and adjust the instructions where people still need to guess.

Use the map to write a practical software brief

If a system change is still justified, list requirements that follow from the tested workflow. You might need named ownership, a visible approval step, controlled document access or a way to export the records. Separate essential functions from preferences and identify who will maintain the system after setup.

Use an ordinary case and an exception as demonstration scenarios when evaluating a possible tool. Ask someone to show the whole route rather than a collection of attractive screens. Include the effort of moving existing information, teaching the team and maintaining the workflow. The map then becomes a shared reference for the decision, rather than another document left behind after a purchase.