Ask most founders of a growing ecommerce business what happens if they take two weeks fully offline, and the honest answer is usually "several things break." That's key-person risk, and it's one of the most common structural weaknesses in businesses that are otherwise performing well. Standard operating procedures (SOPs) — written, specific instructions for how a recurring task is actually done — are the primary tool for reducing it, and they're also what makes hiring and delegation work well instead of becoming a slow, frustrating apprenticeship every time.
What actually counts as an SOP
A good SOP is specific enough that someone with reasonable general competence, but no prior knowledge of your business, could follow it and get a comparable result to what you'd get doing it yourself. That's a higher bar than most founders' mental model of "documentation." Compare:
- Not an SOP: "Respond to customer messages promptly and professionally."
- An SOP: "Check the [platform] inbox at least twice daily (morning and afternoon). For a delayed-shipment message, use Template A, checking tracking first to give an accurate updated ETA. For a damage/defect claim, follow the Returns Decision Tree (linked) to determine refund vs. replacement vs. request-for-photo. Escalate to [name] any message involving a threatened chargeback or a legal complaint."
The second version transfers the actual judgment calls, not just the intent. That's the difference between a document that looks like an SOP and one that actually reduces key-person dependency.
What to document first
Not everything needs an SOP on day one — prioritize by a combination of frequency and how much it currently depends on one person's undocumented judgment:
- High-frequency, judgment-light tasks (order processing, standard return handling, routine listing updates) — these are the fastest wins because they're easy to document and immediately delegable.
- High-frequency, judgment-heavy tasks (pricing exceptions, customer service escalations, inventory reorder decisions) — these take longer to document well because you have to make the founder's implicit decision rules explicit, but they're usually the highest-leverage SOPs once written, because they're what currently forces people to interrupt the founder constantly.
- Low-frequency but high-stakes tasks (marketplace account suspension response, a major supplier issue, a data breach or security incident) — worth documenting even though they're rare, precisely because when they happen there's no time to figure out the right process from scratch.
Low-frequency, low-stakes tasks are usually fine to leave undocumented indefinitely — the SOP-writing effort isn't worth it relative to how often the gap actually causes a problem.
A simple SOP format that works for most tasks
- Purpose — one sentence on why this process exists / what it's for
- Trigger — what starts this process (a new order, a specific type of message, a weekly calendar reminder)
- Steps — numbered, specific, in order, including where to find any tools/logins/templates referenced
- Decision points — anywhere the process branches ("if X, do A; if Y, do B"), made explicit rather than left to be inferred
- Escalation — exactly when and to whom this gets escalated instead of handled independently
- Owner — who currently owns this SOP and is responsible for keeping it updated
How to actually write them without it consuming weeks
The biggest barrier to SOP-building isn't knowing the format, it's finding the time. A few practical approaches that work better than blocking out a week to "write all our SOPs":
- Document while you do the task, the next several times you do it, rather than trying to reconstruct it from memory afterward — screen-record it or take notes in real time.
- Have a new hire write the first draft as they learn a role, since the gaps in the existing (possibly nonexistent) documentation are most visible to someone encountering the process fresh; a manager then reviews and corrects it.
- Prioritize ruthlessly — a rough SOP for the 10 highest-frequency tasks beats a polished one for a single low-frequency task.
- Treat SOPs as living documents, not one-time projects. Build a lightweight habit (e.g., updating the relevant SOP any time a process changes, or during a monthly review) rather than a single documentation sprint that goes stale within a quarter.
Where to keep them
A shared, searchable location beats a folder of disconnected documents — a wiki tool, a shared drive with clear folder structure, or a dedicated knowledge-base tool all work, as long as it's actually where the team looks when they have a question, and it's kept current. The specific tool matters far less than two things: everyone who needs an SOP can find it in under a minute, and outdated SOPs get flagged/updated rather than silently ignored.
Common mistakes
- Writing SOPs so generic they don't transfer judgment, leaving the reader with the same open questions the founder would have answered on the spot.
- Documenting once and never updating. A stale SOP that describes a process you no longer follow is worse than no SOP, because it actively misleads whoever follows it.
- Trying to document everything before hiring anyone, rather than documenting the highest-priority processes and improving coverage as the team grows and gaps become apparent.
- No single owner for keeping an SOP current, so it drifts out of date with no one accountable for noticing.
- SOPs that exist but no one knows where to find them — a documentation system with poor discoverability gets the same result as having no documentation at all.
Best practices
- Include screenshots, templates, and links to actual tools rather than describing them abstractly — the easier it is to follow exactly, the less it depends on prior institutional knowledge.
- Review your highest-traffic SOPs on a set cadence (quarterly is common) even without a specific trigger, since processes drift gradually and rarely announce that they've changed.
- Ask new hires directly what was unclear or missing in the SOPs they used to onboard — this is the fastest, most honest source of gaps.
- Pair SOPs with your org chart so it's clear who owns each documented process, not just how to do it.
Checklist
- [ ] List your team's recurring tasks and rank by frequency and how judgment-heavy each is
- [ ] Draft SOPs for the highest-frequency, most delegable tasks first
- [ ] Make decision points and escalation paths explicit, not implied
- [ ] Store SOPs somewhere searchable and shared, not in one person's notes or inbox
- [ ] Assign an owner to each SOP responsible for keeping it current
- [ ] Set a recurring review cadence (e.g., quarterly)
- [ ] Ask each new hire what was missing or unclear once they're ramped up, and update accordingly
FAQ
How detailed should an SOP be — should it cover every possible edge case? No — cover the common cases and the highest-stakes edge cases explicitly, and give clear escalation guidance for anything not covered rather than trying to enumerate every possibility. An SOP that tries to cover every edge case becomes too long to actually be used.
Who should write SOPs — the founder or the person doing the task? Both, ideally: the person currently doing the task (often the founder, early on) knows the actual steps and judgment calls; having someone else (a new hire, a manager) review the draft for gaps and clarity catches things the original person doesn't notice because it's second nature to them.