A proper virtual assistant trial task is the step most people skip. The interview went well. The sample looked relevant. You're ready to say yes.
But there's still a gap between someone explaining how they'd work and actually doing the work, with your inputs, your rules and the kind of messy complication that turns up every week.
A virtual assistant trial task fills that gap.
A good one looks like the real job. It's small enough to check properly, has a fair fee, and includes the sort of uncertainty that real work always has. It's not a puzzle designed to trip someone up. It's not a free project in disguise. And it's not proof of permanent reliability.
This guide walks you through designing one, then gives you a complete ready-made example you can adapt, with fictional cases, the rules, and what good answers look like.
Here, a virtual assistant (VA) is an independent freelancer or agency. The trial is a small paid assignment before a bigger commitment.
Decide what the trial needs to prove
Look back at your application and interview notes. What are you still unsure about?
- Maybe they explained source checking brilliantly but never showed it.
- Maybe their writing is great, but you don't know if they'll keep an unfinished case open instead of quietly closing it.
Test that.
Use a slice of the real job. If the job is managing a returns queue, a general essay about productivity tells you nothing. If customer contact matters, a spreadsheet-only test misses half the job.
Before building the task, write down:
- What a successful result looks like.
- Which ordinary complication should appear.
- How much work is enough without becoming excessive.
- What you'll do if the trial reveals a problem with your instructions rather than their skill.
Every part of the task should have a reason to be there. If something's only there to make it harder or more interesting, remove it. Difficulty is only useful when it matches a real demand of the job.
Agree the fee and the limits before you send anything
State clearly:
- the fee and currency,
- when it's paid,
- expected effort (a time limit),
- the deadline, with time zone,
- what happens if it takes longer than expected.
A fixed fee suits a clearly bounded task. An hourly fee with a cap suits uncertain effort. Either way, pay according to the agreed terms, whether or not you continue together.
Upwork's rules explicitly prohibit asking freelancers for free work, including work submitted just to win a job. Other platforms have their own rules.
Also agree which tools are allowed. If the real job allows AI assistance, you can allow it in the trial, as long as they check the result and mention meaningful use. If you want to test unaided writing, say so beforehand. Don't change the rules after they submit.
And be clear that completing the trial doesn't guarantee further work, and no ongoing service starts automatically.
Use invented data that keeps the real decisions
Real customer data in a trial is a bad idea. Use made-up information instead, but keep the same structure and the same kinds of decisions.
The trick is making sure not every case is clean. Include at least one common gap or conflict the candidate should notice:
- a return request missing an order reference,
- a message that contradicts an old tracker entry.
The complication must be visible from the information you provide. Testing whether someone spots a problem is fair. Hiding an essential rule and punishing them for not guessing it isn't.
Avoid realistic-looking contact details that might belong to real people. Case IDs and role labels are usually enough.
And never ask a candidate to contact anyone, buy anything or change a live system as part of a trial.
If you share files, put them in a dedicated, properly restricted folder. Google Drive's sharing guidance explains that access to a folder is inherited by everything inside it. Don't accidentally share your business drive because the trial file happened to sit inside it.
A complete example: the equipment returns queue
Here's a ready-made trial for a made-up equipment hire business. The real job involves reading customer messages, matching them to hire records and flagging problems. Financial adjustments and disputes stay with the owner.
It tests evidence handling, decision boundaries and handover quality. It doesn't test equipment safety knowledge, debt collection or accounting.
Here's what you send the candidate:
PAID TRIAL: PREPARE AN EQUIPMENT-RETURN REVIEW QUEUE
Purpose
Use the fictional records below to prepare a review queue and draft
messages. Do not contact anyone or access any live account.
Terms (agree before starting)
Fee: US$60 for this exercise (example only), paid on delivery whether
or not we continue. Maximum effort: 90 minutes. Agree the deadline and
time zone before accepting. If you can't finish within the limit,
stop and send what you've done, the remaining issues and a short
explanation. Don't add unapproved time.
Tools
A spreadsheet and document editor are enough. AI may be used only on
the fictional material provided. Mention any use that shaped your
answer, and check every result yourself.
Rules
- A customer saying equipment was returned is NOT warehouse
confirmation.
- Mark a return "confirmed" only when the warehouse record matches the
hire reference AND the item.
- If a record is missing or inconsistent, keep it unresolved and
request the relevant check in your internal note.
- Do not decide charges, issue refunds or promise an account is closed.
- Don't change the source records. Work in a separate queue.
What to deliver
A queue with: case reference, evidence used, current state, permitted
next action, decision owner, unresolved question.
A draft customer message where one is needed.
A short note listing any assumptions, conflicts or gaps in these
instructions.
How it will be judged
Whether states follow the evidence, exceptions stay visible, messages
avoid unsupported promises, and someone else could pick up each case
from your record. Visual design is not assessed. A correct unresolved
case is better than a confident made-up resolution.
The four cases, and why each one is there
Here are the fictional records. Every case tests something specific.
CASE R-101
Hire record: R-101, one projector.
Customer: "The projector has been returned. Please confirm receipt."
Warehouse: R-101, one projector received, item matches.
Old tracker: awaiting return.
CASE R-102
Hire record: R-102, one speaker.
Customer: "We left the speaker at the collection desk. Please close
this and confirm no further charges apply."
Warehouse: no matching receipt.
Old tracker: awaiting return.
CASE R-103
Hire record: R-103, one microphone kit.
Customer: "The microphone kit has been returned."
Warehouse: R-103, one SPEAKER received.
Old tracker: return confirmed.
CASE R-104
Customer: "We returned the lights. Can you check the booking?"
Hire record: no reference supplied.
Warehouse: no identifiable matching record.
Old tracker: no matching entry.
R-101 tests routine matching. Easy.
R-102 tests whether a customer request gets mistaken for authority. They asked you to confirm no charges. You can't.
R-103 tests a conflict between current evidence and an old status. The tracker says "confirmed," but the warehouse logged the wrong item.
R-104 tests what happens when the identifier is missing altogether.
No obscure traps. No white text. No misleading filenames. Every complication is visible in the information provided.
Keep your expected-answer notes separate and don't share them.
What good answers look like (write these before results arrive)
Decide your standard before anyone submits.
R-101: The queue records a matched warehouse receipt. The draft confirms the projector was received. It doesn't promise every financial issue is closed, because nothing in the trial gives that authority.
R-102: The return stays unconfirmed. The candidate requests an internal warehouse check and avoids confirming "no charges." A good draft acknowledges the message and explains receipt is being checked.
R-103: The candidate spots that the hire was a microphone kit but the warehouse received a speaker, and doesn't trust the old "confirmed" status. They flag it for review instead of guessing which record has the typo.
A strong internal note might read:
"Warehouse entry shows a speaker, but the hire was a microphone kit. Old tracker says confirmed. Please verify the warehouse receipt before any customer confirmation. No source record changed."
R-104: The case stays unresolved. A draft asks for the hire reference or another permitted identifier. They don't match it to a random booking or claim the lights arrived.
A strong submission might use different labels or a different layout. That's fine. Judge whether the next person could act safely from it, not whether it matches the spreadsheet in your head.
Answer questions without quietly changing the test
Give the candidate a clear way to ask questions and a realistic reply time.
Keep a note of every clarification. If you discover a rule was unclear, consider giving the same clarification to every other finalist. Otherwise you're no longer comparing like with like.
Tell the difference between:
- A helpful question: "Should the warehouse mismatch stay unresolved?" That shows they understand authority.
- A request to do the task for them: "Can you fill in the queue fields?" That leaves the skill untested.
If they hit the time cap, follow the agreed rule. A clear partial result with remaining work listed is often more useful than extra unpaid hours hidden to impress you.
And don't add new cases halfway through. If something new needs testing, agree another paid task afterwards.
Check the work against the evidence before reading their explanation
When the submission arrives, open the deliverable first. Compare each case against the source records:
- Are the required fields there?
- Are the statuses supported by evidence?
- Do the draft messages stay within authority?
Only then read their method note. This stops a well-written explanation from hiding an incorrect record.
Score these separately:
- Accuracy
- Handling exceptions
- Communication
- Handover quality
A plain spreadsheet might score highly on all four. A beautiful one can fail if it closes R-102 without evidence.
Pay attention to how serious each issue is. A spelling mistake is not the same as promising a customer there are no charges. Don't average a serious authority failure into an "okay" overall result.
Was it the candidate, or was it your brief?
Sometimes a candidate follows your written rules perfectly and still produces something different from what you expected.
Before judging them, ask: did I actually tell them that? Does the difference matter to the result? If not, it's a preference, not a mistake.
If they repeatedly ignored clearly supplied evidence, that's different. If they marked R-103 "confirmed" despite noticing the mismatch, ask why. Their answer might reveal a misunderstanding about authority that training could fix, or a deeper mismatch with the job.
Ask yourself whether the gap is realistically trainable. Learning your file labels is easy. Learning a whole specialist profession isn't.
If a correction round would help, agree whether it's included or paid separately. Keep the original submission. You want to see if they can apply feedback, not erase the evidence that they needed it.
Trial ideas for other common VA roles
The returns queue suits admin and operations. Here's how the same idea works for other jobs. Every one includes one ordinary case and at least one that should be paused.
Calendar management. Give a fictional calendar and three meeting requests. One fits cleanly. One fits only if a protected preparation block is ignored. One says "Thursday afternoon" with no time zone. A strong result books the first and asks questions about the other two.
Inbox management. Give ten invented emails. Include a newsletter, a routine booking request, a complaint, and an invoice asking to update bank details. A strong result sorts them, drafts the routine reply, escalates the complaint, and refuses to act on the bank change.
Customer support. Give three invented tickets plus a short policy. One is clearly covered by the policy. One asks for an exception. One mentions an earlier promise. A strong result answers the first, escalates the second, and searches for the promise before replying to the third.
Research. Ask for a comparison of three fictional suppliers using a small pack of "web pages" you've written. Make one key fact appear only on a reseller's page. A strong result separates verified facts from unverified claims.
Social media. Give a product sheet and ask for three captions. Include a tempting claim that the sheet doesn't support. A strong result stays within the evidence.
Keep the time limit, fee and rules the same as in the main example.
Close the trial cleanly before going live
Pay the agreed fee promptly and tell them your decision.
If you're continuing:
- Say what the trial showed.
- Say what the first live job will be.
- Confirm the ongoing agreement, fees, availability, authority and data handling before granting live access.
A good result on fictional data doesn't justify broad permissions or an open-ended retainer. Start with the responsibility you actually tested.
If you're not continuing, keep it short and factual. No speculative judgements about their abilities.
Then tidy up. Remove trial access. Restrict or delete files you don't need to keep. If you're in the UK, the ICO's recruitment guidance covers contractors too. When checked in September 2026 it was marked as under review following the Data (Use and Access) Act, so treat it as context rather than a final rulebook.
A trial should end with a clear, limited conclusion:
"This person showed these skills on these cases. These questions remain. This is what we'll agree next."
That's enough to make a much better decision, without pretending a short task can prove everything.
Next: once you've chosen, use our onboarding checklist to get the first month right. For the bigger picture, see how to hire a virtual assistant.
Frequently asked questions
Should a virtual assistant trial task be paid?
Yes. Pay an agreed fee whether or not you continue. Unpaid test work puts off good candidates, and some freelance platforms prohibit it.
How long should a VA trial task take?
Long enough to show their method on a few realistic cases, often an hour or two. Set a time limit and say what to do if they reach it.
Can I use real customer data in a trial?
Avoid it. Use invented data with the same structure and decisions. Don't give a candidate live account access during a trial.
What makes a good virtual assistant test project?
It resembles the real work, includes at least one ordinary complication, has clear rules and scoring decided in advance, and is small enough to review properly.
What if the candidate does well on the trial but struggles with live work?
Look at what was different. Interruptions, volume or missing information may exist in live work but not in the test. A trial is evidence about a specific task, not a guarantee.