Frequently asked questions

CommsPliant is a communication governance, rendering and evidence platform designed for organisations that need greater control over regulated, high-risk or operationally important customer communications.

It brings approved wording, reusable templates, version history, reviews, approvals, release controls, rendering and customer-level communication evidence into one connected workflow.

A communication can move through a controlled lifecycle:

Template & Version → Governance & Approval → Customer & Channel → Rendered Output → Delivery Status

Teams can create or update approved wording, record the reason for a change, assign reviewers and approvers, control which version is released and maintain a clear history of previous versions.

When a communication is generated, CommsPliant can connect the approved template and version with the relevant customer or communication reference, channel, timestamp, rendered output or recorded communication evidence, sending status and, where available, delivery status returned by connected systems.

This helps organisations answer important questions such as:

• Which wording was approved?

• Who reviewed and approved it?

• Why and when was it changed?

• Which version was active at a particular time?

• Which version was rendered for a specific customer?

• What communication evidence is available?

CommsPliant works alongside existing CRM, customer, case-management, operational and delivery systems rather than replacing them.

It is not the organisation’s compliance decision-maker. The organisation remains responsible for deciding what wording is appropriate and compliant. CommsPliant provides the controlled system underneath the communication process, helping teams manage approved content and retrieve connected evidence more efficiently.

CommsPliant CommsPliant is designed for organisations that create, approve, update and distribute regulated, high-risk or operationally important customer communications.

It may be particularly useful for businesses in financial services, pensions, fintech, insurance, debt collection, utilities, legal services and property management, where customer wording must be controlled, approved and evidenced.

Different teams may use CommsPliant for different reasons:

• Compliance and risk teams can review wording, approve changes and see which version was authorised for use.

• Legal and governance teams can maintain clearer records of reviews, decisions and responsibilities.

• Product and operations teams can update customer communications through a controlled process without relying on informal email chains or shared folders.

• Customer communication teams can manage reusable templates and approved wording more consistently across different journeys and channels.

• Engineering and technology teams can reduce the number of simple wording changes that require code changes, tickets, testing and deployment.

• Internal audit and assurance teams can retrieve connected evidence more easily instead of reconstructing the history from several systems.

CommsPliant is especially relevant where communication templates and evidence are currently spread across application code, tickets, pull requests, spreadsheets, shared folders, email conversations or separate approval tools.

It is also useful where a business can show which wording was approved but finds it harder to demonstrate which version was rendered for a particular customer, through which channel and at what time.

The platform is intended for organisations that want communication changes to be faster and easier to manage, while maintaining clear governance, accountability and customer-level evidence.

In many regulated businesses, customer communication content is buried inside application code or scattered across shared folders, email threads, spreadsheets and ticketing systems. This creates several common problems.

Developer dependency. A compliance or operations manager who needs to correct a single sentence may have to raise a ticket, wait for engineering capacity, arrange testing and wait for deployment, even when the wording change itself is simple.

Approval confusion. Without a structured workflow, approvals may happen informally across emails, documents and tickets. There may be no clear record of who reviewed the communication, who approved it, when approval was given or which version was authorised for use.

Fragmented audit evidence. When a regulator, auditor or internal risk team asks which version of a communication was used on a particular date, the evidence may be spread across inboxes, pull requests, shared folders, tickets and deployment records rather than available in one clear record.

The approval-to-customer gap. A firm may know which wording was approved but still struggle to demonstrate which template version was rendered for a specific customer, through which channel, at what time and with what sending or delivery status.

Difficult remediation. When outdated, incorrect or unclear wording is discovered, disconnected records can make it difficult to identify which communications and customers may have been affected.

CommsPliant connects the communication lifecycle in one traceable evidence chain:

Template & Version → Governance & Approval → Customer & Channel → Rendered Output → Delivery Status

This helps teams manage communication changes more efficiently and retrieve connected evidence without having to reconstruct the story across code, inboxes, tickets and delivery systems.

CommsPliant is designed to support repeatable transactional, regulated and operationally important customer communications that require controlled wording, approval, versioning and evidence.

Examples may include:

• registration, onboarding and welcome communications;

• account balance and account-status communications;

• weekly, monthly, quarterly and annual customer reports;

• customer reminders and nudge communications;

• payment, arrears and late-payment notices;

• transactional customer emails;

• policy, product or service updates;

• renewal and cancellation notices;

• complaints and remediation communications;

• disclosure documents and regulatory notices;

• customer letters and CRM-generated PDFs;

• document templates containing approved wording; and

• other customer-facing communications where version history, approval evidence and customer-level communication records matter.

CommsPliant is particularly relevant where teams regularly update approved wording and need a faster, more controlled way to manage changes, approvals, rendering and communication evidence.

