How to Train a Virtual Assistant So You Stop Explaining the Same Thing Twice

If you're learning how to train a virtual assistant, you've probably been here. You've already explained the task. There's even a recording.

The next version comes back with the same kind of mistake. So you get ready to explain it again, more slowly this time.

Stop. Before you do that, check what your assistant was actually missing.

It might be:

• the software skill (how to filter a report),
• a fact about your business (cancelled orders don't count),
• judgement (what to do when two systems disagree).

Those need completely different fixes. More company background won't teach someone a spreadsheet formula. Another video of the same easy example won't explain an exception you never showed.

That's the secret to how to train a virtual assistant without endless repetition: find the right gap, teach the decision rather than the clicks, and test the principle on a new case.

This guide walks through it, with a full worked example you can recreate in a blank spreadsheet in ten minutes.

Here, a virtual assistant (VA) is an independent freelancer or agency. Training should give them your business context, standards and limits, while respecting their skills and their right to choose sensible methods.

Find out which kind of knowledge was missing

Take one recent correction and rebuild what happened:

• What information did they have?
• Which instruction did they follow?
• What did they think "finished" meant?

Ask them before giving your explanation.

Then sort the problem into one of three boxes:

Type	Example	Fix
Task skill	Doesn't know how to create a filtered report	Targeted practice or training
Business context	Didn't know cancelled orders are excluded	Write down the rule
Judgement	Unsure what to do when order status conflicts across systems	Examples of the boundary, plus an escalation rule

They can overlap, but separating them stops wasted effort.

Start with one correction important enough to matter. If your feedback mixes factual errors, brand preferences and spacing tweaks, your VA might perfect the formatting while missing the decision that makes the work trustworthy.

Define what "acceptable" means, without inventing rituals

Show a finished example and explain why it's acceptable. Point to:

• the evidence used,
• the required content,
• what's deliberately left out,
• where it goes.

"This is how I usually do it" isn't as useful as:

"This check stops a cancelled order showing up in the weekly total."

Separate requirements from preferences:

• A total must match the approved source. That's a requirement.
• A heading can be phrased several ways. That's a preference.

If you insist on one phrasing, give it as a reference. Don't treat every alternative as a mistake.

Remember you're buying an independent service. A specialist might have a better way to get the same result. Discuss which methods are flexible and which controls are essential for your systems or customers. Don't demand they copy inefficient habits just to prove they listened.

Where a particular order of steps matters, explain why. "Check the reporting period before importing the data, otherwise you'll calculate a perfect total on the wrong records." That reason helps them keep the important step even if the software changes.

Pick examples that show where the rule stops

An easy example shows the normal route. A contrasting example shows where that route stops working. You need both for any task involving judgement.

Choose:

• a routine case,
• a plausible exception,
• a near-miss that looks similar but needs different handling.

For a weekly report:

• Routine: a complete, approved export.
• Exception: an export with missing dates.
• Near-miss: a newer export covering a different reporting period. The newest file isn't automatically the right file.

Keep examples within the real job. Don't invent obscure puzzles to make training feel rigorous.

Use invented or reduced data when customer information isn't needed. Google Drive's sharing guidance explains that access to a folder flows down to its contents, so put practice material in a properly restricted area.

Keep a private answer note explaining the intended decision and why. If you can't explain why one case differs from another, the rule might still be unresolved in your own head. Decide it first.

Narrate what you notice, not just where you click

Record or show one task from start to finish. Briefly explain the purpose, then say out loud the observations that change your decision:

"The date range is wrong, so I'm not importing this file."

That teaches far more than silently clicking back to the folder and opening another file.

Show where evidence comes from. If you rely on an approved price list, open it and point to the version. If a customer claim needs checking, show which record confirms it, and what you do while that record's unavailable.

Keep it focused. A long recording that wanders through unrelated systems is hard to reuse. Split genuinely different tasks, but don't chop one decision into so many tiny clips that your VA has to piece the logic together.

Before sharing, check the recording for passwords, private notifications or personal information.

End with the handover itself. Show where the finished file goes, how it's named, what status it gets and how an unresolved question is recorded. Training often stops at the visible output, even though the missing final update is what leaves you unsure whether anything's ready.

Ask them to talk through a new case before doing it

After the demonstration, give a different but comparable case. Ask:

• What would you check?
• Which rule applies?
• Does anything need a decision from me?

That makes their reasoning visible before a wrong assumption spreads through the work.

A great prompt:

"Show me the source you'd use, and the point where you'd stop if something didn't match."

Don't interrupt every sentence or steer them to the answer. Let them show their current understanding. If they ask a sensible question your materials didn't answer, note the gap rather than inventing a rule on the spot and forgetting to write it down.

Then let them produce the draft in a safe workspace. Reviewing the approach and reviewing the finished output tell you different things. Someone can explain the right method and still miss a field. Someone else can produce a plausible result through a method that'll fail next time.

This practice is part of setting up the service, so agree the time and pay for it. If the learning needed is much bigger than expected, talk openly about scope and fit.

Feedback should point to the exact decision that needs to change

Compare the result with the agreed standard and point to a specific difference:

"The report includes cancelled orders, but this service only reports active ones."

That's actionable. "Be more careful" isn't.

Ask how it happened. Maybe the export used a new status label, the procedure left out an exclusion, or they genuinely overlooked an instruction. The fix should match the cause, not your first assumption.

Explain the consequence without exaggerating. "A wrong date range makes the weekly comparison misleading" is enough. No need to invent a catastrophe.

Separate a real error from a change of mind. If you've decided you now want a different layout, call it a change. Pretending they should have known your new preference teaches them that accepted work can become "wrong" later without warning.

Finish with the updated rule and a new chance to apply it. Feedback isn't complete when they say "got it." It's complete when the next relevant decision changes.

Retest the principle, not the memorised answer

Give another case with the same underlying issue but different surface details.

If the problem was a missing reporting date, change the file names or where the date appears. You're checking whether they now check the period, not whether they remember which file you rejected last time.

Change one thing at a time. If you change everything at once, a failure becomes impossible to diagnose.

Judge readiness by consequence and variety:

• A few successful routine cases can justify less checking of that routine category.
• They don't prove readiness for an unusual financial or customer-facing decision.

Keep an escalation rule for anything outside what they've demonstrated.

Record what's been shown and what's still untested. That's far more honest than "fully trained," which hides huge differences between tasks. Our onboarding checklist places these checks within the wider first month.

A worked example you can recreate in ten minutes

Here's a hypothetical example.

A VA prepares a weekly order summary for a small retailer. The owner supplied an export, a template and an example. The first draft looks tidy, but includes orders cancelled before the cut-off.

The owner asks which source and rule the VA used. The VA explains: the example included every row, and the brief said "total orders."

So the problem is missing business context, not poor spreadsheet skill.

They agree the real definition: report eligible active orders for the stated period, excluding cancelled orders under the supplied status rule. The owner updates the reference, and explains why. They don't quietly change the standard and call the earlier version careless.

Build the practice exercise yourself. Open a blank sheet with four columns: Order reference, Reporting period, Status, Proposed treatment. Add:

Order reference	Reporting period	Status
TEST-A	Current period	Active
TEST-B	Current period	Cancelled
TEST-C	Current period	Under review

The rule you give them is deliberately incomplete: Active is included, Cancelled is excluded. "Under review" has no approved treatment.

The right answer:

• include TEST-A,
• exclude TEST-B,
• list TEST-C as unresolved.

And the report must flag that unresolved record, rather than presenting its total as complete and final.

For the retest, change the references and row order so position can't give away the answer.

What happened next, in the example. A later live export introduced a brand-new status label. The VA didn't automatically treat it as active to make the report look complete. They used the exception route.

That's the proof training worked. They learned where the rule stops, not just the answer to the demo file.

Keep current knowledge where the work happens

Keep one current procedure beside the task, and link the demonstration from it. Add the approved example and a small set of meaningful exceptions. Your VA shouldn't have to search chat history to find today's rule.

Name who can approve changes. Your VA might draft an improved procedure after spotting a missing step, which is great. But a significant business rule shouldn't change silently because someone edited a shared document.

Google's version history lets you see earlier versions and create named versions. Useful for tracing what changed. But version history isn't proof that anyone noticed the update.

For each change, state:

• what's different,
• why it changed,
• which current tasks are affected.

If older work is still valid under the previous rule, say so, or your VA might redo accepted work unnecessarily.

Retire conflicting material. An old training video can be more convincing than a newer written note because it shows you actually doing the task. Mark it superseded or replace it.

Our SOP guide explains how to write procedures that stay usable.

Stop training when the real problem is the wrong fit

Some repeated problems won't be solved by another explanation:

• The VA lacks a core skill the work requires.
• The work needs a qualified specialist.
• The brief contains more than the agreed time can support.

Look across several cases:

• If they understand the rule but can't execute the technical work reliably, discuss targeted skill-building or a different provider.
• If you keep changing the goal, stabilise the brief before judging how fast they learn.

A general assistant can sometimes develop a new skill, but not every specialist service should become a beginner's training project. Consider the risk, cost, supervision needed, and whether they even want to offer that service. Willingness to help isn't the same as qualification.

Respect the independent relationship. Business-specific instructions and security requirements are different from controlling how someone runs their own work. Our contractor or employee guide explains why that matters.

If it's not a fit, say what evidence led to that conclusion. Repeated vague criticism wastes everyone's time. A clear scope change, a specialist referral or an agreed ending is kinder than an endless training loop.

Leave behind a lesson anyone could apply

Keep a short training record for each lesson:

TRAINING RECORD

Task:
Missing knowledge (skill / context / judgement):
Example shown:
Practice case used:
What happened:
Rule updated (link):
Retest case and result:
Authority that stays with me:
Still untested:

A completed entry might say:

"Weekly order report. Exclusion rule missing from brief. Synthetic cancelled-order example demonstrated. New case completed with unknown status held. Procedure updated. Owner still approves unfamiliar statuses."

That's real evidence, without pretending one practice run proves permanent competence.

Keep your VA's suggestions too. They might find a clearer source or a safer check. Training should improve the service, not just copy your existing habits.

When the same question comes back, check first: was the answer actually findable? Does the new case genuinely fit the old rule? Sometimes repetition means a missing reference. Sometimes the new case deserves a new decision.

The goal isn't zero questions. It's making ordinary decisions repeatable, unusual cases recognisable, and new learning available next time. You should be able to point to what changed in the work, not just how many times you explained it.

Related: how to delegate to a virtual assistant and handling VA performance issues.

Frequently asked questions

How long does it take to train a virtual assistant?

It depends on the task and the person. Routine work with clear rules can settle within a few weeks. Judgement-heavy work takes longer. Judge readiness by successful work on varied cases, not by days passed.

Why does my VA keep making the same mistake after training?

Often the training showed the answer to one example but not the underlying rule, or the missing piece was business context rather than skill. Work out which kind of knowledge was missing before retraining.

Are screen recordings good for training a virtual assistant?

Yes, if you say out loud what you notice and why, not just what you click, and keep a short written procedure alongside it for rules and exceptions.

Should I pay my VA for training time?

Yes. Agreed training and practice time is part of setting up the service. If the learning needed is much bigger than expected, discuss scope and fit openly.

How do I know my VA has really learned something?

Give a new case with the same underlying decision but different surface details. If they apply the principle correctly, the lesson stuck. If they only get the original example right, they memorised it.