Most virtual assistant SOP documents fail at exactly the same moment. The procedure says: open the spreadsheet, add the customer details, send the confirmation.
Your assistant opens the spreadsheet.
There are already two records with similar names. The customer's address doesn't match. And the confirmation template contains a price that's changed since last month.
Every numbered step is perfectly clear. And the procedure still can't tell them what to do.
That's the problem with most virtual assistant SOPs (standard operating procedures). They describe the happy path in beautiful detail, and go silent the moment real work stops looking like the demonstration.
A useful SOP explains when the task applies, which evidence wins when records disagree, and where the normal route stops. Without those, a careful VA has two choices: ask you constantly, or make assumptions the document never authorised.
This guide shows you how to write SOPs that hold up when things get messy, with a full worked example and a reusable template.
Here, a virtual assistant (VA) is an independent freelancer or agency. An SOP records your agreed service process, key checks and authority limits. It shouldn't dictate every personal working habit.
Pick one task with a clear start and a clear finish
"Customer administration" is a category, not a procedure.
"Prepare a confirmed workshop attendee's joining-information draft" has:
- a trigger,
- required records,
- a result someone can check.
Narrow tasks make missing pieces easy to spot.
Write the start condition first. Does work begin when:
- a booking is paid?
- you approve a request?
- a form arrives?
Those can happen at different times. A procedure that starts too early can produce a perfectly formatted but unauthorised message.
Then define the finish. Is it:
- a draft ready for approval?
- a message sent?
- a customer record updated?
Don't squash "prepared" and "sent" into one vague "done" if they need different permissions.
Answer these inside the SOP, not in a separate conversation:
- What happens if information is missing?
- Which source wins when records disagree?
- How does your VA avoid doing the same task twice?
If you haven't decided what your VA can do without you, sort that first. Our delegation guide helps. Writing steps can't fix a business decision you haven't made.
Watch one real run before you write a word
Do the task yourself, or watch it being done, using safe material. Take notes on the decisions, not just the steps:
- Where do you look for evidence?
- What do you reject?
- What would you do if something expected was missing?
Those details are usually invisible in the polished finished product.
Don't write from an imagined ideal workflow. If you always check the booking record before trusting an email, that check belongs in the SOP. Otherwise your VA works with less evidence than you do.
But question your habits too. Opening tabs in a particular order might just be your preference. Keep meaningful dependencies, and let your VA suggest a quicker method that reaches the same checked result.
Use screen recordings where they genuinely help. But the written SOP should still identify the current sources, decisions and result, so nobody has to replay a long video to find one exception rule.
Before sharing examples, remove unrelated sensitive information. Google Drive's sharing documentation explains that folder access flows down to everything inside, so store training examples in an appropriate place, not a broad business folder.
Write "which source wins" before writing the clicks
This is the section most SOPs are missing, and it's the one that stops most questions.
Your VA can't resolve contradictory records by following more detailed clicks. So name the authoritative source for each important fact:
- Payment status: the booking system.
- Venue and arrival details: the approved event brief.
Then say what happens when they disagree. Not "use common sense," if a wrong choice could reach a customer. Say which decision stays with you, and what safe work can continue meanwhile.
Define "current," not "recent." The newest file in a folder might be a draft, or for a different event. Say how to identify the approved version (its status in the task record, or the exact linked document), rather than trusting a file name with "final" in it.
Say what evidence closes the task. A link to the draft, the booking reference and the event brief version might be enough. Collect what lets a reviewer check the result, without copying customer details into yet another system.
This one rule, which source wins and where uncertainty stops the task, is often the missing mechanism behind constant questions. Once it's written, your VA can handle variation without waiting for you to interpret every conflict.
Exceptions should change the action, not just raise a warning
"Watch out for duplicates" isn't an exception rule. It doesn't say whether to merge records, create a new one, or stop. Those have very different consequences.
Write each branch as a condition and the next permitted action:
"If two records might refer to the same attendee, don't merge them. Link both in the task note and ask the owner to confirm the correct booking."
That says what to avoid and how to move forward.
Define a safe holding state. Your VA should be able to mark a task "waiting for a named decision," without pretending it's finished or quietly abandoning it. Include who must respond and when to raise it again.
Don't try to list every possible exception. Cover the ones that recur, and the high-consequence uncertainties. Then add a general rule for anything outside the procedure:
"Keep the evidence, don't take any irreversible action, and ask a specific question."
Keep urgency separate from emotion. A customer writing in capitals doesn't authorise a refund, booking change or instant promise. Link escalation to consequences and deadlines, not to how forceful someone sounds.
A complete example SOP you can copy
Here's a full hypothetical procedure for a workshop business. The VA prepares joining-information drafts. The owner keeps sending authority. Swap in your own policies.
PROCEDURE: Prepare a workshop joining-information draft
Owner: Business owner
Version: Initial approved version
TRIGGER
The task queue contains a booking marked eligible for joining
information under our booking rules. Don't infer eligibility from
an unverified customer message.
REQUIRED INPUTS
Booking reference, authorised attendee details, approved event
brief, current joining-information template.
ACCESS
Read: booking information and event brief.
Edit: the working draft and the task record.
NOT included: payments, booking changes, sending email.
EXPECTED RESULT
A draft to the correct attendee, with approved event details and no
unconfirmed promises. The task record links to the draft, lists the
sources checked, and says "Ready for review" or "Waiting for owner
decision".
STEPS
1. Open the task record. Check whether a draft already exists. If it
does, open it and check its status before creating anything new.
If the task is already completed, stop and ask why another
message is needed.
2. Find the booking using its REFERENCE, not the attendee's name.
Confirm the event and attendee match the request. If records
conflict or no reference matches, hold the task and record the
exact discrepancy. Don't merge or edit the booking.
3. Open the approved event brief linked from the task. Check it's
for the right workshop and approved for use. Don't take venue,
times or materials from old messages just because the wording
is convenient.
4. Create the draft from the CURRENT template in the designated
folder. Add only the necessary attendee and event information.
Don't copy private booking notes into the customer message.
Leave out anything not confirmed by the approved source.
5. Check every customer-facing fact against its source: recipient,
event, date, venue, links. If a link needs private access, flag
it before review.
6. Read the draft as the customer would. Check no placeholders
remain and the instructions make sense together. (A correct venue
and a correct travel note can still contradict each other if
copied from different events.)
7. Save the draft. If everything is confirmed and checked, set the
task to "Ready for review". Otherwise set "Waiting for owner
decision" and name the missing fact. Add the draft link and
sources, then notify the owner through the agreed channel.
Don't send the message, change the booking, or tell the customer
joining information has been issued.
EXCEPTIONS
- Missing or conflicting source information: "Waiting for owner
decision".
- Requests for a discount, transfer or special accommodation: outside
this procedure. Send to the named decision-maker with the question
and any real deadline. Don't invent an answer to clear the queue.
COMPLETION CHECK
The owner can open the draft, see its booking and sources, and spot
any unresolved decision without searching chat. The VA's task ends at
the agreed review handover. Any revision or sending follows its own
instruction and authority.
Notice how much of this is about what not to do and when to stop. That's what makes it work on a messy day.
Test it with someone who can't fill gaps from memory
Give the SOP and safe inputs to your VA. Ask them to do the task without your usual running commentary. Be available for questions, but write each question down before answering. It probably reveals a missing instruction or a term only you understand.
Watch for silent assumptions too, not just questions. Your VA might use an old template because the SOP says "the template" without linking it. The output could look fine while the method is fragile.
Test an ordinary case and a realistic exception. In the workshop example, give one complete booking and one where the event brief doesn't match. The second should produce a properly held task, not a forced "completed" draft.
Ask where the document was hard to use. Your VA might suggest a clearer order, a direct link or an example of a common confusion. That improves the SOP, rather than just testing whether they're good at guessing.
A successful test proves this person could use this version on the tested cases. It doesn't prove every future exception is covered. Note what was tested honestly, and improve the SOP when real work exposes a new recurring branch.
Our training guide covers this kind of rehearsal in detail.
Don't let screenshots become a second, conflicting procedure
Screenshots help when they solve a genuine navigation problem: "the button's hidden under this menu." Don't add one after every sentence for decoration. The text should still explain why each action exists.
Crop or redact before sharing. A screenshot of a customer record can reveal far more than the one field you meant to show. Use invented examples where possible.
Expect software to change. Refer to what a control does alongside its current label, and say where to stop if the option has disappeared. Don't instruct anyone to pick "something similar" if the similar option is destructive.
Keep images and recordings under the same ownership as the written SOP. If a screenshot shows an old setting and the text describes a new one, say which is current, then replace the old image. Better still, remove conflicting examples from active use.
A document full of screenshots can still miss the one decision that matters. The test isn't "is every screen captured?" It's "could my VA explain why each important step exists?"
Update the rule without rewriting history
Name an SOP owner and what triggers a review:
- a policy change,
- a new platform permission,
- a recurring exception,
- a corrected source.
You don't need to rewrite it every time someone completes a routine task.
Record each change and when it applies. A new venue might apply to one workshop. A revised duplicate-booking rule might apply to all future tasks. Make it clear whether existing drafts need revisiting.
Google's version history lets you see earlier versions and name them. Useful for showing what the SOP said when a task was done. But it doesn't replace telling your VA that an important rule changed.
Keep old versions out of the working path while keeping the history. A folder with several equally prominent "current" SOPs isn't controlled, however good each one is.
Judge past work against the rule that applied at the time. If a rule was missing, admit it and improve the SOP. Judging old work against a new rule makes feedback feel unfair, and encourages your VA to ask permission for everything.
An SOP can't replace skill or authority
A procedure explains a business process. It can't magically supply professional judgement, a legal qualification or authority for high-stakes decisions.
Identify where the work needs a specialist, rather than adding another paragraph telling a general assistant to "be careful."
Same with software permissions. A sentence saying "don't send" doesn't remove the Send button. Use our secure access guide to match permissions to the service where possible, and document unavoidable limits where a platform bundles actions together.
Don't use a long SOP to hide an undecided policy. If you haven't decided which customers qualify for an exception, give that decision to someone who can make it. Your VA can prepare evidence and recommendations without pretending the SOP already has an answer.
Let your VA improve the method. An independent provider might find a safer way to produce the output or cut duplicate entry. Review it against the required result and safeguards, rather than rejecting it because it's different from your demonstration.
If errors keep repeating, check whether the cause is an unclear rule, missing input, wrong skill set or too much work. More steps aren't automatically the fix. Our performance issues guide helps you tell them apart.
Your reusable SOP template
SOP TEMPLATE
Procedure name:
Owner:
Version and date:
Link to current location:
TRIGGER (when work starts):
REQUIRED INPUTS:
AUTHORISED ACCESS:
Read:
Edit:
Not included:
EXPECTED RESULT (and where the proof lives):
SOURCE PRIORITY (which source wins for each fact):
Fact: / Authoritative source: / If they conflict:
STEPS:
1.
2.
3.
(For each: does it change the result, preserve evidence,
or prevent a real failure? If not, cut it.)
EXCEPTIONS (condition -> next permitted action):
-
-
Anything else: keep evidence, take no irreversible action,
ask a specific question.
SAFE HOLDING STATE and who must respond:
HANDOVER (status, links, notification):
COMPLETION CHECK:
TEST RECORD:
Who used it / safe cases tried / questions raised / what changed
MAINTENANCE:
Who approves changes / where to suggest corrections
For every step, ask: does it change the result, preserve evidence, or prevent a real failure? Cut unnecessary narration. But don't cut the explanation that makes a judgement transferable. "Check the date" is shorter than explaining which date matters, but it's not usable.
The real test is the same situation we started with. When two records conflict or an input's missing, can your VA show what the SOP allows, what it requires them to hold, and how the task will reach a decision?
If so, your document is doing far more than recording clicks. It's making the service repeatable.
Related: the VA onboarding checklist and tools for managing virtual assistants.
Frequently asked questions
What should a virtual assistant SOP include?
The trigger, required inputs, authorised access, expected result, which source wins when records disagree, the normal steps, exception branches, the handover and a completion check.
How detailed should an SOP be?
Detailed enough to change the result or prevent a meaningful failure. Cover decisions and exceptions carefully. You don't need to document every click.
Should I use screen recordings or written SOPs?
Both, where helpful. A recording shows navigation. The written SOP should hold the current rules, decisions and exceptions, so nobody has to replay a long video to find one answer.
How do I keep SOPs up to date?
Name an owner, record what changed and when it applies, retire conflicting old material, and tell your VA which work is affected. Version history alone doesn't prove anyone noticed.
Can an SOP replace training?
No. An SOP records the agreed process. Test it with someone using safe cases, and use training and rehearsal for the judgement parts.