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 : Brightfield Commerce
Revenue : $48M
Industry : DTC E-Commerce
Primary Dimension : D01 - Process Documentation Coverage
Secondary Dimension : D09 - Onboarding Effectiveness
Characters : Cathy Miller, Maya Chen, Thomas Wu
PART A
The SOP Library that nobody used
Cathy Miller, the operations coordinator, had been at Brightfield Commerce for three weeks on Wednesday morning when she received an order return request she couldn't answer.
The customer wanted to return a $340 gift order. 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" listing 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 her manager. Her manager messaged Maya Chen, Brightfield's VP of Operations, on Slack. Maya answered in two sentences. Four minutes later, 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. Each one could have been answered by existing documentation. None of them were.
Maya had known this was a problem since Month 2. Brightfield had 83 documents in its operations wiki, which was the product of 18 months of work across three teams. It wasn't wrong or outdated, mostly. Just unused.
The SOP documentation had been built to satisfy the moment it was created, not for the moment someone would need to use it under time pressure with a customer waiting.
Every quarter, Maya had planned to fix it.
The first quarter brought an inventory audit. The second quarter brought a new fulfillment partner. The third quarter was peak season. The documentation problem was always the thing she'd get to after the current fire was out.
She ran an experiment. For two weeks, she logged every question escalated to her that should have been answerable from the wiki. 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 either couldn't be found in under 90 seconds, was out of date, or required reading more than 400 words to find a 20-word answer.
The documentation didn't fail because the content was wrong. It failed because the structure 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 unanswerable question at a time.
Mid-market operations functions universally 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.
The gap between 'We have a wiki' and 'we have a wiki people actually use' is structural, not a content problem. It cannot be fixed by writing better documents. It requires a different architecture entirely.
PART B
Documentation without an owner is institutional decoration, not institutional memory.
Enterprise companies have knowledge management platforms, information architecture specialists, and dedicated wiki governance teams.
When their documentation fails, they 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 structure.
This produces newer, better documentation that is also unused. Because the problem has never been 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
Maya Chen's two-week escalation audit at Brightfield Commerce, logging every team question that should have been answered by existing documentation, produced findings that hold consistently across operations functions at the $20M–$75M revenue stage.
Of 34 escalations logged across two weeks, 31 escalations had a document in the wiki that was supposed to answer them. In 27 of those 31 cases, the document failed on one of three specific dimensions:
- 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.
Of Brightfield's 83 wiki documents, only 14 documents had a named author. Nine of those fourteen documents were written by people who had since changed roles or left the company.
In practice, only three documents were actively maintained. The other 80 documents were documentation in name only — accurate at some point in the past and unverifiable in the present.
The new-hire test: Could a new hire use this document to execute this process without asking anyone for help? Three or more of the five most recently accessed documents failed it.
The pattern is 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
Most 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 is written in passive voice, with exhaustive caveats, no decision trees, and no specific tool names — technically complete and practically useless 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.
An SOP linked inside Gorgias gets used. 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 has 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.
The transition from owned to abandoned 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.
Documents without an owner are either assigned one within seven days or archived. Archived documents are deleted within thirty days. 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.
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.
It should not include narrative context or explanation of why the process exists. That context belongs in the wiki. The SOP is the checklist, nothing else.
The Single Owner SOP System applies all four fixes simultaneously:
- Every SOP is created as a numbered checklist only.
- 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 lives inside the tool where the work actually happens.
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 (If this date is more than 90 days old, 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 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 templates. No instructions on format or length.
Then she tested every draft with the new-hire standard. 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.
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.
90-Day Results
- Questions escalating to Maya dropped by 61%.
- Thomas Wu's (Operations Analyst) daily escalation rate fell from 4 questions per day to 1.2 questions per day.
- New-hire orientation time dropped from 17 days to 9 days.
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 ()