Stop 6 of 9 · Daily
The reply, the note, the article
One fix, three documents in one pass: the reply the user understands, the change note the audit needs, and the article the next person will find by searching.
One fix, three readers
The fix took Tariq eleven minutes. The writing afterwards takes twenty-five, and it is the part that gets skipped at 17:30, which is why the same problem gets solved from scratch three more times this year.
Three people need something from every fix, and they need different things.
| Reader | What they need |
|---|---|
| The user | It is fixed, what changed for them, what to do if it comes back |
| The file | What changed, when, why, and how to reverse it |
| The next technician | The symptom in searchable words, then the steps |
Writing all three by hand means writing the same fix three times in three registers. Writing them in one pass means describing the fix once, badly, in your own shorthand, and letting Claude do the translating.
The one prompt at the end of a ticket
Here is what happened on ticket 4471 at Grantham and Reed, in my own rough notes. Turn it into three separate documents, with clear headings between them. 1. A reply to Priya, the user. Under 120 words. Plain language, no component names, no error codes, no blame. Say what she will notice, what to do if it happens again, and nothing else. 2. An internal change note. What changed, on which device or tenant object, when, why, what I checked afterwards, and the exact steps to reverse it. Bullet form, no adjectives. 3. A knowledge-base article. Title it with the sentence a user would type into search when this happens to them. Then: who this affects, the symptoms, the steps with the command where there is one, and how to confirm it worked. Put the ticket number at the bottom. Flag anything in my notes that is too vague to publish rather than smoothing over it. [paste your rough notes]
The last line is the one that keeps the article honest. Rough notes are full of "did the usual thing", and an article built on that is worse than no article, because the next person will follow it.
Rewrite this reply so a partner in an accounting firm understands it. Remove every component name, error code and acronym. Keep it under 100 words, keep the fact that the cause was on our side, and end with one specific thing she should tell me if it happens again. [paste the draft]
Here are the titles of the articles in our knowledge base. For each one, tell me whether a non-technical user would find it by searching for their symptom, and if not, rewrite it as the sentence they would actually type. Keep the internal reference as a suffix. [paste the list of titles]