Case study
An AI platform integration, redirected three times.
A vendor AI platform going into enterprise service management, where the integration everyone assumed was correct would have made the queue worse.
The situation
A vendor AI and AIOps platform was being integrated into an enterprise service management system already carrying a large live ticket volume. The integration had been specified before anyone examined how the two systems actually classified work.
They did not agree. The AI platform reasoned in terms of severity — how bad the technical fault is. The service management side ran on urgency — how quickly a human needs it resolved. Mapping one directly onto the other is the obvious integration, and it is wrong: a low-severity fault on a system a hundred people are waiting for is not a low-urgency ticket.
I can't name the client. The method is the transferable part, and the mapping problem is not specific to either vendor.
What happened
Three redirects, each one only visible once the previous had been made.
Severity to urgency. Rather than mapping the fields directly, the integration translated between the two models explicitly, so a ticket arriving from the AI platform landed in the queue at the priority a human would have given it.
Full rollout to phased. The plan was a single cutover across the estate. On a live queue that is a bet with no way back. It became a phased rollout, so a wrong assumption cost one phase rather than the whole programme.
Single route to multi-route. One integration path assumed every alert deserved the same handling. Different classes of event needed different routes into the queue, and building one pipe would have meant rebuilding it later.
The result
The platform went in without degrading the queue it was meant to improve, which is the outcome that does not make a headline and is the entire point. Each redirect cost a conversation early and saved a rebuild later.
Most AI integrations fail at the seam rather than at the model. Two systems that both work can still be wrong about each other, and the mismatch is usually in the vocabulary — a word that means one thing on each side of the join.
The question worth asking before any AI platform goes into an existing system: what does this thing think it is measuring, and does that match what the receiving system thinks it is measuring?
Each redirect was only visible after the previous one had been made, which is an uncomfortable way to run a programme. You cannot present three course corrections at the start; you present one, make it, and the next becomes obvious.
The severity-to-urgency problem was the hardest to raise because both systems were working correctly. Neither vendor had made a mistake. The mismatch lived in the join, which is nobody's component and therefore nobody's defect.
Arguing for a phased rollout on a live queue also meant arguing against a plan that looked faster on paper. Phasing always looks slower until the first phase surfaces something you would otherwise have shipped across the whole estate.
Common questions
Why does severity not map to urgency?
Severity is how bad the technical fault is. Urgency is how quickly a human needs it resolved. A low-severity fault on a system a hundred people are waiting for is not a low-urgency ticket, so mapping the fields directly puts work in the queue at the wrong priority.
Why phase an AI platform rollout instead of cutting over?
Because a single cutover on a live ticket queue is a bet with no way back. Phasing means a wrong assumption costs one phase rather than the whole programme.
Where do AI integrations usually fail?
At the seam rather than the model. Two systems that both work can still be wrong about each other, and the mismatch is usually vocabulary — a word that means one thing on each side of the join.
Your turn
Bring me the list nobody's willing to question.
Twenty minutes, no pitch. If I'm not the right person, I'll say so and point you somewhere better.