Self-Hosted AI Layer for Customer Support
Location
USA, Czech Republic
Partnership period
2022 – Ongoing
Team size
5
Project information
Overview
A global infrastructure hosting provider serving customers from individual developers to enterprises running production workloads. The company operates its own data centre footprint across North America, Europe and Asia, and sells physical and virtual compute capacity along with adjacent network services.
Customer support runs 24/7 through a distributed organisation of roughly 45 agents split across three regions, combining an internal team with outsourced delivery partners. Support is not a cost centre for this business — for an infrastructure provider, a slow or wrong answer is a production outage on the customer’s side.
The engagement took place during a period of rapid growth. Ticket volume was rising faster than headcount, the company was consolidating its support organisation, and leadership had launched a transformation programme covering process, staffing and tooling in parallel. The work described here is the tooling track of that programme.
Challenge
The client’s support organisation was structurally sound but operationally expensive. The cost was not in solving problems — it was in getting to the point where an agent could start solving one.
Context reconstruction on every handoff
Follow-the-sun coverage means a single ticket is worked by several agents across timezones. Each new agent had to read the full customer thread and every internal note before touching the ticket.
Inconsistent quality across regions and vendors
Tone, structure and completeness of customer replies varied by who picked up the ticket.
Knowledge scattered across systems
Answers lived in the knowledge base, the billing platform and internal notes, with weak search across all three; agents fell back on asking colleagues.
Factual errors reaching customers
An agent could confirm a fix that internal notes showed had never been applied, generating rework, escalation and credibility damage.
No safe path to public AI
Tickets contain customer data and infrastructure detail. Commercial LLM APIs were not an option, which ruled out every off-the-shelf AI support product on the market.
New agents trained on live customers
There was no environment in which a new hire could make a mistake without a real customer receiving it.
Volume outpacing headcount
Ticket load grew faster than the team, so the time lost per handoff multiplied across the day.
What the client asked for: reduce the time an agent spends getting into a ticket, make internal knowledge answerable, and do it without a single byte of customer data leaving the company’s own network.
Solution
CodeIT designed and built a self-hosted AI support layer — five components running entirely inside the client’s own network perimeter, with all inference performed on locally hosted models.
Ticket enrichment pipeline
A processing layer that turns raw ticket text into structured signal, in tiers by cost: fast lexical features (sentiment, urgency, politeness, escalation pressure), extraction of technical artefacts (IP addresses, ASNs, error codes, server identifiers), then locally generated embeddings, and finally LLM synthesis producing an executive summary, the customer’s actual request, the work performed, the current blocker and an escalation risk score. Lexicons were tuned specifically for hosting and infrastructure language rather than generic sentiment.
AI assistance inside the management and billing platform
The platform that holds the customer record — accounts, orders, services and every support request — is where agents spend their day. Rather than moving them somewhere new, the AI layer was built into it: an auto-generated draft reply attached to a ticket the moment it arrives, and an on-demand summary of where the request currently stands. The first layer of help sits inside the system agents already work in, with no change to their habits.
Ticket Assistant — a chat bot in the team’s existing messenger
The component that most directly attacks the context reconstruction problem. An agent focuses a ticket once, then works it through short commands:
- context — where the ticket stands right now, what should happen next, and risk markers such as an unhappy customer or a missed commitment. Replaces reading the thread.
- assist — a plain-language question answered from the knowledge base, with sources.
- reply — a drafted customer response built from the conversation, the internal notes and matching KB articles, with tone selected automatically from ticket signals.
- notes — a summary of the internal agent notes customers never see.
- factcheck — an agent’s draft checked against the internal notes, which the system treats as the source of truth, returning specific issues and a corrected version.
- transfer — the last answer written into the ticket as an internal note, so the next agent inherits the summary instead of rebuilding it.
Focus is shared across a team space: when one agent focuses a ticket, everyone in that space is working the same ticket. This was a deliberate choice — the tool is built for handoffs, not for individuals.
Knowledge base retrieval
The company’s internal wiki — runbooks, procedures, hardware and network guidance accumulated over years — was ingested, chunked and embedded into a vector store, then exposed as a natural-language question-answering service. Agents ask a question the way they would ask a colleague and get an answer with the source articles behind it. The knowledge was already written; it simply was not findable.
AI training simulator
Built on the client’s new helpdesk platform, a set of scenario-driven training tickets where AI plays the customer, the console the agent is diagnosing, and a coach. At the end of a scenario the agent receives an assessment of strong points, weak points and what to communicate differently. New agents now make their first mistakes on a simulated customer.
Design decisions that shaped the build
- Self-hosted models only. Embeddings and generation run on infrastructure inside the client’s VPN perimeter. No customer data reaches a third-party AI provider. This constraint drove the architecture from day one rather than being retrofitted.
- The assistant is never autonomous. It sends nothing to customers, changes no ticket status, closes nothing, assigns nothing. Its single write path is adding an internal note, and that was gated behind an allowlist during rollout.
- Internal notes are the source of truth. Fact-checking a draft compares it against what the team recorded, not against the model’s own reasoning.
- The system marks what it cannot know. Where a fact depends on something only the agent can verify, the draft contains an explicit placeholder rather than a plausible invention. The agent must fill it in before sending.
- Feedback instrumentation from the first release. Every generated answer carries a helpful / not-helpful control, tied to that exact answer. Weakness is found from usage data, not from opinion.
- Built for a team, not a user. Shared focus and note transfer are handoff features. The unit of work is the ticket, not the agent.
Result
Rollout to the full support organisation began in September 2026. The following outcomes are established by the design and confirmed in use; quantitative figures from the first weeks of production are noted where measurement is in place.
- New agents train without customer exposure. Onboarding moved from live tickets to scored simulation.
- Quality became measurable. Built-in ratings on every answer give a continuous signal on where the assistant is weak, replacing anecdote with data.
- Getting into a ticket became one command. Picking up a colleague’s ticket, returning from time off, or triaging no longer requires reading a full thread and its note history.
- Handoffs leave a record. A context summary can be written back into the ticket, so the next agent inherits a briefing rather than reconstructing one.
- A factual check exists before a reply is sent. Claims that internal notes do not support are caught before the customer sees them.
- Internal knowledge became answerable. Agents ask a question in plain language and receive an answer with its sources, instead of searching or asking a colleague.
Note on attribution: the client’s response-time improvements over this period were delivered by a transformation programme covering process, staffing and tooling in parallel. The AI layer is one contributing element, not the sole cause. Figures reported here are those that measure the tooling directly.
Delivery
The layer was built between May and August 2026, with rollout to the full support organisation beginning in September. The bulk of the work — enrichment pipeline, retrieval service, chat assistant and training simulator — was carried by a single Python engineer. Integration work drew in a PHP engineer for the billing platform side and a frontend engineer for the interface layer, with the client’s CTO involved directly in shaping requirements and prototyping.
Achievements
In-Perimeter LLM Stack
A production LLM stack running entirely inside a client’s network perimeter, with locally hosted embedding and generation models, vector storage, retrieval, and orchestration — no commercial AI API required. A reusable pattern for regulated industries and clients bound by data-residency limits.
Domain-Tuned Language
Lexicons for urgency, threat, temporal pressure, and politeness, calibrated for hosting and infrastructure support rather than generic sentiment analysis. Reusable across any technical support domain that needs to read tone, not just topic.
Source-Attributed Knowledge Retrieval
An ingestion-to-answer pipeline where every generated answer carries the documents it came from — the pattern that makes an internal RAG system trustworthy enough for staff to actually rely on.
Guardrails for Justified Scepticism
No autonomous action, notes treated as ground truth, explicit placeholders instead of invented facts, and a fact-checker aimed at the AI’s own output. Designing for scepticism, not against it, is what got the tool adopted.
AI-Driven Training Simulator
Scenario-based practice where AI plays customer, system, and coach, ending in structured assessment. Directly transferable to any client with a support, sales, or service organisation to onboard.
Feedback Built In From Day One
Rating capture tied to individual generated answers, shipped in the first release rather than bolted on later — so the improvement loop exists from day one, not as an afterthought.
Team-Level, Not Personal, AI
Shared ticket focus and note transfer designed around handoff rather than individual productivity — an uncommon choice, and the one that actually fits 24/7 operations.
Technology stack
- Python
- FastAPI
- Django
- Self-hosted LLM
- PostgreSQL
- ClickHouse
- Redis
- Apache Airflow
- NLP
- Kubernetes
- VPN perimeter
Team
- Python engineer
- PHP engineer
- Frontend engineer
- Delivery manager
- CTO
Explore related services
Custom AI Development
Build AI systems designed around your data, your infrastructure, and the way your teams already work.
Generative AI Development
Deploy generative AI and LLMs on your own infrastructure, with full control over where data goes.
AI Knowledge Assistant
Turn scattered internal documentation into answers your team gets in plain language, with sources attached.
Generative AI & LLM Consulting
Decide what to build, which models to run, and whether to self-host, before development starts.