Not a guide to copying files. A checklist for what the next system has to do that the free ones never did.
Your refund policy lives in a Google Doc. In April, someone suggested changing the return window from 30 days to 45. The suggestion is still sitting there, neither accepted nor rejected.
One support agent has suggestions turned on in their view and sees 45 days. Another has them off and sees 30. Neither is wrong about what the document says. The document just says two things at once.
This is not a story about a careless team. It is what Google Docs does by default once more than two people touch a procedure over enough months.
The Slack half of this problem. A decision gets made in a thread, the Doc never catches up, and the thread quietly becomes the real policy.
Suggestion mode is the feature that makes this possible. It looks like version control. It is not.
Real version control forces a decision. A suggestion accepted or rejected, a clear current state. Google Docs lets a suggestion sit forever, half-applied, visible to some readers and invisible to others depending on a settings toggle nobody thinks to check.
The same thing happens with comments. A comment says this is wrong, we changed the process, from six months ago. Nobody resolved it. It is still attached to a paragraph that has not moved, so it reads as current advice sitting right next to the text it is contradicting.
Google Docs and Slack were the right call at the start. They cost nothing extra, everyone already had them open, and writing the first version of a procedure took ten minutes.
That is not a mistake to walk back. It is how every operation begins. The question is not whether starting there was wrong. It is whether the tools that got you to your first ten SOPs are still doing the job at your fortieth.
Three specific failure modes, not a vague sense that things feel disorganized.
Version history exists and nobody reads it. Google Docs keeps every revision, technically. What it shows is a wall of timestamps and initials, not a summary of what changed. Scrolling through forty saved versions to find the one edit that matters costs more time than most people will spend. Nobody does it. The version history might as well not exist.
The real decisions happen in Slack, not the Doc. A policy changes in a thread on a Tuesday. The Doc gets updated eventually, if someone remembers, days or weeks later. Until then the team is split between people who saw the thread and people who only ever open the Doc.
Nothing signals that a document needs attention. A Doc edited yesterday to fix a typo looks identical to one verified against real work last month. Both just say Edited [date]. There is no field for who owns this, no field for when it was last confirmed still accurate, so staleness is invisible until someone follows the wrong step.
This is not a ranked list of features to compare across vendors. It is the minimum bar. If a candidate system is missing more than one of these, it solves storage, not the actual problem.
| Require | What it fixes |
|---|---|
| Version history with a real diff | Shows what changed, not just that something changed. No half-applied suggestions. |
| A named owner per document | Not a role, a person. Someone accountable for whether it is still true. |
| A verified date, separate from last edited | A typo fix should not reset the same trust signal as a real review. |
| Assignment with read acknowledgment | Proof the right people were pointed at the document, not just that it exists somewhere. |
| Access scoped by team | Support sees support procedures. Nobody scrolls past forty unrelated docs to find one. |
The version-history requirement is the one worth being strict about. A tool that shows you the diff between two versions of a procedure is telling you what changed. A tool that just says last updated August 14 is telling you a file was touched. Those are different claims, and only one of them is useful during an incident.
Why the diff matters more than the timestamp, and why most capture-and-store tools hide it instead of showing it.
What a real owner field needs to do. A name that goes stale is a problem you can see. A role is a problem you cannot.
Try it on one of your own procedures.
Record a process once, AI writes the structured SOP. 3 free SOPs, no credit card.
Every vendor in this category leads with the same three things, and none of them is why teams actually switch.
Templates. A polished starter template saves twenty minutes on document one. It has no bearing on whether document forty is still accurate a year from now.
Editor polish. Rich formatting, embedded video, drag-and-drop blocks. Nice to have, and none of it prevents the suggestion-mode problem or the ownership problem.
Unlimited storage. Storage was never the constraint. Google Docs never ran out of room. The constraint was always knowing which of the documents already sitting there was still telling the truth.
Weigh a candidate on the five requirements above first. Let templates and editor polish be the tiebreaker between two tools that already clear that bar, not the reason you pick one.
Do not migrate everything in one sprint. That produces the exact failure a previous post on this site covers in detail: a burst of effort, a pile of freshly copied documents, and no mechanism to keep any of them accurate afterward.
The same ordering logic, applied to documents that do not exist yet instead of documents you already have.
Move by cost of being wrong, not alphabetically and not by document age. A refund policy or a chargeback procedure being stale costs you a customer or a dispute. A staff onboarding checklist being stale costs someone a slightly confusing first day. Migrate the first kind before the second.
A rough order that holds for most DTC teams: anything customer-facing with a dollar figure attached first (refunds, chargebacks, price matches), then anything with a compliance angle (data requests, SMS opt-outs), then internal workflow docs, then reference material nobody urgently needs.
Do not delete the Google Doc the day you migrate. Old links are already out there: bookmarked, pasted into other documents, saved in someone's browser favorites from eight months ago.
Instead, edit the top of the old doc to say, in bold, moved to [new link], this version is no longer maintained. Leave the content below it intact for reference. Anyone who lands on the old link through a stale bookmark sees the redirect before they see anything that might now be wrong.
Archive it properly a month or two later, once you are confident nothing still points at it. That gap matters more than it looks. The first few weeks after a migration are exactly when old links get clicked most, out of habit.
Below roughly fifteen active procedures and a team small enough that everyone already knows who wrote what, dedicated software solves a problem you do not have yet.
The signal to watch for is not a number. Watch for the first time someone follows a stale step because the version history told them nothing. Or the first time a policy changes in Slack and takes two weeks to reach the actual document. That is the moment the free tools stop being the efficient choice and start being the risk.
Not on a schedule, on a signal. If nobody has followed a stale step because version history did not surface what changed, or a Slack decision has not made it into the actual document within a reasonable time, that is the sign. Below about fifteen active procedures with a small team, Google Docs and Slack are usually still fine.
It records that something changed, not what changed or whether the change was ever finished. Suggestion mode lets an edit sit half-applied indefinitely, visible to some readers and not others depending on a view setting. Scrolling forty timestamped revisions to find the one that matters costs more time than most people spend, so in practice the feature goes unused.
Five things, in order of importance: version history that shows an actual diff rather than just a timestamp, a named owner per document rather than a role, a verified date that is separate from last-edited, assignment with read acknowledgment, and access scoped by team. Templates and editor polish are real but secondary. They should break a tie between two tools that already clear the first five, not decide the choice on their own.
Not immediately. Old links are already bookmarked and pasted into other documents. Edit the top of each old doc to say it moved and is no longer maintained, keep the content below for reference, and archive it for real a month or two later once you are confident nothing still points at it.
By cost of being wrong, not alphabetically and not by age. Move anything customer-facing with a dollar figure attached first, refunds and chargebacks and price matches, then anything with a compliance angle, then internal workflow documents, then reference material nobody urgently needs.
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 August 13, 2026
Most SOPs are wrong within 90 days of publishing. Here's how to detect it before it costs you a customer.
The Slack message pinned two years ago is the real SOP. The document nobody reads is the decoy.
Most teams answer this with a role, a moment, or a virtue. All three evaporate, which is why the question keeps coming back.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.