.png)
You don't get to choose whether your team has processes. You only get to choose whether those processes are documented, or whether they're just living in someone's head, waiting for that person to have a bad week.
I spent years running ecommerce operations before I ever thought about this as "systems" or "SOPs" or any of the vocabulary that gets thrown around now. At the time it just felt like firefighting. A launch would go sideways, someone would ask what happened, and the answer was almost never that someone was careless. It was that nobody had actually agreed on how the thing was supposed to work in the first place.
I've broken enough launches to know this isn't theoretical.
That's a systems problem. Most teams treat it like a people problem. Which is part of why it keeps happening.
Think about your last product launch. Someone updated the homepage. Someone scheduled the email. Someone checked that inventory was actually synced. Someone set the discount code, and, if you got lucky, someone tested it at checkout before customers did.
Now ask yourself: if that person took PTO next week, could anyone else run that exact launch without texting them?
For most teams, no. And I don't think that's really a knock on anyone. Processes just form around whoever handles a task most. Nobody sits down and designs them on purpose. They accumulate quietly, and they stay in one person's head until something forces them out into the open. Usually not on a schedule you'd pick.
Every ecommerce team I've worked with has had one. The person who just knows how the Klaviyo flows are wired. The person who remembers which metafields control the size chart. The one who understands, somehow, exactly how the ERP behaves when a SKU gets discontinued mid-cycle, and nobody else can explain it without calling them.
It feels like a strength until it isn't. That person can't really take a vacation. They can't get promoted without leaving a hole nobody else can fill. And people leave. When they do, you don't just lose an employee. You lose an entire piece of institutional memory, all at once, usually with two weeks' notice.
I watched this happen at a brand doing eight figures a year. The person who understood their collection logic left, and it took the team three weeks to figure out which collections were manual, which were rule-based, and why certain products had been pinned to the top of a category page since 2022. None of it was written down anywhere. It was just something she knew.
Here's where I'll push back on the usual advice, though: documentation doesn't mean bureaucracy. I think "SOP" has a bit of a branding problem. People hear it and picture a giant binder nobody actually opens.
That's not what I'm talking about. Some things genuinely deserve a full written process with screenshots and edge cases. Other things just need a two-minute Loom walking through the steps. A checklist with eight boxes is sometimes more useful than a document with eight pages, because someone will actually use it under pressure. The goal was never documentation for its own sake. The goal is consistency. Getting the same result whether it's your best person doing the task or someone's first week on the job.
If your SOP takes thirty minutes to read before someone can launch a product, you've probably overcomplicated it.
Think about everything your team repeats every month. Product launches. Promotion setup. Homepage updates. Inventory changes. Email QA. Redirects. Subscription configuration. Analytics validation. None of these are one-off projects. They're recurring operational work, which means they deserve recurring systems.
The bigger your store gets, the more expensive undocumented work becomes.
It's easy to say "watch out for inventory errors." Fine. But the mistakes that actually eat a week of your life look more specific than that.
A Recharge selling plan that never got updated for a new SKU, so subscribers keep getting billed for a product that's been discontinued. Collection sort order that quietly reset itself after a merchandising update, so your best sellers are buried under clearance items during a campaign. A product that launched without Search & Discovery boosts, so it's invisible in on-site search for the first critical week.
A missing GA4 event, so your team spends a Monday arguing about attribution numbers that were never being recorded correctly to begin with. A Klaviyo flow still pointing at the old PDP URL, so half your welcome series sends customers to a 404. A metaobject that wasn't published before launch, so the size guide component just doesn't render.
A bundle SKU that never got mapped correctly in the ERP, so it shows in stock everywhere except the warehouse. A redirect created two days after Google already crawled the dead URL, so you're stuck waiting weeks for reindexing. A subscription frequency that defaulted to monthly instead of the intended six-week cycle, and nobody notices until customers start complaining about getting product too often.
None of these are dramatic. They're small, boring, easy-to-miss steps. That's exactly why they slip through, and exactly why a checklist beats talent here. Talented people miss checklist items too. That's not a talent problem. It's a memory problem, and checklists don't have memory problems.
I've seen a mispriced bundle stay live for forty minutes during peak Black Friday traffic because one missed checkbox let it through. Forty minutes doesn't sound like much. It was enough.
New hires learn a job one of two ways. They either shadow someone for three weeks and absorb things unevenly, or they follow a documented process and ask specific questions about the parts that don't make sense yet. The second one is faster. It's also a lot less dependent on how good a teacher their trainer happens to be, which, let's be honest, varies a lot.
When a new coordinator has an actual written process for launching a product, they don't need someone hovering over their shoulder the entire time. They follow the steps, flag what's confusing, and get corrected on specifics instead of reconstructing the whole workflow from scratch through trial and error.
This one's underrated. Watch how much time gets lost to that exact question showing up in Slack, over and over, phrased slightly differently each time. Someone stops what they're doing to answer it. Sometimes the answer changes depending on who you ask, because it was never actually agreed on. Just repeated informally by whoever did it last.
When it's documented, nobody has to ask. The answer already exists, and it's the same answer every time.
One thing I noticed after moving into management was that I spent less time doing the work and more time wondering whether the work had actually been done. Did we check inventory before the drop? Did anyone QA that email before it hit the full list? Did the redirect actually get created? Good systems remove that uncertainty.
A checklist turns that hope into a status. Checked or not checked. Much easier to manage than trying to hold a dozen moving pieces in your head during the busiest weeks of the year.
When something breaks on a team without documented systems, the instinct is to ask who screwed up. Understandable reaction. Doesn't fix anything, though. The same mistake shows up again with a different person next time, because nothing about the underlying process actually changed.
The better question is what should get added to the process so it doesn't happen again. A missed metafield becomes a new line on the launch checklist. A pricing error becomes a required second person sign-off before any promo goes live. The mistake stops being something to assign blame for and starts being useful.
Documentation isn't really about replacing people, if I'm honest. It's about making your best people more valuable, because they're not stuck answering the same five questions every week.
Document it. Run it. Watch where it breaks. Improve it. Run it again.
Sounds almost too simple to matter. But run that loop consistently for six months and the difference is real. Launches that used to take three people scrambling now run cleanly with one person and a checklist. New hires ramp in days instead of weeks. Mistakes that used to repeat every quarter just stop, because they got engineered out the first time they happened.
The goal was never fewer mistakes, exactly. It's making sure you only make each one once.
I've never seen a team outgrow good systems.
Every SOP you create buys your team a little more consistency. Every checklist removes another opportunity for an expensive mistake. Every documented process makes onboarding easier, launches smoother, and your best people more available for work that actually moves the business forward.
That's what an ecommerce operating system really is. Not a binder full of documentation. A business that doesn't depend on remembering everything.
If you're looking at your own team right now and realizing most of what keeps things running lives in someone's head, that's a pretty normal place to start from. It's also fixable. We've put a lot of that thinking into the Platt Development Playbook library, worth a look if you're trying to get your team's systems out of memory and onto paper.
