Why is this claim stuck?
Sherlock takes a single claim ID and tells a claims-ops person, in plain language, why it’s stuck, whether it will clear on its own, and the one thing to do — and who owns it.
The problem
A claim sits. Is it genuinely stuck, or just moving normally? Whose court is it in — the member, the insurer, the hospital, ops, engineering? Answering it today means digging by hand across the claim record, the system logs, and the support tickets, and knowing how to read each.
What changes
Sherlock does that dig in seconds and hands back a decision, not a data dump: a plain-English “why,” a clear disposition (self-resolving, needs action, or closed), and the single next move with an owner. No error codes, no system names, no member identity — just what to do.
How a verdict is made
A claim ID — in the app or “@Sherlock CL3845” in Slack
Records, Logs & Support each read their own source in parallel
Each detective revisits its read against the others’
Weighs the evidence + facts into one plain-English call
The one action, and who owns it — a person decides & moves
◇ human decision
Sherlock investigates and recommends. A person always makes the call and acts — the last step is human by design.
A team of detectives, not one black box
Three specialists each read a different source and report findings — never a verdict. A Chief Inspector weighs their findings against deterministic facts (turnaround, SLA, whose court) and reaches the call. Every verdict is auditable: you can see exactly which detective said what, and which known patterns fired.
Records
The paper trail
Reads the claim’s own record, full comment trail, ops notes and milestone timeline — the richest signal for why a claim actually sits where it does.
Logs
The system trail
Reads what the pipeline actually did or failed at (New Relic) — a real fault vs. routine noise — and how widely a fault is hitting other claims right now.
Support
The human trail
Reads the claim’s Zendesk tickets, including the internal RCA — often the most authoritative word on whether it’s a genuine bug, whose court it’s in, and what fixes it.
It learns, safely
When a real case teaches Sherlock a lesson, it becomes a seeded pattern — a durable, human-confirmed memory it applies to future claims. Every pattern is reviewed and traceable; nothing becomes “truth” automatically.
Measured, not asserted
Sherlock is graded by its own evaluation loop against curated ground truth — each claim run and judged on the right party, the right disposition, and whether the reasoning captures the real cause. It went from the low-60s to 92% across four improvement cycles, and held on fresh claims it had never seen — improvement, not overfitting.
Open the live scorecard →Where you use it
In the app
Type a claim ID and get the full case — the verdict, the detectives’ notes, and the patterns it recognized.
In Slack
“@Sherlock CL3845” in your ops channel → a scannable verdict in seconds, with a deep link to the full case.
On the scorecard
See exactly how accurate Sherlock is, per cycle and per claim — transparency you can put in front of anyone.
Built for confidential data
Sherlock reads real Plum claims data through the sanctioned, masked, audited data desk — names, phones and emails are stripped before anything reaches it, and its verdicts carry no member identity. Access is limited to Plum (@plumhq.com) accounts, and every integration is read-only. It surfaces judgment; it never moves money or data.
See it on a real claim
Give Sherlock a claim ID and watch it work.
Investigate a claim →