In this hypothetical service-business example, a new account manager opens the onboarding guide, follows the steps, and sends a client the wrong request.
The guide says to collect the deposit before booking the kickoff. Last month, the business changed that rule for returning clients. Their kickoff can now be booked while billing confirms the account.
The founder remembers the change. Two experienced employees remember it. The guide remembers something else.
This is a hypothetical example, but it raises a useful question: when your team follows the written process, are they following the business you run today?
A standard operating procedure, or SOP, can be easy to find and neatly formatted while giving the wrong instruction for the work in front of someone.
When that happens, the next message may land with you: “Which version should we follow?”
The knowledge was captured. The responsibility for keeping it useful was left unclear.
A date cannot tell the whole story
It is tempting to judge a playbook by its last update. An old date looks like neglect. A recent date feels reassuring.
Neither tells you enough.
A two-year-old rule may still be correct. A guide updated yesterday may cover the wrong service, client group, or location. Even a correct guide can fail to help if your team keeps opening an old attachment.
Separate three questions before deciding what to fix:
- Is it accurate? Do the instructions reflect the agreed way of working?
- Does it apply here? Is this the right rule for this client, service, role, and point in time?
- Can people reach it? Does the link they actually use lead to that instruction?
These questions lead to different repairs. Rewriting a sound process will not fix a broken link. Changing a date will not explain a client exception.
In the onboarding example, the team needs a visible distinction between new and returning clients. Without that context, two people could follow the same guide and reach different conclusions about whether it applies.
The founder becomes the missing change history
Consider what happens if every uncertain instruction sends someone back to you.
You remember why the rule changed, which clients it affects, and who agreed to it. Answering the question feels faster than repairing the guide, especially with a client waiting.
The immediate problem gets solved. The next employee still has the old instruction.
That is one way founder dependency can survive a documentation project. Your team has the steps, while you still carry the changes and exceptions in your head.
In the Execution Gap Framework, moving from Documented Systems to Team Execution requires people to understand and use the shared standard. A document that needs your memory to make sense of it leaves part of that work unfinished.
The useful shift is to include the instruction whenever you change the process. If a change affects what someone should do, updating the place they look for guidance belongs in the same piece of work.
Give maintenance a home
Who is responsible for keeping the onboarding guide useful after its original author moves on?
In a 2025 episode of The Not-Boring Tech Writer, Kate Mueller describes caring for documentation and eventually passing that responsibility to someone else. Her perspective is a reminder to plan for continuity beyond the person who first wrote the guide. Read the episode transcript.
For your business, that means naming an owner who has the time and authority to keep corrections moving. Assign a backup and make the responsibility part of any role handover.
The owner does not need to write every sentence. People who use the process should have a simple way to flag a problem and suggest a correction. Someone must also be able to settle a disputed business rule and approve the change.
Otherwise, a named owner can become another queue that everyone waits behind.
Make the feedback concrete. “This guide is wrong” gives the owner little to work with. “Step four asks returning clients for a deposit, but the agreed process changed last month” identifies the mismatch and where to look.
Let the work tell you when to review
A calendar reminder can help, but it should not be the only thing that prompts a review.
If a tool change breaks step three on Tuesday, a quarterly review is a long way off. Useful triggers include a changed client commitment, a new approval rule, a role handover, or a user reporting that the instruction no longer works.
Knowledge-Centered Service, or KCS, offers a related practice: improve knowledge as people reuse it, with a quick response to feedback. It treats use as an opportunity to check quality. Read the Consortium for Service Innovation's guidance.
Our practical adaptation combines three habits: review when the work changes, respond when users find a mismatch, and schedule checks based on how the process changes and what an error would mean. That is a suggested starting point, not a universal review schedule.
Also consider what you are maintaining. In a product-management forum discussion, participants describe changing screen instructions and question whether every interface detail belongs in an SOP. These are individual accounts, but the distinction is useful. Read the discussion.
“The account manager confirms the client's billing status” is an operating responsibility. Instructions for finding a particular button are tool help. Keeping those connected but distinct can make it easier to update the part that changed without rewriting the business rule.
Check one playbook your team already uses
Choose a recurring process where a wrong instruction would cause meaningful rework. Resist starting with the whole library.
1. Follow the real link
Ask a teammate to open the guide they would use for the next task. Watch where they start. A bookmark, chat attachment, or onboarding checklist may lead somewhere different from the folder you expect.
2. Make its scope visible
Check that the guide says who and what it covers, when the rule takes effect, and which exceptions need a different instruction. In our example, the distinction between new and returning clients belongs beside the billing step.
3. Name the owner and the correction route
Record the owner, backup, and place to report a mismatch. Agree who can approve a changed rule. Give that person enough time and authority to respond.
4. Connect an update to a real change
Choose the events that should trigger review. Add the affected guide to the change checklist so updating it is part of finishing the work. Include the reason for the change in a short note.
5. Make the current version easy to recognize
Keep one shared working link for each applicable guide. Mark replaced copies clearly and point readers to the current version. Preserve history your business needs, while making clear which instructions people should use now.
6. Check what the next person receives
Have someone try the changed instruction. Can they tell which rule applies and what to do next? Tell the person who reported the problem what changed. After a few uses, check whether the same confusion returns.
The meaningful result is that the next person receives a usable answer. A fresh date alone does not show that.
Where AI fits
Before adding AI to this process, separate the state of your knowledge from the way an assistant finds and uses it.
On Practical AI, Rajiv Shah discusses challenges that emerge when AI systems encounter real users and larger document collections. His observations show why old content is only one possible explanation for a poor answer. Read the episode transcript.
For a wrong instruction, check the source behind the answer. Did the assistant use the applicable guide? Did it find the relevant section? Does the answer match what that section says?
Keep a person responsible for deciding disputed rules and approving changes. An answer that sounds confident cannot establish what your business has agreed to do.
These podcasts and forum accounts offer practitioner perspectives, not proof of savings or better business outcomes. Use the ideas to test a small change in your own operation.
Keep the next answer out of your head
Return to the new account manager in our example. The better outcome is simple: they open the guide, see the rule for returning clients, and know how to proceed.
You can still make the decisions that belong with you. Your team has a dependable place to find the decisions already made.
That creates room for founder freedom: fewer routine moments in which work needs your memory before it can move.
When the work changes, what makes the playbook change with it?
Use the Knowledge Capture Assessment to reflect on where useful operating knowledge still depends on a person being available.
A quick SOP maintenance check
Copy these prompts into the process you choose to review. Ask the people doing the work to fill in the answers together.
Process and scope: What work does this guide cover, and which situations need a different rule?
Working link: Where will the next person look for the current instruction?
Owner and backup: Who can resolve a mismatch and approve a correction?
Review trigger: Which change, exception, or reported problem should prompt a check?
Next verification: Who will try the updated instruction and report whether it works?
Continue reading: Questions that capture expert judgment.
Explore PlaybookOps SOPs and operational playbooks.