Most virtual assistant onboarding checklist templates would call this a great start. The first call went really well. Your new assistant has the folder link, a collection of training videos and a warm invitation to "ask anything."

The next morning, they ask which document is current. And whether they're allowed to send the finished reply.

You've given them information. You haven't given them a working service.

A typical virtual assistant onboarding checklist can look complete while your VA still can't take one request from start to finish. Folder shared? Tick. Call attended? Tick. Videos watched? Tick. None of those prove the work can actually run.

This guide gives you an onboarding checklist where every tick points to evidence, plus a month-long plan built around one real service, using a worked example you can adapt.

Here, a virtual assistant (VA) is an independent freelancer or agency. Onboarding means connecting your business to their service: access, context, authority, delivery and review. Not treating them like an employee.

Editorial scene showing reviewing the owner decision at a worktable for this guide.

Choose one complete service to bring online first

Start with something small enough to watch from start to finish.

  • Too broad: "Help with marketing."
  • Just right: "Prepare the weekly event email from approved event details, leaving it as a draft for my review."

The second one has a clear input, output and approval point.

Open a real example from your business and write a short service card:

  • What starts the work?
  • What decisions come up along the way?
  • Where does the result go?
  • Who accepts it?
  • Can the VA start without you being online?
  • How will they spot an exception?
  • What if the source is wrong?

Pick something representative, not something trivially easy to manufacture an early win. Renaming a folder proves access works. It doesn't prove your VA understands the service you're paying for.

If you're torn between several possible starting tasks, our what to delegate first guide helps. One complete modest workflow teaches you far more than fragments of five.

Editorial scene showing checking a remote handover with another person for this guide.

Do your homework before their first day

Onboarding stalls on the client side more often than people admit. Before the start date:

Confirm the agreement. Service fee, invoicing, start date, initial scope and how extra work gets agreed. Don't bury unpaid prep or heavy training inside "just get ready."

Book your review time. If your VA submits drafts but nobody has time to check them, onboarding stalls however capable they are. Name your backup reviewer too.

Prepare your materials:

  • current source documents,
  • one accepted example,
  • a short explanation of why it's acceptable.

Remove or clearly label old versions. A new person can't guess which of three conflicting files you still believe in.

Set up access properly. Create an access register and check privacy arrangements before sharing real customer data. Google Drive's sharing guidance explains that folder permissions flow down to everything inside. Don't put sensitive unrelated files in a broadly shared onboarding folder and hope a note asking them not to look will work.

Your pre-start list is done when: the agreement's confirmed, the first service is defined, a reviewer has time booked, the right materials exist, and access can be granted at the right level.

If any are missing, write it down as a dependency, rather than letting your VA discover it during paid time.

Editorial scene showing comparing the workload against a simple calendar for this guide.

Make the first session a walk through one real request

Start with context that matters. Not your company's founding story. Instead, what you promise customers and where this service fits in:

"This email must never mention a venue until it's confirmed, because we've had people turn up at the wrong place."

Walk through one real workflow using safe material. Show the input, the expected result, the key checks and where questions go.

Say out loud the decisions that aren't visible on screen, especially when you reject something that looks reasonable.

Then flip it. Ask your VA to:

  • find the current instructions,
  • find where outputs go,
  • explain the authority boundary in their own words.

That's checking your handover, not testing their memory.

Agree how to flag a blocker. A useful question includes:

  • the case,
  • what's already been checked,
  • the missing decision,
  • what happens if it waits.

"Please advise" on its own makes you rebuild the whole problem.

End with a specific first submission and review time. Both of you should know exactly what happens next without another planning call.

If your VA can't open a file they need, fix that before adding more tasks or broader access.

Editorial scene showing reviewing the evidence before approving the next step for this guide.

Run a safe rehearsal to find the missing connections

Give your VA a practice case using invented or appropriately reduced information. It should resemble real work closely enough to reveal gaps, but shouldn't involve real customers, payments or publishing.

Include:

  • one ordinary case,
  • one plausible uncertainty.

For the event email:

  • Ordinary: confirmed event details.
  • Uncertain: an old venue in a previous draft, and a newer source saying the venue's still pending.

The right result isn't prettier writing. It's leaving the venue out and flagging it.

Ask for the draft and a short note explaining anything held back.

Review against the agreed standard: factual accuracy, source choice, format and respect for the approval boundary.

Separate a missing instruction from a skill gap before giving feedback. If your VA spots a contradiction you missed, update your instructions. The rehearsal worked. Don't penalise them for failing to guess which of two "authoritative" sources you meant.

