Document before you delegate: why most VA hires fail in month one

Almost every founder who tells us their last virtual assistant "didn't work out" describes the same first week.

The assistant was given a set of logins, a short call about what needed doing, and an invitation to ask questions. Two weeks later the founder was spending more time answering those questions than the work had taken in the first place. By week six they'd quietly taken it all back.

The failure gets attributed to the assistant. It is almost never the assistant.

What actually went wrong

You cannot delegate a process that does not exist outside your head.

When work has lived with one person for years, it stops looking like a process. It looks like a series of obvious decisions. The founder genuinely believes there isn't much to explain — right up until someone asks why supplier orders go out on Tuesday, and the honest answer is that a supplier changed their cutoff in 2022 and nobody wrote it down.

There are typically dozens of those. Each one is small. Collectively they are the job.

Handing someone logins and expecting them to reconstruct that from first principles is not delegation. It's an exam nobody can pass.

Document first — it takes less time than you think

Before an assistant starts, we spend two days documenting the recurring processes that consume the most time. Not exhaustively. Not beautifully. Enough.

For one eCommerce client that produced eighteen SOPs, most of them under a page. The format for each is deliberately minimal:

• Trigger — what causes this to need doing, and when
• Steps — numbered, with the actual tool and the actual button
• Judgement calls — the decisions that aren't mechanical, with the rule of thumb
• Escalate when — the explicit line where it stops and comes back to you
• Done looks like — how anyone can tell it was completed correctly

That fourth section is the one people skip and the one that matters most. Without an explicit escalation line, an assistant has two bad options: interrupt you constantly, or guess. Both are how the arrangement ends.

What documenting first changes

Onboarding cost collapses. The founder above spent roughly four hours on onboarding, against the four weeks they'd budgeted from the previous attempt. The assistant trained against the documentation, not by shadowing someone who didn't have time to be shadowed.

Replacement stops being catastrophic. If it doesn't work out — and sometimes it doesn't — the next person starts from documentation rather than zero. The cost of a bad match drops from months to days.

You find out how much of it shouldn't exist. This is the unadvertised benefit. Writing down eighteen processes reliably reveals that two or three are pure historical residue. One client discovered a weekly report that had been produced for three years and read by nobody since the person who requested it left.

It becomes hiring material. Those eighteen SOPs later became the onboarding pack for two permanent hires. The documentation outlived the engagement that produced it.

The two-day objection

The universal response is that there isn't time to spend two days writing documentation, which is precisely why an assistant is needed in the first place.

That is true and it is also the trap. The two days are not additional work — they're work being brought forward. You will spend that time either way: two days up front in a structured block, or twenty hours spread across six weeks of interruptions, in worse conditions, while also being interrupted.

The second option costs more, produces no reusable artefact, and ends with you concluding that delegation doesn't work for your business.

If a process only exists in your head, you haven't got a process. You've got a dependency — and hiring someone to take it over doesn't remove it, it just adds a person who is now also dependent on you.

---

This is stage one of every virtual assistant engagement we run, before anyone is matched to a role. The Verge Commerce case study covers what it produced in practice.