Category: Operations · Read time: 6 min

Operations Systems for Founder Led Businesses That Actually Stick

The Notion graveyard.

Every founder who's been running a business for more than a few years has one. A collection of SOPs that were written with the best of intentions, filed under a folder called "Process" and never opened again. Sometimes they were written by an operations consultant who charged a lot of money for a very tidy document. Sometimes they were written by the founder on a Sunday afternoon in a rare moment of organisational ambition. Either way, they're not being used.

This is not a laziness problem. It's a design problem.

Operations systems that don't get used were never designed to get used. They were designed to exist, to satisfy the feeling that the business has processes, even if no one can find them or remember what they say.

The goal of this playbook is to explain how to build operations systems that your team actually runs to. Six months from now.

Why most SOP projects fail

Before we talk about what works, it's worth being honest about what doesn't, and why.

They're too detailed. The classic SOP project produces a comprehensive, exhaustive document for every process. A 30 step guide to onboarding a client. A 15 page document explaining how to write a proposal. The result is a system that nobody has time to read and nobody will remember to consult when the moment arrives. Detail is not the same as useful.

They're written for an imaginary employee. SOPs are often written as if the person reading them has no context, no judgment and no ability to use common sense. They end up being either patronising or so generic that they don't actually help with the specific situation that came up.

They live in the wrong place. A process document only has value if it's findable in the moment you need it. If someone has to dig through a Notion workspace, a Google Drive, a Confluence wiki and a shared Dropbox to find the SOP for client offboarding, they won't. They'll ask the founder instead. Which is exactly what the SOP was supposed to prevent.

The founder doesn't follow them either. This is the one nobody says out loud, but it's often true. The founder created the SOP, knows it exists, and then does things differently anyway, because they're experienced enough to adapt, or too busy to follow the process, or they've already mentally updated it but not on the document. The team notices. The SOP loses authority.

They were built in a burst of enthusiasm and never maintained. A process document that doesn't reflect how the business actually runs is worse than no document at all. It creates confusion. It erodes trust in the system. And it gives everyone a convenient excuse to ignore it.

The design principles that make operations systems stick

The systems that actually last, the ones that become part of how the team works rather than an artefact of an initiative, share a few characteristics.

They're built around the jobs that matter most, not every job. The first question is not "what do we need an SOP for?" It's "which processes, if they broke down or were done inconsistently, would cause the most damage?" Client onboarding. Proposal creation. Delivery handover. Monthly reporting. Hiring. These are the ones to build first. A business with five excellent, current, genuinely used processes is in a far better position than one with fifty theoretical ones.

They're short enough to read in the moment. A good process document is one that someone can read in two minutes and then do the thing correctly. If it takes longer than that to read, it won't be read. The discipline is in cutting, not adding. What's the minimum someone needs to know to do this well? Write that. Delete the rest.

They include the why, not just the what. A team that understands why a process exists is dramatically more likely to follow it, and dramatically better at adapting it sensibly when the situation is slightly different from the template. "We send the proposal within 24 hours of the call because we've found that close rates drop significantly after 48 hours" is more useful than "send proposal within 24 hours."

They're owned by someone who isn't the founder. Every process needs a named owner, someone who is responsible for it being current, being followed and being improved. The founder owning every process is the same as no one owning them. It has to go somewhere else.

They live where the work lives. If your team works in Slack, the process needs to be accessible from Slack. If they live in a project management tool, the checklist needs to be in the project template. The operations system should sit inside the workflow, not alongside it.

The four step approach we use

When we go into a founder-led business and build an operations system, we do it in four steps. Here's what each one actually involves.

Step 1: Audit, find the real friction first

We don't start with processes. We start with pain.

Where does the founder spend time they shouldn't? Where do things fall through the cracks? Where does the team regularly have to ask someone else how to do something? Where do clients have inconsistent experiences depending on who's working on their account?

The answers to these questions tell us which processes are missing, which exist but aren't being followed, and which are being followed by some people but not others.

An audit doesn't have to be complicated. A conversation with the founder and two or three team members, asking the right questions, surfaces most of what you need to know. What the business thinks its processes are and what actually happens day-to-day are often quite different.

