An AI routing engine anyone could overrule.

Preqin sells data, and 60% of it was unhealthy at any given time. Accounts touched by stale records were three times more likely to churn, and a ticket took six months to turn around. There was no system underneath any of it: people found, prioritized, assigned, chased, and tracked the work in Excel.

We built the company’s first AI-powered operations platform, a routing engine that assigns tasks and priority scores from historical patterns, individual expertise, and team bandwidth. What made it shippable was not the model. It was giving anyone the ability to overrule it, then logging and feeding back the override.

Three things stayed contested: the routing itself, the progress bar, and the launch date. Nobody was persuaded on any of them, and it shipped anyway.

A job that should have been one step took twelve: find data to update, prioritize it, create tasks, assign them, coordinate the people doing them, wait on a data check, call Sales to identify a client, wait for Sales to call that client, publish, then track it all in Excel.

Research surfaced three problems, none about the interface. Workflows and systems were disjointed. No one could see the work’s state. And nothing was tracked anywhere the team could act on it.

Eleven of those steps are coordination wrapped around one step of work. Nobody in operations was slow at their job; the job had been surrounded by handoffs, and every handoff was a place for a ticket to sit.

That is what decided where the intervention went. A faster interface makes the one step quicker and leaves the eleven alone, which is why the previous tooling had capped out. Routing attacks the coordination directly: if the right person gets the right task with a priority already attached, most of the eleven stop existing rather than getting faster.

It also explains why this had to be an AI problem at all, which is not a sentence I would write for most projects. Assigning work well requires knowing who is good at what and who has capacity right now, across a queue nobody could see the state of. That is a judgement people were making badly from a spreadsheet, not a workflow anyone could hard-code.

Automatic routing to the right person, with a priority score and an override on every assignment. A progress bar for quick visibility into work in flight. Flags for what needed attention first.

Deferred: the data-input surface. It stayed in the team’s existing system, which kept them where they were and meant some work was entered twice.

The durable outcome wasn’t on the dashboard. Before this project, the product organization did not define measurable business-success metrics for what it built. Setting them here is what made that the practice, and that outlived the routing engine.

Two smaller things carried forward. The override log means the model improves on operations’ own corrections, so the concession that got it accepted is also the thing that makes it better — the team never has to have the adoption argument twice. And putting the change in the engine rather than the surface turned out to be repeatable: the routing could be retuned repeatedly without anyone in operations noticing a new interface, which is the only version of iteration available to a team that is mid-collection-cycle all year.

Every objection I got was about control and none was about accuracy. Nobody asked how good the model was, or for a confidence figure, or to see the training data. They asked who was accountable and whether they could change what it assigned.

What I do differently since: on an AI feature I spend the design budget on the reversal path before spending it on the model’s presentation. Accuracy buys nothing until somebody is willing to let the thing run, and a system that is reversible gets adopted at an accuracy people would have refused outright if it were final. The override log is the part I would repeat everywhere — it turns the concession into a training signal, so the price of getting adopted is also what makes the model better.

What it does not do is settle accountability, and I want to be exact about that because it is the thing an override log is most often assumed to fix. A log records that nobody caught a bad route. It does not say who should have. That question was open when I left and the note below is about it.