Time per claim
A customer-service back-office that treats every claim as a workflow.
Tefal's diamond-tier service program had been operated out of a constellation of spreadsheets and email threads, which scaled fine until volume crossed a threshold and then stopped scaling at all.

Context, constraint, and the part that mattered.
The brief was to build a single back-office surface — a place where an agent could take a claim, attach the right documentation, route it to the warehouse, and close it — without inventing a new CRM. We designed the surface around the claim itself, not the agent or the customer, on the basis that the claim is the only entity that moves through every team. Every team ended up with a view that was a projection of the same underlying record, which removed the entire category of state-mismatch bugs that the spreadsheet workflow had been generating.
What we did, in the order we did it.
- 01
The claim is the entity
Every screen, every report, and every notification is a projection of a single claim record. Agents, the warehouse, and management see different views of the same row, never copies. State-mismatch bugs disappear by construction.
- 02
A workflow, not a form
Each claim moves through an explicit state machine. The UI shows the agent only the fields that the current state requires, which collapses the previous all-or-nothing form into a sequence of small, defensible decisions.
A small spread from the engagement.


The numbers we agreed to ship against.
of customer state
Manual handoffs
Have a project that looks like this?
Send a short brief — we'll reply with concrete next steps. New engagements are limited each quarter.