Step 2: Design, build for the user, not the document

The processes we build are always designed with the person who will use them in mind. Not the business, not the founder, the specific person who will run this process on a Thursday afternoon when they're busy and mildly stressed and need to know what to do next.

We favour checklists over narrative documents. We use numbered steps rather than paragraphs. We include decision points where they exist ("if the client hasn't responded in 48 hours, do this; if they have, go to step 4"). We keep them short.

We also design for exceptions, which most SOP projects ignore. The edge cases are where consistency matters most, when something unexpected happens, that's exactly the moment you want your team to have a clear, confident answer rather than defaulting to panic or escalation.

Step 3: Install, wire it into the working day

A process that exists but isn't embedded in the way work happens won't get used. Installation means making it the path of least resistance.

For client onboarding, this might mean a project template in your project management tool that creates every task automatically and assigns them to the right people. For hiring, it might mean a Notion database with a hiring scorecard built in. For monthly reporting, it might mean a recurring calendar event with an agenda template attached.

The goal is to make following the process easier than not following it. When someone has to actively choose to skip a step rather than actively choose to follow one, compliance improves dramatically.

We also install an operating cadence, a rhythm of weekly and monthly meetings that the leadership team runs to. Not long meetings. Short, structured ones with a fixed agenda and a clear purpose. A fifteen-minute daily check-in. A sixty-minute weekly review. A half-day monthly close. These are the heartbeat of an operations system. Without them, even the best processes drift.

Step 4: Hand over, train an owner, not just users

The last step is handover. And handover is not a one-hour training session.

We identify who is going to own the operations function, or in smaller businesses, who is going to own specific processes. We work with them through the system, not just show them where it lives. We make sure they can update it, they understand why each element exists, and they know what to do when something in the process stops working.

The founder's job at this point is to stop being the backup. To actively direct questions to the process owner rather than answering them directly. To demonstrate that the system has authority by following it themselves, visibly, even when they know the answer instinctively.

This last part is harder than it sounds. But it's the part that determines whether the system actually survives the first month.

The three processes to build first

If you're starting from scratch, or rebuilding from a Notion graveyard, do these three before anything else.

Client onboarding. The first six weeks of a client relationship sets the tone for the entire engagement. A consistent, well run onboarding process reduces early churn, increases satisfaction and makes it far less likely that the founder needs to personally manage every new client in.

Delivery handover. The moment where work passes between people, or between stages, is where things most commonly fall down. A clear handover process, what needs to be documented, what needs to be communicated, who is responsible for what from this point, reduces errors, reduces escalations and reduces the founder's involvement in problems that should have been caught earlier.

Weekly team rhythm. One short, structured weekly meeting with a fixed agenda is worth more than a hundred individual processes. It creates visibility, surfaces blockers early, keeps priorities aligned and gives the team a regular moment to ask questions in the right forum rather than throughout the week in scattered messages.

Build these three well before you build anything else. A business with these three running reliably is a business that can scale.

A test worth doing

Here's a simple test for the operations systems you already have.

Pick a process you think exists, let's say client onboarding. Ask a team member to walk you through what they actually do when a new client comes in. Not what the SOP says. What they actually do.

Then ask a different team member the same question.

If both answers are the same, the process works. If they're different, even slightly, you have an operations problem, regardless of what's written down.

Consistency of execution is the only measure that matters. Not the existence of the document.

What this makes possible

The reason we care so much about operations in a growth context is that operations is the ceiling.

A business that is operationally fragile cannot grow sustainably. Every new client adds pressure to an already-stretched system. Every team member who leaves takes institutional knowledge with them that was never written down. The founder can never fully step back because too much depends on their presence.

Fix the operations and the ceiling rises. You can take on more clients without burning the team. You can hand off more to the right people. You can go on holiday, not as a founder who checks emails every hour, but as a person who trusts that things are running without them.

That is what good operations actually delivers. Not better documents. A business that can survive and grow without the founder in every room.

Growth BFF helps founder-led businesses build operations systems that actually stick, then installs the rhythm and ownership to keep them running. Book a free discovery call and we'll take a look at what you've got.