Last month I opened a document called Booking Intake Process v4. Fourth revision, so we had clearly gotten serious at some point. The first instruction told the reader to paste the client's details into a spreadsheet we stopped using in January.
Nobody on that team was being lazy. That is the part I want to be clear about.
SOP drift is not a discipline problem. It is a detection problem. The work changes because the person running the business changes it, usually in one Slack message or one sentence at the end of a call, and the document never hears about it.
Why founder-led businesses drift faster than anyone else
In a bigger company, somebody's whole job is keeping documentation current. In a founder-led service business, you are the process department and you are also the delivery. You change the intake flow on a Tuesday because a client asked for something. You stop chasing small deposits because the chasing took longer than the deposit was worth. You switch follow-up from email to text because email gets ignored.
Every one of those is a good decision. None of them got written down.
Because of that, the doc stays frozen at the version of you that existed when you wrote it. That person is not the person delivering the work now. And here is the part that costs real money: a new hire reads the doc, follows it exactly, and does the job wrong with total confidence. They trusted you. The document lied to them.
I have trained more than 90,000 people on software and systems since we started teaching in 1998, and the pattern is always the same. A manual is accurate the day you write it. It starts decaying the day after.
Step one: capture what actually happens, not what you think happens
You cannot detect drift from the document. The document is the thing that drifted. You have to read the work.
The good news is that most of the work is already being recorded. Calls are transcribed. Walkthroughs get recorded on Loom. Questions get answered in Slack or typed into the CRM notes. That is a paper trail of your real process, and it is sitting there ignored.
Pick one process. Follow-up after a discovery call is a good one, or client onboarding, or how a proposal gets priced. Then pull the last 30 to 60 days of evidence for that process only.
The setup I use: Fathom for call transcripts, Loom for any walkthrough a team member records, and one dedicated folder in Google Drive or an Airtable base where it all lands. Nothing clever. The point is that the evidence collects itself instead of depending on someone remembering to write it down.
Two rules. One process at a time. And no new tool that requires extra work from a person, because that person is you.
Step two: run the comparison
This is the part that used to take a consultant two weeks and now takes about twenty minutes.
Take your current SOP, paste it into Claude or ChatGPT alongside the transcripts and notes from that 30 to 60 day window. Then ask four specific questions:
- Which steps in this SOP did nobody perform?
- What did people do that is not in this SOP at all?
- Where did the order of steps change?
- Which instructions are vague enough that two people did them two different ways?
That fourth question finds the real damage. Ambiguity is where a process quietly forks, and once it forks you have two versions of your business running side by side with no way to compare them.
If you want this running on its own, Zapier or Make can push new transcripts into the folder automatically and trigger the comparison on a schedule. It takes me a minute to set up and then it is boring, which is exactly what you want from infrastructure. We set this up live in the workshop if you would rather see the folder and the prompt than read about them: https://workshop.mastermindshq.business
Step three: the thirty minute monthly review
A drift report is useless if it sits in a folder. Put a recurring 30 minute block on the calendar with whoever owns that process, and walk the report line by line. Every item gets one of three decisions.
Bless it: the new way is better, so update the SOP to match reality. Fix it: the new way is a shortcut that will hurt later, so coach the person back to standard. Delete it: the step no longer matters, so remove it and stop pretending.
Here is the part people skip. The person who actually does the work has to be in that room. If you write the SOP alone and then hand it to people, you are writing fiction with better formatting. Every process I have ever documented that actually stuck came out of a conversation with the person who was already doing it.
You will get through this in 30 minutes if you keep it to one process per month. Twelve processes a year, and your documentation is honest again. That alone does more for business systemization for founders than any tool you could buy.
Some drift is your business getting better
This is the idea I keep coming back to.
If your only response to drift is correction, you are freezing your business at whatever it looked like the day you typed the doc. Your best operator invents a shortcut on a Thursday because a client needed something. That shortcut might be the upgrade. It might be the thing you should have been doing all along.
The detector's job is not compliance. It is making sure a change gets a decision instead of becoming an accident. That is the whole point. It is also the difference between a business that systemizes and a business that just owns a lot of documents.
Because of that, the founders who scale are rarely the ones with the longest manuals. They are the ones who notice, fast, when the manual and the work stopped agreeing. If you are still the bottleneck for every decision in your own business, this is one of the cheapest places to start loosening that grip, and it works the same whether the work is client calls, print jobs, or wedding weekends.
If this resonates and you want to build this kind of infrastructure in your own business, the Mastermind is where we do the work live. You can learn more at mastermindshq.business.