Most organisations have plenty of documentation.
What they don’t have is documentation anyone opens twice.
The difference between a work instruction that gets used, versus one that gets written then forgotten, usually comes down to a handful of decisions made before anyone starts typing.
Here’s what those decisions look like, plus how to use AI properly in the process without producing something generic.
📐 Know which document you’re actually writing
The first mistake is mixing document types.
An SOP defines what must happen, who’s accountable, plus why the control exists.
It’s a governance artefact, usually reviewed annually, often audited.
A work instruction shows 1 person how to complete 1 task in a system.
It’s operational, changes whenever the system changes, needs to be findable in 10 seconds.
Combine them, then you get a 30 page document nobody reads, satisfying neither purpose.
Keep them separate.
Link the SOP to the work instructions sitting beneath it.
✅ What a good work instruction contains
The shape matters more than the prose.
A reliable structure looks like this.
- A title matching what someone would search for, not what the project calls it
- Who this is for, plus what access they need
- Prerequisites, before step 1 rather than at step 7
- Numbered steps, 1 action per step
- What the person should see after each significant step
- What to do when it fails, including who to contact
- Owner, plus last review date, at the bottom
That last line does more than people expect.
It tells a reader whether they can trust what they’re reading, which determines whether they come back.
A few other rules worth holding to.
Keep it to 1 task.
If a procedure runs past 2 pages for something simple, that’s usually telling you the interface is wrong rather than the writing.
Use the words on the screen, exactly, including the odd capitalisation.
Say what the button does, not just where it is.
👥 Writing for the actual audience
Same task, 3 different audiences, 3 different documents.
A new starter needs context, screenshots, plus an explanation of why the step exists.
An experienced operator needs a checklist, since anything longer slows them down.
A contractor needs the access requirements stated first, because that’s where they’ll get stuck.
Work out who you’re writing for before choosing a format.
Some questions worth answering.
- What do they already know, so you’re not explaining basics
- What terminology do they use, which may differ from the system’s
- Are they under time pressure while reading this
- How often do they do this task, weekly or twice a year
- What’s the consequence of getting it wrong
That last question sets the tone.
High consequence tasks need warnings, verification steps, plus explicit confirmation points.
Low consequence tasks need brevity.
🤖 Using AI without producing something generic
AI drafts documentation quickly.
Left alone, it produces bland, plausible content that reads like every other manual.
The difference is entirely in how you prompt it.
A weak prompt looks like this.
“Write a work instruction for submitting an expense claim.”
A prompt that produces something usable specifies the constraints.
- The style guide, in my case usually the Microsoft Manual of Style for technical publications
- The audience, including their technical level, plus how often they do this
- The document type, since a work instruction behaves differently to a reference guide
- Voice plus tense, normally second person present tense for procedures
- Terminology the organisation insists on, listed explicitly
- A length ceiling, otherwise you’ll get 6 pages for a 3 step task
- The exact screen labels, pasted in
That last point is the one people skip.
Without real screen labels, the model invents plausible ones, which is the fastest way to publish something wrong.
🔧 Prompting to adjust the reading level
Once you have a draft, most of the work is tuning it.
Useful follow-up instructions.
- “Rewrite for someone doing this for the first time, add context before each step”
- “Compress this into a checklist for an experienced operator, no explanation”
- “Reduce to plain English, target reading age 12, keep every technical term intact”
- “Split anything with 2 actions into separate numbered steps”
- “Add a what you should see line after each step that changes the screen”
- “Rewrite in second person present tense throughout”
- “Cut this by 40% without removing any step”
Run those iteratively rather than trying to specify everything at once.
Each pass fixes 1 thing properly.
Worth keeping a saved prompt for your house style, so every document starts from the same baseline.
🔍 What you still have to do yourself
Verification isn’t optional here.
The specific things that need checking every time.
- Every field name, against the live system
- Prerequisites, since the model doesn’t know what access this user has
- Exceptions, which transcripts rarely cover
- Step order, because plausible ordering isn’t always correct ordering
- Terminology, against what this organisation actually says
Text that reads confidently is harder to check than text that reads awkwardly, since nothing signals a problem.
So read line by line.
Then test the procedure by following it yourself, in the system, exactly as written.
🗂️ Then put it somewhere findable
None of this matters if people can’t locate the document.
One home, not 4.
Titles written the way people speak.
A stable ID linking the work instruction back to the task on the process map.
An owner named, plus a review date set before the project team leaves.
Good documentation that nobody can find performs identically to no documentation at all.
About the author
Aiver is the managing consultant at Aliso Digital, an IT consultancy based in Melbourne.
For 19 years he’s worked on enterprise digital transformation programs.
His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design.
He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He has run his own consultancy for 12 years and works with a small number of clients at a time.
Available for remote and hybrid contracts.
alisodigital.com
