AI support assistant for a multi-client IT/ITSM provider
Rebuild of an AI support assistant (Teams/WhatsApp → bot → ticketing system) as an in-house SDK, moving off a discontinued low-code platform, for an IT provider serving multiple companies under an outsourced-support model.
- In-house SDK (TypeScript/Node)
- LLM-based text classification
- Ticketing system (ITSM) integration
- Corporate messaging (Teams/WhatsApp)
- Multi-tenant architecture
- systemd
Context
An IT/ITSM provider serving multiple companies under an outsourced-support model, building an AI support assistant — for internal use and for its own end clients — designed as a multi-tenant platform from the start, with an AI layer able to answer from a knowledge base instead of only routing tickets.
Problem
- Ticket categorization that didn’t scale: exact keyword matching only covered a handful of the hundreds of possible categories, dropping everything else into a manual triage queue.
- Natural-language ambiguity when referring to ticket numbers, easily confused with other valid numeric patterns in conversation.
- Two low-code platform migrations in under a year, making clear that business logic embedded in a third-party vendor tool is guaranteed rework at the next discontinuation.
- An unreliable messaging channel for carrying conversation state across turns, and session resilience across restarts.
Approach
Full rebuild of the business logic as an in-house TypeScript/Node SDK, independent of any third-party low-code orchestrator. Category classification via LLM with a deterministic fallback, covering the entire catalog (500+ categories) instead of a small keyword-matched subset. Ticket-reference recognition with format-based disambiguation, tested against a battery of trap cases. All conversation-continuity intelligence moved inside the SDK, deployed as a small load-balanced cluster of workers behind a single router, with multi-tenant credential routing so the same codebase serves more than one internal bot/client.
Outcome
System in real production, processing support traffic for more than one end client, with classification covering the full category catalog. Zero third-party platform dependency after the second migration, with an expansion pipeline for additional end clients underway on the same multi-tenant base.
Lessons
Keeping all business intelligence in the layer you control, never in the third-party orchestrator, paid off at the second platform migration: the logic survived intact, only the transport layer changed. LLM classification with a deterministic fallback scales coverage without reducing reliability. Designing for multi-tenancy from day one avoids rewriting the transport layer for every new client.