Blog / Method / No.004

Writing a message that does not sound like a template

One specific true sentence beats four paragraphs of personalisation tokens, and the reason is mechanical rather than aesthetic.

Mohamad · KnockwireMay 19, 20266 min readMethod

A message that does not sound like a template is not a message with more variables in it. Merge-field personalisation reads as automated precisely because it is structurally identical every time: the slot changes, the sentence around the slot does not, and the recipient has long since learned to recognise the sentence. One specific true observation about the business you are writing to beats four paragraphs of tokens, and it beats them for reasons that are mechanical rather than aesthetic.

01Why personalisation tokens sound like a template

Take the canonical opener: I loved your post about {topic}. The variable is the only part that moves. Send it a thousand times and you have sent one sentence a thousand times with a thousand different nouns dropped into it, and the invariant part is most of the characters on the screen.

Recognition happens before comprehension. Someone who receives six of these in a week is not reading them, they are pattern-matching on the frame, and the frame is the one thing you cannot vary. The token was meant to prove you paid attention. What it proves is that a field existed for it, which means a table existed, which means a list existed, which means the reader is on a list.

There is a second tell, and it is structural too. A merge field can only be filled from data that exists for every row, which pushes the personalisation toward whatever is cheapest to collect at scale: a first name, a company name, a job title, the headline of a recent post. Those are the facts that are true of everyone on the list by construction. The property that makes a field fillable at volume is the same property that makes it uninformative.

A concrete observation about the recipient's actual business is expensive per company, and that expense is not a defect of the method. It is the signal. Research cannot be faked at volume, which is exactly why research at volume reads as real.

02The test we apply to every sentence

Our test is a substitution. Take each sentence in a draft, swap in another company from the same qualified list, and ask whether it is still true. If it survives the swap, cut it. Most opening lines do not survive, including several that feel personal while you are writing them.

  • You are scaling fast and data is central to what you do. True of every company on the list by definition, because that is what put them on the list in the first place.
  • I have been following your work for a while. True of nobody, checkable by no one, and the reader knows both of those things immediately.
  • Congratulations on the funding round. True of a few hundred companies this quarter, and usually three months out of date by the time it arrives.

What passes the test differs in kind rather than in degree. Your documentation describes handling 403 responses as the caller's problem, and your pricing page tops out at a tier that implies continuous collection rather than a one-off project. That sentence is true of a handful of companies and false of the rest of the list, which is why it is worth writing and why it took a research step to produce.

If a sentence survives having another company name dropped into it, it is not evidence. It is decoration.

Length follows from this on its own. Once the standard is one specific true sentence, drafts get shorter, because the padding was only ever there to carry tokens between the parts that mattered. A draft that survives the substitution test usually runs to four or five sentences: what we noticed, where we noticed it, why it might matter to them, and a question that can be answered in one line.

03The draft sits beside its evidence

Every draft goes to a human before anything is delivered. That gate is not a formality, and the design of the screen decides whether it does any real work.

The reviewer sees the draft on one side and the evidence rows it was written from on the other: the source, the address it came from, the date the fact was observed, and which gate it cleared. The question the reviewer is answering is whether this message follows from these facts. It is deliberately not whether this reads nicely.

That distinction carries most of the weight. Reads nicely is unfalsifiable and cheap to satisfy, and a fluent, well-mannered paragraph of nothing sails through a proofreading review before failing the only test that counts, which is whether the recipient recognises their own business in it. Follows from the evidence is checkable by anyone. A reviewer can point at a clause and say the evidence does not support that, and the draft goes back.

Reviewers have three actions: approve, edit, or reject with a written reason. The rejections are the useful output, because they are the only place where the drafting step gets told it was wrong in a form it can learn from. In our own runs, the reason recorded most often has been that the message asserts something the evidence does not establish, which is the polite way of saying the writer guessed.

GateA draft is not a knock. Delivery today goes through the target's own public contact form, under a real named person at a real address, and only after a human has approved it. Email sending is planned for Q4 2026 and is not built.

04What we refuse to send

We will not send a draft that has no specific evidence attached to it. That is enforced in the data rather than in a style guide: a draft carries a set of evidence rows, and a draft whose evidence set is empty cannot enter the review queue at all. There is no override button, because an override would be used on the busy days, and the busy days are precisely when it should not be available.

The reasoning is narrow. If a message could have been written without the evidence, then the evidence was never doing anything, and what remains is a template with a company name in it. A message written without evidence is the exact thing the review queue exists to catch, so letting one into the queue would leave the reviewer judging prose, which puts us back at reads nicely with extra steps.

It also keeps the refusal ledger honest. When we turn a company down, the ledger records why: no usable door, wrong profile, nothing we could write a specific sentence from. That last one is a legitimate reason to turn a company down, and it belongs in the ledger as a refusal rather than being smoothed over by a vague message we sent anyway. A company we cannot say anything specific about is a company we have not finished researching, and the honest options are to research it or to reject it, never to write around the gap.

The uncomfortable consequence is that this caps volume, and we are content with the cap. The number of companies we can say one true, specific thing about is smaller than the number we can find doors for, and that number is smaller again than the number we can read. Every one of those gaps is a refusal with a reason written next to it. A short list of messages that could only have been sent to one company each is the product. A long list of messages that could have gone to anyone is what everybody already has.

Knockwire reads the internet, throws out the companies that will never buy from you, and knocks on the doors of the ones that will. Run it on your own domain and read your own refusals.

Run it on my siteAll posts