A lender letter is easy to read and hard to process. One arrives as a scanned image with a reference the scanner half recognises, a paragraph that means the claim can proceed, and a deadline that starts running the moment it lands. LogiClaim now handles all of that end to end. What it does not do is let a model decide what the letter means.
In brief
- Process high volumes fast. Post and email together, linked, categorised and actioned.
- More compliant. Deterministic decisions, fully auditable: the same letter always gets the same answer.
- Complete audit trail. Every decision traced to the phrase, the evidence and the rule that produced it.
- You own every outcome. New lender wording is handled in minutes and reprocessed in bulk, with no model to retrain.
The inbound half of a claims operation
Outbound work is the part everyone automates first, and it is the easier half. You control the template, the trigger and the timing. Inbound is where high volume operations actually struggle, because you control none of those things. The post bag turns up as a pile of scans. The lender inbox fills with thousands of emails written to no standard you had any say in.
Each item still has to be opened, matched to a client and a claim, understood, recorded, and turned into the next action. That is four separate decisions per item, and at scale the people doing it are the bottleneck and the risk at the same time. The failures are familiar to anyone who has run one of these operations: an acknowledgement filed against the wrong claim, a final response nobody actioned until the complaint window had closed, a client chasing an update that has been sitting in a shared mailbox for a fortnight.
What we built
The new module in LogiClaim takes an item of incoming correspondence and carries it all the way through.
Reading. Scanned post is converted to text, including the poor quality scans that defeat older recognition. Emails and their attachments come in the same way. Once an item is text it can be searched, matched and acted on in bulk.
Linking. The system scans the text for claim references, client identifiers and agreement numbers. Here is the rule that matters: a reference read off a scanned image is never trusted on its own. Character recognition produces errors that look exactly like valid data, and a mis-linked item is worse than an unprocessed one. So a reference has to be corroborated by a second piece of evidence, a matching client name, date of birth, address or agreement number, before anything is linked. A client identity can corroborate a claim match but can never carry one on its own. Exact identifiers in digital text are treated differently: an agreement number typed in an email subject line is trusted on its own, provided nothing contradicts it. And when an agreement number matches more than one claim, any claim on a status that marks it as a duplicate is set aside, so the item lands on the live claim. Fail those tests and the item goes to a queue for a person rather than onto a claim.
Categorising. Each outcome category holds a library of match phrases drawn from the wording lenders really use. A phrase can be global or scoped to one lender or lender group, which matters because the same sentence can carry different weight depending on who sent it. Categories can carry a second level where an outcome needs finer grain. Your compliance team owns that library and edits it in an admin screen.
Finding everything, not just the first thing. Lender letters sometimes include several outcomes. A single response can acknowledge the complaint, confirm that the commission was discretionary, and need a copy sending to your client. The system does not stop at the first match. It recognises every category whose phrases appear in the document, and each one can set the questionnaire answers it implies. A letter recognised as Lender – Acknowledgement with the second level outcome DCA writes Commission Type: DCA and Acknowledgements: DCA ACKNOWLEDGED onto the claim, while a second category on the same letter sends the client their copy.
Acting. Categorisation is not the finish line, it is the trigger. Once an item is categorised the claim moves by itself, and the workflow engine acts on every finding in the document, not just one. The answers attached to each category are written onto the claim file. The status updates. The item is recorded in the claim history under its category. The follow on tasks and chasers are scheduled. The client update goes out. One letter can drive the entire next stage of a claim without anyone opening it, which is where the hours actually come back.
Processing high volumes fast. Incoming documents go through that sequence at volume, post and email together. The point is not the speed for its own sake. It is that the morning’s post is already linked, categorised and actioned before anyone sits down to it, so the queue a person works is the small set the system would not commit to rather than the whole bag.
A complete audit trail. Every item keeps a processing trace: what was read, what was found, what was rejected and the reason, which phrase triggered which category, what was scheduled, and the final outcome. It records the checks as well as the result: that a client reference could not link the item on its own, that a duplicate claim was set aside, and which phrase decided the outcome. You can open any item months later and read the decision back.
More compliant: deterministic decisions, fully auditable
We could have pointed a language model at the whole job. It would have worked, most of the time, and the demo would have been shorter. We did not, and the reason is the audience. Our clients are FCA regulated firms whose processes get examined.
A model classifying correspondence on its own gives you three problems that do not show up until you are under scrutiny. It is probabilistic, so the same letter can land differently on different days. It cannot tell you why it decided what it decided, only how confident it was. And when it is retrained or updated you cannot say precisely what else just changed.
Rules remove all three. Every match and every outcome is deterministic: the same letter produces the same result today, next month and in a file review. And every decision is auditable, down to the item. Ask why a claim was recorded as DCA acknowledged and the answer is specific: the lender’s letter contained this phrase, configured against Lender – Acknowledgement and its DCA outcome for that lender, and the letter was linked on the client reference, corroborated by the client’s identity. When you want different behaviour you add or amend a phrase, and nothing else moves.
Put side by side, the difference shows at every point where a model would have to guess:
| At this step | LogiClaim checks | A model guesses |
|---|---|---|
| Finding the claim | A second piece of evidence, or a person decides | A best guess from the text |
| Duplicate claims | Set aside by their status | Could pick either one |
| What the letter means | Your exact phrase, for that lender | A probable category |
That is the difference between automation you can operate and automation you can defend. Under Consumer Duty and in any file review, “the system decided” has to be followed by “and here is exactly why”, and a confidence score is not a reason. The side by side comparison is on our rules, not AI page.
Automation does not get to hide behind the software either. Work the system does is logged as the system’s. Work a person does by hand, linking an item or overriding a category, records that person against the claim. When someone asks who made a decision, the file answers.
The part that is genuinely automated
The reading is the model’s job, and it is good at it. Turning a smudged scan of a lender letter into accurate text is exactly the kind of work machine reading has become very good at, and it is also the kind of work where a mistake is caught by the next step rather than buried in it. That is the design: let the model transcribe, let your rules decide, and make the rules prove themselves against corroborating evidence before anything touches a claim.
You own every outcome
Rules mean the outcomes belong to you. No model update or supplier retrain changes how your correspondence is handled. Your admin users decide, and the screens are built to make deciding quick.
Lenders reword their standard letters and new outcomes appear as a claim type matures. With a model you would find out from a misfiled claim. Here it shows up in the Unlinked and Uncategorised queues as a cluster of similar letters, which is a pattern your team can see. They add the new phrase to the right category, scope it to that lender, set the answers it should write, and reprocess the affected items in bulk. Those items are then linked, categorised and actioned exactly as if the rule had been in place when they arrived. A change in wording on a Tuesday morning can be handled by the afternoon, and every reprocessed item carries its own trace. More on how that works on our page about owning every outcome.
When nothing matches
Some items will always need a person: a handwritten note, a letter with no usable reference, wording nobody has seen before. The system does not guess at these. It routes them to the right queue, Unlinked if the evidence did not corroborate a claim, Uncategorised if no category matched, and handling them takes seconds. The document sits beside the queue; link it to the client and claim, choose the category, or assign it to a colleague. From there the item runs through the same workflow as an automatic match, and the person who resolved it is recorded against it.
And a manual fix is rarely a one-off. If the same wording keeps turning up, it becomes a phrase, and the rest of the queue is reprocessed in one go. The steps are laid out on our unmatched correspondence page.
Want to handle more post with less admin?
A free demo walks through the queues, the configuration screen and a processing trace, and shows how every outcome is decided and evidenced. The overview is on our compliant correspondence automation page.
Frequently asked questions
Automated text recognition converts each scanned page into text, including low quality scans. That reading step is the only part of the process a model is trusted with, and nothing is filed on the strength of it alone.
It goes to the Unlinked queue for a person to handle. The system does not guess a claim from partial evidence. Anything a person links by hand records who linked it.
Your own team, in an admin screen. Phrases can apply to every lender or be scoped to a single lender or lender group, and adding one needs no developer, no release and no downtime.
It writes the answers that category sets onto the claim, updates the status, records the item in the claim history, schedules the follow on tasks and chasers, and issues the client update.
Yes. The system recognises every category whose phrases appear in the document, extracts the references it needs, and the workflow engine acts on all of them, for example recording a DCA acknowledgement on the claim and sending the client a copy from the same letter.
The new wording shows up in the Uncategorised queue. An admin user adds the phrase to the right category and lender scope, then reprocesses the affected items in bulk.
Yes. Every item carries its own processing trace listing what was read, what was matched, what was rejected and why, the phrase that triggered the category, and what was scheduled as a result.
