Jump to section
Somewhere on your firm's shared drive sits a folder called Procedures. It has an intake checklist from three managing lawyers ago, a document naming convention nobody uses, and a forty-page onboarding binder a summer student wrote and then left. You know it exists. You would never open it while actually opening a file. That is the whole problem with most standard operating procedures: they are written to be complete, not to be followed.
A good SOP is not documentation. It is a tool someone picks up while their hands are already busy. If you write one that survives contact with a real Tuesday afternoon, delegation stops feeling like a gamble and coverage stops depending on one person's memory. Here is how to get there.
Why your last SOP binder went unread
Binders fail for a boring reason: they answer the wrong question. The author writes down everything they know about a process. The reader wants one thing, right now, mid task, under a little pressure. Those are different documents: one comprehensive, one immediately usable.
The other quiet killer is timing. Nobody reads an SOP before they need it. They read it at the exact moment they are stuck, and if it does not resolve the stuck feeling in about thirty seconds, they close it and ask the person beside them instead. Which means the knowledge lives in someone's head again, and you are back where you started.
Note. An SOP that gets ignored is worse than no SOP, because it creates false confidence. Everyone assumes the process is documented, so nobody fixes the gap.
Write for the person mid task, not the author
Picture the actual moment of use. An articling student has a new family file open, it is 4:40 on a Friday, and they need to know how your firm opens a matter without missing a conflict check or a limitation period. They do not need your philosophy of intake. They need steps, in order, that they can do without you.
So write in the imperative and stay in second person. "Run the conflict search before you create the file." Not "Conflict searches should be conducted prior to file creation." Number the steps. One action per step. Put the decision points where they occur, not in a notes section at the bottom.
- Start with the trigger. Say when this SOP applies in the first line. "Use this when a new client has signed the retainer."
- Name the tools by their real name. Where the step happens in your practice software, say so, so nobody hunts for the right screen.
- Flag the thing that goes wrong. Every process has one step people botch. Call it out inline with a short warning, not buried in prose.
- End with done. State how the reader knows the task is finished and what the file should look like.
Keep it short enough to scan. If a procedure runs past a screen or two, it is probably two separate tasks combined. Split it. The intake SOP and the trust deposit SOP are different jobs done by different people at different moments, so give them separate homes. Our note on choosing which tasks to hand off pairs well here, because the tasks worth documenting are usually the ones worth delegating.
Screenshots, screen recordings, or plain steps
Format follows the task, not your preference. Three rough rules.
| When the task is | Reach for | Because |
|---|---|---|
| A fixed sequence of clicks in one system | Plain numbered steps | Fast to write, fast to scan, easy to edit when the button moves |
| Something visual or easy to misidentify on screen | A screenshot or two, annotated | A picture settles "which field" faster than a sentence |
| A flow that spans several screens or apps | A short screen recording | Motion carries context that stills and text drop |
One caution on screenshots and video: they rot fastest. The instant a vendor ships a redesign, your beautifully annotated capture is now wrong, and wrong pictures teach people to distrust the whole SOP. So use images only where they earn their keep, and keep plain text as the backbone. A step that reads "open the matter, then the billing tab" survives a UI refresh. A screenshot of last year's billing tab does not.
Tip. Record the screen recording while you actually do the task, narrating as you go. It is faster than writing, and the parts where you pause and think out loud are exactly the parts the reader will get stuck on.
Where to store an SOP so it gets found
The best-written procedure is useless if it lives one folder deeper than anyone will dig. The rule is simple: the SOP belongs where the work happens, not in a documentation silo across the hall.
If the task lives inside your practice software, the instructions should live a click away from it. A firm running its files, billing, and intake in one place, say A1 CMS, can lean on a shared knowledge base so the how-to sits beside the doing. If your procedures scatter across email threads, a wiki, and three people's memories, no amount of good writing will save them. Consolidate first.
Give every SOP a plain, searchable title that matches how people describe the task out loud. "How to open a new matter," not "Matter Intake Procedure v3 FINAL." People search for the words they would say, so title accordingly. And put a single owner's name on each one, because a document that belongs to everyone belongs to no one when it needs updating.
The SOP belongs where the work happens, not in a documentation silo across the hall. A1 Team
Reviewing procedures before they rot
Every procedure has a shelf life. The registry changes a filing rule, a form gets a new field, you switch a tool, and quietly your SOP starts lying to people. The fix is not a comprehensive annual audit that never actually happens. It is a small, boring rhythm.
- Date and owner on every SOP. If you cannot tell at a glance when it was last touched and by whom, you cannot trust it.
- Review on a trigger, not just a calendar. Any time a process breaks in real life, the person who hit the snag updates the SOP that day, while it stings. That single habit does more than a scheduled review ever will.
- Sweep the stale ones quarterly. Fold it into an existing ritual so it actually happens. Our quarterly planning post and the Friday reset both make a natural home for a ten-minute pass over what changed.
One more test worth running: hand the SOP to the person least familiar with the task and watch them try to follow it without help. Every place they hesitate is a gap. Fix those, and you have a procedure that teaches instead of one that assumes. For more on building rhythms that keep a firm running without constant supervision, the Firm Operations hub and the rest of our writing go deeper.
Here is the honest bar to aim for. A good SOP is one a competent colleague can follow on a bad day, at 4:40 on a Friday, without texting you. It is short, it is where the work is, it says who owns it and when it was last true, and it gets fixed the moment reality moves. Write that, store it well, and keep it alive, and you will stop being the bottleneck your own firm routes around. The binder was never the point. The next person doing the task correctly, without you in the room, always was.