The exact communication types, channels and integrations depend on the organisation’s use case and technical implementation.

CommsPliant supports approved communication templates, API-based rendering and PDF generation, including password-protected PDFs created from approved templates.

For example, an organisation may store approved wording and layout within CommsPliant, connect the template to customer or case information, and generate a controlled PDF communication for a specific customer. The system can then record which approved template and version was used, when the document was rendered and the related communication evidence.

CommsPliant is not intended to work as a general file-conversion tool. It is not designed simply to open a Word document and convert it into a PDF, transform an Excel spreadsheet into a letter, or convert CSV files between formats.

Word, Excel and CSV files may still form part of an organisation’s wider communication process. For example, they may contain source information, customer data, reporting data or draft content. However, how these files are imported, connected or used depends on the organisation’s technical requirements and agreed implementation.

The main purpose of CommsPliant is to control the communication itself. This includes:

• managing approved wording and reusable templates;

• maintaining version history;

• recording reviews and approvals;

• controlling which version is released;

• rendering customer communications;

• generating PDFs where required; and

• retaining evidence of which approved communication was produced for a particular customer or communication event.

Support for additional document or data formats may be considered where there is a clear regulated communication use case and suitable technical fit.

CommsPliant should therefore be understood as a communication governance, rendering and evidence platform, rather than as a general document-conversion service.

When a business or operations team member wants to update a piece of approved wording, they make the change inside CommsPliant.

That change enters a structured review workflow and cannot go live until the right approver reviews and signs it off. The approver may be from compliance, risk, legal review, operations or another authorised team, depending on the business process.

Once approved, the updated content can be made available through the API. There is no need for a code change, template deployment or developer ticket for every small wording update.

Every key step is recorded, including who edited the wording, who reviewed it, who approved it and when the approval took place.

Yes. CommsPliant is designed to keep a complete version history for every communication template.

Teams can see what the wording looked like at a specific point in time, review previous approved versions and understand how a communication changed over time.

This version history is designed to answer an important question in regulated businesses: what exactly was approved, what version was live, and can the business evidence which wording was in use at the time?

CommsPliant maintains an audit trail of changes, reviews, approvals and customer-level communication events.

This can include:

• who made each change and when;

• what changed and why;

• who reviewed and approved each version;

• when a version became live;

• the full text of historical approved versions;

• the customer or communication reference;

• the exact template version used at runtime;

• the rendered output or its recorded reference;

• the channel and timestamp;

• sending status;

• delivery status where the connected provider supplies it;

• the workflow steps taken before release.

This creates a connected audit trail from wording change and approval through to the individual customer communication event.

It is designed to support audit readiness and internal review, so that if a regulator, auditor or risk team asks about a specific communication, the relevant evidence can be retrieved in one place rather than reconstructed from tickets, emails and shared folders.

Engineering connects CommsPliant through an API.

Once the integration is in place, approved communication content can be pulled from CommsPliant by the client’s existing systems. The client’s own application, CRM, email platform or document-generation process can then use that approved content at the point of use.

This means engineering connects once and stays in control of the wider technical environment, while business and compliance teams can manage approved wording without needing a new developer ticket for every change.

The exact integration approach depends on the client’s existing systems, template complexity, communication volume and internal governance process.

Not necessarily.

CommsPliant can integrate with a client’s existing email, CRM, PDF-generation, document-storage or delivery systems. This allows those systems to continue sending customer communications through the client’s established infrastructure.

Communication delivery is not currently positioned as a standard standalone service. However, a tailored sending workflow or delivery integration can be provided where this forms part of an agreed client implementation.

Where the connected provider supplies sending or delivery information, CommsPliant can record the available status against the relevant communication event.

Yes. CommsPliant supports customer-specific rendering through approved data sources such as API integrations, connected databases or structured file imports.

Depending on the client setup, CommsPliant can:

• render an individual customer email, PDF or letter;

• return the completed communication to the client’s existing system without retaining the private customer document;

• store the rendered communication where the client requires managed storage;

• record the template version, approval history, customer or communication reference, channel, timestamp and sending status;

• record delivery status where the connected provider supplies it.

The exact integration, rendering and storage model is agreed with each client.

CommsPliant’s standard platform focus is controlled template management, approval workflows, version history, audit evidence and API-based rendering.

Batch rendering, asynchronous processing and tailored delivery workflows may be supported as part of a specific client implementation, depending on communication volume, technical requirements and agreed scope.

Where clients already have established delivery systems, CommsPliant can integrate with them and record the relevant sending and available delivery evidence.

CommsPliant can support different data and storage models depending on the client’s existing systems, security requirements and retention preferences.

Where a client already has its own customer database or document archive, CommsPliant can receive the required data through an API, database connection or approved file import, render the personalised communication and return it to the client’s system without retaining the completed customer document.

