The Letter Written For One Person
You write a message thinking of one guest, then set it to send automatically to everyone. The details that made it good for that one person are exactly what makes it wrong for the rest. Here is what to strip before it goes in.
You write a message to a specific guest. It is good — it names their situation, it uses the right date, it acknowledges what has already happened between you.
Then somebody says: this is good, let's send it to everyone in that position.
⚠️ Every detail that made it good is now a liability. The date is their date. The history is their history. Sent to the next person, each of those becomes a small, confident lie.
The short version
- A message written for one person contains specific facts that only apply to them
- Put in an automated send, those facts are repeated to everyone
- Three kinds to strip: dates, counts, and statements about the reader
- Machines catch some of these and not the ones about the reader
- The fix is to write for the second recipient, not the first
Why good writing becomes the problem
| What makes it good for one | What it does to everyone else |
|---|---|
| "Your trial ends on the 16th" | Wrong date for every other reader |
| "We've written twice already" | Wrong count for anyone else |
| "Since you haven't started yet" | Tells active users they have not started |
⚠️ The more personal the original, the more of these it contains. A bland message survives automation; a good one does not, without editing.
One: dates
The easiest to spot and the easiest to fix.
Written "your trial ends on 16 October"
Automated "your trial ends on [their end date]"
⚠️ If your system cannot insert their date, do not state a date at all. "Your trial end date is shown on your account" is worse writing and correct, which beats better writing that is wrong.
The tell
In our own case, the software refused to compile — the slot for the reader's date was sitting unused because a fixed date had been typed in its place. The machine noticed before we did.
⇒ Not every system will do that. It caught one of three problems; the other two it could not see.
Two: counts
Any number about the relationship will drift.
"We've sent you two messages already"
"This is your third visit"
"You've been with us for six months"
⚠️ Each is true on the day it is written and false soon after. Worse, they are false in a way that sounds authoritative.
⇒ We found this exactly: a line saying two previous messages had been sent, in a sequence that actually sends three — and, for the one person it was written about, had sent none automatically at all.
The rule
Count it at send time, or do not mention it.
⇒ "We've been in touch before" carries the same meaning and cannot go stale.
⇒ Related: the messages that never arrived.
Three: statements about the reader
The dangerous one, because nothing catches it.
"Since you haven't tried it yet..."
"We noticed you've been quiet lately"
"As you're not using the booking feature..."
⚠️ These are assertions about somebody the machine has never looked at. An automated send goes to everybody in the group, including the ones doing fine.
What it costs
A guest who is using you perfectly reads that you think they've stopped
⇒ they conclude you do not know who they are
⇒ That is worse than sending nothing. It is a message that actively demonstrates you are not paying attention.
The fix is one word
Bad "Since you haven't started yet, ..."
Good "If you haven't started yet, ..."
⚠️ Conditional, not declarative. It costs nothing, reads almost identically, and cannot be wrong.
⇒ On the reverse — assuming a full screen means active use: the screen that looks used.
Four: what machines catch and what they do not
Worth being precise about, because it determines how much you can rely on the system.
Caught an empty slot where a value should go
Caught a broken link, sometimes
Not caught "we've written twice"
Not caught "since you haven't started"
⚠️ The two that cannot be caught are the two that talk about the reader. No system knows whether the sentence is true of the person receiving it.
⇒ Which means a person has to read it as the second recipient, not the first. That is the whole job.
Five: the review that works
Not a proofread. A specific exercise.
Pick somebody in the group who is the OPPOSITE of the person you wrote for.
Read the message as them.
⚠️ Every sentence that becomes false is a sentence to change.
Example
Written for a guest who has not visited since signing up
Read it as a guest who comes every week
⇒ "since you haven't been in" becomes an insult
⇒ "your first visit" becomes wrong
⇒ "we'd love to see you" is fine - it survives both
⇒ The sentences that survive both readings are the ones to keep. The others need conditionals or removal.
Six: the same shape outside messaging
This is not only about email.
A sign written for one situation, left up permanently
A policy written for one incident, applied to everyone
A script written for one caller, read to all of them
⚠️ All three start as a good response to a specific case. The failure comes from the promotion to general use, not from the original.
⇒ On instructions that stay up after they stop being true: the note that was true when you wrote it.
Seven: who checks
Worth settling explicitly, because it falls between roles.
Whoever writes it knows what it means
Whoever sets it up knows who it goes to
⇒ neither alone can see the problem
⚠️ The check needs both facts in one head at one time. In practice: the writer reads it again after being told exactly who will receive it.
The one-line handover
"This goes to everybody who has X, including people who have Y."
⇒ Hand that to the writer before they finalise. Most of these problems disappear at that sentence.
Numbers worth keeping
One For each automated message: when was it last read by a person?
Two How many contain a fixed date?
Three How many contain a count?
Four How many make a statement about the reader's behaviour?
⚠️ Four is the one to act on, and reading for it takes ten minutes across a whole sequence.
The card for the office
────────────────────────
Before a message goes automatic
1. Any fixed dates? Replace or remove.
2. Any counts? Count at send, or drop.
3. Any "since you..."? Make it "if you...".
4. Read it as the opposite person.
Written for one, sent to all.
────────────────────────
Common objections
"It reads better with the specifics"
⚠️ It does. It also reads worse to everyone it is wrong about, and there are more of them.
"We'll update it when things change"
⇒ Nobody does. Automated messages are set up once and read again only when somebody complains.
"The system will flag anything wrong"
⚠️ It flags empty slots. It cannot flag a sentence that is grammatically fine and factually wrong about the reader.
"It's only a small inaccuracy"
⇒ To the reader it is evidence about how well you know them. Small and wrong is worse than general and right.
"We only have a handful of customers"
⇒ Then write to each one properly and skip the automation. The trouble starts when a personal message is promoted to automatic.
What to do this week
One List your automated messages. Include the ones you forgot exist.
Two Read each one as somebody who is doing fine.
Three Mark every sentence that becomes false. Fix those.
Four Replace fixed dates with inserted ones, or remove them.
Five Turn every "since you..." into "if you...".
Summary
- Personal detail is what makes a message good and what makes it unfit to automate
- Strip dates, counts, and statements about the reader
- Machines catch empty slots, not claims about the recipient
- Read it as the opposite person — that is the whole review
- The writer needs to know exactly who receives it before finalising
- "Since you" becomes "if you", and the problem disappears
The message that felt personal is the one that travels worst. Everything that made it right for one person is waiting to be wrong for the next.
Related articles
The Rule You Broke An Hour After Making It
The hour after you write a rule is when you are most likely to break it. Not because you forgot — because you were looking at the thing you just fixed, not the next one. Here is why, and what actually holds.
The Check That Proved The Wrong Thing
You test something to rule out a cause, it passes, and you move on — but the test never touched the part that was broken. Here is how a comparison goes wrong, and the four questions that make one worth running.
The Account Nobody Remembers Creating
Somewhere in your systems is a login made years ago by someone who has left, still working, still able to do things. Here is how to find them, how to judge which matter, and why deleting is rarely the first move.
Map out your operations in 5 minutes
Eight questions cover reservations, customer management, shifts, and settlement. Results shown instantly with industry benchmark. Sales emails only if you request them.
Your answers are not stored. The assessment runs entirely in your browser.
Try tasteck free for 30 days
No credit card required. Full access to reservations, cast shifts, dispatch, and analytics.
- No card required
- Free data migration support
- All features unlocked for 30 days