Turning service-failure refunds into recovered cash.
Carriers owe us service-failure refunds for late, lost, and damaged shipments. The catch: at human-review pace, most of them just quietly go unclaimed. I designed the operating model, the eligibility scanner, and the working dashboard that flip those missed refunds into actual recovered dollars.
Service-failure refunds (late deliveries, lost packages, damaged shipments) are real money just sitting on the carrier's books. Filing for them is high-volume, low-dollar, deadline-bound work. Done by hand, the cost per claim eats the refund. Done as a system, the same line item shows up in the P&L as recovered margin instead.
The operating model behind the recovery program: eligibility scanning, auto-filing through Zendesk macros, win-rate tracking, denial-reason analysis, and the working dashboard that lets one operator answer "what's our MTD recovery?" in two clicks. This sits inside the broader $5M+ revenue leakage work.
Try the dashboard
I built a fully interactive React demo of the recovery dashboard. Seven views, mock-but-realistic shipment and claim data, the same flow an operator works through every morning.
Demo runs in the browser · synthetic shipment and claim data · mirrors the production tool's flow and KPI structure.
The operating model underneath
Five threads of work, designed to run as a system. They're what makes the dashboard an actual P&L tool instead of a reporting toy.
Eligibility scanning
A scheduled job reads shipment data, applies carrier-specific eligibility rules (late thresholds, scan windows, exception codes), and queues newly eligible claims into the dashboard inbox. This scanner is honestly the whole difference between "we should be filing claims" and "claims actually get filed."
Auto-file through Zendesk macros
Once a claim clears eligibility and operator review, a Zendesk macro generates the carrier-specific submission with the right fields and attachments. The macro is where the per-carrier claim formats get standardized. That part used to live entirely in someone's head.
Win-rate & denial-reason analytics
Every approved or denied claim feeds back into the dashboard's analytics layer. Denial-reason analysis (weather, address, outside window, insufficient evidence) tells the team where eligibility rules need tightening, and where to push back on carrier pattern denials.
Recovery trend & carrier mix
Monthly recovery trend by carrier. This is the metric that makes the work visible to Finance. UPS, USPS, and FedEx are broken out so carrier-specific service issues surface fast. It's the view a CFO can read in 60 seconds before deciding whether it's time to escalate with a carrier rep.
Operator workflow design
Seven views (Dashboard, Inbox, Filed, Bot Activity, Analytics, Top Recoveries, Settings), all sized for one operator running the recovery program inside a normal workday. The flow is what turns the dashboard from something you look at into something you actually work in.
Why this matters at the P&L level
Service-failure refunds are honestly the textbook case for using AI to assist ops work: it's high volume, deadline-bound, the rules are clear, and it has a pretty direct line to recovered margin. Without a system, the refund just sits on the carrier's books and ages out. With one, every late delivery becomes a small recovery event you can actually budget against.
This isn't the most ambitious thing I've built, but it's probably the easiest to explain. It's the kind of work a BizOps team can copy and stand up across other variance categories without me in the room. Which makes it a pretty good first proof point for any team trying to figure out whether to invest in a broader carrier ops function.