AI tooling, a support desk, and the training to run both

The problem

By this stage EKA had a growing web platform, an active demand programme and an expanding product range — which produced a new class of problem. More enquiries meant more triage. More models meant more specification content to keep accurate across every channel. More systems meant more questions from internal teams about how to use them.

These are the tasks that quietly consume a team's capacity: repetitive, judgement-light, but consequential when done wrong. They are also exactly where AI is genuinely useful — and exactly where a badly-built AI feature causes real damage by confidently stating a wrong specification to a customer.

What we did

AI tools built around the existing workflow

We did not start by choosing a model. We started by sitting with the people doing the work and finding out which steps were repetitive, which required judgement, and which had a clear right answer that was simply tedious to look up.

The tools we built were narrow by design. A narrow tool with a verifiable output is useful on day one. A general assistant that might be wrong about anything requires the user to check everything, which removes the benefit entirely.

• Retrieval grounded strictly in EKA's own approved specification documents, with citations
• Refusal rather than guessing when the source material did not contain the answer
• Human review required on anything customer-facing before it went out
• An evaluation set built from real historical queries, so changes could be measured
• Logging on every interaction, so failure patterns were visible rather than anecdotal

Technical support calling

Alongside the tooling we ran the technical support function directly: L1 and L2 support calling, ticket triage and a defined escalation path into engineering. This covered the period while EKA's internal team was being hired and brought up to speed.

• Defined severity levels with response expectations, agreed rather than assumed
• Named escalation contacts on both sides — no anonymous ticket queue
• Every recurring issue logged into a knowledge base as it was resolved
• Monthly pattern review, feeding fixes back into the product instead of re-answering

Training as a deliverable, not a courtesy

The stated goal from the beginning was that EKA's team would be able to run all of this without us. That is an unusual thing for a vendor to optimise for, and it is the main reason the relationship extended across three programmes.

• Live training sessions per system, recorded and kept for future hires
• Runbooks for operational tasks that had been living in individual heads
• Documentation written for the next engineer, not as a reference back to us
• A deliberate reduction in our involvement as internal capability grew

Outcome

EKA's internal team now operates the tooling and handles the support patterns we documented. Our involvement narrowed to the engineering work that genuinely needs outside capacity, which is the correct end state.

Why this matters for other clients: everything we learned building production AI here — the failure modes, the evaluation discipline, the human review boundaries — went into the tooling we now run internally. See the AI Lab for what that looks like.