Automation
The rules are yours to write, and yours to change.
The biggest complaint about the incumbent in this market is that changing anything requires a specialist. In ClaimCore an administrator writes an automation rule in a screen, in a few minutes, and changes it the same way when the process changes.
Included in Core, for every customer, at every tier. There is nothing to buy under this name.
Why it exists
Every claims operation has rules it applies by hand. When the engineer’s report arrives, move the claim on and tell the handler. If the third-party insurer has not responded in ten days, chase. When the authority comes back signed, start the next thing.
Applied by people, those rules are applied unevenly — reliably on a quiet Tuesday, less so in a busy week, and not at all while somebody is on leave. Applied by most software, they are applied consistently and can only be changed by the vendor.
Neither is what a firm actually wants. They want the rules applied every time and changed by them.
What it does
Seventeen things to trigger on
- The claim
- Verified from intake. Liability decided.
- The vehicle
- Hire started or ended. Storage started or ended. Engineer instructed. Report received. Valuation confirmed.
- The paperwork
- A signature completed. The vehicle damage authority signed and returned.
- The money
- Payment pack assembled and sent. Payment received. Payment sent to the client. Settlement recorded.
Four things a rule can do
- Move the stage
- Forward only. If somebody deliberately moved a claim back, automation will not drag it forward again behind them — a rule cannot overrule a person.
- Raise a task
- For a named person or a team, with a due date from your SLA.
- Assign a team
- Route the claim to whoever should own it next.
- Add a note
- Onto the claim's timeline, so the record explains itself.
And when
- Now, or in seven days
- Every action carries an optional delay. Which is what makes “chase the engineer if there is still no report in a week” a rule rather than a diary entry.
- Conditions
- Evaluated against the claim at the moment the trigger fires, so a rule can apply to total losses and not repairs, or to one branch and not another.
- In a defined order
- Which matters when one rule advances a stage that another rule's condition tests.
And you can see what it did
- A run log
- Every firing recorded — including the ones that were skipped, and why. So “why didn't my rule run” has an answer rather than a theory.
- Checked when you save it
- Not when it fires. A rule that throws at three in the morning is a rule nobody knew was broken.
What changes
The process runs the same on a busy week
Because it is not being remembered by a person who has forty other things on.
Changing it does not need us
No consultant, no release, no invoice. Which is a direct answer to how the market leader works.
Nothing sits silently
A delayed rule is a chase that happens whether or not anybody diarised it.
What it does not do
Rules act inside ClaimCore. They move stages, raise tasks, assign teams and write notes — they do not send emails to third parties, move money, or change figures on a claim. Anything with a consequence outside the system stays a decision a person makes.
There is no scripting language and no code. That is deliberate: the people who should be changing these rules are the people who know the process, and a rule builder that requires a developer has recreated the problem it was meant to solve.
Related
See it against one of your real claims.
Thirty minutes, no slides. Bring a live file and we will run it through the system end to end.