Real wiki structures for DTC ops teams, and the freshness habits that keep them from going stale within a quarter.
Layout is not what decides whether a company wiki gets used. Findability and freshness are. The wiki examples that teams actually open are the ones where a part-time support hire can search one word, land on the right page, and see proof that someone checked it recently.
So this walks through a structure a Shopify ops team can copy, the two signals every page needs, and why each example goes stale inside a quarter.
The trap is treating a wiki as a build. It is a maintenance habit, the same habit that keeps an SOP from drifting out of date, and pretty screenshots hide that part completely.
A company wiki is the internal library an ops team keeps on how the store actually runs, with one page per task and one named owner per page. Plane's step-by-step guide argues for designing categories before writing pages, and that order matters more than the tool.
Start from what breaks, not from a template. We use eight shelves for what breaks first in a DTC store: refunds, fulfillment exceptions, chargebacks, escalations, discounts, inventory, vendors, onboarding.
Those eight make a usable top level. A finance shelf sits beside them, built from accounting SOP templates like month-end close and AP. Under each heading, keep pages task-sized: one page per job someone does on a shift.
The tool matters less than that shape. Confluence asks you to pick a space purpose when you create one, with Collaboration, Knowledge base, or Custom. Google Sites is lighter: pick a template, edit, publish. Both will hold the same eight shelves.
KnowWhyy makes the case in its guide to keeping internal docs trusted. A missing page costs a question to a colleague. A wrong page costs the hour spent following it, and after that, the reader's trust in every other page.
Madewithlove lands on the same line in its guide to keeping documentation up to date: "Outdated documentation is often worse than no documentation." Its other warning is about volume. Some companies write so much that their knowledge base turns into a mess, and every extra page is another page to maintain.
The cost of that is measured mostly in engineering, not ecommerce ops. KnowWhyy's write-up of Atlassian's State of Developer Experience 2024 reports that 41% of developers named insufficient documentation a major hindrance, and 69% said they lose eight or more hours a week to inefficiencies.
Read that as direction, not as a figure for a support team. The mechanism travels even if the number does not: people route around documents they cannot trust.
Title pages the way the work gets named out loud. Someone three weeks into a support role types "refund", not "Post-Purchase Resolution Framework".
Four rules do most of the work, drawn from madewithlove, Plane's wiki guide and KnowWhyy:
Naming is the lever most teams skip. A convention that puts the tool, the task and the review date in the title makes stale pages visible in a file list. This site's post on an SOP naming convention that flags a stale procedure works through what to encode and what to leave out.
Name each SOP file with the tool it runs in, the date it was last checked, the process and the owner.
KnowWhyy's model for a trusted wiki puts two signals at the top of every page that matters: an owner and a last-verified date.
Make the owner one named person, with the team as backup. A role fails quietly when the person in it moves on. A name fails loudly, so the page gets reassigned. The site's post on whose job it is to update outdated documentation explains why.
A last-verified date is not the same as a last-edited date. Fixing a typo does not verify anything. Only checking the page against the live screen does. And a deprecated page should link to its replacement in the first line, not just say it is gone.
The honest part is that a date is a claim, not a check. It tells the reader when someone last compared the page with the live screen. If nobody ever runs that comparison, the header just dates the lie more precisely. The site's post on SOP drift covers the signals that reveal a gap in a procedure before any date does.
Try it on one of your own procedures.
Record a process once, AI writes the structured SOP. 3 free SOPs, no credit card.
It names the exact setting and the exact value, not the policy in prose. Returns is the clearest example because Shopify stores the rules as configured fields.
Shopify's return and cancellation rules let you pick a return window of 14 days, 30 days, 90 days, Unlimited, or a custom number of days. You also choose when the window starts: each item's delivery, or delivery of the last item in the order. Return shipping can be free, a flat fee charged once per return, or the customer's own label. A restocking fee is set as a percentage.
One line on that page saves a double refund: "Return fees aren't automatically deducted from refunds." Someone has to deduct them when creating the refund. Shopify's documentation adds two limits worth putting on the page: "You can create a return only for fulfilled items" and "The restocking fee is displayed only if it's set up and you create a return for a fulfilled order."
So a usable wiki page says: window 30 days from delivery of the last item, restocking fee 10%, and the named person who deducts return fees when creating the refund. A page that says "follow our returns policy" sends the reader back to guessing.
Plane's wiki guide sets the balance: read access wide, edit access narrower, one named owner per page. That split keeps a wiki open without letting it drift into contradiction, and it does not need a formal approval workflow to work.
Confluence enforces part of this already: the person who creates a space is its owner, there can be only one space owner at a time, and ownership can be reassigned in space settings.
Plane keeps reviews for pages that need extra care, such as policies or critical processes. For an ops wiki, add anything that touches money. Gating every operational page behind a review just guarantees nobody updates it.
Contractors and agencies are the awkward case. Mirror the read-and-edit split for them too: give an agency or contractor exactly the pages the job needs, nothing else. The post The Shopify permissions your SOPs should name lists the specific admin permissions to check before handing over access. A knowledge transfer plan template covers the handover record a departing contractor should leave behind, and the employee offboarding checklist for Shopify teams covers what to lock down when the work ends.
Because the processes live inside other companies' software, and that software ships changes you did not schedule.
Returns is the live example. EU Directive 2023/2673 took effect on June 19, 2026, and it requires stores selling to EU consumers to offer an electronic way to withdraw. Shopify's help page says the 14-day withdrawal period runs from delivery of the last item in the order, and EU refunds are due within 14 days of the cancellation request. A returns page written before June 2026 probably misses those settings. Check which settings your own store actually has turned on.
Sweeps catch some of this. KnowWhyy suggests one hour per team per quarter, filtering for pages past 90 days and starting with the most-read ones. Madewithlove suggests going through live documents every six to twelve months, separate from one-off records like meeting notes.
Another option is to re-record the task instead of waiting for the next sweep. Walking the process again and comparing it against the written steps shows which step moved, instead of asking someone to remember.
Four ways, in rough order of likelihood.
Ownership collapses onto one person. If the ops lead owns every page, nothing gets verified during a busy quarter, and the dates on the headers go from useful to misleading.
Freshness turns into theater. A team starts clicking "verified" without opening the live screen. Then the wiki looks healthier than it is, which is worse than an obviously old page.
Archiving gets treated as deletion, so nobody does it. Move the page out of search results and keep the history.
A recording or a written page still only shows the way one person did the task, not necessarily the best way; someone has to review it before trusting it. None of this works as a one-off sprint either, since a wiki built in a week and never touched again decays the same way any documentation sprint does. Someone still has to read it and cut the detours. A wiki also cannot run the process, watch your store settings, or make a judgment call for a new hire.
Pick the one page that would cost you most if it were wrong. For most Shopify brands that is refunds or returns. Open it today and do three things: name an owner, add a last-verified date, and replace every vague instruction with the exact setting and value in the admin.
Then repeat on the next two pages. Eight good pages beat eighty that nobody trusts.
How ReccordSOP fits: a screen recording becomes a numbered, screenshotted SOP, with the clicked element highlighted on each step. Recording the same task again compares it against the existing version and flags which steps moved, instead of quietly replacing the old copy. Version history stays intact, and workspace admins get an email once a published SOP has gone 90 days without a review or an edit. It documents the process; it does not run it or watch the store settings. The free plan covers 3 SOPs in total. Team is $19 per user per month, with a 3-user minimum. Sign up at reccordsop.com to record your first one.
A company wiki is an internal set of editable, searchable, linked pages where a team documents how the business works, from processes to decisions. Unlike a static handbook, pages are meant to be updated by the people doing the work. For a Shopify brand, the useful version is a small library organized around what breaks: refunds, fulfillment exceptions, chargebacks, escalations, discounts, inventory, vendors, onboarding.
A Shopify store's company wiki should start with eight shelves for what breaks first: refunds, fulfillment exceptions, chargebacks, escalations, discounts, inventory, vendors, onboarding. Add a finance shelf for month-end close and AP, and keep one page per task. Each page should name the actual setting and value in the tool, such as the specific return window and its starting point, a restocking fee percentage, and who is responsible for deducting it.
There is no fixed interval that works for every team, but a review triggered by a change in the underlying tool beats a calendar date, because that is when pages actually break. As a baseline habit, check the most-read pages each quarter and verify them against the live screen rather than against memory.
A wiki works for stable, text-friendly knowledge: org context, policies, decisions, who owns what. Step-by-step procedures inside Shopify, a helpdesk or a 3PL portal are where wikis struggle, because screenshots and steps go out of date silently and nothing flags it.
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 November 3, 2026
A file name can show you an out-of-date procedure before anyone opens it, as long as the date in it means someone actually checked the steps against the live screens.
Most teams answer this with a role, a moment, or a virtue. All three evaporate, which is why the question keeps coming back.
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.