I have had two contractors quit in the same year and only one of them hurt.
The one who hurt didn't leave badly. She gave me three weeks' notice, helped train her replacement on the way out, and was genuinely kind about it. What walked out with her was nine months of context that had never been typed once, including the exact phone script she used when a venue double-booked a Saturday and the client's deposit was already sitting in our account.
Nobody had ever asked her how she handled that. Nobody knew it was a thing that needed handling.
The bus factor in a service business is usually not the founder
Bus factor is the number of people who can vanish before the work stalls. Founders assume they are the one. In most founder-led service businesses I look at, the real bus factor is the contractor running the back office, and the founder finds out the week after the resignation email.
Here's the annoying part. You probably did train her. You spent a month on screen shares and voice notes and "here's how we do invoicing." But the training was a conversation, not an asset. It lived in her head and her inbox, which were the same place.
Because of that, the knowledge evaporated on her last day. Hiring a better VA doesn't fix this. A better VA is a better head to keep it in, which is the same problem with nicer furniture.
What's becoming clearer to me is that the fix isn't the hire. It's a different container for the context.
The four kinds of tribal knowledge that never make it into an SOP
Every service business I've worked inside has the same gaps, and none of them show up in a standard operating procedure, because SOPs describe the happy path.
Per-client tone rules. She knew which three clients needed a phone call before any written update, and which one read emails on Sunday night and hated surprises on Monday. That is not in a doc. It's in a person.
The refusal list. What we don't say yes to, and how we decline it without burning the relationship. She knew which rush jobs to turn down and the exact wording that made it land well.
The real sequence. The official process says invoice after delivery. The real process says invoice the deposit after the site visit, because that client's bookkeeper goes on vacation the third week of every quarter.
The approval map. Who has to feel consulted versus who actually signs. Those are two different people more often than anyone admits, and getting it backwards costs you a week.
Then there's the exceptions log, which is where the money is: what to do when the card declines, when the venue double-books, when the client's assistant quits and nobody tells you for a month.
How to document processes for a virtual assistant so a machine can read them too
This is the part people get wrong. They write a 40-page SOP nobody reads. You want something short enough that an AI agent can hold all of it in context and answer questions from it.
Here's the method I use now.
Step one: a weekly 20-minute recorded interview. Phone voice memo is fine. Don't ask her to teach you her job. Ask one question: "walk me through the last time this went wrong." Then shut up and let her talk. The exceptions come out first, and the exceptions are the whole value.
Step two: transcribe and structure. Run the recording through Whisper or Otter.ai, then paste the transcript into a Claude or ChatGPT project with one instruction: turn this into rules, exceptions, and a short list of open questions. Ten minutes of review with her, and you have a page.
Step three: Loom for anything with a screen. Under five minutes per video, one task per video, named by task and not by date. Loom's auto-transcripts make these searchable later.
Step four: store it where the agent can reach it. One page per client, one page per vendor, one page of house rules, in Notion or a shared Google Drive. Then load those pages into your AI agent as standing context. That's the AI knowledge base for a service business. It's not a wiki nobody opens. It's the thing the agent reads before it drafts a reply.
Step five: test it. Ask the agent a question you never explicitly taught it, like "what do we do when a venue double-books." If it answers correctly, the context is real. If it guesses, you have more interviews to do.
The virtual assistant offboarding checklist you should run quarterly
Stop treating the virtual assistant offboarding checklist as a document you open when someone resigns. Run it every quarter, on a Tuesday, while nobody is quitting. It takes about an hour and it's the cheapest insurance you'll ever buy.
Six items:
- Credential inventory in 1Password or equivalent, one vault per contractor, so revocation is a single click instead of a scavenger hunt through old texts.
- A calendar audit. Every recurring event named, with an owner attached. Unnamed recurring events are where work goes to die quietly.
- A vendor and subscription log with renewal dates and who approves each one.
- A client tone sheet. One paragraph per client, written in plain language.
- The "if I'm unreachable" page. What to do, who to call, what not to promise.
- A decisions log for the last 30 days. Not the emails, the decisions. Three lines each.
Do this quarterly and offboarding becomes what it should be: reading a document that already exists.
Re-onboarding a replacement in a week, not three months
The test of all this is speed. Hand a new contractor the docs plus the agent, and see whether her week-one questions are already answered.
Day one is access and the client pages. Day two is the exception log and two Looms. Day three she owns one email thread with you reviewing before it sends. Day four she runs the full weekly cycle. Day five she writes the update to the client page herself, which is the only real proof that the knowledge transfer landed.
That's a contractor handover process measured in days. Compare it to the three months most founders spend re-explaining their own business to the third person in eighteen months.
The thing I keep coming back to is that this isn't really about quitting. It's about being able to step out for two weeks and have the work keep moving. If you want the bigger picture on replacing yourself as operator, that's exactly what we dig into in Mastermind vs. other programs. The point of capturing tribal knowledge is freedom, and freedom is a systems problem before it's a mindset problem.
A few of you have asked for the tactical version of this without the program. The workshop covers the interview method and the context setup in a couple of hours, and you leave with the first two pages written.
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.