The challenge
The group had been assembled through acquisition, and each company arrived with its own systems, support model, and engineering structure: a sixteen-person in-house team in the UK, a three-person founder-led team in Australia, and outsourced development in the US. Leadership across all three was enthusiastic about AI. The growth equity sponsor wanted a clear answer to a harder question: where AI could expand the group's capability within 90 days, and where it should be kept out entirely.
Our approach
We ran a structured interview program over six weeks. It began with the group CEO, moved through functional leaders at each company, and finished with individual contributors those leaders flagged as doing interesting work. Every session was scored against a five-dimension rubric: Process Maturity, Data & Systems Readiness, Current AI Adoption, Team Change Appetite, and Opportunity Density. Scores describe the state of a workflow and the systems around it, so the assessment rates the work rather than the people doing it.
Interviews with leaders report intent accurately and team behavior less reliably. To close that gap, we fielded an anonymous survey to the in-house engineering teams and reached near-complete coverage (n=17).
What we found
Engineering adoption was far earlier than it appeared.
The survey showed that 41% of developers had no AI tool license, 88% had no codebase-specific configuration, and PR review was entirely human. Confidence in AI output scored an NPS of −56. The cause was clear once the workflows surfaced: most developers were pasting code into a chat window that couldn't see their codebase, then judging the output accordingly. The developers were asking to be enabled. One wrote:
“It would also be useful to know which tools we are allowed to use.”
Support knowledge was scattered and at risk.
We inventoried at least six parallel support endpoints across the three companies, three of them individual people's personal inboxes. None had ticketing, response-time tracking, or satisfaction measurement. Every resolution lived in one person's sent folder, which created key-person risk and hid the company's best source of product feedback.
Operators were spending their best hours assembling context.
Senior people across all three companies were manually pulling information from email, calls, documents, and calendars before they could do the work that needed their judgment. As one put it:
“Everyone has big ideas, everyone wants to be doing more, and everyone is already doing too much.”
The opportunities came with the client's own numbers.
Renewals consumed about 40% of sales rep time in peak season, and the sales lead estimated 75% of them were mechanical. About 145 recent trial prospects had never been systematically re-contacted. Trial signups waited one to three days for login details.
What we recommended
The report prioritized 30 projects and built three flagship programs from them:
- Support consolidation onto a platform the group already licensed, followed by AI-drafted replies that a human always reviews and sends.
- Operator context tooling: short, hands-on training that connects existing tools to AI agents, starting with the people already pulling for it.
- An engineering AI program built around guardrails first (test integrity, CI hardening, shared skills), following the UK engineering lead's own principle of “go slow to go fast.”
Three of the highest-leverage moves cost almost nothing: a published sanctioned-use policy, license coverage for every developer, and protected training time.
The report was equally specific about where to hold back. It kept AI away from the group's government-level enterprise partnerships, ruled out automated customer-facing support responses, and deferred autonomous code merges until guardrails existed. It also recommended a non-AI investment, a business process analyst, because applying AI to an undocumented process automates the ambiguity along with the work.