A customer quotes the old wording back to you
A customer makes a claim and quotes a clause from their policy document. The clause was changed three months ago when your capacity provider approved a new wording. Their policy started after the change, but the document they received was generated from the old template, because the template folder had two versions and the system pointed at the wrong one.
Elsewhere, a policy schedule shows the wrong excess because a field mapping broke when the policy system was updated. A certificate for a business customer is missing an endorsement. Each is found by a customer, a broker or a claims handler, not before sending.
Why document errors keep happening
Documents are often the last thing set up before launch and the least controlled afterwards.
- Templates are Word files edited by hand and stored in shared folders.
- There is no link between a policy's start date and the wording version that applies.
- Endorsements are added manually for special cases.
- Field mappings from policy data to the template break silently when data changes.
- Nobody checks a generated document before it is sent.
Which wording applies to which policy is set by your agreements and approved with your capacity provider. We make sure the approved version is the one used.
Why this matters more than it looks
Policy documents are what the customer relies on, and what claims are assessed against. A document with the wrong wording or details creates disputes, complaints and awkward conversations with your capacity provider. Fixing errors means reissuing documents to every affected customer, which first means finding them. Support spends time correcting documents instead of helping customers.
A controlled document service
What we build treats documents as versioned outputs of your policy data.
- Templates for schedules, certificates, statements of fact and letters are held in a document service, each with a version.
- Policy wordings and endorsements are stored as approved versions with effective dates and the approver's name.
- When a document is generated, the service picks the template and wording versions from the policy's product and dates, not from a folder.
- Every field is filled from policy data through a defined mapping, and generation stops if a required field is missing.
- Endorsements are selected by rules from policy data, with a manual endorsement option that requires a reason.
- A sample of generated documents, or every document for new versions, can be held for review before sending.
- Each issued document is stored with the versions used, so you can find every policy issued with a given wording.
| Document | Driven by | Check before issue |
|---|---|---|
| Policy schedule | Policy data and template version | Required fields present, values match policy |
| Policy wording | Product and effective date | Approved version for the policy's dates |
| Certificate | Policy data, cover type | Endorsements match rules |
| Statement of fact | Customer answers | All answers present |
| Mid-term endorsement | Change data | Premium and dates match the adjustment |
When a wording changes next time
Wording changes often arrive at short notice, after your capacity provider signs off a new version. With the service in place, the switch is a data change with a date rather than a scramble to replace files in folders and remember which products use them.
The new wording is uploaded with its effective date and approval. Policies starting from that date get it automatically. Renewals pick it up at their renewal date. If you ever need to know who has which wording, you run a search rather than an investigation. Broken field mappings stop generation and raise an alert rather than sending a wrong schedule.
Is this happening to your documents?
- Templates live in shared folders as Word files.
- Customers or brokers find errors in schedules.
- You cannot list policies issued with a particular wording.
- Endorsements are added by hand.
- Nobody checks documents before they are sent.