A rehearsal passes when your VA can produce the expected output and recognise when not to proceed. It doesn't prove readiness for every related task. Keep publishing, refunds and account changes out until each has its own agreed authority. Our training guide covers rehearsals in more depth.

Editorial scene showing checking access and responsibility before the work continues for this guide.

Week one: prove one small loop works end to end

In the first week, run the service on a limited live scope. Your VA prepares work, records exceptions and submits it through the agreed channel. You review promptly and record decisions in the same place.

Don't measure progress by how many apps you've introduced. The real milestone is one completed loop:

  1. An eligible request arrived.
  2. Your VA had what they needed.
  3. The work was checked.
  4. Approval was handled.
  5. The result was stored correctly.

Keep a short issue log: the case, what caused delay or correction, and what changed.

  • Useful: "Needed current event price."
  • Useless: "More confidence needed."

Separate your delays from theirs. If the source arrived late, note it. If your approval sat unanswered, note that too. Otherwise a perfectly capable service looks slow because it includes time spent waiting for you.

Expand authority only where the evidence supports it

At the next review, look at real completed cases:

  • Which needed correction?
  • Were corrections about facts, process or personal preference?
  • Did your VA hold back the right exceptions while continuing safe work?

Use that evidence to decide what changes. You might:

  • remove approval for one narrow routine action,
  • keep approval for anything public-facing,
  • add one more type of request.

Write the new boundary down with a date, and confirm your VA understands it.

Familiarity isn't authority. Someone who's prepared reliable drafts doesn't automatically have permission to publish them. Understanding invoice preparation doesn't mean authority to release payments.

But don't keep every tiny choice waiting for you either. Once there's a clear standard, let your VA choose between acceptable options. Otherwise your review process teaches them that initiative just creates more corrections.

There's no magic number of successful cases that makes a task "safe." Consider variety, consequences and evidence. A rare, high-risk exception might always need escalation, even after months of routine success. That's a sensible limit, not a failed onboarding.

Mid-month: test what happens when things go wrong

A service can work beautifully on a quiet day and fall apart when an input's missing or you're away.

Before widening scope, talk through likely interruptions:

  • What if your VA can't connect?
  • Who answers an urgent question if you're travelling?
  • What if the current source file isn't available?

Agree a safe holding action and an alternative contact, rather than expecting permanent availability from an independent provider.

Run a "tabletop" exercise. Describe the problem, and ask your VA to show where they'd record it and what work could continue. You don't need to create a real outage or secretly withhold information.

Check planned closures and time zones while there's still time to arrange cover. Our time zone guide helps here. Agree any extra service or backup access in advance. A substitute shouldn't inherit someone's login informally.

Update your operating notes from what you learn. If you discover there's no backup approver, that's your action item. Your VA shouldn't have to solve a missing client decision by exceeding the authority you gave them.

Keep the current rule separate from the pile of feedback

After a few reviews, your chat history might contain a dozen corrections that never made it back into the original instructions. Now your VA has to remember which messages override which documents. That's a hidden memory test inside every task.

Put current rules in the active procedure. Keep individual feedback with the relevant case.

  • If a correction changes the rule for future work, update the procedure.
  • If it's a one-off, label it as a one-off, so it doesn't spread.

Google's version history lets you see earlier versions of Docs and Sheets and name versions. Helpful for seeing which instructions applied when a task was done. But it doesn't prove your VA read the change.

Note: browsing version history requires edit access. If your VA only needs to read the procedure, send them the relevant dated version instead of widening access. And note the rule version in the task record, so evidence doesn't depend on browsing history.

For significant updates, say what changed and which current work is affected, and ask your VA to acknowledge it.

If a training video contradicts the written procedure, fix or retire the video. Don't leave both active.

Keep the library small. Our SOP guide shows how to write decisions and exceptions clearly. You don't need a complete manual for every future service before the first useful task can begin.

A worked example: one month of event emails

Here's a hypothetical example.

A workshop business hires an independent VA to prepare event emails. The owner has approved copy examples, a booking page and a spreadsheet of event details. The VA's initial authority: prepare drafts, not send them or change prices.

Before day one. The owner creates a restricted working folder, identifies the current event sheet and agrees a review window. The contract covers the fee and how extra campaigns will be quoted. The VA confirms the first draft date and what information they need.

The rehearsal. The VA notices that the old example names a venue missing from the current sheet. They hold that detail and ask a specific question. The owner confirms the venue is still pending, and adds a source-priority rule to the instructions. That stops plausible-but-outdated details being copied in future.

