Four rows on one page, each written so a stand-in can keep orders moving without calling the owner. The hard part isn't writing it. It's keeping the procedures it points to current.
A business continuity plan is a written plan for keeping your business running through a disruption. For a small Shopify store, it fits on one page: one row for each thing that would stop orders going out.
Four rows cover most stores: a Shopify or checkout problem, payments going wrong, your warehouse or 3PL failing, and the one person who knows how something works being unavailable. Add a fifth if all your logins sit with a single person.
Each row names a warning sign anyone can check, who steps in, the access they need already set up, and a link to a procedure they can follow with no help. The links are what make it a plan. A page that points to out-of-date procedures looks prepared and isn't.
Most continuity templates start from disasters: fire, flood, illness, a power cut. Those matter if your stock sits in a warehouse in a flood zone, and the free templates are worth borrowing for that.
But a Shopify store mostly runs inside other companies' software. The outage that costs you a weekend is usually something smaller: checkout running slowly, orders stuck between your store and your 3PL, or a 3PL quietly missing its shipping times. A flood checklist has no row for any of that.
| Column | Why it's there |
|---|---|
| Warning sign | Turns "something feels wrong" into something anyone can check |
| Who decides, by role | Someone can act while the owner is unreachable |
| Who does the work, by role | Names who runs the steps, which may be a different person |
| Linked procedure and last review date | The column most plans leave out, and the one that decides whether the row works |
| Access set up in advance | Access requested during an outage is access nobody has |
| Customer message, and who may send it | Stops someone improvising a public statement under pressure |
| Clean-up afterwards | Orders, stock counts and refunds to reconcile once it's over |
| What forces an update | A change, not a calendar date |
Write roles, not names. Roles survive staff changes; names don't.
The linked procedure needs numbered steps, one action each, written so someone with no background can follow them.
The minimum structure for a procedure a stand-in can follow cold.
Make the warning sign specific. "The site is down" isn't one. "Checkout shows degraded performance on Shopify's status page and a test order from our own store fails" is, because two people reading it at 6am reach the same conclusion.
Shopify's status page shows each part of the platform as operational, degraded, partially or fully out, or in maintenance, and links to a status view for your own store. Pair it with a check inside your own store, such as a test order, because your store can be broken while the platform looks fine.
Don't build this row around being alerted. Shopify removed text-message and RSS alerts from its status page when it moved to store-specific status. Someone has to look, so write down who and how often.
How to place a test order safely on a live store, which doubles as your own outage check.
Try it on one of your own procedures.
Record a process once, AI writes the structured SOP. 3 free SOPs, no credit card.
When payments are failing, three things should already be decided: who can pause ad spend that is sending people to a broken checkout, the exact message customers see and where it goes, and how much a stand-in can refund without the owner. A message written live under pressure is the one that gets screenshotted.
The holding message and the refund rule belong in your support procedure before anything goes wrong.
The refund steps and approval threshold a stand-in can work to.
If you sell subscriptions, failed payments have their own playbook, and it is worth knowing which company actually handles the payment before writing down who to call.
Retries, reminders and the recovery sequence for subscription payments.
Split this row, because the two failures look nothing alike.
The first is the connection between your store and your warehouse quietly breaking. Orders stop flowing, or stock levels stop updating, and you oversell. The warning sign is anything sitting in your integration's error queue, or a stock count that disagrees between your store and the warehouse.
The second is the 3PL itself missing its service levels. That warning sign should be a number from your 3PL scorecard, not a feeling.
The numbers to hold a fulfilment partner to, which become this row's warning sign.
If you ever need to move to another warehouse in a hurry, the new one will need your data first: product sizes and weights, how items are packed, accurate stock counts, your order volumes including your busiest periods, and any rules about expiry dates or batches. Keep that in one file. It serves you whether you are joining a 3PL or leaving one.
Make the warning sign a time window. "The support lead hasn't replied on our agreed channel within four hours in working hours" is something you can check. "If someone quits" isn't, and it's too late anyway.
This row needs two things owners usually leave out: which decisions the stand-in can make alone, and which regular tasks simply stop until the person is back, rather than being half-done by someone guessing.
And the knowledge has to be captured before anyone is away, not during.
What to get out of one person's head, and in what order.
Every login the stand-in needs should be set up before anything goes wrong. Access requested during an outage is access they don't have.
For a small store the list is short: their own Shopify login with permissions for the task rather than full admin, the helpdesk, your carrier accounts and the 3PL portal. Add a written spending limit, as a number: the refund amount above which they wait for the owner. A stand-in without a number escalates everything, which is the same as having no stand-in.
Giving a stand-in the exact permissions for the job, rather than the whole store.
A plan is only as good as the procedures it links to, and those go out of date every time a tool changes its screens. So check them by running them, not by reading them.
Update the plan when something changes, not once a year: a new supplier or app, a move to a new 3PL, a staff change, a tool that redesigns a screen your procedure relies on, and after any real incident, while the details are fresh.
Then test one row cheaply. Hand it to the named stand-in, stay silent for an hour, and write down exactly where they got stuck. That list is your update list. Ready.gov puts it plainly: "Training, testing and exercises are essential components of preparedness."
How procedures quietly stop matching the screens they describe.
Where this still fails, honestly:
This is where ReccordSOP helps. Record each procedure once and it becomes a step-by-step SOP with a screenshot of each step and the clicked button highlighted. Record it again after a tool changes, and it shows which steps changed instead of overwriting the old version. It emails the owner when a published SOP has gone 90 days without a review, and you can send a procedure to your stand-in as a checklist run, which is exactly the hour-long test above. What it won't do is watch your store or decide anything for you.
Write the four rows on one page this week; an hour is enough for a first pass. Then record the one procedure behind your most expensive row, usually fulfilment or refunds, and put its review date next to the link. The free plan covers 3 SOPs in total, enough for the riskiest rows.
A written plan for keeping the business running through a disruption. For a small Shopify store, the practical version is one page with four or five rows, each naming a warning sign, who decides and who does the work by role, a linked procedure with its last review date, access set up in advance, the customer message, and how to clean up afterwards.
Check Shopify's status page, which shows each part of the platform and links to a status view for your own store, then check something inside your store directly, such as a test order. Shopify no longer sends text-message or RSS status alerts, so someone has to look rather than wait to be told.
When something changes rather than on a date: a new supplier or app, a move to a new 3PL, a staff change, a tool changing a screen your procedure relies on, or after any real incident. Re-check any linked procedure that hasn't been reviewed in 90 days before relying on it.
Pick one row and hand it to the named stand-in. Say nothing for an hour and write down exactly where they get stuck: a missing login, a step that no longer matches the screen, a decision they weren't sure they could make. That list is what to fix.
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 October 13, 2026
A handover document tells the next person what someone believed was true on their last day. This template adds the two things it leaves out: a recording of the real work, and a way to prove the successor can do it.
A refund starts in your helpdesk and ends in your store. The seam between them is where refund procedures quietly break.
Most onboarding guides are written by 3PLs for their own benefit. This is the merchant's playbook, and the scorecard that holds any partner accountable.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.