If you're figuring out how to delegate to a virtual assistant, this might sound familiar. Your virtual assistant has finished the customer email. It's sitting in drafts, waiting for you.
You open it between other jobs. The wording's fine. But the refund is wrong: this customer bought under the previous policy. You explain the exception, fix the amount, and then notice another message asking whether a different customer qualifies.
You hired help with the inbox. Somehow you're still handling the inbox. It just arrives as questions now.
So you do the obvious thing. Write better instructions. Record your screen. Add examples. And the next unusual case brings another interruption anyway.
Learning how to delegate to a virtual assistant properly means spotting what you're actually failing to hand over. It's usually not the task. It's the decision inside it.
This guide shows you how to hand over decisions safely, test them before going live, and turn questions into quick yes-or-no answers, using one task and the records you already have.
Here, a virtual assistant (VA) is an independent freelancer or agency providing an agreed service.
You can hand over the clicks and keep every decision
"Handle customer refunds" sounds like one task.
Inside it are several decisions:
- Does this purchase qualify?
- Which policy applies?
- Has someone already promised an exception?
- Can the payment still be reversed the original way?
The visible activity is opening the order and clicking refund. The real work happens before that.
If you only explain where to click, you've handed over the activity while keeping responsibility for deciding what those clicks should do.
That's why a detailed screen recording can still leave someone dependent on you. They know the steps for the case you showed them. They don't know which steps change when the facts change.
Imagine showing your VA how to refund a recent purchase. The next customer has two orders under two email addresses. Your VA can follow every click in your video perfectly and still refund the wrong order.
"Use your judgement" doesn't fix this. Judgement needs a basis for choosing, and permission to act on the choice. Without those, asking you is the most responsible thing they can do.
So before writing more instructions, look at the questions coming back. They're a map of the decisions that still belong to you.
More instructions can't fix a decision you've never made
Standard delegation advice has useful parts: choose repeatable work, explain the outcome, document the process, set a deadline, give feedback.
The trouble starts when "document the process" assumes there's a consistent process to document.
Maybe you waive a fee when someone seems genuinely upset. Sometimes you offer a replacement because you're busy. Another day, you refuse an almost identical request because the customer was rude.
You might have good reasons. But your VA can't work them out from finished emails. They see conflicting examples. You see obvious differences, because you remember context that never got written down.
Adding all those examples to a longer guide can make things worse. Now your VA has several precedents and no idea which applies to the current case.
What you actually need is to decide how the business will handle that situation from now on. Until you do, "follow the process" asks someone to follow a rule that doesn't exist.
You can absolutely keep some choices personal. A long-standing customer with an unusual history might still come to you. Just make that boundary visible, rather than expecting your VA to discover it by getting it wrong.
Hand over a bounded decision before a whole responsibility
The sweet spot is smaller than "own the inbox" but bigger than "draft replies."
For example:
"You can resolve duplicate-charge requests when the payment records show the same order was charged twice. Separate orders aren't included."
That gives your VA:
- a recognisable situation,
- evidence to examine,
- an action they can complete.
You're not asking them to become you. You're giving them room to make one specific decision without you.
The key question: at what point can they finish the work?
If the answer is "after I approve it," you've created an assisted task. That's useful during training or for sensitive work, but expect to stay involved.
If you want the task genuinely off your desk, some defined group of cases has to end without your approval.
Start where a correct decision is easy to check and a mistake can be contained. The group can grow later.
Pick work you can check after the fact
For this week, choose a recurring task with records you can review: customer requests, appointment changes, routine order corrections.
"Improve our marketing" is too broad. You couldn't tell a poor decision from a reasonable experiment that hasn't paid off yet.
Choose something you understand well enough to judge. If you're unsure how it should be done, sort that out first.
Avoid starting with work where a mistake could expose sensitive data, create a legal commitment or cause serious financial harm. You can practise those decisions on copies without authorising live action.
Check access too. Your VA can't resolve a payment question if the payment history is only visible in your account.
Don't solve that by sharing your password. Use a separate account with the right permissions, or choose a different task while access is set up. The UK's National Cyber Security Centre (NCSC) recommends deciding who needs access to which systems and functions, and when.
The test needs to be fair. Missing information and missing access look just like poor judgement from a distance.
Rebuild one real case and write down what changed your mind
Take an actual finished case and open a blank document beside it.
Write the request in plain language. Then work backwards:
- What fact made that action right?
- Where did you find it?
- What would have made you choose differently?
Don't write "checked eligibility." That's the decision you're trying to explain. Write the actual checks:
"Opened the order history to confirm which purchase the customer meant. Read the policy attached to that purchase. Searched the support thread for an earlier refund promise."
Link to the real policy where possible. Copying policy text into several training documents creates more places that go out of date.
Now the powerful bit. Find a case that looked similar but ended differently. Put them side by side and find the smallest factual difference that justified the different outcome.
Maybe one customer asked about an eligible purchase and the other about a different order. Or one involved a promise someone had already made.
That difference is exactly what your instructions need. It tells your VA what to notice.
If you can't explain the difference, don't cover the gap with "common sense." Decide: is it a consistent rule, a narrow exception, or something that always needs your review? Write it down before handing over another case.
Turn the explanation into permission someone can actually use
Now write a short working note for this task. Keep it focused enough that your VA doesn't need to search your entire operations manual.
Which cases it covers. "Routine refund requests" is still vague. Name the product or service and the conditions.
What they may do. Issue the refund, or prepare it? Send the confirmation? What still needs approval?
Set limits deliberately, based on your actual policy and risk. And make sure the policy respects customers' legal rights. For example, UK government guidance on returns and refunds explains that a business can't remove statutory rights with its own returns policy. The examples here illustrate a handover, not legal rules for every country.
The evidence to check, and where it lives.
What finished looks like. For a refund, that might be confirmation in the payment system plus a note on the customer record. A polite "done!" email doesn't prove the money moved.
When to stop. Conflicting records, uncertain identity, an existing payment dispute. Use the conditions that genuinely matter for you.
What to do when work stops. Who receives the question, what evidence to include, and what the customer can be told while waiting.
Then ask your VA to read the note and explain a case back to you. Listen for their reasoning, especially when their answer happens to be right. A lucky guess can hide a missing rule.
Test on old cases before risking a new one
Use past cases for the first test. Remove unnecessary personal details, limit access, and agree when the copies get deleted.
Show your VA the information that was available when the request arrived, but hide your final answer.
Ask them to write what they'd do and which facts support it. They should point to actual records, not just say "I'd check the system."
Compare their answer with your note. And don't automatically assume your original decision was right. You might discover you handled the old case inconsistently.
When you disagree, find the cause:
- Missed evidence that was available? Practise the check.
- Unclear rule? Fix the rule.
- Acted outside a clear boundary? Talk directly about the boundary.
Include a case that can't be resolved from the available information. This matters a lot. If every example has a neat answer, you teach your VA that finishing always means taking action. Sometimes the right result is to stop and ask for what's missing.
A worked example: duplicate charges
Here's a hypothetical example.
An online shop wants help resolving apparent duplicate charges. The owner prepares sample orders, payment records and customer messages.
The permission covers: a confirmed second charge for the same order, where no refund or dispute exists yet. It excludes separate purchases and conflicting records.
Practice case 1. Both charges point to the same order. The VA identifies the duplicate, checks neither has been refunded, and records which charge the owner should review. This practice version only allows a recommendation, so even a correct answer must not trigger a real payment.
Practice case 2. Same customer name, same amount, but two different order references. The VA shouldn't assume it's a duplicate just because the amounts match. They note the separate orders and ask which purchase the customer means.
Practice case 3. The order shows a refund, but the payment history is incomplete. The right result is a precise request for the missing record, not another refund.
The owner reviews the reasoning alongside the answers. If the VA gets case 1 right but never checked the existing-refund field, the test has found an unsafe shortcut. They practise that check before discussing live authority.
Once live refunds are agreed, the account permissions, completion record and review arrangement must support exactly that scope. The practice exercise tested a decision. It didn't quietly expand access.
Make every question arrive half-answered
During the trial, agree how questions should look.
"Can you check this?" hands the whole problem back. You have to open the record, rebuild the situation and work out what's uncertain.
Instead, ask for the proposed action, the evidence, and the unresolved point:
"I'd refund this order under the policy linked to its purchase date. The payment matches the order, but an earlier reply promises a replacement instead. Should I honour that, or confirm which option the customer wants?"
That's a decision you can answer in ten seconds.
If they can't propose an action, ask them to name the missing fact or the conflicting instruction. Don't demand a confident recommendation when the evidence doesn't support one.
Agree where non-urgent questions wait, and when you'll review them. Customer deadlines still apply, so separate what can wait from what can't.
And watch your own behaviour. If you routinely reverse decisions because you'd have phrased it differently, your VA learns your unstated preferences override written permission. They'll go back to asking first.
Correct errors that affect the outcome. Discuss style separately, and only add it to the guidance if it really matters.
Count everything that comes back to you, including quiet fixes
Keep a simple log during the live trial. For each case, note whether your VA:
- completed it within permission,
- paused for a valid reason,
- needed a correction.
Link to the case.
Log your own involvement too. Include the email you quietly rewrote and the order you double-checked because you didn't quite trust it. Otherwise the trial looks successful while you're still doing hidden work behind it.
Review returned cases together, and look at the cause, not just the number:
- A question about a missing cancellation policy is different from one clearly answered in the note.
- A pause caused by missing access says nothing about decision-making.
Repeated corrections need a closer look. Is the same fact being missed after clear feedback? Or is each new case exposing another rule you've never written?
That's how you answer "is it training, or is it the person?" Give them clear instructions, the information they need and a chance to apply feedback. Then see whether the same understood mistake keeps coming back.
And notice decisions you reopened unnecessarily. If your VA followed the rule and got an acceptable result, your urge to redo it is part of the workload you're trying to remove.
Our VA KPI guide can help you build this into a lasting scorecard.
Expand authority only where the work has earned it
After the trial, decide what changes based on what you saw.
If routine cases were handled well but conflicting records caused sensible pauses, keep the routine permission. Decide how to handle the conflicts before expanding.
Don't respond to success by handing over everything. Processing a standard refund doesn't prove readiness to negotiate compensation or respond to a legal threat.
Widen one boundary at a time. Add another clearly defined case type, test it on past records, then review live use.
Keep the working note current. When a policy changes, your VA needs to know which version applies and from when. Old examples shouldn't quietly override a new rule.
Some decisions should stay with you or another qualified person forever. That's a sensible outcome when the consequences justify it.
And if you use an AI tool for any part of this, the same written boundaries help, but they're not controls on their own. Restrict the tool's actual permissions and check its output before allowing anything consequential. A written "do not" isn't an access restriction. Our AI vs VA guide explains more.
You'll know it's working when ordinary cases stop reaching you
Go back to that draft customer email.
At the start, you had to check it because your VA didn't know which purchase policy applied. Now they know where to find the policy, how to match it to the order, and what they can do when the evidence is clear.
If records conflict, the question that reaches you explains the conflict. You only handle the part that genuinely needs you.
You can see the difference in the records. Ordinary requests close without coming back. Exceptions arrive with facts already gathered. Corrections lead to a changed instruction or a specific training action.
Keep the final working note beside the reviewed cases. The note explains the permission. The cases prove your VA can use it.
When the next ordinary request arrives, let them finish it. Check it at the agreed review time, rather than jumping in before they've had the chance.
Your delegation working note template
DELEGATION WORKING NOTE
Task:
Cases this covers (specific conditions):
Cases this excludes:
Evidence to check, and where it lives:
1.
2.
3.
You may:
You may not:
Needs my approval:
Finished means (and the proof):
Stop and ask when:
When you stop:
Send the question to:
Include: proposed action / evidence / unresolved point
What the customer can be told meanwhile:
Practice cases tested (links and results):
Review point:
Related: how to train a virtual assistant and how to write SOPs your VA can follow.
Frequently asked questions
Why does my virtual assistant keep asking me questions?
Usually because you handed over the activity but kept the decisions. Every unwritten rule comes back as a question. Look at what the questions are about to find the decisions you still need to make or hand over.
What is the best way to delegate to a VA?
Hand over a bounded decision: a specific situation, the evidence to check, the action they can take, what finished looks like and when to stop. Test it on past cases before going live.
Should my VA get approval before every action?
During training, sometimes. But if every case needs your approval, the work never really leaves your desk. Define a group of ordinary cases they can finish alone, and keep review for exceptions.
How do I know if my VA needs more training or isn't right for the role?
Give clear instructions, the right access and a chance to apply feedback. If the same understood mistake keeps happening after that, it's a different conversation from a missing rule or missing access.
Can I use the same delegation approach with AI tools?
The written boundaries help, but they're not controls on their own. Restrict the tool's real permissions and check its output before allowing consequential actions.