Engagement · AI delivery · Build
A payroll & HR services group, putting AI to work across support and delivery without ever risking a wrong answer to a customer. The roadmap named the prize on the outside of the product. The order that earned it started on the inside.
Three AI capabilities went live in production: knowledge agents for support, automated documentation-quality checks, and AI inside the delivery pipeline. The client-facing pieces were architected and queued behind them, a gating decision made on engineering discipline so the foundation was right before a customer ever saw an AI answer.
3
AI capabilities built and running in production, all internal-facing
Copilot Studio
knowledge agents the support team used to find answers and surface gaps in the docs
CI/CD
AI-assisted review and quality gates inside a containerised delivery pipeline
2025–26
the group’s most recent engagement; payroll & HR sector, public-sector market
The proof · Ship the foundation first
The internal foundation went live first: support agents, documentation quality, AI in the pipeline, all running in production. The architecture decided what had to be true before a customer ever saw an AI answer, then built that part and ran it. Gating the client-facing layer behind it was the engineering discipline that keeps a wrong answer off a customer’s screen.
Section A · The work
From an AI roadmap to a foundation in production, sequenced so the risky part comes last.
A roadmap that already existed, and the order it needed
The group runs a payroll and wage-calculation platform sold into a demanding market, including public-sector customers with their own rules. AI was already on the table as a way to make support faster, the documentation trustworthy, and delivery safer. As IT Manager, Kurt owned the platform’s delivery, architecture, budgets, recruitment and team management, the only IT seat on the business-unit management team, so the AI roadmap was his to architect and sequence: the function that owned the IT set the order the AI work would follow. The work here was to turn that ambition into an architecture: which pieces depend on which, what has to be true before a customer can be trusted to an automated answer, and therefore what gets built first. The order mattered more than the list. Several of the most visible ideas could only be safe once quieter, internal work was done.
Knowledge agents the support team could lean on
The first foundation piece served the support people who answer the customers. Knowledge agents built in Microsoft Copilot Studio, with Microsoft Semantic Search reading across the SharePoint documentation, gave the helpdesk and support team a way to find the right answer fast. The agents did a second job too: as the team used them, they surfaced where the documentation was wrong or missing, and that feedback fed the quality work on the manual. So the assistive layer sat with the human support staff, making them quicker and sharper, while the manual it read from kept getting better underneath it. Letting an AI answer the customer’s first question directly was designed as a later step, held back until the answers were good enough to be worth it.
Make the manual trustworthy before anything reads from it
A client-facing assistant can only be as good as the manual underneath it, so the manual came first. Automated documentation-quality checks read the product manual for contradictions and gaps and surfaced them for correction. This was the unglamorous prerequisite: until the source the AI would answer from was coherent, putting that AI in front of a customer would have meant putting its errors there too. Doing the quality work first is what let the client-facing endpoint stay on the roadmap as a credible next step rather than a hope.
AI inside the pipeline, where the code is made
The third delivered piece moved upstream into delivery itself. GitHub Copilot and Claude Code ran inside a containerised pipeline, with AI-assisted code review and quality gates built into how changes shipped. The effect was on the team’s own throughput and on the safety net under every release, so the platform could be changed faster and caught earlier. Here AI ran as production engineering, governed and gated inside the pipeline itself.
The next step, by design
The roadmap’s headline pieces were designed and architected here, and left for the next phase by design. An AI-assisted first-line tier would let the AI take the customer’s opening question itself, escalate along a structured path, and hand off to a person when it was unsure. It was held back for the same reason the client endpoint was: until the assistant’s answer quality and the range of topics it could cover were high enough, an AI front line would frustrate the people it was meant to help, so the discipline was to wait. A client-facing, in-app assistant would one day answer customers from the 2000-plus-page manual, once the documentation-quality work had brought that manual up to standard. Unsupervised machine-learning anomaly detection would flag irregular wage calculations for review. An AI-assisted effort would document and port the roughly seven thousand legacy scripts off a language the platform is set to lose, into a coherent whole ahead of the deadline. These were the designed next step, gated on the foundation. By the time the engagement closed the foundation was in production and the next phase was queued by design, sequenced behind work that had to be right first rather than left open-ended. Naming them as roadmap, and the three pieces above as in production, is the whole point of the order.
Section B · What shipped
A working AI foundation runs in production, and the roadmap behind it earns the next phase’s trust.
When the engagement closed, three AI capabilities were live and in daily use, all of them internal. The support team had knowledge agents that helped them find the right answer fast and flagged where the documentation was wrong or missing, which fed the quality work on the manual. The product manual was being held to a quality standard by automated checks, which is the condition any customer-facing assistant would later depend on. The delivery pipeline carried AI-assisted review and quality gates, so the platform could change faster with more caught before release. The bigger, client-facing ideas, the AI-assisted first-line tier and the in-app assistant among them, were architected and sequenced behind that foundation, ready for a next phase that would not have to start from a shaky base. Data handling, GDPR and the EU AI Act shaped the architecture from the start. The discipline of keeping a person in the loop, and of holding the AI front line back until its answers were good enough, was the visible evidence of that.
3
internal AI capabilities live in production at handover
CI/CD
AI-assisted review and quality gates running inside a containerised delivery pipeline
1
architected roadmap the next phase can build on, with the customer-facing layers gated on the foundation
“The architecture decided what had to be true before a customer ever saw an AI answer, built that part, and ran it. The client-facing layer was designed to wait on it.”
AI on the roadmap, and an honest question about what to build first?
The fastest way to find out whether this shape of work fits your problem is a short conversation.