You are the bottleneck. Every refund decision, every supplier email, every “wait, how do I do that again?” message in the team chat lands back on you. Your store can only grow as fast as the number of decisions you can personally make in a day, and right now that ceiling has your name on it.
What’s in This Article
The numbers say you are not alone. The 2025 COSBOA Small Business Perspectives Report found 57% of Australian small business owners have hit burnout, 76% report stress or anxiety, and 65% have had their sleep disrupted by the business. While the average Aussie employee is working fewer hours, plenty of founders are still grinding 70-hour weeks. The cause is rarely a lack of effort. It is that the entire operation lives inside one head: yours.
The fix is not another VA, another app, or another late night. It is a documented operating system. Brands that push past seven figures are not run by smarter founders. They are run by founders who wrote down how the work gets done, then handed it over. This is the SOP playbook we use with eCommerce Circle members to get the business out of your head and onto the page, so the store can run without you in every loop.
Why “I’ll Document It Later” Keeps You Stuck at the Same Revenue
Documentation feels like overhead, not growth. So it sits at the bottom of the list behind the next campaign, the next product drop, the next fire. Months pass, the business gets more complex, and the gap between what you know and what your team can do quietly widens.
That gap is expensive. Research from Time etc found entrepreneurs spend roughly 36% of their working week on admin tasks. A McKinsey study put the time knowledge workers lose hunting for information at about 1.8 hours every day. Interact’s research is starker again: 19.8% of business time, a full day every working week, is wasted just searching for the information needed to do the job. When that information only exists in your head, every day you are off is a day the business stalls.
Look at the businesses that scaled past the founder. McDonald’s is not famous for its burgers. It is famous for its operations manual. A 17-year-old in any country can produce a consistent product because the process is documented down to the gram and the second. That manual, not the food, is the actual product the franchise sells.
Amazon is the same story in a different industry. Jeff Bezos banned slide decks in favour of six-page written narratives and standardised its processes so tightly that the company scaled to hundreds of millions of orders without the founders touching each one. The documentation is the moat. Your store does not need you to work harder. It needs you to write down what only you currently know.
Part 1: Run an SOP Audit Before You Write a Single Word
Do not try to document everything at once. That is the mistake that kills the project in week one. Instead, find the 20% of tasks that eat 80% of your week and your team’s mistakes, and start there.
For one week, log every repeated task as it comes up. Drop each into one of four buckets: Daily, Weekly, Monthly, or Triggered (things like a chargeback, a stockout, or a damaged delivery). Then rank them on two filters that actually matter:
- Frequency. How often does this happen? A daily task compounds faster than a quarterly one.
- Cost of getting it wrong. If a junior does this unsupervised, how badly can it hurt the customer, the cash, or the brand?
A daily, high-risk task that still only you can do is your number one SOP. For most Aussie Shopify stores the first ten usually include processing a refund, fulfilling and adding tracking, answering a “where is my order” ticket, building a Klaviyo campaign, reconciling a supplier invoice, and running a product launch. That top-ten list is your documentation backlog. If you have not yet worked out which tasks should leave your plate entirely, our founder time audit and delegation framework is the right place to start.
Part 2: Capture the Process, Do Not Write It From Scratch
The single biggest reason SOPs never get made is that founders imagine sitting down to write a manual. You do not have to. The fastest way to document a task is to record yourself doing it once, then let a tool turn that into a step-by-step guide.
The tool we point most members to first is Scribe. It captures your clicks and screenshots automatically while you do the task, then builds the guide for you. Here is the exact setup:
- Install the Scribe browser extension for Chrome or Edge and create a free account.
- Open the task you want to document, for example issuing a refund inside your Shopify admin.
- Click the Scribe icon and hit Start Capture.
- Do the task exactly as you normally would. Scribe records each step and grabs an annotated screenshot as you go.
- Click Stop. In seconds you have a numbered guide with screenshots, no manual writing required.
- Tidy the step labels, redact anything sensitive, add a one-line “why” at the top, then share the link or embed it in your library.
If you want testing, sign-offs, and onboarding workflows baked in, Trainual does that natively, though it carries a setup cost and is better suited once your team is past a few people. For a small, scrappy team, Notion is free, flexible, and perfectly good as a home base, and Loom is ideal for nuanced tasks where watching beats reading. The rule that matters more than the tool: capture first, polish later. A rough SOP that exists beats a perfect one that never gets written.
Part 3: The Anatomy of an SOP People Actually Follow
Most SOPs fail because they read like legal documents. Yours should read like a recipe a stressed person can follow at 9pm on a Saturday with a queue of tickets in front of them. Clarity beats completeness.
Every SOP you write should include these parts:
- A verb-led title. “Process a Refund”, not “Refunds”. The reader should know what they will be able to do.
- Owner and last-updated date. Who keeps this current, and when was it last checked.
- Trigger. The exact moment this SOP gets run. “A customer requests a refund within 30 days.”
- Definition of done. What “finished and correct” looks like, so quality is not a matter of opinion.
- One action per step. “Click Refund”, not “Handle the refund process”. Numbered, with screenshots.
- Edge cases. “If the order is outside the 30-day window, do X.” This is where the real knowledge in your head lives.
- Escalation. “If you are unsure, message Paul. Do not guess.” A clear off-ramp prevents expensive improvisation.
Write for the newest, least experienced person who will ever touch the task. If a brand-new hire can follow it on day two without asking you a question, the SOP is done.
A Worked Example: The Refund SOP Most Stores Get Wrong
To see why structure matters, take the most common SOP of all: processing a refund. Left undocumented, it produces wildly different outcomes depending on who is on shift. One person refunds instantly to keep the customer happy and quietly bleeds margin. Another argues the toss and earns a one-star review. Neither is following a standard, because there is not one.
A documented refund SOP removes the guesswork. The trigger is clear: a customer requests a refund within your stated window. The steps are exact: verify the order in Shopify admin, confirm it falls inside policy, check the item is not on the final-sale list, issue the refund or store credit per the decision tree, then send the templated confirmation. The edge cases are spelled out: faulty goods follow Australian Consumer Law and are refunded regardless of the window, while change-of-mind requests outside the window are offered store credit instead.
The result is consistency. Every customer gets the same fair answer, your margin is protected by a rule rather than a mood, and a brand-new hire can run the process correctly on day one. That is the difference a single well-built SOP makes, and you have dozens of these decisions running through your store every week.
Part 4: Build a Library, Not a Pile of Documents
Forty random docs scattered across Google Drive, Slack, and someone’s desktop is worse than nothing, because people stop trusting that the right version exists. The library is what turns individual SOPs into a system.
Three rules keep a library usable as it grows:
- One home. Pick a single source of truth, whether that is Notion, Trainual, or a structured Google Drive, and ban competing copies. If it is not in the library, it does not exist.
- Organise by function or by the 10 P’s. Fulfilment, Customer Service, Marketing, Finance, Product, Suppliers. A new team member should be able to guess where a process lives.
- Use a naming convention. “[Area] – [Action]”, for example “CS – Respond to WISMO ticket”. Consistent names make search actually work.
The payoff is speed. A good library turns the answer to “how do I do this?” from a ten-minute interruption of you into a ten-second self-serve link your team drops into a chat reply. Multiply that across a week and you have just handed yourself back hours you did not know you were spending.
Part 5: Make SOPs the Spine of Your Onboarding
This is where the return on the whole exercise shows up. SOPs are not just reference docs, they are the fastest onboarding tool you will ever build. The data here is hard to ignore: structured, documented onboarding has been shown to cut onboarding time by up to 70%, lift new-hire retention by 82%, and get people to full productivity around 50% faster. Yet 36% of companies still run no structured onboarding at all, which is exactly why a documented store hires and scales faster than its competitors.
Turn your library into role-based paths. A new customer service hire gets the six CS SOPs, a short checklist, and a quick quiz on your refund policy. From day one they are productive on the simple, repeatable work, and your senior people are freed from babysitting. Assign the path, set due dates, and track completion. Trainual does this natively, but a Notion checklist with checkboxes works just as well when you are small.
There is a compounding effect here too. Every SOP you add makes the next hire faster and cheaper to bring up to speed, because most of their training already exists. If you are about to make your first real hire and want to get the sequence right, our first hire playbook walks through exactly who to bring on and when.
Part 6: Keep Them Alive, Or They Quietly Rot
An out-of-date SOP is more dangerous than no SOP, because people follow the wrong steps with full confidence. A library is not a one-off project. It is a living asset that needs a light maintenance habit.
- Give every SOP an owner. Ownership, not authorship, keeps a doc current. The owner is responsible for it being right, even if someone else wrote it.
- Tie review to a cadence you already run. Add five minutes per area to your monthly business review: has anything changed? Our monthly business review playbook is a natural home for this check.
- Update on change, same day. New app, new supplier, new policy means the SOP gets updated that day, not “soon”. The cost of stale instructions is paid by your customers.
- Make it everyone’s job. Anyone who spots a gap fixes the doc or flags it. The library belongs to the team, not just to you.
The Mistakes That Quietly Kill SOP Projects
Plenty of founders start documenting and stall within a fortnight. The failures are predictable, and avoiding them is half the battle.
- Trying to boil the ocean. Attempting to document all 34 tasks at once guarantees burnout on the project itself. Ship your top ten, then add one a week.
- Writing for yourself. An SOP that assumes the reader already knows your shorthand is useless to a new hire. Write for someone who started yesterday.
- No owner, no review. A library with no maintenance habit is out of date within a quarter and trusted by no one.
- Perfectionism. Waiting until an SOP is flawless means it never ships. A rough draft your team can use today beats a polished one that lives in your drafts forever.
- Hiding it. If the library is not one click from where the work happens, people will ask you instead. Link it everywhere.
Get these right and the system sustains itself. Get them wrong and you will be back to answering the same questions in three months, wondering why the documentation never stuck.
The Compound Effect: From Operator to Owner
One SOP saves you a handful of interruptions. A full library changes what your business actually is. When the work is documented, you can hire juniors to run senior playbooks, delegate without the knot in your stomach, and take a week off without the store wobbling. The knowledge no longer walks out the door when a key person leaves.
There is a bigger prize too. A store that depends on the founder for every decision is a job you cannot quit. A store that runs on documented systems is an asset you can scale, step back from, or one day sell, because a buyer is purchasing a system, not your personal presence. The founders who escaped the 70-hour week did not find more hours in the day. They moved the knowledge out of their heads and into a system the team could run without them.
Your 6-Part SOP Build Checklist
Run this in order. Do not skip the audit to jump to writing, and do not write a single SOP you have not first proven is worth documenting.
- 1. Audit. Log every repeated task for one week. Rank by frequency and cost of getting it wrong. Pick your top ten.
- 2. Capture. Record each task once with Scribe, Loom, or a screen recording. Do not write from a blank page.
- 3. Structure. Give every SOP a verb-led title, owner, trigger, definition of done, one-action steps, edge cases, and an escalation path.
- 4. Library. One home, organised by function or the 10 P’s, with a consistent naming convention so search works.
- 5. Onboard. Turn SOPs into role-based training paths with checklists and a quiz. Assign, set due dates, track completion.
- 6. Maintain. Assign an owner to each SOP and review them inside your monthly business review. Update on change, same day.
Inside eCommerce Circle, building the operating system that runs your store without you is one of the core pillars we work on with every member. If you want a second opinion on where your business is still trapped in your head, let’s talk.
