A team picks an AI tool. They hook it up to their data. It works in the demo, classifies tickets correctly, generates summaries, catches the anomalies they were looking for. They ship it.
Three months later, it's either turned off or running in a corner that nobody trusts.
The technology worked. The implementation didn't.
If your support team processes 100–300 emails a day, you've probably had the conversation: “We need to hire someone, or find a better way.” Most teams that go looking for AI find a tool. What actually matters happens before the tool.
The diagnosis everyone gets wrong
The default explanation is adoption. “People didn't buy in.” “The team wasn't ready.” “Change management failed.”
That's not usually wrong, but it's downstream of something else.
When I map what actually happened in these projects, the failure almost always traces back to one moment: when someone decided what to automate before they understood how the process actually ran.
Not how the process was supposed to run. How it actually ran.
Those are different. Sometimes dramatically.
What “how it actually runs” means
A support team I worked with processed about 200 tickets a day. The stated process was: read ticket → classify → respond or escalate.
The actual process: read ticket → check if it's from a known complainer → check if the order was placed in the last 7 days → check if the issue is also appearing in the Discord community (which meant it was systemic) → then classify.
Four invisible decision points that didn't exist in any documentation. The team had developed them organically over 18 months because the documented process didn't work for their specific customer base.
An AI system trained on the stated process would have auto-responded to half the systemic issues as individual complaints, at scale, with consistency.
The AI would have made the problem faster, not solved it.
The architecture problem
Enterprise architecture is the discipline of understanding how systems connect: how information flows, where decisions actually get made, what the dependencies are between processes that appear separate.
Applied to AI implementation, it means answering a specific set of questions before touching any tooling:
- What are the actual inputs to this process, in the order they're evaluated?
- Where do humans add judgment that isn't documented?
- What are the failure modes of the current process, and which ones does AI need to handle better vs. avoid entirely?
- What does the process touch downstream, and what breaks if it behaves differently?
This isn't a discovery phase that you run once and file. It's the architecture of the automation. Get it wrong, and the AI is optimising the wrong thing, sometimes in ways that are hard to notice until the damage compounds.
What this looks like in practice
The support triage system I built for a D2C clothing brand resolved 61% of tickets automatically. The number that mattered to me wasn't the 61%. It was the taxonomy.
Before writing a single line of automation, I built a complete map of every ticket type they received over six months: what the ticket said, what context the team needed to respond, what the response actually was, and where the edge cases were.
That map had 12 categories. The team had been informally using 4.
The 8 additional categories (small volume, high stakes, inconsistently handled) were where the human judgment lived. Half of the failures in their existing process were in those 8 categories. The AI needed to handle the 4 standard categories well and route the 8 nuanced ones to humans with context already attached.
94%+ classification accuracy came from mapping the problem space first. That sequencing (operations architecture before automation design) is what makes AI implementations stick.
The failure mode you can prevent
Most teams approach AI implementation like a software project: define requirements, pick tools, build, ship, iterate.
The missing step is before the requirements: understand the operational reality of what you're trying to automate. That reality is never fully documented. It lives in the team's working knowledge, in the exceptions that got silently handled, in the informal rules that developed because the formal ones didn't cover enough.
The AI needs to encode that knowledge, not the documented version of it.
That's the architecture layer most AI projects skip. And it's usually the reason they don't stick.