Issue 01 : The Single Owner SOP System
An operational case study from Brightfield Commerce, exploring the decisions, constraints, and outcomes behind the issue.
Overview
Company : C02 - Brightfield Commerce
Revenue : $48M
Industry : DTC E-Commerce
Primary Dimension : D01 - Process Documentation Coverage
Characters : Cathy Miller, Maya Chen, Thomas Wu, Hannah Brooks
PART A
The SOP Library that nobody used
Three weeks into her job at Brightfield Commerce, on a Wednesday afternoon, Cathy Miller, the operations coordinator, received an order return request she couldn’t answer.
The customer had received a $340 gift order and wanted to return it. The original purchaser was unreachable. Cathy opened the operations wiki and searched for the returns process. She found a Notion page titled Returns Handling SOP v2 FINAL (updated).
It was a seven-page document listing the standard return process, the holiday return policy, the process for damaged items, and a section called “edge cases” that set out seven exceptions, none of which covered her situation.
She read all seven pages. She still didn’t know what to do. She reached out to Hannah Brooks, the operations manager. Hannah opened the wiki herself and reached the same conclusion in under a minute.
Hannah messaged Maya Chen, Brightfield’s VP of Operations, on Slack. Maya answered in two sentences. Hannah passed them on, and four minutes after Cathy had come to her, Cathy was back on track.
Maya had been back from lunch for 45 minutes when that message arrived.
In that time, she had answered six messages from her team, a busier stretch than usual. Each one was the kind of question documentation exists to answer. None had been answered by it.
Maya had known this was a problem since her second month at Brightfield.
Brightfield had 83 documents in its operations wiki, the product of 18 months of work across three teams. It was less wrong than unusable: hard to find, hard to trust, and mostly unowned.
The SOP documentation had been built for the moment of its creation, not for the moment someone would need it, under time pressure, with a customer waiting. Every quarter since her second month, Maya had planned to fix it.
The first quarter brought an inventory audit. The second quarter brought a new fulfilment partner. The third quarter brought peak season. The documentation problem was always the thing she would get to after the current fire was out.
She ran an experiment. For two weeks, she logged every question escalated to her that the wiki should have answered. She counted 34 questions. She then checked each one against the documentation library.
In 31 of the 34 cases, a document existed that was supposed to answer the question. In 27 of those 31, the document failed at least one test: it couldn’t be found in under 90 seconds, it was materially out of date, or it required reading more than 400 words to find a 20-word answer.
The documentation mostly didn’t fail because the content was wrong. Where it was materially out of date, the cause was structural too: nobody owned keeping it current. It failed because the structure around the content was wrong.
Of Brightfield’s 83 wiki documents, only 14 documents had a named author. Nine of those were written by people who had since changed roles or left the company. In practice, only three documents were genuinely maintained. The rest were institutional memory in the process of becoming institutional fiction.
The most expensive operational problem is not the one that breaks publicly. It is the one that drains quietly. One avoidable question at a time.
Most mid-market operations functions have documentation.
What they lack is documentation that works at the moment someone needs it — when the person is time-pressured, mid-task, and cannot afford to spend seven minutes reading to find a 20-word answer, or to discover that it isn’t there.
The gap between ‘We have a wiki’ and ‘we have a wiki people actually use’ is mostly structural, not a content problem. Better writing alone will not close it. It requires a different architecture.
PART B
Documentation without an owner is institutional decoration, not institutional memory.
Enterprise companies typically have knowledge management platforms, information architecture specialists, and dedicated wiki governance teams. When their documentation fails, they often commission a new platform, hire a knowledge manager, and run a documentation sprint with executive sponsorship.
Mid-market companies have a Notion account, a shared Drive folder, or a Confluence installation someone set up two years ago that nobody fully configured. When their documentation fails, the instinct is the same as at any scale:
- Write more documentation
- Get the content right
- Fill the gaps
- Reorganize the folders
It produces newer, better documentation that is also unused. Because the problem was never only the content.
What does the same problem look like at $48M, with one VP of Operations and a team where the fastest path to an answer is two taps on Slack?
What The Data Shows
Brightfield Commerce is a fictional company in the Headroom HQ Universe. The figures below come from its case file. They show how the failure works. They do not show how often it occurs.
Maya Chen’s two-week escalation audit, logging every question escalated to her that the wiki should have answered, produced these findings.
Of 34 escalations logged across two weeks, 31 had a document in the wiki that was supposed to answer them. In three cases no document existed. In 27 of the 31 escalations, the document failed at least one of three tests:
- It couldn’t be found in under 90 seconds
- It was materially out of date
- It required reading more than 400 words to find a 20-word answer
A document could fail more than one test. In the other four, the document passed all three, and the question was escalated anyway. Nothing on the page said whether it could be trusted.
Of Brightfield’s 83 wiki documents, only 14 had a named author. Nine of those 14 documents were written by people who had since changed roles or left the company, which left five with an author still in the role.
Three of those five documents had been reviewed in the past six months.
The three documents were the only ones genuinely maintained: an author still in the role and a review in the last six months. The other 80 documents were documentation in name only. They may once have been accurate, and nobody could confirm they still were.
The new-hire test: Could a new hire use this document to execute this process without asking anyone for help?
In a spot check of the five most recently accessed documents, chosen because they were the ones people actually used, three failed it. The pattern is mostly structural, not individual. Documentation systems don’t fail because teams stop caring.
They fail because ownership decays invisibly, format drifts from the user’s actual needs, and the document lives where the reviewer expects to find it rather than where the executor is working when they need it.
The Single Owner SOP System
There are four structural reasons SOP libraries fail at the mid-market scale. None of them are content problems. Fixing content without fixing structure produces a better-written version of the same unusable system.
Failure 1 → Documentation was built for compliance, not execution
Many SOP libraries are created to satisfy an auditor, to respond to a near-crisis, or to accommodate a new manager’s request for documentation.
Documentation written to satisfy those purposes tends to be written in passive voice, with exhaustive caveats, no decision trees, and few specific tool names — technically complete and hard to use at the moment of execution.
The fix is to write the documentation for the person who is executing the process at the moment they need help, not for the person reviewing it later.
It requires a different author who is the actual executor, not their manager, and a different format with a numbered checklist, not prose narrative.
Failure 2 → Documentation lives where nobody works
When Cathy needed the returns process, she was working in Gorgias, Brightfield’s customer service tool.
The SOP was in Notion. The path to the SOP required switching applications, searching for the document, and reading through seven pages. The path to her manager was two taps on Slack.
Documentation needs to live where the work happens, linked directly from the relevant screen in the tool where the process is executed.
If a process crosses tools, it lives in the one where its first step happens and is linked from the other tools. There is one copy. Two copies become two versions.
An SOP linked inside Gorgias is one click from the work. An SOP in a wiki gets opened when someone remembers it exists.
Failure 3 → No ownership and no update cadence
Every document in a documentation system is in one of two states:
- Owned
- Abandoned
Owned documents have a named person accountable for keeping them accurate and a specific date for the next review. Abandoned documents have neither. A document that is under revision or waiting for review is still owned.
The transition from owned to abandoned documents is invisible. It happens as the named author changes roles, as processes evolve past what the documentation describes, and as the company grows past the stage the document was designed for.
The fix is simple. Every document has one named owner and one specified review date. No exceptions.
The owner is accountable for accuracy, not for policy. When a step needs a decision the owner can’t make, the escalation path names who can. Documents without an owner are either assigned one within seven days or archived.
Archived documents are deleted within 30 days, unless a legal, contractual, or audit requirement says to keep them. Those move to a records archive outside the SOP library. The library shrinks. The usefulness grows.
Failure 4 → Format ignores the actual user
The person executing a process under time pressure is not in a state to read three pages of context and background. They need a specific answer to a specific step at that time.
The format that works at the moment of execution is a numbered checklist with decision branches, verb-first steps, specific tool navigation instructions, and if-then language at each decision point. Every branch ends in an action or in the escalation path.
It should not include narrative context or explanation of why the process exists. That context belongs in the wiki, and the SOP links to it. A warning that changes what the executor does stays in the step. The SOP is the checklist.
The Single Owner SOP System applies all four fixes simultaneously:
- Every SOP is created as a numbered checklist. Context is linked, not embedded
- Every SOP has one named owner who is the person who executes it most frequently, not their manager
- Every SOP has a review date calibrated to usage frequency
- Every SOP has one home, in the tool where the work starts, linked from the other tools it touches
The Complete SOP Template
- Process Name (One specific process. Never combine two or more processes)
- Owner (Name, not role. Roles change, names make ownership real)
- Last Reviewed (The date of the last review. Set the next one by usage: every 90 days for processes run weekly or more, less often for rarer ones. If the next review has passed, treat this SOP as stale until the owner confirms it remains current)
- Trigger (What initiates this process? Be specific)
- Steps (Numbered, verb-first, tool-specific)
- Completion Definition (How do you know the process is done?)
- Escalation Path (Whom to contact if a step cannot be completed as written, or needs a decision the owner can’t make, and within what timeframe?)
What Maya's SOP Rebuild Produced
Maya gave the operations team one assignment:
Document the three processes you execute most frequently, in checklist format, with your name and today’s date at the top. No template. No other instructions.
Where two people listed the same process, the one who executed it most often became its owner, and the other moved on to their next process.
Then she tested every draft with the new-hire test. She gave the document to someone who had never done the process and watched them execute it. Any step that required clarification came back to the owner for a rewrite.
Maya handed out no template. The one above is what the drafts that passed the test had in common.
Brightfield went from 83 documents to 22 documents. Not 83 improved documents, but 22 documents, because that was how many processes were genuinely high-frequency and worth standardizing at this stage.
Every old document was either replaced by one of the 22 documents or archived under the ownership rule.
90-Day Results
- Questions escalating to Maya dropped by 61%, counted by the audit’s rules and compared as daily averages.
- Thomas Wu, the operations analyst, had been the team’s heaviest escalator. He counted every question he sent up or across the team, not only those that reached Maya. His daily rate fell from 4 questions per day to 1.2.
- New-hire orientation, measured as the days until a new hire worked their queue without asking for help, dropped from 17 days to 9 days.
The rebuild changed several things at once: who wrote the documents, what format they took, who owned them, and how they were tested.
The results measure the system together, not any one rule. The documentation improved not because Maya wrote better documentation, but because the right people wrote the right format with the right accountability structure attached.
Dimensions
Apply
- The SOP Library Working Example
- Building an SOP Library your team actually uses
- The SOP Library Audit and Rebuild Kit
Comments ()