A fluent claim letter can conceal a weak connection between the file, the applicable terms and the conclusion being communicated. That is why I resist describing automated drafting as a small administrative step whose risks can be handled after the main technology decision. The communication may carry an important judgement to a policyholder. Preparing its words and authorising that judgement are different responsibilities, even when the same screen brings them close together. An insurer needs to decide explicitly who holds each responsibility.
I approach this as a CIO, not as the person empowered to settle every claim. My team can make relevant material easier to find and can show the basis of a proposed draft. Claims and legal colleagues must determine the authority required for the communication and the review appropriate to its consequences. If we leave that boundary implicit, the product's convenience can become the institution's operating policy without anybody making a conscious decision to adopt it.
Separate the proposed words from the decision behind them
Consider the questions hidden inside an apparently routine letter. Which policy applies to the loss? Which endorsement was effective at the relevant time? What facts have been established, what remains disputed and what conclusion is the author entitled to communicate? A system might reproduce a familiar style while selecting the wrong supporting reference. The resulting paragraph can look more confident than the evidence warrants. Improving its grammar does not repair that underlying connection.
Our first correspondence test at Caldermere used 1,800 closed property claim files. Reviewers found 216 drafts with an outdated endorsement and 144 with a reference from the wrong jurisdiction. The remaining 1,440 had the correct supporting references under that classification. I would not call all of those letters correct in every other respect. The classification addressed one part of the problem. It showed that the original ambition to minimise intervention was ahead of the evidence available to support it.
The useful management response was to narrow the tool's authority. We retained drafting assistance but withheld autonomous dispatch from the approved release. That decision preserved a review cost and reduced the headline benefit. It also gave us a product whose responsibility could be described honestly. A colleague could use the proposed text as working material, inspect its sources and decide whether to change or reject it. The insurer remained answerable for the communication it actually sent.
This distinction should be visible in the product specification. A draft needs a status that cannot be mistaken for an authorised letter. Supporting references need to be accessible at the point of review. A substantive change needs to remain intelligible when the file is revisited. Those design choices require cooperation with the people who understand the claim, rather than a generic approval step added when the engineering work is nearly finished. The consequence determines the review; the interface should support it.
Design a review that permits disagreement
Putting a person in the process does not establish that the person has time, information or practical permission to disagree. A colleague faced with a long queue and a polished answer may accept it quickly, particularly if the new operating measure rewards throughput alone. I want the pilot to examine this pressure. How long does a meaningful review take? What material must the reviewer open? What happens to the colleague's workload when the proposed answer is unsuitable?
We recorded reasons for substantial rewrites during our later supervised pilot. Eighty-three of nine hundred letters were rewritten before release. That count would have disappeared if the report had treated every final approved communication as a successful untouched draft. I do not regard a rewrite as evidence that the reviewer has obstructed the technology. It may be the evidence that the review is doing useful work. The content and consequence of the change matter more than whether the programme can make the percentage smaller.
A disagreement also needs somewhere to go. A reviewer should not have to choose between sending an unsuitable letter and abandoning the task without explanation. The route might involve a claims supervisor, a specialist on the relevant product or legal advice, depending on the issue. Technology should preserve the question and its eventual resolution. It should not assign professional authority merely because somebody has permission to edit a text box or click a release control.
I ask programme sponsors to include less convenient files in the review. A tool evaluated only on familiar, complete material may look dependable while remaining poorly understood around unusual endorsements or disputed evidence. That does not require the first release to handle every situation. It requires the approved scope to describe what has actually been examined, with a workable route for the rest. Exclusions are part of a responsible product definition when they are explicit and operationally usable.
Make the narrower result worth reporting
The later pilot reduced median preparation time from twenty-two minutes to fourteen for the observed cohort. That was a useful result. It excluded later investigation and the eventual claim decision, and it retained human approval for every letter. Reporting those boundaries does not undermine the improvement. It tells operations where the time was released and tells the board what has, and has not, changed in the insurer's responsibility to the policyholder.
I would pair that timing evidence with examples of the work reviewers still performed. A board does not need a demonstration of every screen, but it should understand why the control remains and what could cause the scope to change. If the case for removing a review step later becomes stronger, the proposal should identify the additional evidence, the consequences considered and the owner accepting the change. A successful limited pilot is not automatic authority for a materially different operating model.
There is also a people decision. Colleagues may be asked to move from composing material to assessing it, a change that requires practice and an understanding of common failure modes. Training should use examples where the proposed text is plausible but wrong, not only examples that confirm the tool's value. Supervisors need a way to recognise careful challenge. Otherwise the institution can retain a formal approval step while gradually removing the conditions that make it meaningful.
The leadership choice is to value a defensible, bounded improvement over an unsupported claim of autonomy. I want insurance technology to make an authorised person better informed and less burdened by avoidable preparation. I do not want its fluency to obscure who decided, which material they considered or how a policyholder can question the result. Keeping those responsibilities visible is a practical design requirement, and it belongs in the investment conversation from the beginning.