Preqin~5 min read
Would ops trust AI to assign their work?
Ops staff would not accept a system that assigned their work. The routing engine shipped because they could overrule it.
- Role: Product strategy and design
- Timeline: 3 months
- Team: 1 PM, 1 engineer, me
- Impact: 75% efficiency gain
- Platform: Web
The model was not the hard part
Preqin’s data operations ran on coordination, not a system. People found, prioritized, assigned, chased, and tracked work in Excel, while 60% of the data was unhealthy at any given time.
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.
What I owned
I owned
- Product strategy and design end to end
- User research and the operations journey map
- Framing the opportunity and the constraints
- The MVP definition, and the two directions that failed before it
- Rapid testing across the iterations
Shared with the PM and engineer
- What the routing model could infer from historical patterns
- The launch timing dispute, which neither of us settled: see the note
Problem
When data operations break down, what do they cost besides time?
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.
Before
Unhealthy data
Ticket turnaround
More likely to churn
From the deck’s problem slide. The churn multiple applies to accounts affected by stale data; the population it was measured across is not recorded.
Improve the process without retraining ops?
Could we change the process without making ops learn a new one?
The options were a streamlined new interface, incremental Excel fixes, incentives for completing work, or iterating on the existing experience. Operations were mid-collection cycle throughout, so learning a new way of working competed directly with the work it was meant to speed up.
We iterated on the existing experience. That risked capping improvement at the old workflow's limits, so the routing engine sat beneath the existing surface: the process could change without making the interface unfamiliar. Data collection got faster without a training programme.
Kanban looked good. The split panel worked.
Why did kanban lose to a split panel?
We considered a kanban board, split panel, and list with detail navigation. Kanban tested well on paper for this workload, but risked slowing the workflow and was unfamiliar to non-technical operations staff.
We chose a split panel for speed and decision-making. Its density echoed what the previous tool had failed on, so the routing engine's priority score ordered the left-hand queue by what mattered. It mapped to the existing workflow. A second, priority-sorted iteration still failed: it fit the team's system but left them unable to see each other's work, which the third version fixed.
AI could assign work, but could it be overruled?
What made AI routing acceptable to ops?
The choices were fully automated assignment, AI suggestions requiring manual acceptance, or automatic assignment with logged override. Operations had zero trust in AI routing: “If the AI messes up in routing tasks, who’s accountable?” and “I won’t use it unless I can change what it assigns.”
We used automatic assignment that was always overridable, logging every override and feeding it back to the model. The log records what happened but does not answer accountability; if a wrong route goes uncaught, it only records that nobody caught it. Priority scores appeared with assignments so people could see why they received work before accepting it. The system routed automatically and was used; accountability remained unresolved, while the design conceded control.
What actually shipped
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.
What changed
Efficiency gain
Revenue
up from 10%
Renewals
up from 5%
All three from the portfolio deck. They are not the same kind of claim: 75% efficiency is an operational measure of this tool, while revenue and renewals are business outcomes on a platform this tool served from the inside. Attributing the second two to an internal operations system takes a chain of reasoning (healthier data, fewer stale records, better retention) that I have not written down and that nobody instrumented. Read the efficiency figure as the result of this work and the other two as context around it.
The durable outcome was not on the dashboard. This project got the product organization to define measurable business-success metrics at all, which had not been the practice before.
The launch happened without agreement
Operations never came around to AI routing. They accepted a system they could overrule, which is different. The override log recorded what happened, not who was accountable when a wrong route went uncaught.
Engineering called the progress bar gimmicky scope creep. It shipped because the second failed iteration had lacked visibility into work in flight, though I do not know whether Engineering changed its view. The ops manager wanted to wait a quarter; the PM had promised Q3. They piloted instead. The record does not say what the pilot found, so I cannot claim it resolved the argument. It was a way to proceed while the argument remained live.
