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.
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. Each item still has to be opened, matched to a client and a claim, understood, recorded, and turned into the next action. At scale the people doing it are the bottleneck and the risk at the same time.
What the new module does
- Reads. Scanned post is converted to text, including poor quality scans. Emails and their attachments come in the same way.
- Links. A reference read off a scanned image is never trusted on its own. It 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. Duplicate claims are set aside by their status.
- Categorises. Each outcome category holds a library of match phrases drawn from the wording lenders really use, global or scoped to one lender or lender group. One letter can trigger several categories, and every one is recognised.
- Acts. The answers attached to each category are written onto the claim. The status updates, follow on tasks and chasers are scheduled, and the client update goes out.
- Records. Every item keeps a processing trace: what was read, what was matched, what was rejected and why, and which phrase decided the outcome.
High volumes go through that sequence fast, post and email together. The morning’s post is already linked, categorised and actioned before anyone sits down to it.
Rules, not AI
We could have pointed a language model at the whole job. We did not, and the reason is the audience. Our clients are FCA regulated firms whose processes get examined.
A model classifying correspondence 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. Rules remove both problems. 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.
The reading is the model’s job, and it is good at it. Let the model transcribe, let your rules decide.
You own every outcome
When a lender rewords its standard letters, the new wording shows up in the Uncategorised queue. An admin user adds the phrase to the right category, scopes it to that lender and reprocesses the affected items in bulk. No developer, no release, no model to retrain. Anything the rules cannot prove goes to a person rather than onto a claim, and the person who resolved it is recorded against it.
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.
For the full reasoning behind the design, read Compliant correspondence automation: why we decide on rules, not AI, or see how it works.
Frequently asked questions
It reads incoming post and email, links each item to the right client and claim, categorises it against phrases your team configures, and runs the follow-on workflow. Answers are written to the claim, the status updates, chasers are scheduled and the client is updated.
The reading step does, because scanned post is converted to text automatically. Deciding what a letter means is done on rules your team controls, so every outcome is deterministic and auditable.
It goes to a queue for a person rather than onto a claim. Once resolved, the item runs through the same workflow as an automatic match, and the person who resolved it is recorded against it.
An admin user adds the phrase to the right category, scopes it to that lender and reprocesses the affected items in bulk. No developer, no release, no model to retrain.
