Your process documentation is not being ignored. It is at the wrong altitude.
Nobody reads the diagram because it is unreadable, and nobody follows the procedure because it does not say enough. Both problems have the same cause, and it is one of the cheapest things in a business to fix properly.
The single most common mistake in process work is putting detail at the wrong altitude. Too much in the diagram and nobody can read it. Too little in the procedure and nobody can follow it. There are three altitudes, and each has exactly one job.
The three altitudes
Operations grid
- What it shows
- The whole business in lanes, end to end, with metrics and gaps marked
- Who reads it
- The owner, and the advisor
Process diagram
- What it shows
- One process in full, with its decisions, branches and handoffs
- Who reads it
- The advisor, the manager, anyone improving it
SOP
- What it shows
- One step, in hyper detail
- Who reads it
- The person actually doing the work
The person doing the work never opens the diagram. They open the SOP. That separation is the entire point of having both.
A workflow step is one verb and one object
That is the rule that keeps a diagram readable. Open email. Categorize email. Respond to email. Not "handle the customer's enquiry appropriately based on which marketplace it came from", which is not a step, it is a paragraph, and it belongs inside an SOP.
If a box needs a comma to describe it, it is probably two boxes, or it is an SOP hiding in a diagram.
What that looks like on a real process
Take one box from the diagram and answer a single question: how, exactly, does a person do this? Email management is a three step process.
The diagram
The SOP for one box: Categorize email
- 1.Open the email.
- 2.Read which marketplace it came from. Amazon, Walmart, or the website.
- 3.Decide which category it is. Order status, refund, or something else.
- 4.Apply that label in the email system.
- 5.Find the information needed to answer it.
- 6.Respond.
- 7.Archive.
Seven steps for one box. That ratio is normal and it is correct. Write it in simple language and short sentences, with a screenshot wherever a screen is involved. Your reader is competent and has never done this job.
Where detail belongs, by layer
| Layer | Detail level |
|---|---|
| Operations grid | Minimal, visual |
| Process diagram | Structure only, one verb and one object |
| Framework | Short enough to hold in your head |
| Curriculum | Medium |
| SOP | Hyper detailed, with screenshots |
| Exercise handout | Short, one instruction |
A framework written in hyper detail stops being a framework, because its whole value is that someone can recall it under pressure. A ten page model gets read once.
Assume complexity when mapping. Never assume it when publishing.
Capture everything. Every branch, every exception, every decision point. That is what makes the map true. Then publish for the reader. The person doing the work gets the SOP and nothing else. A diagram with five decision gates that the operator cannot read is a thing that got built and never got used, which is the same failure as a system nobody switched on.
The diagram holds the truth. The SOP is what gets executed.
What good looks like
- Every box on a diagram is one verb and one object.
- Every box that a person performs has an SOP behind it, linked from the box.
- No SOP describes more than one box.
- Nobody doing the work needs the diagram in order to do their job.
Want the whole operation mapped, not just one process?
Mapping a business end to end is the first week of an engagement, and it is the part that shows a founder where their time actually goes. The strategy call is a free version of the diagnosis. If you are not ready for that, the community costs nothing.