An approval is only useful if you can tell exactly what was approved.
That sounds obvious. In practice, customer communication approvals are often spread across email threads, ticket comments, shared documents, meetings and release records. A Compliance colleague may write "approved" in one system while the wording changes later in another.
Months afterwards, the organisation may still know that somebody approved the communication. What becomes much harder is proving which wording they actually reviewed, what changed afterwards, and which version eventually became operational.
A controlled wording workflow is designed to remove that ambiguity.
Approval should belong to a specific version
The starting principle is simple: an approval should be attached to a specific version of a communication, not just to the name of the template.
Imagine a payment reminder called PAYMENT-REMINDER-01. Version 6 is reviewed and approved. A colleague then changes two sentences to create Version 7.
Version 7 should not automatically inherit the approval given to Version 6. The approved decision belonged to the wording that existed when the reviewer or approver made that decision.
This is why approval workflow and customer communication version control need to work together. Version control identifies the state of the communication; the workflow records what happened to that version.
What should the workflow record?
The exact requirements will depend on the organisation, regulatory context and type of communication. A useful workflow, however, should normally be capable of answering a small set of very practical questions.
- Which exact version was submitted for review?
- What changed from the previous version?
- Who made or proposed the change?
- Why was the change made?
- Who reviewed it?
- What decision did they make?
- Who gave the final approval required by the organisation's process?
- When were those decisions made?
- Were comments, conditions or requested changes recorded?
- When did the approved version become available for operational use?
The purpose is not to create bureaucracy for its own sake. It is to preserve enough context that somebody who was not involved in the original discussion can later understand what happened.
1. The exact version reviewed
The most important record is the content itself.
An approval entry saying "Payment reminder approved by Compliance" is incomplete if the underlying wording can continue changing without creating a new version.
The decision needs a stable reference: Version 6, for example, with content that remains identifiable after Version 7, Version 8 and Version 9 have been created.
This also prevents a subtle problem that appears when documents are overwritten. If a shared Word file changes after approval, the organisation may still have the approval email but no longer have an authoritative copy of the wording that was on screen when the decision was made.
Controlled versioning keeps the decision and the content together.
2. What changed
A reviewer should not have to rediscover every alteration by manually comparing two long documents.
A useful workflow makes the change visible. Depending on the system, this might be shown through a version comparison, highlighted edits, a change summary or another controlled representation of the difference between versions.
This becomes particularly valuable when the change appears small. Replacing a sentence, changing a deadline, moving a disclosure or altering a single qualifying word can materially affect what a customer understands.
Recording what changed also makes later investigation easier. Instead of asking, "Why does Version 8 look different?", the organisation can follow the evolution of the wording through its version history.
3. Why the wording changed
Knowing what changed answers only half the question.
A useful record also captures enough context to explain why the change was proposed. The trigger might be a regulatory change, customer complaints, testing results, legal advice, a product change, operational feedback, accessibility concerns or simply clearer wording.
This principle aligns closely with the FCA's March 2026 review of consumer understanding. In its examples of good practice, the FCA describes firms documenting what changed, why it changed and the impact of each change, creating a clearer link between insight and action.
The FCA also highlights clear records of decision-making and governance structures that connect relevant functions across the organisation. See the FCA's Consumer understanding: good practice and areas for improvement.
That does not mean every wording change requires the same level of documentation. A punctuation correction and a substantial rewrite of a customer warning are not necessarily equivalent. The organisation's control framework should determine what level of explanation and review is proportionate.
4. Who made the change
A controlled workflow should record who created or changed the version and when.
This is not primarily about finding somebody to blame. It is about establishing provenance.
If a communication evolves through several drafts, the audit history should make it possible to understand how the version reached its approved state without relying on people's memories.
Identity also matters because different roles may have different permissions. An organisation may allow Operations to edit wording, for example, while requiring Compliance or another authorised role to approve it before it becomes available for use.
5. Who reviewed it
Review and approval are often spoken about as though they are the same event. They do not have to be.
A reviewer may inspect wording, raise questions, request changes or confirm that particular concerns have been addressed. Depending on the organisation's governance model, another authorised person may then make the final approval decision.
There is no universal rule that every customer communication requires two different people acting as reviewer and approver. The appropriate roles depend on the organisation, communication, applicable regulation and internal controls.
What matters operationally is that the workflow does not hide the distinction when the organisation uses one. If Sarah reviewed Version 12 and James approved it, the record should not collapse those events into an anonymous green status badge.
6. What decision was made
A useful workflow needs more than an Approved button.
A version may be:
- returned for changes;
- rejected;
- approved;
- superseded before becoming operational; or
- withdrawn from use later.
The precise statuses can vary, but the important point is that the decision remains intelligible afterwards.
If a reviewer rejected Version 4 and the author responded by creating Version 5, the rejected Version 4 should remain part of the history. Otherwise the eventual approved wording tells only the ending of the story and not how the organisation reached it.
7. Comments and requested changes
Review decisions often involve more nuance than yes or no.
A reviewer may question one sentence, request additional prominence for important information or ask the author to clarify why particular terminology is being used. Those comments can form part of the governance evidence behind the final version.
The useful principle is that comments should remain connected to the version being discussed. A comment attached vaguely to "the latest template" becomes difficult to interpret after several additional edits.
When the author responds by changing the wording, that change should produce the next controlled version rather than silently rewriting the version the reviewer originally examined.
8. Timestamps matter
Who approved a version matters. So does when.
A timeline can establish when the wording was created, when it entered review, when a decision was made and when the approved version became operational.
Those are not necessarily the same moment.
A version might be approved on Monday but scheduled to become operational on Friday. Alternatively, an urgent regulatory change may be reviewed and released much more quickly.
If those events are recorded separately, the organisation can distinguish approval time from effective or release time. That distinction becomes particularly important when investigating communications generated close to a wording change.
Approved does not automatically mean live
This is another distinction worth preserving.
Approved means the required decision has been made according to the organisation's workflow. Live means the version is available for operational use.
Keeping these concepts separate allows the organisation to approve future wording before its effective date without replacing the version currently being used too early.
It also makes the audit trail clearer. Instead of one status trying to represent several business events, the history can show the sequence from draft to review, approval and operational release.
The workflow should continue after approval
The control problem does not end when a status changes to Approved.
Once the communication is operational, the organisation may later need to establish which approved wording was used when a particular email, letter or PDF was generated.
That requires a connection between the approval workflow and the generation process. We cover that separately in How to Evidence a Generated Customer Communication.
It is also important to distinguish generation evidence from delivery evidence. Showing which approved version produced a communication does not, by itself, demonstrate that the communication was successfully sent, delivered, opened or read.
Approval should not accidentally become a software release decision
In many organisations, customer wording is stored inside application code. That can cause communication approval and software deployment to become tightly coupled.
Compliance approves the wording, but the change cannot become operational until an engineering ticket is completed, code is reviewed, testing finishes and the next deployment takes place.
Some changes genuinely require engineering work. A new data field, integration, channel or technical behaviour may need software development. But a wording-only change does not necessarily need to inherit that entire process if the communication architecture separates content governance from application code.
We explore that boundary in When a Wording Change Should Not Wait for a Software Release.
What the FCA context tells us
For firms within scope of the UK Consumer Duty, PRIN 2A.5 applies to firms involved in the production, approval or distribution of retail customer communications and requires firms to support retail customer understanding.
The FCA's March 2026 consumer understanding review provides useful operational context. Its good-practice examples include clear ownership, documented decision-making, governance involving relevant functions, testing and monitoring, and documenting what changed, why it changed and the impact of those changes.
None of this means that the FCA prescribes one particular software workflow or database structure. Nor does the existence of an approval record establish that the communication is automatically compliant.
The practical lesson is narrower: where organisations make decisions about regulated customer communications, preserving a clear link between the wording, the evidence considered and the decision made can make governance substantially easier to demonstrate.
Automation can assist without becoming the approver
Modern communication systems can assist people in drafting, comparing or reviewing wording. That does not require the system itself to become the decision-maker.
For high-governance workflows, there is value in keeping the distinction explicit: technology can assist with the work, while the authorised human remains responsible for the approval decision.
This also makes the audit record easier to understand. A later reviewer should be able to distinguish between content that was changed, automated assistance that was used, and the human decision that allowed the version to progress.
How CommsPliant approaches wording approval
CommsPliant connects approval directly to version-controlled customer communication templates.
A change creates a new version rather than rewriting the previously approved content. That version can move through review and approval while the existing approved version remains available for operational use until the replacement is ready.
Review and approval actions are recorded against the relevant version, creating a clearer history of who acted and when. Once the required approval has been completed and the version is released for use, connected systems can generate communications from the controlled approved version rather than choosing an arbitrary historical version themselves.
CommsPliant's governed AI model follows the same separation of responsibilities. AI can assist with template wording, but it cannot approve, publish or send a communication. Those decisions remain within the human-controlled workflow.
The CommsPliant Evidence Vault then preserves evidence around the approved version and its approval history, helping maintain the connection between the communication content, the governance process and subsequent rendering evidence.
The objective is not more approval steps. It is a clearer record of the approval steps the organisation actually needs.
A simple approval-record test
Choose one customer communication that was changed and approved several months ago. Without contacting the people who worked on it, try to answer:
- Which exact version was submitted for approval?
- What changed from the previous version?
- Why was the change proposed?
- Who made the change?
- Who reviewed it?
- What comments or requested changes were raised?
- Who made the approval decision?
- When was that decision made?
- Did anybody edit the content after approval?
- When did the approved wording become operational?
If those answers can be obtained from one coherent history, the workflow is doing more than recording a status.
If they require reconstructing the decision from email, tickets, meeting notes, source code and shared files, the organisation may have an approval process without having a durable approval record.
That difference becomes most visible when the people who remember what happened are no longer the people being asked to prove it.