Write It the Way the System Reads It

Two small writing habits prevent a surprising share of back-office mistakes. Keep confirmations generic, with nothing in them to fill in. And write every name exactly the way the system stores it. Both come down to the same idea: write for the reader who will act on it, including the search box.

Neither habit is clever. I learned both from small errors in one back office, each of which cost a day or a little trust. Neither error was anyone being careless. The format let them happen.

The confirmation that got a date wrong

The work was exception outreach. People owed us one missing piece of information, usually a time that should have been on a record. We wrote to ask. They replied. We fixed the record and wrote back to confirm.

The confirmations were being written fresh for each person, with the dates and times of what had been fixed. It seemed like good service. It was slow, because every reply needed checking against the record. And one draft dated a shift wrongly. The record was right. The confirmation describing it was not.

That is the trap with personalized confirmations. Every detail you add is a detail that can be wrong, and the confirmation is the message people trust most, because it says the matter is closed.

So the confirmation became two lines, the same for every case:

The adjustment has been entered and the error has cleared. No further action needed.

Nothing to fill in, so nothing to get wrong. It goes out in seconds. And if someone wants the detail, it is already in the request they received, and in their reply to it.

Requests carry the detail. Confirmations carry none.

The split is deliberate. A request has to be specific, because the person needs to know exactly what is missing. A confirmation only has to close the loop.

The request follows its own rules. One person, one message, with every open date for that person in one place. Nobody wants three emails about three days. A first-contact version introduces who is writing and why. A repeat version, for anyone already on the contacted list, skips the introduction and gets to the dates.

Before choosing between them, check the contacted list. That one check is what stops someone getting a polite introduction for the second time, which reads as if nobody remembers writing to them. After each batch goes out, add the new names to the list the same day, not at the end of the week.

And one rule sits above both templates.

Never message anyone about today

A draft once went out to someone about a shift that was still in progress. Their record showed a start and no end, which was exactly right, because they had not finished yet. The message asked them to fix something that was not broken.

So items dated today are dropped before any outreach is drafted. An item dated today may still be in progress, and the record will often complete itself by evening. Watch the time zones too: "today" for the person on the record may not be today on your clock.

The person who did not exist

The second habit came from a name. Someone signed every email with a short version of their name, the one everybody used. Our log used it too, because that is what was on the replies.

When the operator went to fix their open item, she searched the system for that short name. The system stores names as they were registered. The search returned nothing. With no record found, the item was marked resolved.

It was not resolved. It sat open for another day, until the next copy of the queue showed it was still there. One search had turned a real open item into a closed one, and nothing in the log looked wrong.

The fix: every list, log and checklist uses the name exactly as the system stores it. If the person goes by something else, the nickname goes in brackets after it.

Katherine Lund (Kat)

The registered name comes first because it is what the search box needs. The nickname stays because it is what the person signs, and what you will see on their reply.

Why the system's spelling wins

A work log is a list of future searches. Every name in it will be typed into some system by someone, often not you, often in a hurry. Whatever you wrote is what they will search for.

Search boxes match what is stored, not what people are called. A nickname, a shortened surname or a swapped first and last name each returns nothing, and "no result" looks a lot like "already done". That is the dangerous part. A failed search does not feel like a failure. It feels like an answer.

The same goes for everything else you will search for later. Account names as the system spells them, not the short form everyone says out loud. Codes exactly as stored, including any leading zeros. Dates in one format, the system's, so a search for one day does not miss half the entries written another way. Every shortcut you take while writing becomes a guess for whoever reads it.

Where the system gives you an ID, use it alongside the name. IDs do not have nicknames. A short people list that pairs registered name, short name and ID makes the lookup instant in both directions.

The habits, as rules

• Confirmations are generic. If a template has a blank in it, it is a request, not a confirmation.
• Requests are specific: one person, one message, every date in one place.
• Check the contacted list before choosing first contact or repeat.
• Drop anything dated today before drafting. Check whose "today" you mean.
• Names appear as registered, with any nickname in brackets.
• "Not found" in a search is never a reason to mark something resolved. Check the latest queue first.

The free exception email builder applies these rules to a pasted list. It drops rows dated today, groups the rest by person, picks first contact or repeat from your contacted list, and puts every date in one message. The comparison method behind the outreach, with the full template set, is in The Diff Playbook (PDF).

The takeaway

Put the detail in the request and keep the confirmation to two lines with nothing to fill in. Never write to anyone about an item dated today.

Write every name the way the system stores it, nickname in brackets. Your log will be searched by someone else, and the search box only knows the registered name.