You've been there. Six months after a successful ERP go-live, you get a call from the client. Half the team has forgotten how to run the month-end close. The other half never learned properly in the first place. The training videos are somewhere on a SharePoint nobody can find. And your beautifully formatted Word document — the one that took three days to write — is sitting in a folder called "Handover Docs" that hasn't been opened since the day you handed it over.
This is the SOP problem. Not the writing of them, but the using of them.
Software consultants are good at building things. Configuring systems, training users, managing go-lives. Documentation is the part that gets squeezed — written fast at the end of an engagement when the budget is running out and everyone's exhausted. Then it gets ignored, becomes outdated, and eventually causes the very problems it was supposed to prevent.
This guide is about doing it differently.
Why Most SOPs Fail Before Anyone Reads Them
Before we talk about how to write a good SOP, let's understand why most fail. There are three consistent patterns.
They're written for the writer, not the reader. Consultants write SOPs in the language they use to think about a system, not the language the end user uses to work in it. The result reads like a technical specification, not a job aid.
They're too long. A 40-page SOP for processing a supplier invoice is not a document — it's a punishment. Users don't read it, can't find what they need in it, and stop trusting it after the first time it doesn't match what's actually on their screen.
They're not maintained. Software changes. Processes evolve. The SOP that was accurate at go-live is wrong by month three, and everyone knows it. Once users learn they can't trust the documentation, they stop referring to it entirely.
The Foundation: Know Who You're Writing For
Every SOP should be written with a specific person in mind. Not "the finance team." A specific person — ideally someone you've watched struggle with the process during training or UAT.
Ask yourself:
- What is this person's technical comfort level?
- What do they already know about the process?
- Where do they most commonly make mistakes?
- When will they reach for this document — at their desk during a normal day, or in a panic when something's gone wrong?
The answers shape everything: the language you use, the level of detail, where you put warnings, and how long the document should be.
A SOP written for a warehouse operative running goods receipts in SAP looks completely different to one written for an accountant doing journal entries in Dynamics 365. Same format, radically different content and tone.
Structure That Works in the Real World
Forget the traditional SOP format you learned from an ISO manual. For software processes in enterprise systems, this structure works far better:
1. When to use this SOP. One sentence. "Use this procedure when you need to process a customer refund in Salesforce." If someone picks up the document and isn't sure whether it applies to their situation, they'll put it down.
2. Before you start. What does the user need to have in hand before they begin? An approved purchase order number? A specific user role? Access to a particular module? Getting stopped halfway through a process is more disruptive than not starting.
3. The steps. Numbered. Short sentences. One action per step. Not "Navigate to the Accounts Payable module, select the vendor, and enter the invoice details" — that's three steps disguised as one. Screenshots at every significant screen transition, not just at the beginning.
4. Decision points. Flag them clearly. "If the system shows an error at this stage, see the Troubleshooting section below." Users need to know when a fork in the road is coming.
5. What to expect when it works. What does success look like? What confirmation message, status change, or system response tells the user they've done it correctly? This is the most underrated section in most SOPs. Users who aren't sure it worked will either do it twice or call support.
6. Troubleshooting. The five most common things that go wrong. Not an exhaustive error log — just the things you've watched real users hit during training and UAT.
7. Who to contact. When all else fails, who do they call? Name, email, or team. Don't make them guess.
The Screenshot Problem
Screenshots age badly. System upgrades, UI refreshes, configuration changes — all of these can make a screenshot misleading within months of publication. But removing screenshots entirely makes SOPs harder to follow.
The answer is to screenshot strategically:
- Capture full screen context, not just the field being discussed
- Highlight the specific element with a box or arrow — don't expect users to find it themselves
- Caption every screenshot with what the user should see, not just what you're showing
- Use screenshots to confirm navigation ("your screen should look like this") more than to show data entry
When a system update changes the interface, updating ten targeted screenshots is manageable. Updating seventy scattered screenshots across twelve documents is why documentation rots.
Writing Style That Gets Read
SOPs are not essays. Users scan them, not read them. Your writing style needs to match that behaviour.
Active voice, always. "Click Save" not "The Save button should be clicked." The document is giving instructions, not describing what might happen.
Second person. "You will see a confirmation message" not "The user will see a confirmation message." Users should feel the SOP is talking directly to them.
Consistent terminology. Pick one word for each concept and use it throughout. Don't alternate between "supplier" and "vendor," "invoice" and "bill," "post" and "submit." Inconsistency creates doubt.
Short sentences. If a sentence runs longer than twenty words, it probably contains two instructions. Split it.
Bold for UI elements. When you refer to a button, field, or menu item, bold it. "Click Post Document" makes it immediately clear what the user is looking for on the screen.
Capturing Workflows at the Speed of Consulting
Here's the practical reality: most consultants don't have time to write SOPs properly at the end of an engagement because there's no time budgeted for it, the client is pressing for closure, and it's genuinely tedious work.
The answer is to capture as you go, not document at the end.
The best time to capture a workflow is while you're configuring it or training on it. You're already in the system, walking through the steps. Capturing what you're doing in real time — screens, clicks, transitions — takes a fraction of the effort of reconstructing it from memory a week later.
MySOP.guru captures your workflow as you walk through it and generates a structured SOP document automatically. Review, export as PDF or HTML, and hand it over — in a fraction of the time it takes to write from scratch.
Try it free →Getting Clients to Actually Use the SOPs
Writing good SOPs is half the battle. Getting clients to use them is the other half, and most consultants underinvest here.
A few approaches that consistently work:
Make them searchable. A PDF in a folder is a dead document. HTML-format SOPs that can be searched in a browser or intranet are used far more frequently. Format matters.
Involve key users in the review. When a user has contributed to a document — even just reviewing and approving a draft — they're more likely to refer their colleagues to it. Ownership drives adoption.
Build SOP review into hypercare. The first 30 days after go-live are when most process questions surface. Schedule a two-week and four-week check-in specifically to update SOPs based on real usage. Show the client that the documents evolve.
Embed them in the system where possible. Most enterprise platforms allow you to add links or notes to screens. A link to the relevant SOP directly from the transaction screen dramatically increases the chances of it being found when needed.
The Deliverable Standard Your Clients Deserve
Your clients are paying for a working system. But a working system that isn't understood by the people running it isn't actually working — it's just waiting to break.
SOPs are not an afterthought or a nice-to-have. They are the mechanism through which your implementation continues to deliver value after you've left. Treated that way, documentation becomes a competitive differentiator: the consultant who hands over documentation that actually gets used is the consultant who gets the next engagement.
The bar isn't high. Most implementation documentation is poor. Clear, well-structured, user-focused SOPs that are delivered on time and maintained after go-live will set you apart from most of the competition.
Write them for the person who'll use them. Capture them at the right time. Format them to be found and read. That's the whole game.