Whether it should exist as-is
Is this workflow worth repeating, or is it a workaround for an upstream decision?
Field Note
SOPs can document the mess instead of removing it
SOPs help when the workflow is worth repeating. They add drag when the workflow is unclear, outdated, or owned by nobody.
Documentation can make work easier to teach and repeat. It can also turn an unclear workflow into official-looking confusion. The fix may be right. The sequence may be wrong.
Visible symptom
The same questions keep coming back.
Repeated questions, inconsistent delivery, founder explanations, team requests for documentation, and case-by-case work all point toward a documentation problem. The founder may feel like the business cannot scale because too much context is trapped in conversations.
That read may be partly right. If the workflow is stable and useful, SOPs can help. But if the workflow keeps changing because the offer is unclear, the intake is inconsistent, the owner is missing, or the trigger is vague, documentation may preserve the drag instead of removing it.
Fix founders usually consider
Write the process down before the team asks again.
The normal response is to create SOPs, record walkthroughs, build a knowledge base, document onboarding, assign someone to write processes, or turn founder explanations into checklists. That work feels responsible because it moves knowledge out of the founder’s head.
The problem is that many undocumented workflows are not just undocumented. They are unresolved. The team asks because the path keeps changing. The founder explains because the decision before the SOP is not standardized. The SOP request may be pointing at a workflow that should be changed before it is captured.
Sequence risk
A documented unclear workflow is still an unclear workflow.
An SOP can describe what happens today. That does not mean today’s workflow should become the model. If the work starts at the wrong trigger, changes owner halfway through, depends on hidden founder approval, or changes based on package scope that was never settled, the SOP may make the wrong path easier to repeat.
That can create a false sense of progress. The team has a document, but the document still needs exceptions. The founder still answers edge-case questions. Delivery still changes from one situation to the next. The sequence should inspect the workflow’s shape before the business invests in documenting it at scale.
Fictional example
An onboarding SOP request points upstream.
Fictional example: A founder wants SOPs for onboarding because each new client feels different. The team asks what to request, when kickoff should happen, who sends the first message, and when the founder should review the account. The founder wants the whole onboarding process documented so the questions stop.
In this fictional sample review, documentation may help later. But the onboarding decisions are not standardized because package scope and client readiness are unclear before kickoff. Some clients arrive with clean materials. Others need scope clarification. Some need founder review because the sale promised custom work. An SOP written too early would document several workflows without deciding which workflow should exist.
What to inspect first
Before documenting the workflow, decide whether the workflow deserves its current shape.
Owner of each step
Who owns the step, who reviews it, and who handles the exception path?
Trigger for starting
What event starts the workflow, and what must be true before it begins?
Decisions before the SOP
Which package, readiness, qualification, or approval decisions happen before the checklist starts?
Founder gap-filling
Where does the founder still interpret, approve, translate, or rescue the workflow?
Repeatability
Which parts happen the same way often enough to document without turning exceptions into policy?
How a Bottleneck Audit maps it
The audit separates documentation work from workflow work.
A Bottleneck Audit would map the workflow, owner, trigger, inputs, decisions, exceptions, and founder fallback points before treating SOPs as the answer. It would ask whether the workflow is stable enough to document or whether the drag sits in scope, readiness, handoff, role clarity, or decision rights.
The output is a priority sequence: what should be clarified, redesigned, or documented first; which SOPs are worth writing now; and which workflows should wait until the upstream decisions are cleaner.
Manual route review