Hiring a virtual assistant is only the first step. What determines whether the relationship actually works is the quality of your systems. Without documented processes, your VA will ask the same questions repeatedly, produce inconsistent output, and require ongoing hand-holding that defeats the purpose of delegation.
Standard operating procedures give your VA the context they need to complete tasks correctly without coming back to you every time. This guide explains what a good VA SOP looks like, how to write one, and how to maintain a library that makes your business easier to run, and easier to scale.
Standard operating procedures for virtual assistants
A standard operating procedure (SOP) for a virtual assistant is a written document that describes how to complete a specific task, step by step, including what tools to use, what the finished result looks like, and how to handle common problems along the way. It is not a job description or a policy statement. It is an instruction manual for a single, repeatable task.
The difference between a business that scales with VA support and one that stalls is almost always documentation. When your processes live in your head, you become the bottleneck. Every new task requires a conversation. Every edge case requires your judgment. Every new hire starts from zero.
SOPs break that dependency. Once a task is documented, your VA can execute it without you present, a second VA can be trained quickly, and you can step away without the work falling apart. For more on building a repeatable VA workflow, see this guide on scaling your business with VAs.
The Asana SOP guide offers a solid overview of SOP formats across different business contexts, including templates and structural approaches worth reviewing before you start writing your own.
What goes into a VA SOP
A complete SOP for a virtual assistant covers five things: the task name and purpose, the tools required, the step-by-step process, the definition of done, and how to handle exceptions. Each section serves a specific purpose, and leaving any of them out creates confusion downstream.
Task name and purpose. Start with one clear sentence that says what the task is and why it matters. "This SOP covers how to update client contact records in the CRM after each completed call, so the team always has current information." A VA who understands the why behind a task makes better judgment calls on edge cases.
Tools required. List every platform, login, or resource needed before the task can begin. Include the name of the tool, where to find login credentials (e.g., "in the shared vault under CRM access"), and any permissions the VA needs to have set up in advance. Do not assume they know where to look.
Step-by-step process. Write each step as a single action. "Open the CRM" is a step. "Find the client record" is a step. "Update the phone number field and save" is a step. Steps should be short enough that a VA can check them off one at a time without re-reading for meaning.
Definition of done. Describe exactly what the completed task looks like. This is where most SOPs fall short. "Done" is not "I finished." It is "The client record shows the updated phone number, the last-edited date is today, and the task is marked complete in the project tracker." Specific output descriptions prevent half-finished work from being handed back.
Edge cases and escalation rules. Every task has exceptions. What happens if the CRM shows a duplicate record? What if the client's phone number does not match what was provided in the meeting notes? Build a short decision tree for the most likely exceptions: "If X, do Y. If Y is not possible, flag in Slack with the message format below." This keeps your VA moving instead of stuck.
How to write your first VA SOP
The fastest way to write a VA SOP is to do the task yourself once while narrating every step out loud, then turn that narration into a document. This works because you already know all the nuances; you just need to make them visible.
Use a screen recorder like Loom to capture the session. Record your screen and your voice as you walk through the task in real time. Note every tool you open, every decision you make, and every place where experience shapes what you do next. That recording becomes the raw material for your SOP.
Once you have the recording, write out the steps in plain language. Do not try to be thorough on the first draft. Write a version that covers the main path from start to done. Then hand it to your VA and ask them to follow it on a real task while flagging anything unclear. Their questions become your revisions.
This is the key mindset shift: the business owner writes the first SOP, and the VA improves it. You have the knowledge; they have the perspective of someone executing the task without your background. The best SOPs come from one or two cycles of this back-and-forth.
Prioritize the tasks you delegate most often. If you are handing off inbox management, social scheduling, and CRM updates in the first 30 days, write those three SOPs before your VA starts. Everything else can follow as needs arise. Starting with a VA onboarding checklist alongside your first set of SOPs helps structure those early weeks so nothing gets missed.
Avoid the temptation to write SOPs for every possible task before your VA starts. You will write documents no one uses, and the effort drains momentum. Write just-in-time: create the SOP the first time you delegate the task, not before.
Where to store and maintain SOPs
Your SOPs need to live somewhere your VA can find them without asking you. A shared Google Drive folder, a Notion workspace, or a dedicated section in your project management tool all work. The platform matters less than the consistency of your structure.
Organize SOPs by category, not by the name of the person who executes them. Categories like "Client communications," "CRM and data," "Social media," and "Finance and invoicing" stay stable even as your VA roster changes. Organizing by person means every hire creates a reorganization project.
Set a review schedule for your SOP library. Tools change. Processes evolve. A quarterly review is usually enough for a small VA team: pick 20% of your SOPs each quarter and confirm they still reflect how the task is actually done. Ask your VA to flag any SOP they had to deviate from in the past 90 days, because those deviations usually mean the document is out of date.
Include a version date on every SOP. A simple line at the top, "Last updated: [month, year]," tells your VA whether the document is current. Without a date, a VA has no way to know if the steps they are following reflect your current tools and preferences or a process you abandoned two years ago.
If a VA asks you a question that is answered in an existing SOP, that is a signal: either the SOP is unclear, it is hard to find, or the VA was not pointed to it during onboarding. Treat every repeat question as a systems improvement opportunity, not a performance issue.
Frequently asked questions
How long should a VA SOP be?
As long as it needs to be, and no longer. Simple tasks might need a one-page SOP. Complex, multi-tool processes might need four or five pages. The goal is that a VA can follow the SOP correctly on the first try without asking you for help. If it takes ten steps to achieve that, write ten steps.
What format works best for VA SOPs?
Numbered steps work better than paragraphs for most tasks because they are easy to follow in sequence. Use screenshots or short Loom video clips to document anything that is hard to describe in words, like where to find a specific menu or what a correctly completed form looks like. A hybrid approach, numbered steps with one or two screenshots at the tricky points, covers most tasks well.
Should the VA write the SOP or should I?
You write the first version; your VA refines it. You have the process knowledge, so the initial draft has to come from you. Once your VA has executed the task a few times, ask them to update the SOP to reflect anything they discovered that the original draft missed. This produces a more accurate document and gives the VA ownership of maintaining it.
What happens to SOPs when I replace one VA with another?
This is one of the biggest advantages of building a strong SOP library. When you transition to a new VA, your documented processes mean training time drops significantly. The incoming VA reads the SOPs, executes the tasks, and flags anything that needs updating for your current setup. You are not starting from zero; you are handing over a working system.
