← all posts

How to Onboard and Train a New Virtual Assistant in a Week

Most people know how to hire a virtual assistant but never learn how to train a virtual assistant, and a month later they are wondering why it is not really working. The tasks come back half done, they are redoing things at eleven at night, and they quietly decide getting help was a mistake. Almost every time, the problem is not the person they hired. It is the onboarding, or really the near-total lack of any.

So here is my process: how I take a brand new assistant from their first day to genuinely useful, running real tasks on their own, in a week. There is nothing magic about it — mostly going slow on purpose, in the right order. The video above walks through the same process if you would rather watch than read.

Why the first week is an investment

Here is the mindset that changes everything. The first week with a new assistant is not overhead, it is an investment. You will do things you could have done yourself in ten minutes, and part of your brain will insist you are wasting your time. You are not.

Every hour you put in that first week buys you months where you barely think about that work. Rush someone through their first few days to save time now, and you pay for it across the next three months: explaining the same task, fixing the same mistakes, losing trust on both sides. Going slow and being clear at the start is the cheapest insurance you will ever buy.

Day one is access and expectations

The goal on day one is not to finish real work. It is to get the person set up, comfortable, and clear on how you will work together.

1. Access. I give scoped logins, and never my master passwords — a separate account with only the permissions they need for the tasks I am handing over. If something ever goes wrong, or the day comes when you part ways, you want to switch off one login cleanly, not change every password you own in a panic.
2. Tools. I point them at the two or three tools they will touch this week, and nothing more — do not dump the entire stack on day one.
3. Rhythm. I tell them where we talk, how fast they can expect an answer, and when I am usually offline, so they are never stuck and afraid to ask.
4. Preferences. I ask how they like to work. Small stuff, but it keeps the first day calm, which is what a nervous first day should feel like.

The method is record then document

Here is the real engine that everything else hangs on. I call it record then document.

The first time I hand off a task, I do not explain it in a wall of text or live on a call. I do the task once myself on a screen recording, talking out loud through every step: why I click this, what I am checking for, what I do when something looks off. It costs me one extra pass through a task I was doing anyway.

That recording becomes the raw material for a simple standard operating procedure the person can follow on their own and, just as importantly, improve as they learn. The recording shows them how it flows; the written SOP gives them something to check against, step by step, without scrubbing through a video every time.

You record it once, you write it down once, and from then on the task has an answer that lives outside your own head, something you both own.

Where AI actually helps

This is where AI earns its place, and I want to be precise about it. Writing that first guide from scratch is tedious: you have a rambling recording full of ums and false starts.

So I take the plain transcript, hand it to an AI model, and ask it to turn the mess into a clean first draft: numbered steps, plain language, right order. It gives you a real starting point in seconds instead of half an hour of typing from nothing.

But that draft is never the finished thing. The assistant and I read through it together, fix the parts the model quietly got wrong, and add the small warnings that only come from having done the task. The AI does the boring first pass. The human still owns the final SOP, every single time. I am using it to skip the typing, not to decide how we work.

Start with one task, not the job

Here is the mistake almost everyone makes, myself included: you are so relieved to finally have help that you hand over the whole job at once. Do not.

Start with one task. A single, small, well-defined slice of the work with a clear finish line, so they always know what done looks like. Let them run it, and check the first few times closely so you can give real feedback while it counts.

Be specific. Do not just say "that was great" or "that was wrong." Say this part was exactly right, keep doing that, and this field needs the date in this format, and here is why. Kind and specific at once. Once they can run that first task without you looking over their shoulder, you widen: add the next task, and the next. Before long you are handing over whole areas of the work, because the person has learned how you actually think.

The feedback loop that makes it stick

None of this holds together without a feedback loop. In the first week I do a short daily check-in over chat: what did you work on, what got in your way, what was unclear. I am not managing them minute by minute. I am closing the gap between a small mistake and someone catching it, so nothing hardens into a bad habit.

As the week goes on and things click, I back off: the daily check-in becomes every couple of days, then twice a week, then whenever we need it. The point is to need each other less over time, not more.

And here is the honest part. Almost every mistake in that first week is not their fault; it is an unclear instruction, and that is on me. So when something comes back wrong, nine times out of ten the fix is not a stern talking-to. It is me writing a clearer guide.

Building a library of how we work

As the weeks add up, every task you record and write down once becomes a permanent asset: a small, steadily growing library of how your business works, in plain language, somewhere you can both reach.

This compounds: the tenth task is far easier to document than the first, because now you have a template and a rhythm. Then a line gets crossed: the assistant stops following your guides and starts improving them. They hit an unclear step, or find a faster way, and update the SOP themselves. That is the moment a hire turns into a real teammate. And if that person ever moves on, the library stays, so the next person starts from everything the last one learned instead of from zero.

What week one should end with

At the end of week one I am not expecting someone who can run my whole business — that is months of work. What I am expecting is real, and it is enough:

• A person who can run two or three specific tasks completely on their own, without me checking every result.
• A small but real library of written SOPs covering exactly those tasks.
• A working relationship where they feel comfortable telling me when something is unclear, instead of guessing and hoping.

That is a strong first week. Two or three tasks lifted off your plate for good, documented so they stay off, and a person who will only keep getting better. It mostly looks like a little more breathing room than you had seven days earlier, and a foundation to build the next month on.

If you still need to hire someone

Maybe this sounds great but you have not hired anybody yet. I hire remote assistants through a site called OnlineJobs.ph, and I have a separate walkthrough of my exact hiring process. To be straight with you, browsing is free but messaging workers needs a paid employer plan, so it is not a free tool; you subscribe for the month you are hiring and cancel once you have found your person.

The onboarding, though, is what decides whether any of this works: record then document, start with one small task, daily check-ins that first week then back off, build the library as you go, and treat the person like the capable teammate they genuinely are. Do that, and the first week will quietly pay you back for months. If you want to try OnlineJobs.ph yourself, that is what the button below is for.