B2B Decision System
Seven agents managing returns and order disputes across four markets. Each handling 10 to 15 active cases at any given time. Returns are not their primary responsibility. Every minute spent on a routine return case is a minute taken from something that matters more.
Three things became clear from working sessions with agents and coordinators.
Two agents handling the same type of case made completely different decisions. Neither knew what the other did. This was not incompetence. It was the absence of a shared framework.
Contractual deadlines were being missed because there was no proactive signal. The system had no concept of urgency.
When a client called about a case handled two weeks ago by a different agent, the answer was: it depends on whether that agent is available to ask. Information lived in people, not in the system.
The initial request was an interface for managing return cases. A list with forms, something cleaner than what existed. I reframed it on day one.
A cleaner form on top of a process without rules produces inconsistent decisions with better presentation. The problem was not visual. It was structural. The question was not "how should this look." It was "what are the rules, and how does the system enforce them."
The most important finding was not operational. Agents did not want another system. Their words, in different variations: "we already have too many things to look at." That resistance was not irrational. It became the constraint that shaped every design decision that followed.
Reframe the problem before designing anything
Reframe the project from "build a cleaner interface" to "define the decision rules the system will enforce" before opening any design tool.
Building a cleaner form over the existing process, which is what the team expected and what would have been faster to show.
The team had processes running. A cleaner interface would have been visible, fast to deliver, and politically easier. Two weeks without screens creates real tension with stakeholders who want to see progress.
Seven agents were making different decisions about the same type of case with no shared framework. A cleaner form does not solve that. It presents the inconsistency more neatly. I ran the decision model past coordinators in a two-hour session before drawing a single wireframe. That session surfaced two edge cases that would have become production bugs.
Return Case State Machine
Deliberate friction in the exception flow
Introduce real friction in the exception flow. Justification field required, minimum 20 characters. Agents cannot approve an out-of-standard case without documented reasoning.
Minimizing friction across all cases, as the PM requested.
The PM had a legitimate argument. Every additional field is resistance to adoption. Agents already had resistance to a new system. I had to take it seriously.
If an agent can approve an expired case in one click, the override becomes a shortcut, not a documented exception. The Override Dashboard is useless without real justifications. We accepted more friction for the 20% of exception cases to guarantee those decisions are conscious and traceable. Quick-reason chips reduce the effort without eliminating the mechanism.
| BEFORE | AFTER |
|---|---|
| Different agents making different decisions on identical cases | Shared decision framework enforced by the system |
| No concept of deadline urgency in the queue | Proactive signals. Agents see what is expiring before it expires. |
| Information living in people, not the system | Full case history accessible to any agent regardless of who handled it |
| No exception traceability | Every exception documented with justification, flagged in audit trail |
| Inconsistent return decisions across agents and markets | -22% erroneous return decisions. Consistent logic enforced by the system. |
Run structured validation sessions with agents earlier. I validated informally. With more time, I would have asked agents to walk me through live cases using the model and verified whether the states and transitions matched how they actually thought about their work. Real operational language surfaces edge cases that modeling alone does not.
Agents do not resist automation. They resist opacity. When the system showed the reasoning behind a proposal, not just the conclusion, skepticism dropped immediately. A proposal with visible validation logic is something an expert can evaluate and override. A proposal without it is something they have to accept or reject blindly. Transparency of reasoning drives trust more than accuracy of output.