What to Map First When Everything Looks Broken

When everything in a business looks broken, start business process improvement by mapping the process that runs most often and touches money most directly, which in most companies is the path from a customer saying yes to the cash arriving. Not the messiest process. Not the one people complain about loudest. The one with the most repetitions and the shortest line to revenue, because that is where a fix pays for itself fastest and where a mistake costs the most per week of delay.

That answer feels wrong to most founders, so it is worth walking through why the instincts it overrules are unreliable.

Why the loudest problem is the wrong starting point

Complaints are a record of friction, not of cost. The process people moan about is the one that annoys them daily, and annoyance correlates poorly with money. A clunky expense process generates noise every week and costs almost nothing. A quoting process that quietly loses a deal a month generates no noise at all, because the deals that leak away never come back to complain.

There is a second problem with following the noise. The loudest process is usually loud because it crosses the most people, and a process that crosses many people is the hardest place to learn how mapping works. You will spend your first attempt refereeing disagreements instead of drawing the flow. Better to earn that fight after a win or two.

So the volume of complaint tells you where morale is leaking. It does not tell you where to point your first map.

Frequency times money: the boring arithmetic that picks for you

The value of understanding a process is roughly how often it runs multiplied by what each run is worth, plus what each failure costs. That arithmetic almost always lands on the same few candidates.

The revenue path first: enquiry to quote, quote to order, order to delivery, delivery to invoice, invoice to payment. It runs constantly, every step leaks in a different way, and small percentage improvements compound across every deal you do. If a week of mapping finds one place where quotes stall for three days, you have bought that time back on every future sale.

Then whatever process only one person can run. Not because it is broken today, but because the day that person is off sick it becomes your most broken process instantly, and you will be mapping it in a panic with the one expert unavailable. Mapping it now is cheap insurance, and it is often a short job because a single-owner process tends to be a straight line.

Onboarding, whether of customers or staff, comes third. It runs less often, but every run shapes months of what follows, and it is where the gap between the official version and the real version is usually widest.

Map the real version, not the official one

Whichever process you pick, the trap is the same: mapping what is supposed to happen rather than what happens. The SOP says quotes go out within two days. The person who writes them knows they wait for a price check from someone who is in meetings all Tuesday. Draw the first version and your map is fiction with boxes.

The fix is to build the map from the people who run the work, then compare it with the documents rather than starting from them. This is exactly the gap abi. Clone is built to expose, as a free working model of how your business actually runs: it treats a document as a claim to be checked against what the team says, keeps the two apart, and shows you where accounts differ, which is usually where the process is broken. You can build the first map by hand in minutes, and it stays free with no card and no expiry.

One person's account is a start. Two accounts of the same process that disagree are better, because the disagreement is the finding.

What not to map yet

Leave anything that runs a few times a year. Annual budgeting, the office move, the audit. The cost of those being messy is capped by how rarely they happen, and a map of a rare process is stale by the time it next runs.

Leave anything you already know you are about to kill. Mapping a process you plan to replace documents a corpse. Decide first, map what survives.

And leave the whole exercise alone if the broken thing is actually one obvious fire. If cash runs out in six weeks or your largest customer is halfway out the door, mapping is a way of feeling productive while avoiding the frightening call. A map is for when the problem is fog. When the problem is a fire, you can already see it, so go and put it out. That is the honest limit of this whole approach: process work rewards businesses whose problems are diffuse, and does very little for the ones in acute trouble.

Under about five people the same logic applies for a different reason. A conversation over lunch covers what a map would, and the overhead is not worth it yet.

How rough is rough enough

The first map should be embarrassing. Eight to twelve steps, the names of who does each one, and the places where work sits waiting. That is all. Resist the urge to buy notation, to standardise symbols, or to capture every exception on the first pass. Exceptions are the second pass, once the spine of the process is agreed.

You are done with the first map when the people who run the process look at it and correct it. Correction is the point. A map nobody argues with has not been read, and the corrections are where the improvement candidates live: every "actually, we skip that step" and every "that goes back to Dan twice" is a lead.

Then pick the single worst wait or repeat, fix that one thing, and measure whether the process got faster. One fixed step in a mapped process beats a transformation programme in an unmapped one. When it works, take the next process on the same arithmetic: most runs, closest to money, or one owner. The order rarely surprises anyone in hindsight. The value is that you stopped starting with the loudest thing.