Where the client requires managed storage, CommsPliant can also store individual rendered emails, PDFs or letters under agreed security, access, retention and data-processing arrangements.

In either model, CommsPliant can retain the communication evidence needed to trace the template version, change history, approval, customer or communication reference, rendering event and available sending status.

CommsPliant does not need to become the client’s main customer database in order to provide customer-level communication traceability.

CommsPliant is intended to support export of communication templates, version history and audit records, so teams can retain access to their communication evidence outside the platform if needed.

This is important for regulated businesses because approved communications are not just content. They are operational records that may need to be reviewed, evidenced or retained as part of internal governance, audit or regulatory processes.

CommsPliant is designed to connect through a lightweight API, but the exact setup time depends on the client’s existing systems, template complexity, communication volume and internal review process.

For some teams, the first technical integration may be straightforward. For others, implementation may involve mapping existing templates, reviewing approval processes, confirming data handling requirements and agreeing how approved content should be rendered through the API.

Implementation timelines depend on your existing systems and governance requirements. CommsPliant is a working platform; we discuss scope, integration approach, and rollout with each client individually.

Yes. Financial services, pensions and fintech are the primary focus, but the underlying problem exists in many regulated or compliance-sensitive industries.

CommsPliant may also be relevant for teams in insurance, utilities, telecoms, legal services, property management and other sectors where customer communications require approval, version control and audit evidence.

If your team manages approved customer communications and needs clearer control over what was changed, who approved it and which version was sent, we would like to hear from you.

Neither, exactly.

CommsPliant is a controlled communications layer: a dedicated workspace that sits between business teams, compliance teams and engineering systems.

It is not a broad content management system for general website content or marketing pages. It is designed specifically for regulated customer communications where wording changes need approval history, version control and audit evidence.

It is also not a legal or regulatory advice platform. CommsPliant helps teams manage the operational process around approved communications, but it does not replace legal, compliance or regulatory judgement.

Shared folders and spreadsheets are common starting points, but they create problems as communication volumes and governance expectations grow.

Common issues include:

• No structured approval workflow

• Informal sign-off through emails or messages

• Files being overwritten, renamed or duplicated

• Weak version control

• Limited audit history

• Difficulty proving which version was live on a specific date

• Unclear ownership over who can edit approved wording

When a regulator, auditor or internal risk team asks for evidence of what the customer received and who approved it, a shared folder may not provide a clean answer.

CommsPliant is built to give teams a clearer way to manage approved wording, version history and communication evidence.

CommsPliant is designed to help regulated businesses build better operational control around customer communication governance.

This includes approval workflows, version history, audit trails and evidence of review for customer-facing wording. These are practical operational questions that may be relevant when firms need to demonstrate how communications are managed, reviewed and controlled.

CommsPliant does not provide legal advice and should not be treated as a compliance guarantee. Businesses remain responsible for their own regulatory obligations, legal review and compliance decisions.

CommsPliant is a working platform open to new clients and potential design partners.

Book a discovery call or contact us to discuss your communication workflow, see a demonstration, and explore implementation options. We review each enquiry to understand your use case and whether CommsPliant is a good fit.

Contact us through the registration form and tell us what communication problem your team is trying to solve.

We are especially interested in speaking with regulated and enterprise teams that manage customer emails, CRM-generated PDFs, letters or document templates through developer tickets, shared folders, spreadsheets or manual approval processes.

CommsPliant is not affiliated with or endorsed by the Solicitors Regulation Authority or any other regulator.

As the product develops, we welcome opportunities to engage with regulators, legal professionals and industry bodies to better understand communication-governance challenges and support responsible product development.

To prove what was sent, the communication record should connect the customer or communication reference to the exact approved template version used at the time.

The evidence may include:

• the template and version ID;

• the timestamp;

• the channel;

• the rendered output or recorded reference;

• the sending status;

• any delivery information supplied by the connected provider.
  

CommsPliant connects these elements so teams can trace how approved wording became a specific customer communication without relying on separate tickets, inboxes and system logs.

Preparing communication evidence involves more than retrieving the final email, PDF or letter. Teams may also need to show how the wording was created, changed, reviewed, approved, released, rendered and used.

Start by collecting the full evidence chain. This can include:

• the template and version used;

• the change history;

• the reason for the change;

• reviewer and approver details;

• the release or effective date;

• the customer or communication reference;

• the rendered output or its recorded reference;

• the channel and timestamp;

• the sending record;

• delivery status where the connected provider supplies it.

CommsPliant keeps these elements connected in one workflow, helping teams prepare relevant communication evidence without rebuilding the history across inboxes, tickets, code repositories and delivery systems.