Week one. The VA prepares a live draft and checks links against the approved booking page. The owner corrects a stylistic preference but accepts the factual checks. They add the preference to the example, rather than treating it as a mistake the VA should have known.

Week two. The owner lets the VA make routine formatting choices within the template. Sending still needs owner approval, because it reaches customers. The service needs less cosmetic review, without expanding into unapproved publishing.

Week three. The owner will miss a normal review window. They name a backup approver and rehearse the handover. The VA can now show the draft, the unresolved issue and the decision needed, without retelling the whole project.

Month end. The review looks at this complete service, not whether the VA attended the first call.

Make the month-end decision from evidence

Look at accepted outputs and recurring corrections. Is the service delivering what you wanted? Does the scope still fit the fee and agreed availability? Your VA might be doing great work while the original scope turns out too small for your actual queue.

Be honest about your own effort. Are you checking a few key decisions, or rewriting everything? If you're still rewriting a lot, find out why:

  • unclear preferences?
  • missing context?
  • wrong skills?
  • a changing brief?

Each has a different fix.

Ask your VA what's still hard. They might see a missing input, duplicate instruction or pointless approval step invisible from your side. Treat it as useful information, not an excuse.

Choose a specific outcome:

  • keep the current scope,
  • widen one bounded part,
  • revise the process,
  • address a mismatch.

Don't promise extra work just because a month has passed. Agree scope or fee changes before they become expectations.

Write down what stays with you. A great first month can still leave sensitive decisions, unusual cases and publishing approval in your hands. Independence within a defined service is different from handing over every decision.

Check the invoice against what you actually agreed. Extra rehearsals, wider scope or added cover shouldn't become a surprise dispute. Resolve any difference and confirm the basis for next month.

Your evidence-based onboarding checklist

Every tick should point to proof, not just "done."

VA ONBOARDING CHECKLIST (30 DAYS)

Service:
VA:
Start date:
Review owner and backup:

BEFORE DAY ONE
[ ] Agreement confirmed (fee, scope, extra work)    Evidence:
[ ] First service card written                       Evidence:
[ ] Current sources + one accepted example ready     Evidence:
[ ] Old versions removed or labelled                 Evidence:
[ ] Access granted at the right level                Evidence:
[ ] Access tested FROM the VA's account              Evidence:
[ ] Review time booked                               Evidence:

FIRST SESSION
[ ] One real request walked through                  Evidence:
[ ] VA explained authority boundary back             Evidence:
[ ] Blocker format agreed                            Evidence:
[ ] First submission + review time set               Evidence:

REHEARSAL
[ ] Ordinary case + uncertain case                   Result:
[ ] Instructions updated from findings               Link:

WEEK ONE
[ ] One full loop completed                          Link:
[ ] Issue log started (my delays vs theirs)          Link:

AUTHORITY CHANGES
[ ] New boundary, date, VA confirmed                 Link:

INTERRUPTION TEST
[ ] Outage / absence tabletop run                    Result:
[ ] Backup approver named and rehearsed              Evidence:

MONTH END
[ ] Accepted outputs reviewed
[ ] Recurring corrections and causes
[ ] My remaining effort
[ ] VA's "what's still hard"
[ ] Decision: keep / widen / revise / address mismatch
[ ] Invoice matches what was agreed
[ ] What stays with me

A compact entry might read:

"Milestone: first live draft. Evidence: linked draft and review note. Open issue: venue confirmation. Safe action: leave venue out until approved. Owner: me. Next review: Thursday."

The strongest sign onboarding has worked is boring, ordinary work that no longer needs rescuing: the right inputs arrive, your VA delivers within agreed boundaries, exceptions reach someone who can decide, and accepted outputs stay easy to find.

Related: how to hire a virtual assistant and how to manage a virtual assistant.

Frequently asked questions

How long does it take to onboard a virtual assistant?

There's no fixed time. A month is a useful planning window for one well-defined service, but progress should follow demonstrated work, not the calendar.

What should I prepare before my VA starts?

A confirmed agreement, one clearly defined first service, current source material, one accepted example, appropriate access, and a reviewer with time booked to check work.

What should happen in the first onboarding call?

Walk through one real request from input to accepted result, explain the decisions involved, confirm where questions go, and set a specific first submission and review time.

When can my VA work without approval?

When they've shown, on real cases, that they produce correct output and know when to stop. Expand authority one narrow area at a time, keeping approval for consequential actions.

What should I check at the end of the first month?

Accepted outputs, recurring corrections and their causes, how much of your time is still needed, what your VA finds hard, and whether the scope and fee still match the work.