Two hundred letters, and only one generated paragraph
The job that looks like a hundred jobs
Two hundred renewal letters. Forty appraisal summaries. Sixty invoices with a covering note. Ninety school reports.
The tempting instruction is: write all two hundred. The result is two hundred documents to check, which is two hundred opportunities for a wrong figure to leave the building, and about as much work as writing them.
There is a much better architecture, and it is mostly forty-year-old technology.
Three layers, and only one is generated
Layer one: the fixed text. The parts that are identical in every letter — the terms, the legal wording, the explanation of the process, the contact details. Written once, by a person, checked once, by a person. This is usually 70 to 90 per cent of the document.
Layer two: the merge fields. Name, address, amount, date, account number. These come from your data, mechanically, with no model involved. A merge field is exact or it is empty; it does not approximate.
Layer three: at most one generated paragraph. The part that genuinely depends on this recipient's situation — the sentence about why their premium changed, the comment on the pupil's progress, the note about their particular usage.
Now count the checking. The risky legal text is identical across all two hundred and was checked once. The figures came from data and can be validated by arithmetic. What is left to read is two hundred short paragraphs — and you can sample them intelligently rather than reading every one.
Do not ask it to vary the wording
Somebody always suggests: "vary the phrasing so they don't look templated."
Resist it, for two reasons. It is the mechanism by which a factual difference creeps in between letters that were supposed to say the same thing — and when two recipients compare, which they do, you are explaining why one was told something slightly different. It is also mildly deceptive: the letters are templated, everybody knows it, and disguising it buys nothing.
Variation should come from the data, because the data is what actually differs between recipients.
Checking a batch properly
You cannot read two hundred and you should not read twenty at random. Split it:
- Check every outlier. Every record with an unusual field value: a negative amount, a zero, a very long name, a missing middle field, an address in a different country, a date outside the expected range. These are where merges break and where generated sentences go strange.
- Sample the ordinary middle. Twenty is plenty if the outliers are all covered.
- Run a mechanical validation over the whole set before anything prints. Search the output for
<,>,NOT FOUND,{{, double spaces, and the word "None". A leftoverDear <FirstName>in one of two hundred letters is the classic, and it is entirely preventable by one search.
Also check the count. Two hundred records in, two hundred documents out. If it is 198, find the two before the post goes.
The free tools are the right tools
Mail merge is free, everywhere, and more reliable than anything generated:
- LibreOffice Writer does full mail merge from a spreadsheet or database, to print, PDF or email, on any operating system.
- Microsoft Word does the same if you have it.
- A twenty-line Python script with a template string does it for anyone comfortable with that, and gives you the validation step for free.
- For PDFs, LibreOffice exports directly, and
qpdfmerges and splits the results.
The model's job is to help you write layer one well — once — and to generate layer three, briefed tightly:
Write one sentence, maximum 25 words, explaining the change in this customer's premium, using only these fields: previous_premium, new_premium, main_reason_code. If main_reason_code is blank, write NOTHING and output the word BLANK so I can catch it. Do not speculate about causes.
That is a narrow, checkable task with an explicit failure signal. It is also the only part of two hundred letters that needed a model at all.
Where the batch goes afterwards
One last step people skip. Two hundred generated documents are two hundred records, and in most trades that means they have to be filed, retained for a period and findable if somebody complains about theirs.
So save the batch with the data that produced it — the spreadsheet of merge fields, the template version, the date, and the exact brief used for the generated paragraph. Six months later, when one recipient asks why their letter said what it said, that folder answers in thirty seconds. Without it you are regenerating from a model that may since have changed, which does not reproduce the original and is not an answer.
Export to PDF rather than leaving the batch as editable documents, keep the source data alongside, and if your sector has a retention period, put the deletion date in the folder name.
The one thing to keep
Fixed human-written text plus mechanical merge fields plus at most one generated sentence turns two hundred documents to check into one document checked once and two hundred short paragraphs you can sample — with every outlier read and a search for unfilled placeholders run over the whole batch.
Before you move on
Why is "vary the wording between letters so they don't look templated" a bad instruction, on grounds beyond taste?
Pick the one you would defend. Nobody sees your answer.