Map your enquiry-to-delivery process before choosing software

Before you compare tools, map what happens now. Start where an enquiry arrives and finish where the customer accepts the finished work. Include the waits and the jobs that do not go to plan. Software may well help later, but by then you will know exactly which step you need it to improve.

This guide shows you how to map a business process using one recent job. It includes a blank template you can copy, a completed illustrative map and a simple way to check the map against what really happens. You do not need special software or formal notation. A document, a spreadsheet or a whiteboard is enough.

1. Pick one service and set the start and end

Map one service at a time. If you run installations and repairs differently, choose the one that causes the most friction and map that first.

Then agree the boundary:

• Trigger: what starts the process. For example, "an enquiry arrives through the website, email or phone".
• End condition: what finishes it. For example, "the customer accepts the delivered work and the job is closed", or "the enquiry is closed with a recorded reason".
• Out of scope: anything you are deliberately leaving out. If invoicing and payment are handled separately, say so and note where that process is described. Do not stretch this map to cover chasing payment.

Writing down the end condition matters more than it looks. Without one, the map tends to stop at "quote sent", which can be where some of the hardest handoffs begin.

If enquiries are going missing before anyone even responds, start with our guide to managing customer enquiries. It covers capturing each enquiry, the first reply and follow-up. This map picks up the whole route from enquiry to delivery and focuses on where work changes hands.

2. Walk through one recent job with the people who did it

Choose a real job from the last few weeks and go through it with the people who handled it. Ask what they actually did, in order:

• What happened first, and who did it?
• Where did the information come from, and where was it recorded?
• What did you wait for, and how did you know the wait was over?
• What did you do that is not written down anywhere, such as copying details between systems or sending a reminder from your own phone?

Record what happened, not the process you wish you had. If the owner's version and the team's version differ, write both down and mark which is observed and which is assumed. That difference can be one of the most useful things on the page.

Refer to the job by a reference rather than the customer's name. The map is about the work, not the person, so it does not need contact details or other personal information. The UK regulator's guidance on data minimisation says personal data should be adequate, relevant and limited to what is necessary for your purpose. A process map can be completed without any.

3. Put the steps in order and mark the decisions

Turn your notes into a sequence. You only need four kinds of mark:

• Start and end: where the process begins and every way it can finish.
• Action: something a person or system does, written as a verb and an object, such as "prepare the quote".
• Decision: a question with labelled answers, such as "Requirements complete? Yes / No". Every answer needs somewhere to go.
• Arrows: what comes next.

Keep waiting visible. "Wait for the customer to confirm the date" is a real step, even though nobody is busy during it. A wait is a point where a job can stall without anyone noticing.

Stop adding detail when another step would not change who does something or what they need. "Open the quote template" rarely needs its own box; "check the quote against the agreed scope" might.

4. Show where ownership changes hands

A handoff happens whenever responsibility moves from one person or role to another. For each one, write down:

• From and to: who is passing the work on, and who is receiving it.
• Information required: what the receiver needs to act without chasing.
• Acceptance signal: how the receiver confirms they have taken it on, such as a reply, a status change or a note on the job.
• Who follows up: who acts if the work is not accepted or is sent back.

Sending a message does not transfer ownership. A notification tells someone that work exists; it does not mean they have read it, agreed it is complete or taken responsibility for it. Until the receiver accepts, the sender still owns the job.

5. Add the routes that don't end in delivery

Not every enquiry becomes a job. A map that only shows the happy path can hide the cases that lead to chasing. Add at least these three exceptions:

1. Requirements are missing. Who asks the customer, and what happens if they never reply?
2. The quote is declined or goes unanswered. Who follows up, when, and when is the enquiry closed?
3. Delivery is blocked or the customer disputes acceptance. Who records the problem, who tells the customer, and how does the work return to the main route?

For each exception, show where it ends: back into the main flow at a named step, or closed with a recorded reason. "No answer" should never drift silently into delivery or simply disappear.

6. Copy the process mapping template

Copy these three tables into a document or spreadsheet. Fill the boundary card first, then the step register, then the handoff check. Use roles rather than names where you can, so the map still works when someone is away.

Boundary card

Step register

