Your VA cannot tell a moved menu from a mistake. That is the whole problem with handing a new contractor a set of SOPs written against screens the vendors have since redesigned.
No, a new VA should not run refunds, macros or customer sends from your existing SOPs in week one. Not because they are new, but because your SOPs are probably describing screens that no longer exist, and a contractor who started on Monday has no way to tell a moved menu from their own mistake.
The fix is a first week spent checking the documents rather than trusting them. The VA re-records your highest-risk tasks, someone compares each recording against the written SOP, and only the steps that survive that comparison go live.
The broader handoff, which tasks to give a VA in what order and how to ramp them over a month, is covered separately in the 30-day guide linked below. This article is only about the first week and only about verifying the documentation.
An experienced team member who hits a redesigned screen shrugs and finds the new button. They have years of context telling them the task still exists somewhere. A VA in week two has no such context. All they have is your document, and when the document and the screen disagree, the document is the only thing they were told to trust.
That gives them three bad options: guess, message you and wait, or skip the step. None of those is in the SOP, and the worst outcomes come from the first one.
Drift also happens below the screen, where nobody is looking at all. Klaviyo's developer changelog marks revision 2026-07-15 with breaking changes to its Conversations API: a profile's conversation relationship is now plural and multi-channel, returning a list rather than a single object, and it replaces the singular endpoint and include parameter from earlier revisions. Any procedure telling a VA how to check an integration built on the old shape is now describing data that no longer comes back in that form, and there is no visual cue anywhere that it has changed.
The six signals that reveal drift, and why a stale procedure looks exactly like a current one until someone follows it literally.
Here is a live example a VA can hit today, using nothing but Gorgias's own published material.
Gorgias's help centre article on connecting a Shopify store gives this route: click the Settings icon in the bottom-left corner, find Workspace in the menu, select Store, then click Add new store in the top-right.
A Gorgias blog post about the Shopify integration gives a different one: go to Settings, then App Store, then All Apps, then Shopify, and click Add Shopify.
| Gorgias blog post | Gorgias help centre | |
|---|---|---|
| Starting point | Settings, then App Store | Settings icon, then Workspace, then Store |
| Final button | Add Shopify | Add new store |
| Published | January 2025 | Current documentation |
That last row is the point. These are not two equally valid paths. One is a marketing post from January 2025 that nobody went back to update, and it is still sitting in Google next to the correct documentation, which is exactly where a VA searching for the task will find it.
Now imagine that older route copied into your SOP eighteen months ago. The instruction says open the App Store and pick Shopify from the app list. The VA cannot find App Store. Nothing is broken, nobody gets an error, and the only person who knows something is wrong is the one person least equipped to judge it.
A wrong step in a reporting task wastes an afternoon. A wrong step in a refund task moves money, and it can move it twice, because a modern support stack has several doors into the same action.
Gorgias also has a shopper-facing feature called Order Management, and it behaves differently. Its documentation is explicit that shoppers cannot trigger automatic refunds or cancellations through it: clicking the refund button only submits a request. If your SOP says refunds happen through Order Management, check which of the two things it actually means.
Put those together and the double-refund scenario writes itself. This is a scenario rather than a reported incident, but the mechanics are all documented. Your SOP says refund from the ticket. The team has since moved refunds into a macro. The VA follows the SOP, the step does not look the way the document describes, they assume it failed, and they try the other door. Two refunds, one order.
It gets worse when the outcome is invisible. Gorgias's own documentation for the ReturnGO integration lists issuing a refund to the original payment method among the actions that create no update in Gorgias at all. It appears in the customer's order history instead. A VA checking the ticket for confirmation sees nothing, concludes it did not work, and tries again.
The procedure itself, with the branches that have consequences and a worked example of what a vendor redesign did to it.
Try it on one of your own procedures.
Record a process once, AI writes the structured SOP. 3 free SOPs, no credit card.
Order the list by blast radius, meaning how much damage one wrong step does. Keep it short enough that you will actually review every recording, because an unreviewed recording is just a video.
| Priority | Tasks | Why |
|---|---|---|
| 1. Moves money | Refunds, cancellations, discount codes | Irreversible or close to it, and the failure is a real cost rather than a delay |
| 2. Reaches customers | Macros carrying order actions, email and SMS flows | A wrong step here is public and cannot be recalled |
| 3. Changes on you | Store connections, settings paths, anything on a screen a vendor has redesigned | Lowest stakes per mistake, highest rate of drift |
The method needs no particular tool. Any screen recorder plus the document you already have. What matters is that the VA narrates each step aloud as they work, describing what they see rather than what they expected to see. That narration is what turns a training video into something you can compare against a document.
One rule holds the week together: a step reaches live work only after it has been verified.
Four days of checking before the first live refund sounds expensive until you price the alternative, which is finding out about the stale step through a customer.
A flagged step has two possible causes and they need opposite responses, so work out which one you have before you touch anything.
| Cause | How to tell | What to do |
|---|---|---|
| The vendor changed the screen | The VA's route matches what the screen shows now, and the document does not | The document is wrong. Rewrite the step and note when the change was spotted |
| The VA did something different | The screen still matches the document, and the VA took another path | The document is fine. Coach the VA, and check whether the step was ambiguous rather than wrong |
Check in that order, not the other way round. Assuming the new person made a mistake is the reflex, and it is how a stale document survives its own review.
Either way, do not overwrite the old wording. Keep the previous version visible beside the new one, so the next contractor can see what changed and when, rather than inheriting a document with no history and being asked to trust it.
Why the old version is worth keeping, and what to do instead of editing over the top of a procedure.
A flagged refund, cancellation or customer-send step blocks live work on that task until it is resolved. Everything else can proceed. That one waits.
Four honest failure modes, because a process that claims none is not describing reality.
That last one is the reason to treat vendor releases as a review trigger for the procedures that touch them, rather than waiting for an annual documentation review that will find the problem months after your VA did.
What happens after week one: which tasks to hand over in what order, how to ramp across a month, and how to check work without micromanaging.
Start with the single refund procedure your VA will touch first. Have them record it against the current document, then go through the two line by line and mark every step. Whatever that one comparison turns up is a fair sample of the rest of your library.
A first week in which the new VA re-records your highest-risk tasks and each recording is compared against the written SOP, so steps that no longer match the software are found before they touch live work. It treats your documentation as something to verify rather than something to hand over, on the basis that a new contractor cannot tell a redesigned screen from their own error.
Only at the end of it, only supervised, and only on refund procedures whose recordings matched the written steps. A flagged refund step blocks live work on that task until the owner has resolved it. The risk is not the VA's competence, it is that refunds can be issued from several places in a modern support stack, so a VA who believes one attempt failed has somewhere else to try.
After any vendor release that touches the screens a task uses, rather than on a calendar. Money-moving tasks also need re-recording whenever your team changes where an action is performed, such as moving refunds from the ticket sidebar into a macro, because that change leaves no trace in the software at all.
Shorten the list rather than the review. Three refund procedures checked properly is worth more than twelve skimmed, and anything not reviewed simply stays off live work. A comparison nobody approves is a flag, not a fix.
No. This is the first week, and it is about the documents rather than the person. The ramp that follows it, handing tasks over in order of risk and moving from full review to independence across a month, is a separate exercise covered in the 30-day handoff guide.
3 free SOPs to start. No credit card required. See if drift detection keeps your docs honest.
Start for freeI built ReccordSOP after watching too many DTC ops teams lose months to undocumented workflows. These SOPs are battle-tested with Shopify operators running $1M to $50M brands.
Last reviewed September 15, 2026
Most VA hires fail at the handoff, not the hire. The 30-day ramp, the order to give tasks in, and what to write down before day one.
A refund starts in your helpdesk and ends in your store. The seam between them is where refund procedures quietly break.
Most SOPs are wrong within 90 days of publishing. Here's how to detect it before it costs you a customer.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.