SOP Templates for a Small Team Running Multiple Shopify Stores

How to write an SOP for your ecommerce store team: which processes to document first, a copy-paste SOP template, owner assignment, and keeping SOPs alive.

Updated 2026-07-02

A team of three can run ten Shopify stores — but only if the work lives in documents instead of in people's heads. The moment your best VA gets sick, quits, or simply forgets how store #7 handles refunds, undocumented process becomes lost revenue. This guide shows you how to write SOPs (standard operating procedures) that actually get used: which processes to document first, a copy-paste template you can steal, how to assign owners, and how to stop your SOP library from rotting.

Why SOPs matter more per store you add

With one store, tribal knowledge works. The founder answers every "how do we handle this?" in ten seconds, and the answer is consistent because one brain holds it.

At five or ten stores, the same question gets answered differently depending on who's asked, which store it's about, and how tired everyone is. The symptoms are predictable:

• Refunds handled three different ways — one VA restocks inventory, another doesn't, a third issues store credit that nobody tracks.
• Listings drift — Store A's product titles follow a naming convention; Store B's were written at 2am and follow nothing.
• Escalations by vibes — a chargeback sits in someone's inbox for four days because nobody was sure whose problem it was.
• Onboarding takes weeks — every new hire shadows someone for a month because there's nothing to read.

An SOP converts a decision you've already made into a procedure anyone can execute. That's the entire trick behind running 10+ stores without chaos: stop re-deciding, start executing.

The test of a good SOP is brutal and simple: could a competent new hire complete the task correctly, without asking anyone, using only the document? If not, the SOP isn't done.

Which processes to document first

Don't try to document everything. Rank processes by two factors: frequency (how often it happens) and blast radius (how expensive a mistake is). Document high-frequency and high-damage processes first; everything else can wait.

A few notes on the top four:

Order processing. Define exactly what "processing an order" means on your team: where orders are checked (per-store admin, or one consolidated dashboard), what counts as a flag (address mismatch, high-value order, repeat chargeback customer), and what happens to flagged orders. If your team checks ten separate Shopify admins each morning, write that down too — then read our guide on managing every store from one dashboard, because that step alone is probably an hour a day you can delete.

Refunds. This is where inconsistency costs real money. Your SOP should answer: who is allowed to refund without approval, and up to what amount? Partial or full? Do we restock inventory? Do we refund shipping? Shopify's refund flow supports partial refunds, restocking toggles, and shipping refunds separately — and critically, a refund can't be reversed once initiated, which is exactly the kind of one-way door an SOP should put a checklist in front of.

Escalations. Write down the triggers, not just the handling. "Escalate to owner if: chargeback received, order value > $300, customer threatens legal action or a public review, shipment stuck > 10 days." Every trigger needs a named destination and a response-time expectation — this pairs directly with your support SLA policy across stores.

Listing updates. The core rule to encode: changes flow one direction. Decide where product data is edited (a master sheet, a PIM, or a bulk tool) and forbid direct one-off edits in individual store admins. One sentence in an SOP — "never edit product data directly in a single store's admin" — prevents months of silent drift.

The SOP template (copy-paste skeleton)

Every SOP on your team should use the same skeleton. Uniform structure means people can skim any SOP and know where the steps are, where the edge cases are, and who to ask. Here's the template we recommend — paste it into Notion, Google Docs, or a sops/ folder in a repo:

# SOP: [Task name — verb first, e.g. "Process a refund request"]

**Owner:** [one name, not a team]
**Applies to:** [all stores / specific stores]
**Last reviewed:** [date]
**Time to complete:** [estimate]

