🎧 Listen to this article as a podcast on Spotify
An illustrative situation, not a customer case.
A reviewer receives one tracked change: a new sentence in paragraph three explaining an extra payment option. It is clear and accurate. They approve it.
Paragraph five still says the original options are the only ones available.
Both paragraphs were approved at some point. Together, they tell the customer two different things.
The short answer: reviewing the change checks the new words. Reading the whole letter checks how those words work in context. Decide in advance when a full read is needed, and record which review happened.
Why a change-only review can miss things
A change-only review may be proportionate for a genuinely isolated correction. Even a phone number or date, however, can appear elsewhere or affect an instruction, so check those connections before limiting the review.
The risk sits in what the change touches elsewhere: a sentence the reviewer never sees, a second mention of the same point, or several small changes that were each fine on their own but together have changed what the letter means.
Five signals that call for a full read
When any of these applies, ask for the whole letter to be read, not just the change:
- The change touches a promise, a deadline, an amount or an option.
- The same point appears somewhere else in the letter.
- Several small changes have gone through since the last full read.
- The change comes from a team that does not own the letter.
- The product or rule behind the letter has changed since the last full read.
A change can be correct on its own and still make the letter wrong.
What a full read covers
A full read is more than reading the tracked document from top to bottom.
- Read the generated output, not only the editor. Preview the generated letter with realistic fictional data and relevant variations, such as long names and addresses, optional sections, or zero amounts where these are valid. Layout problems and missing values can show up there that the template view hides. We explored output testing in more detail in our article on Regulation F validation notices. Its regulatory discussion is specific to the US.
- Check for consistency. Repeated references to the same option, amount, date or next step should agree. Where different figures or dates serve different purposes, their relationship should be clear.
- Check the route to help. Contact details and opening hours should match the current service. Any referenced enclosures should be included and consistent with the letter.
- Read it as the customer would. Start at the top, with no knowledge of what changed. Check whether the purpose, available options and next step are clear. This can reveal problems, although it does not by itself establish customer understanding.
Record what the review covered
Later, someone may ask what the reviewer actually checked. A useful review record captures:
- which version was reviewed;
- whether it was a change-only review or a full read;
- who reviewed it and when;
- which fictional test scenarios and generated outputs were checked;
- the review outcome, including any issues raised and how they were resolved.
That record also tells you when the last full read happened, which helps identify when several smaller changes have accumulated.
Where CommsPliant fits
In CommsPliant, reviewers check the proposed version of the communication itself and can preview it before approval. They can comment, approve, reject or request changes, and each decision stays linked to that version.
The person who wrote or edited a version cannot approve it; the platform enforces this.
The team still needs to define when a full read is required, and the reviewer needs to apply those criteria to the change.
Next step
Pick the letter your team changes most often. Find when someone last read it from start to finish, rather than reviewing a change.
If nobody can say, that is the review to book first.