Claims intake: 95% straight-through target
A health insurer processes 4,200 paper and fax claims per day across six intake specialists. A Pega Robotics unattended solution has run for nine months and achieves 70% straight-through processing. The remaining 30% breaks down as 18% missing or invalid policy number, 7% multi-claim faxes that need splitting, and 5% attachments below the OCR confidence threshold of 0.85. Every exception must be reviewed by a licensed adjuster under compliance policy. The downstream policy administration system is a 3270 green screen with no API. The operations sponsor wants 95% straight-through processing within 90 days and plans to redeploy four of the six specialists. The bot currently writes exceptions to a shared inbox without a structured reason code, so specialists re-key data and sometimes re-open claims that the bot already submitted. Average claim cycle time is 1.6 business days against a 2-day SLA, but month-end spikes push it to 2.8 days.
1. What analysis should you complete before agreeing to the 95% target, and what is your initial recommendation?
Read the worked answer
Start by converting the target into volumes. 95% of 4,200 is 3,990 claims per day; the current 70% is 2,940, so the gap is 1,050 claims per day. Then decompose the 30% exception pool. Missing or invalid policy number is 756 claims per day, multi-claim faxes 294, and low-confidence OCR 210. A bot cannot invent a valid policy number, and splitting multi-claim faxes or rescanning poor images may be automatable but will not reach 95% alone. Even perfect handling of the 504 multi-claim and OCR exceptions would lift straight-through processing to about 82%. The sponsor's target therefore depends on upstream data capture, not robot effort. I would ask: what percentage of missing policy numbers are available from another system, what is the rework rate after bot submission, and what compliance requires for adjuster review? I would not accept 95% in 90 days as an automation-only commitment. I would propose a phased target, for example 82% in 90 days with upstream validation and a structured exception taxonomy, then reassess 95% after data quality improves. I would also challenge redeploying four of six specialists while 1,260 exceptions per day still require licensed review.
2. Design the decision logic for the three exception categories. Which should the bot attempt to resolve, which should route, and what data must accompany the route?
Read the worked answer
Treat each category with a different rule. Missing or invalid policy number: the bot should not submit the claim or retry blindly. It should extract all available identifiers, search permitted alternate sources if the business approves, and route to intake with a reason code, extracted fields, and a link to the source image. Multi-claim fax: the bot can attempt separator detection and page classification. If confidence is high and the business rule allows, create separate claim records and submit; otherwise route the whole fax with a page map. OCR below 0.85: requeue for rescan only if the source image can be improved; after one failed rescan, route to a human with the confidence score and image. Build a decision table with explicit thresholds, maximum attempts, and audit fields. The key reasoning is that automation should resolve only what it can do with evidence; routing is a valid outcome, not a failure. Every route must carry enough context so the adjuster does not re-key, and the bot must record the reason code so the exception taxonomy can be measured.
3. How would you measure success so the sponsor does not optimize automation rate at the expense of compliance and SLA?
Read the worked answer
Do not let the sponsor manage only straight-through processing. A balanced scorecard should include STP by exception category, exception aging, rework rate, adjuster touches per claim, compliance audit pass rate, cycle time at the 95th percentile, SLA attainment, and cost per claim. If STP rises because the bot is submitting low-confidence claims, the rework and compliance metrics will expose it. I would baseline current performance, set guardrails, and review weekly with operations and compliance. Redeployment of specialists should be tied to a sustained reduction in adjuster touches, not to a single STP number. Also track month-end performance separately because the 2.8-day spike is the real SLA risk. Use control charts rather than averages so a temporary gain is not mistaken for a stable process. Finally, document the causal link between upstream validation changes and STP so the sponsor sees where the gain came from.