## When to use this SOP
[The trigger. E.g. "A customer emails or messages asking for a refund,
or a refund request appears in the support inbox."]

## Before you start
- [ ] Access needed: [which tools/logins/permissions]
- [ ] Check: [preconditions — e.g. "order status is Fulfilled or Unfulfilled?"]

## Steps
1. [One action per step. Start with a verb. Include the exact
   button/menu path: "Shopify admin → Orders → select order → Refund".]
2. [Add a screenshot for any step where the UI is ambiguous.]
3. [If a step has a decision, write it as an explicit branch:
   "If order value ≤ $50 → refund immediately.
    If order value > $50 → post in #approvals and wait for a 👍."]
4. ...

## Edge cases
- **[Situation]:** [what to do]
- **Customer paid partly with gift card:** [what to do]
- **Anything not listed here:** escalate (see below), do not improvise.

## Escalation
- Escalate to: [name/channel]
- Escalate when: [explicit triggers]
- Expected response time: [e.g. within 4 business hours]

## Done means
- [ ] [Observable end state — e.g. "refund shows in Shopify order timeline"]
- [ ] [Logging — e.g. "row added to refund log sheet"]
- [ ] [Customer notified with template X]

## Changelog
- [date] — [who] — [what changed and why]

Why each block earns its place:

• Owner is one name. "The support team owns this" means nobody owns it.
• "When to use" stops the wrong SOP being followed for a similar-looking situation.
• Decision branches are written inline, not left to judgment. Judgment is what the escalation section is for.
• "Done means" is the most skipped and most valuable section. It turns "I think I finished" into a checkable state — and it's where you enforce logging, which feeds your team KPI dashboard later.
• Changelog makes the SOP auditable. When a refund goes wrong in March, you can see the procedure as it existed in March.

Keep each SOP under two pages. If it's longer, it's two SOPs.

Assigning owners (and access)

An SOP without an owner is a wiki page waiting to die. Assign each SOP to exactly one person with three responsibilities:

1. Accuracy — the steps match reality today, not last quarter.
2. Training — new team members learn this task from the owner, using the doc.
3. Review — the owner signs off on the review date (more below).

Owners don't have to be managers. Your best VA who processes refunds daily is a better refund-SOP owner than the founder who last touched a refund in January. If you're building out a VA team, bake SOP ownership into their growth path — it's one of the clearest signals in hiring and training VAs for Shopify operations that someone is ready for more responsibility.

Match SOPs to permissions. A procedure that says "VA refunds up to $50 without approval" only holds if the VA's Shopify staff permissions actually stop at refunds — and don't quietly include editing payout settings or deleting products. Shopify's staff permissions let you grant granular access per store, but at ten stores that's ten separate permission setups to configure and audit. This is one of the two places a multi-store platform genuinely changes the game: StoreFleet lets you set per-store and per-feature permissions for each staff member from one place, so the access model in your SOPs and the access model in reality are the same thing.

A simple ownership map is enough — one table, reviewed monthly:

Keeping SOPs alive

Most SOP libraries die within six months. Not because the writing was bad — because nothing forced them to stay true. Four mechanisms fix that:

1. Review dates are deadlines, not decoration. Every SOP header has "Last reviewed." Set a rule: any SOP past its review date is treated as unreliable and gets flagged in your weekly ops meeting. Reviews are cheap — the owner re-runs the steps once, fixes drift, updates the date. Fifteen minutes per SOP per cycle.

2. Fix-it-when-you-hit-it. The person executing an SOP who finds a wrong step has one job: fix the doc (or comment on it) before finishing the task. This distributes maintenance across the whole team instead of piling it on owners.

3. Every incident updates an SOP. Missed a chargeback deadline? Shipped a duplicate order? The retro isn't done until you can point to the changed line in an SOP (or a brand-new SOP) that prevents the repeat. If an incident doesn't change any document, you've decided to have that incident again.

4. Delete aggressively. An SOP for a process you no longer run is noise that makes people trust the whole library less. Archive it, don't hoard it.

Finally, connect SOPs to your daily rhythm. SOPs describe how to do tasks; a daily and weekly ops checklist describes which tasks happen when. The checklist should link to the relevant SOP at every step — that's what keeps the documents in circulation instead of in a folder nobody opens.

A 2-week rollout plan

You don't need a documentation sprint. Two weeks, one hour a day:

1. Days 1–2: List every recurring task across your stores. Rank by frequency × blast radius.
2. Days 3–7: Write the top 4 SOPs (orders, refunds, escalations, listings) using the template above. Write them while doing the task — record your screen if it helps.
3. Days 8–9: Assign owners and backups. Audit staff permissions against what each SOP assumes.
4. Days 10–12: Have someone who did not write each SOP execute it cold. Every question they ask is a missing line — add it.
5. Days 13–14: Set review dates, link SOPs from your daily checklist, and add "SOP drift" as a standing item in your weekly meeting.

From there it's one new SOP a week until the ranked list is empty. Teams that do this before scaling past three or four stores onboard new people in days instead of weeks — and if you're earlier in the journey, it's worth reading how process debt compounds when scaling from 1 to 10 stores so you can write the documents before you desperately need them.

Sources

• Shopify Help Center — Staff permissions
• Shopify Help Center — Refunding orders