Most advice on prompting comes as a list of rules. We find it sticks better when you watch one request go from poor to good, so this piece follows a single task the whole way through. The task is invented, but we see some version of it in support requests most weeks.
The request
Mel runs the payroll team at a mid-sized regional council. On Friday the executive signed off a change to the overtime procedure. From 1 March, overtime has to be approved by the employee's manager in the rostering system before it is worked, rather than signed off on a paper timesheet afterwards. Claims without approval go to the director for a decision and are paid a pay cycle late.
The procedure is eleven pages. Mel's job is to tell about 140 outdoor and depot staff what has changed, in a form they will actually read, before the first affected roster goes out.
She has twenty minutes before a meeting. She opens K9 AI.
Attempt one
Summarise the new overtime policy for staff.
She attaches the PDF and sends it.
What comes back is not wrong. It is a tidy 400-word overview with headings for Purpose, Scope, Definitions, Responsibilities and Approval Process. It says the policy "aims to ensure consistent and transparent management of overtime". It explains what counts as overtime under the enterprise agreement. The 1 March date turns up in the fourth paragraph. The late-payment consequence is missing entirely, because in the procedure it sits in a table in Appendix B.
Mel's first reaction is that the tool isn't much good at this. That is the wrong conclusion, and it is the one that makes people give up after a week.
Look at what the model was given. "Summarise" with no audience means summarise for anyone, which in practice means shrinking the document's own structure. "Staff" could be anyone from the CEO down. Nothing said what had changed, because the model has never seen the old procedure. Nothing said what the reader had to do. It produced a faithful, smaller copy of the procedure, which is a reasonable reading of six words.
What the model can't know
Think of it as briefing someone who has read widely, writes quickly and started at your organisation this morning. They have never seen a timesheet here. They don't know the depot crews read email on their phones in the ute between jobs, or that the last policy email set off a reply-all argument about who it applied to.
Mel knows all of that. Almost none of it made it into the prompt.
Before rewriting anything, she jots down answers to four plain questions: who is reading, what they need to do differently, what they will ask or get wrong, and what the finished thing looks like.
- Field and depot staff, plus their supervisors, mostly reading on a phone.
- Get overtime approved in the rostering system before working it, from 1 March.
- They will ask whether call-outs count (they do, and can be approved within 24 hours afterwards). Some will assume the paper form still works for a while.
- A short message she can email and also pin up in the lunch rooms. Plain words, no policy language.
That takes about three minutes. It is most of the work.
Attempt two
I'm the payroll team leader at a regional council. Write a message to our field and depot staff and their supervisors explaining a change to how overtime is approved, based on the attached procedure.
What changes: from 1 March, overtime must be approved by your manager in the rostering system before you work it. Paper timesheet sign-off after the fact will no longer be accepted. Emergency call-outs can be approved up to 24 hours afterwards. Claims without approval go to the director and are paid a pay cycle late (Appendix B).
Most readers will see this on a phone. Keep it under 250 words, plain English, no headings like Purpose or Scope. Lead with what they need to do. End with who to contact: the payroll team on extension {extension}.
The difference is obvious straight away. The output opens with "From 1 March, overtime needs to be approved in the rostering system before you work it." The call-out rule is there, the late payment is there, and it comes in at 210 words.
Two things still bother Mel.
The tone is stiff in places. The third paragraph says "failure to obtain pre-approval may result in delayed remuneration", which is the procedure's own sentence lightly reworded. Nobody at a depot talks like that, and it reads as a threat.
And it has made something up. The message says the change is "to align with the updated enterprise agreement". The procedure says nothing of the sort. The real reason, which Mel knows, is that late paper claims were piling up and payroll couldn't forecast overtime costs or pay people on time.
An aside on invented detail
This is the failure that catches careful people, because the rest of the answer is good and the invented bit sounds right. It tends to happen when the prompt implicitly asks for something the source doesn't contain. Here, a message about a change seems to need a reason, so the model supplied a plausible one. The fix costs one sentence: give it the fact, or tell it to use only the attached document and what you've said, and to ask if it needs anything else.
Fixing it without starting again
Mel's instinct is to rewrite the whole prompt. There's no need. The conversation already holds the procedure, the audience and a decent draft, so a short follow-up does the job.
Two changes. Remove the line about the enterprise agreement. The actual reason is that late paper claims made it hard for us to forecast overtime and pay people on time; say that in one sentence. Then rewrite the late-payment paragraph so it sounds like a colleague giving a heads-up, not a warning. Keep everything else as it is.
"Keep everything else as it is" does more than it looks. Without it, a model often treats a follow-up as an invitation to redo the lot, and something you liked quietly changes.
Before: "Failure to obtain pre-approval may result in delayed remuneration."
After: "If overtime isn't approved first, it can still be paid, but it goes to the director and you'll get it a pay cycle later."
Checking it as a reader would
Mel does one more thing before sending, and it is the step most people skip. She asks the model to argue with the draft rather than polish it.
Read this message as a depot worker who has claimed overtime on paper timesheets for fifteen years. What would they misunderstand or push back on? List up to five points, most likely first.
Two of the five are useful. Staff on a nine-day fortnight will want to know whether working a rostered day off counts. And "the rostering system" means little to people who only ever see their roster as a printed sheet on the lunch room wall, because supervisors enter it for them. She adds one line on rostered days off and makes clear that supervisors can enter the approval on a worker's behalf.
That second point wasn't in the procedure at all. It came from Mel's knowledge of the depots, surfaced by a question aimed at a specific reader. Asking for criticism as its own step, with a named reader in mind, is a habit worth keeping.
What actually changed
Put the first and last prompts side by side and the differences are mostly not about wording. The first said what to do to a document. The later ones said who the message was for, what they had to do, what they would get wrong and what the result should look like. The model's writing ability didn't change. The brief did.
A few smaller moves helped too. Mel stated the change outright rather than hoping the model would work it out; models summarise what is in front of them and can't see the old version. She pulled the key consequence out of the appendix and into the prompt, since anything buried in a table near the back is at risk of being dropped. She gave a length and a reading context ("on a phone") instead of asking for something short. And she corrected with targeted follow-ups instead of starting over.
All up, including the three minutes of thinking, it took about fifteen minutes. The first attempt took thirty seconds and would have needed a full rewrite by hand.
If the material is sensitive
Mel's procedure is a published internal document, so she left the classification at OFFICIAL. If she had been working from a restructure proposal that hadn't been announced, or pasting in real overtime claims with names attached, she would choose OFFICIAL: Sensitive under the message box before sending. K9 AI then redacts personal details in the browser before anything reaches a model and shows her what it found. The prompt itself stays the same.
One thing to try this week
Take a request you make often, the kind you would normally send as one line. Before sending it, write two sentences at the top: who will read the result, and what they need to do after reading it. That alone gets most people from attempt one to something close to attempt two, and the follow-ups get shorter from there.
Put this into practice with K9 AI.
Australian-hosted AI with redaction, classification and audit built in. Try it free for 14 days with no credit card, or talk to us about a pilot.