TARGET_KEYWORD: how to write SOPs for virtual assistant

SECONDARY_KEYWORDS: virtual assistant SOPs, SOP template VA, standard operating procedures, VA documentation

SEARCH_INTENT: informational

URL_SLUG: how-to-write-sops-virtual-assistant

TITLE: How to Write SOPs for a Virtual Assistant (So They Actually Follow Them)

META_DESCRIPTION: SOPs that get ignored are usually written wrong. Here's how to write SOPs your virtual assistant can follow from day one — format, length, and what to include.

WORD_COUNT: ~1,650

INTERNAL_LINKS_USED:

- /pages/our-process

- /pages/hire-jarvis

- /blogs/blogs/va-onboarding-checklist

- /blogs/blogs/when-to-hire-first-virtual-assistant

- /pages/use-cases

RELATED_ARTICLES_TO_LINK:

- how-to-hire-a-virtual-assistant

- va-onboarding-checklist

- what-does-a-virtual-assistant-do

Most SOPs don't get followed because they were written for the person who wrote them, not for someone learning the task from scratch. You know what you meant. Your VA doesn't. That gap — between what's in your head and what's on the page — is where delegation breaks down. Here's how to write SOPs for a virtual assistant that actually work from day one.

Why Most SOPs Fail

Bad SOPs share a few common traits. They're too high-level ("respond to client emails professionally" tells a VA nothing). They're too long (nobody reads a 10-page process document when they're mid-task). They don't show what a finished output looks like. And they were written from memory after the fact, not while actually doing the task — which means they skip steps the writer does automatically without noticing.

The result is a VA who either does the task wrong or asks you constantly for clarification. Both outcomes make you feel like delegation isn't working. The problem isn't the VA. It's the documentation.

The Minimum Viable SOP

Here's the contrarian take: most SOPs should be one page or less. Founders write long SOPs because long feels thorough. But a VA in the middle of a task doesn't have time to read a document — they need to find the relevant step in 10 seconds and move forward.

A minimum viable SOP has three components:

  1. Trigger — what causes this task to start? (A new lead enters GHL. A client sends an invoice request. Monday at 9am.)
  2. Steps — numbered, one action per step. Max 15 steps. If you have more, break it into two SOPs.
  3. Output — what does "done" look like? A screenshot, a description, a specific state in the software.

That's it. If your SOP has those three things, a trained VA can execute the task with minimal questions.

Before writing SOPs, make sure you've thought through the VA onboarding checklist — SOPs are one piece of a larger onboarding structure.

The Right Format

Use this template for every SOP you write:

  • Task name: (clear, specific — "Send Day 7 Invoice Follow-Up," not "Follow Up on Invoices")
  • Trigger: When does this task start?
  • Tools required: List every tool the VA needs access to.
  • Steps: Numbered. One action per step. Written as commands: "Click X," "Copy the text from Y," "Paste into Z."
  • Output: Screenshot or specific description of the completed state.
  • Common mistakes: The top 2-3 errors you've seen or can anticipate. Be specific.
  • Escalation: When should the VA stop and ask you instead of proceeding? Define the threshold.

The escalation field is the one most founders forget. Without it, your VA either over-escalates (pinging you for decisions they could make) or under-escalates (making calls they shouldn't). Setting the threshold explicitly solves both problems.

Loom First, Write Second

The fastest way to produce a good SOP is to record yourself doing the task once, then have your VA watch the recording and write the SOP draft from what they saw. You edit the draft.

This produces better SOPs than writing from scratch for two reasons. First, you catch steps you'd skip when writing from memory — when you're actually doing the task, every step is visible. Second, you get your VA involved in understanding the task from the beginning, not just receiving a document and executing blindly.

The Loom becomes the source of truth. The written SOP becomes the quick-reference card. Both have a role.

This is part of our onboarding process at Jarvis — we recommend Loom-first documentation for every core task in week one.

How Long Should an SOP Be?

Simple tasks — inbox sorting, CRM stage updates, social media posting: one page.

Complex tasks — weekly reporting, client onboarding, multi-step follow-up sequences: 2-3 pages, broken into logical sections.

If you're writing an SOP longer than three pages, you're documenting a process, not a task. Break it into sub-SOPs. Each sub-SOP covers one discrete step in the larger process. Link them together in a parent document that shows the full workflow.

The goal is that a VA can open the relevant SOP, find the step they need, and continue without interrupting you. If the document is long enough that navigation becomes friction, it won't get used.

Getting ready to hire your first VA and want a head start on documentation? Book a free 15-minute consultation — we'll review your core tasks and help you identify what to document first.

How to Test an SOP

Writing the SOP is step one. Testing it is step two. Most founders skip step two and wonder why their VA keeps making the same mistakes.

The test is simple: give the SOP and the task to someone who has never done it before. Watch them execute using only the document — no verbal guidance, no clarifications in real time. Every time they have to ask a question, that question reveals a gap in the SOP. Write the answer into the document. Run the test again.

If you've hired through Jarvis, you can run this test with your VA in week one as part of onboarding. It's the fastest way to build a reliable SOP library because the gaps surface immediately, in context, with the person who will actually be using the document.

See use cases to understand how other founders have structured their SOP testing during onboarding.

Living Documents vs. Set-and-Forget

SOPs go stale. Your software updates. Your process changes. You add a new step that isn't in the document. Six months later, your VA is following an outdated procedure and producing results that don't match what you expect.

The fix is to make your VA the SOP owner, not you. Whenever a process changes, the VA updates the document the same week — not when someone notices it's wrong. This one shift changes SOPs from a static library into a living system that stays current.

Assign each SOP an owner. Set a quarterly review — the owner reads through it, verifies it's still accurate, updates anything that's drifted. This is a 20-minute task per SOP, not a project.

If you're thinking about hiring your first VA, building this habit from the beginning is far easier than retrofitting it after your SOP library has grown.

Starter SOP Pack: Write These First

Most founders don't know where to start with documentation. Here's the prioritized list — write these five SOPs before you hand anything else off:

  1. Inbox triage — how to sort and flag your email each morning
  2. CRM stage updates — when and how to move a lead through the pipeline
  3. Lead follow-up sequence — the exact steps and timing for following up with new leads
  4. Weekly reporting — what to pull, how to format it, when to send it
  5. Social media posting — how to schedule and publish from your content calendar

These five cover the highest-volume recurring tasks for most small business owners. Once they're documented and tested, you have a working VA operational in the first week. Everything else can be added incrementally as new tasks are delegated.

Ready to hire a Jarvis VA and build your SOP library from day one? We support the documentation process as part of onboarding.

Frequently Asked Questions

How detailed should each step in an SOP be?

Specific enough that someone who has never done the task can follow it without asking a question. "Update the CRM" is not a step. "Open GoHighLevel, navigate to the lead's contact record, change the pipeline stage from 'New Lead' to 'Call Scheduled,' and add a note with today's date and action taken" is a step. When in doubt, be more specific.

Should SOPs include screenshots?

Yes, for any step where the VA needs to identify a specific button, field, or state in a software tool. A screenshot reduces interpretation errors. For software that updates frequently, annotate the screenshot instead of relying on UI elements that may move.

What tool should I use to store SOPs?

Notion is the most common choice — it's easy to update, searchable, and accessible anywhere. Google Docs works too. The tool matters less than the structure: a clear naming convention, a master index, and consistent formatting across all documents.

What if my VA writes the SOP draft and gets steps wrong?

That's expected and valuable. When you review their draft, the errors show you what was unclear in your Loom recording or your initial explanation. Fix the SOP and retrain on the specific step. The mistake was the documentation's fault, not the VA's.

How often should SOPs be updated?

Any time the process changes — same week, not same quarter. Assign the VA as owner and make it their responsibility to flag when something in the SOP doesn't match what they're actually doing. A SOP that reflects last year's process is worse than no SOP at all.

Build Documentation That Scales With You

SOPs aren't busywork. They're the foundation that lets you add VAs, grow your team, and stop being the only person who knows how anything works. Write them right once and they pay dividends for years.

Book a Free Call!

Back to blog