Structuring state, ownership, and next steps to make operational complexity easier to reason about. Designing for decision-making, not data display.
Most case management systems are shaped by the backend, not by the way people actually work. That creates friction in the two moments that matter most: knowing which case needs attention, and understanding what happened once you open it. Instead of seeing a clear queue, agents are forced to hunt through records, combine generic filters, and reconstruct the story from scattered fields, notes, and messages.
That friction eventually reaches the customer. Replies slow down, context gets missed, work gets duplicated, and customers are often asked to explain the same issue again. The deeper issue is structural: the list behaves like a database table, not a queue, and the record behaves like a form, not a workspace.
I reframed the product around how support work actually happens. The system needed to answer three questions quickly and consistently:
Everything else is secondary. That meant treating cases as operational situations rather than collections of fields, making state explicit instead of scattered, and deriving actions from context instead of placing them generically. The product stops displaying data and starts supporting decisions.
The change is not in one screen. It is in the model that connects the queue, the record, and the next action.
I structured the workflow around three layers: the operational state model, the triage list, and the case record. Each layer reduces a different kind of friction.