For decisions, write the question in the second column and list each answer with its next step in the last column, for example "Yes: step 4. No: exception A".

Handoff check

7. Example: a completed map for a service job

The map below is a hypothetical illustration, not a ScalePass client or a real job. It shows one service business's route from enquiry to accepted delivery, with three roles and the exceptions from section 5.

Text version of the map

1. Start: Enquiry received.
   • Then continue to step 2.
2. Action: Clarify what the customer needs. Accountable: Enquiry owner.
   • Then continue to step 3.
3. Decision: Requirements complete?
   • If no: Ask the customer for what is missing. Details arrive: back to step 2. Nothing by the agreed check: close and record the reason. Accountable: Enquiry owner.
   • Yes: continue to step 4.
4. Action: Prepare and send the quote. Accountable: Quote owner.
   • Then continue to step 5.
5. Decision: Customer decision?
   • If declined: Close and record the reason. Accountable: Quote owner.
   • If no answer: Follow up on the agreed date. Reply received: back to step 5. Still no answer: close and record the reason. Accountable: Quote owner.
   • Accepted: continue to step 6.
6. Decision: Handoff: does the delivery lead accept the brief as complete? Handoff from Quote owner to Delivery lead.
   • If not accepted: Delivery lead lists what is missing. Quote owner fixes it: back to step 6. Accountable: Quote owner.
   • Accepted: continue to step 7.
7. Action: Schedule and do the work. Accountable: Delivery lead.
   • If blocked: Record the blocker, tell the customer and agree the next check. Cleared: back to step 7. Accountable: Delivery lead.
   • Work finished: continue to step 8.
8. Decision: Customer accepts the work?
   • If an issue is raised: Resolve the issue, then ask again: back to step 8. Accountable: Delivery lead.
   • Yes: continue to step 9.
9. End: Job closed.

Out of scope: invoicing and payment, mapped separately.

Here is how the main handoff from that map looks in the handoff check:

In a small team, one person may hold more than one of these roles. The handoff still exists: it is the moment the same person switches from selling the job to planning it, and the same checks apply.

8. Check the map against reality

A map is only useful if it matches what happens. Before you change anything:

• Walk it with a colleague. Ask someone who does the work to follow the map with the original job, then with one invented case for each exception. Where they say "that's not what we do", correct the map.
• Check every decision has an exit. Each answer should lead to a step or a recorded close.
• Check every handoff has an acceptance signal. If the only signal is "they'll see the email", mark that handoff as unclear.
• Mark the bottleneck. Put a note where work most often waits, is re-entered or is sent back. Describe what you saw, such as "brief returned twice for missing access notes". Do not claim it caused lost work or revenue unless you have evidence.

Keep this current-state map separate from any improved version. If you draw the process you want, save it as a new version with its own date, so you can compare the two.

9. Choose one change before choosing software

Pick one change from the map and give it an owner and a date to check whether it worked. Possible first candidates include:

• Remove re-entry: stop copying the same details between two places by hand.
• Clarify acceptance: agree what the receiver must confirm at one handoff.
• Connect an agreed step: link two tools you already use, at a step whose rule and owner are now clear.

Then test the change against the same normal case and exceptions, and update the map. If a tool would genuinely help, you now know which step it must support, who owns it and what "done" looks like. That gives you a much better basis for choosing one.

Common questions

How much detail should a process map have?

Enough to show who does what, what they need, and where work waits or changes hands. If an extra step would not change any of those, leave it out.

Do I need process mapping software?

No. A table, a whiteboard or sticky notes work. Diagramming software can make a map easier to share and edit, but it will not tell you what actually happens.

What if one person wears several hats?

Map the roles, not the people. If one person moves from quoting to delivery, the handoff still exists and is still worth checking. It is simply easier to skip.

How do I map exceptions?

Treat each one as a decision with a labelled answer. Show who owns it and where it ends: back into the main route at a named step, or closed with a reason.

How do I know the map matches reality?

Walk it through with the people doing the work, using a real past job and invented exception cases. If they can follow it without saying "we don't do that", it is close enough to start improving.

ScalePass helps service businesses connect the tools and steps they already use. We start with one agreed, scoped improvement and keep what already works.

If your map shows a step that needs connecting, Explore connected systems.