A customer communication contains one sentence that needs to change.
Compliance agrees the new wording. Operations knows exactly what should be updated. The change does not alter a calculation, business rule or system integration.
And yet the next step is:
Raise a developer ticket.
The ticket enters a backlog. A developer changes the wording in code. The change is reviewed, tested, bundled into a software release and eventually deployed.
For some changes, that process is absolutely necessary.
For a wording-only change, it may be solving the wrong problem.
Customer wording and application code are different kinds of change
Software release processes exist for good reasons. Changes to application behaviour can affect security, calculations, integrations, customer journeys, data handling and system stability.
Those changes need appropriate engineering controls.
Customer communication wording has a different control problem. The questions are usually:
- What wording should the customer see?
- Why is it changing?
- Who reviewed the new wording?
- Who approved it?
- When should it become operational?
- Which version should be used after that point?
- Can the organisation later demonstrate what happened?
Those are primarily communication-governance questions rather than software-deployment questions.
When customer wording is embedded directly inside application code, the two control systems become coupled. A content decision then inherits the engineering release process whether it needs it or not.
A one-word change can inherit an entire release cycle
Consider a relatively simple change to an existing customer letter.
The template currently says:
Please contact us immediately if you cannot make this payment.
After reviewing customer feedback, the team agrees clearer wording:
Please contact us as soon as possible if you cannot make this payment.
No new data is required. No calculation changes. No integration changes. The structure of the document remains the same.
If that wording lives inside application code, however, the change may still require a ticket, prioritisation, developer time, code review, testing, release approval and deployment.
The controls are real, but many of them are protecting the application rather than governing the wording.
That distinction matters because the organisation can end up spending engineering capacity on changes that Compliance and Operations are better placed to own.
The real question is not “Do we need developers?”
The useful question is:
Does this change alter communication content, or does it alter software behaviour?
If it alters software behaviour, Engineering should be involved.
If it changes controlled wording within an already supported template structure, a properly designed communication platform can allow that content to move through its own versioning, review and approval process without requiring an application deployment.
This is not about removing Engineering from customer communications. It is about putting Engineering at the correct boundary.
Changes that may not need a software release
Where the communication architecture already supports the required template and data, examples of content-only changes might include:
- rewriting a sentence for clarity;
- correcting outdated explanatory wording;
- changing the order of existing paragraphs;
- updating an existing disclosure;
- making existing information more prominent;
- changing headings or labels;
- simplifying terminology;
- correcting spelling, punctuation or formatting;
- updating standard support wording; or
- changing content in response to customer feedback or communication testing.
The important condition is that the required data, rendering capability and technical behaviour already exist.
A controlled communication system can then treat the change as a new template version rather than a new application release.
Changes that still need Engineering
Separating communication content from application code does not mean every change becomes a self-service content edit.
Engineering may still need to be involved where the change affects the technical contract or system behaviour.
For example:
- a new customer-data field is required and the source system does not currently provide it;
- a new calculation must be performed;
- new conditional business logic determines which content a customer receives;
- the API contract needs to change;
- a new system integration is required;
- a new communication channel is being introduced;
- authentication, permissions or security behaviour needs to change;
- the rendering engine needs new technical capability; or
- the application's behaviour changes beyond selecting and populating an existing controlled template.
These are engineering changes because the system itself must do something new.
The distinction is therefore not business versus Engineering. It is controlled content change versus technical change.
“Put the wording in config” is not the whole answer
A common response to this problem is to move customer wording out of source code and into configuration.
That can reduce deployment dependency, but configuration alone does not create communication governance.
A text field in a database or configuration file still leaves several questions unanswered:
- Who can edit it?
- Does an edit immediately affect customers?
- Is the previous wording preserved?
- Can somebody review the change before it becomes operational?
- Can the reviewer see exactly what changed?
- Does an approval belong to a specific version?
- Can a rejected version remain in the history?
- Can the organisation later establish which version generated a communication?
Moving text outside the codebase solves the location problem.
It does not automatically solve the control problem.
This is why customer communication version control matters. The wording needs its own controlled lifecycle rather than simply a different place to live.
Approval and deployment should not be the same event
Another problem appears when communication approval is tied directly to software deployment.
Suppose Compliance approves new wording on Tuesday, but the next application release is scheduled for the following Monday.
When did the communication change?
Tuesday is the approval date. Monday is the operational date.
Those are different events, and a useful communication workflow should be able to distinguish them.
The same principle works in the other direction. An organisation may approve wording in advance of a planned effective date. Approval should not necessarily make that version immediately customer-facing.
A controlled workflow can therefore separate:
Draft → Review → Approved → Live
Approval records the governance decision. Going live records when the approved version becomes available for operational use.
For a deeper look at that decision trail, see What an Approved Wording Workflow Needs to Record.
Why release dependency can become an operational bottleneck
When every wording change depends on Engineering, several small delays can accumulate.
First, the change has to compete with software work for priority. Then somebody needs to translate the communication request into a technical ticket. The change is implemented and checked. It may need to wait for the next release window. Finally, the business team must confirm that the deployed wording matches what was approved.
For one communication, that may be manageable.
Across hundreds of templates and repeated regulatory, product, customer-service and accessibility changes, the same pattern can consume substantial coordination time.
It can also create uncomfortable incentives. Teams may batch wording changes together because releases are expensive, postpone improvements until a convenient deployment window or treat an urgent communication correction as an emergency software change.
None of those outcomes necessarily improves governance.
Timely communication improvement matters
The FCA's March 2026 review of consumer understanding provides useful context here.
The FCA described good practice as an end-to-end process connecting communication design, testing, monitoring and governance. It also highlighted firms using customer feedback, complaints and other evidence to identify where people were struggling, then making meaningful improvements rather than cosmetic changes.
The review gives examples such as rewriting confusing wording, improving the prominence of important information and acting on monitoring results through governance processes.
See the FCA's Consumer understanding: good practice and areas for improvement.
This does not mean the FCA requires firms to separate customer wording from software releases, nor does it prescribe a particular technical architecture.
The operational point is simpler: if monitoring identifies a communication problem and the organisation decides the wording should change, the process for making that change should support effective governance rather than creating unnecessary friction.
The communication still needs control
Removing a developer ticket should not mean replacing a controlled process with unrestricted editing.
If business teams can change customer-facing wording, appropriate controls become even more important.
The organisation may need role-based permissions, version history, review, approval, comments, release controls and an audit trail. A wording change should become easier to manage without becoming easier to release accidentally.
That is the difference between self-service editing and controlled communication management.
One removes a technical dependency.
The other replaces that dependency with a governance model designed specifically for customer communications.
Generation should use the approved communication, not an old release assumption
Separating templates from application deployments also changes how connected systems should think about versions.
A client application should not need to know that the payment reminder is currently Version 17. It needs to know that it requires the payment-reminder template.
In a controlled model, the application sends the stable template identifier and the communication platform determines which approved version is current for normal generation.
This avoids distributing version-selection logic across multiple consuming applications.
It also means the approval lifecycle can progress without requiring every connected system to be reconfigured each time the wording changes.
The version used at generation should then remain traceable through the communication evidence record. See How to Evidence a Generated Customer Communication.
Changing wording faster should not mean losing evidence
Speed without evidence is not the objective.
If a wording change becomes operational outside the normal software release process, the organisation should still be able to establish:
- what the previous wording was;
- what changed;
- who made the change;
- who reviewed and approved it;
- when it became operational; and
- which version was subsequently used for generation.
In other words, removing the deployment dependency should make the evidence chain clearer, not weaker.
How CommsPliant separates wording changes from software releases
CommsPliant keeps customer communication templates in a controlled, versioned workspace rather than requiring their wording to be maintained inside the consuming application's codebase.
Once Engineering has connected the relevant system to CommsPliant, business or operational users can make supported content changes within the template environment. A change creates a new version rather than rewriting the previously approved content.
The new version can then move through the organisation's review and approval process. Until it has the required approval and is available for use, the existing approved version remains the operational version.
For generation, the connected system requests the template by its identifier. It does not choose an arbitrary historical version. CommsPliant uses the latest approved version available for that template at generation time.
The CommsPliant Evidence Vault maintains evidence around that controlled lifecycle, including the approved-version context, approval history, rendering timestamp and tamper-evident hash associated with the rendering event.
Engineering remains responsible for the integration and for technical changes that genuinely require development. Compliance and Operations can control wording changes without automatically turning each one into a software release.
Where to draw the boundary
A practical way to decide whether Engineering needs to be involved is to ask four questions.
1. Does the change use data the system already provides?
If yes, it may be a template change. If the communication requires new customer or product data, the integration may need engineering work.
2. Does the system need to behave differently?
If a new calculation, routing rule or business decision is required, that is more than wording.
3. Does the existing renderer already support the required output?
Changing text within an existing PDF or email structure is different from introducing a new rendering capability or communication channel.
4. Is the change governed by the communication workflow?
If authorised users can edit, review, approve and release the content through a controlled versioning process, the wording does not need application source code merely to remain governed.
A simple test for your current architecture
Choose one live customer communication and imagine Compliance needs one sentence changed today.
Ask:
- Does anybody need to change application code?
- Does a developer need to raise or complete a ticket?
- Does the change need to wait for a deployment window?
- Can Compliance or Operations preview the exact proposed wording?
- Can the new wording be reviewed without affecting the live version?
- Can an authorised person approve the exact version they reviewed?
- Can the old version remain available as history but unavailable for normal generation?
- Will connected systems automatically use the new approved version once it becomes operational?
- Can the organisation later identify when the change happened and which generated communications used it?
If changing one sentence requires the full machinery of software delivery even though no software behaviour is changing, the organisation may have coupled two different control problems together.
The goal is not to make Engineering move faster.
It is to stop asking Engineering to deploy a sentence when what the organisation really needs is a controlled way to govern communication content.