A strong customer communication audit trail should show:

• what wording was used;

• which template version was used;

• what changed and why;

• who made, reviewed and approved the change;

• when the version became active;

• which customer or transaction it related to;

• which channel was used;

• what was rendered and sent;

• the sending status;

• delivery status, where the provider supplies it.

A good audit trail creates one traceable account of the communication lifecycle from change and approval through to the customer-level event.

Firms should first identify the communication, customer or transaction reference, relevant time period and the specific question being investigated.

They should then retrieve the connected record and explain the sequence clearly, including:

• what changed and why;

• who reviewed and approved it;

• when the approved version became active;

• which template version was used;

• what was rendered and sent to the customer;

• which channel was used;

• the sending record;

• any available delivery status.

CommsPliant links template versions, approvals, customer references, rendered outputs and sending records in one place. This helps firms respond more quickly and reduces the need to reconstruct evidence manually across code repositories, emails, tickets and delivery systems.

Use a controlled workflow that records every material change against a named user, timestamp and reason for change. The same workflow should capture reviewer comments, approval or rejection decisions, release history and the final approved version.

CommsPliant records this history so teams can see who changed the wording, why it changed, who reviewed it and who authorised it for use.

The exact evidence will depend on the organisation, sector, audit scope and issue being reviewed.

An auditor, regulator or internal risk team may ask for evidence showing how a customer communication was created, changed, reviewed, approved, released, rendered and used.

Depending on the scope of the review, this could include:

• the exact communication or rendered output;

• the template and version used;

• the date and time the version became active;

• what changed and why;

• who made, reviewed and approved the change;

• the customer, transaction or communication reference;

• the channel used;

• sending status;

• available delivery information;

• related testing, monitoring or governance records.

The exact request will vary. The evidence should provide a clear and traceable account rather than isolated documents from several different systems.

CommsPliant supports this operational evidence chain, but it does not determine the precise requirements of a particular audit.

You may need to demonstrate both control of the communication process and evidence of what happened in a particular case.

That can mean showing:

1. which wording was approved;

2. who approved it and when;

3. why the wording changed;

4. which version became active;

5. which version was rendered for the customer;

6. when and through which channel it was sent;

7. what sending or delivery status was recorded;

8. how the firm monitored whether communications supported good customer outcomes.

For FCA-regulated firms, communication requirements apply across customer interactions and channels, and firms must support customer understanding. Firms must also monitor and evidence customer outcomes in a way proportionate to their business.

A firm can improve its readiness to evidence customer communications by keeping the full communication lifecycle connected and traceable.

This means maintaining:

• controlled templates and complete version history;

• documented reasons for material changes;

• clearly identified reviewers and approvers;

• defined release and effective dates;

• customer-level rendering and sending records;

• accessible historical evidence;

• clear ownership and retention rules; and

• regular testing and monitoring of communication outcomes.

CommsPliant supports this by connecting the approved template, version history, governance and approval records, rendered communication and customer-level event in one traceable evidence chain.

This can help organisations produce clearer, more audit-ready communication evidence. However, each organisation remains responsible for its wider compliance framework, internal controls and regulatory obligations.

Before an audit or regulatory review, teams should be able to retrieve:

• current and retired communication templates;

• version and change histories;

• approval and rejection records;

• reasons for changes;

• release and effective dates;

• customer-level communication records;

• rendered copies or recorded references;

• channel, timestamp and sending status;

• delivery status where available;

• relevant testing and monitoring evidence;

• ownership, access and retention information.

These records should be organised so that the team can answer a specific question without reconstructing the history from inboxes, tickets and code repositories.

No. An audit trail helps evidence the process and events recorded by the system, but it does not by itself guarantee that the wording was legally correct, that customers understood it or that every regulatory obligation was met.

Compliance may also depend on:

• the content of the communication;

• when it was provided;

• the needs and characteristics of the intended customer;

• the approval and governance process;

• legal and compliance review;

• communication testing;

• monitoring of customer outcomes;

• action taken when problems are identified.

The FCA’s Consumer Duty focuses on outcomes rather than treating record keeping as a complete substitute for clear communications, testing and effective governance.

CommsPliant supports communication governance and evidence management. It does not replace legal advice, regulatory judgement or the organisation’s responsibility for compliance.

Yes. CommsPliant can record the template and version ID, timestamp, customer or communication reference, channel, rendered output or recorded communication evidence, sending status and, where available, delivery status for each communication event.

Template & Version → Governance & Approval → Customer & Channel → Rendered Output → Delivery Status

This creates a traceable evidence chain connecting the approved template with the communication generated for a particular customer.

The client’s existing systems or delivery providers remain responsible for sending the communication. Delivery evidence depends on the status information returned by those connected systems or providers.