Is the Process on Paper the One Your Team Actually Runs?

Usually not. Every company runs two processes: the one in the binder and the one that ships the work. They start out the same and drift apart a little every month, and nobody announces the drift.

This is the fourth pattern in Friction, Found, our series on the friction we see most often inside growing companies.

What are the two processes?

The first is the documented one. It gets written into the onboarding deck, trained and audited. Its steps are clean, and they connect.

The second is the real one. It includes the step everyone skips because it slows the work down, the spreadsheet that holds what the system has no field for, and the call to the one person who knows how the unusual cases actually go.

Neither one is wrong. The documented process describes what was intended. The real process is what customers receive.

Why do the two drift apart?

Because the work changes faster than the paperwork. A customer asks for something unusual, and someone finds a way to deliver it. A system has no field for a detail, so a column appears in a spreadsheet. An approval slows down a rush order once, then gets skipped every time after. Each change is small and sensible, and none of them goes back into the binder.

New people learn the real process from whoever trains them, not from the document. Within a year or two, the binder describes a company that no longer exists, and nobody has written down the one that does. We traced how a single fix becomes permanent in when a workaround becomes the process.

Why does the gap matter now?

Because the documented process is the one that gets automated.

When a company decides to automate, the project usually starts from the diagram. The diagram is tidy, it is already approved, and it fits on a slide. Build from it and you get a system that runs a process nobody follows. The team keeps doing the real work around the new system, and now there is one more place to type.

We wrote about that pattern from the rollout side in why nobody uses the software you paid for.

How do you find the real one?

It takes about ten minutes per process, and you do it by watching the work instead of reading about it. Look for three things:

• A step everyone skips. Ask why. The answer usually tells you what the step was meant to protect, and whether anything still needs protecting.
• A spreadsheet that is in no diagram. If it exists, it is holding something the system cannot. Find out what.
• One person who just knows. If the unusual cases go to them, their knowledge is part of the process, whether or not it is written down.

Each of the three is a place where the real process left the documented one. Write them down beside the diagram. That marked-up diagram is the first accurate map you have.

What does the gap look like in your data?

The same split shows up in lists. Some data records what people intended. Other data records what actually happened. In a spreadsheet, the two look identical.

Take an events business. A registration list says who signed up. An attendance list says who came. Load the first as if it were the second, and the follow-ups go to people nobody met, while the walk-ins who did come never hear back.

The lessons carry well beyond events. About half of any new list is usually people you already have, so match it against what you hold before you add anything. People change employers between one list and the next. And the shorthand on a sign-up sheet is almost always worse than the record you already keep, so never let it overwrite the richer one.

What happens when you build from the real one?

The project gets smaller, and the result gets used.

A small trucking carrier is a good example. The plan assumed one kind of customer. Only the real paperwork showed a middleman whose documents carried both the load and the rate, and that changed what the system had to read. We built from the real documents, and the administrative hours came down by about 75%.

Building from the diagram would have produced something clean that missed the paperwork that mattered.

Who should do the looking?

Someone close to the work, paired with someone who can ask why without it sounding like blame. The point is not to catch anyone skipping a step. It is to learn what the skipped step was telling you. We covered one way to run that session in the 30-minute process map your team draws.

Where should you start if you see this in your own company?

Pick the process you are most likely to automate next. Before anyone talks to a vendor, spend ten minutes watching it run, and mark up the diagram with what you see. Ten minutes of watching costs far less than a build that has to be redone.

If you want a second set of eyes on it, bring it to a Friction Audit. Give us 45 minutes and we will map the process your team actually runs, side trips included, and show where the first fix should go. The Leverage Map that comes out of it is yours to keep.