Проекты

AI service desk — диалоговая система заявок в почте и Teams

AI
Automation
Python
Microsoft 365
Service Desk

Диалоговый сервис-деск для ИТ-отдела производственной компании: сотрудники пишут в свободной форме по почте или в Microsoft Teams, языковая модель превращает сообщение в корректно оформленную заявку, а специалисты ведут очередь прямо из Teams — источником истины по инфраструктуре служит CMDB.

Hands typing a message on a laptop keyboard at a desk

Это описание проекта написано на английском языке.

Challenge

IT requests at a multi-site manufacturer arrived as ordinary email and chat messages. There was no single queue, no traceability, and no link between a request and the device or site it concerned. Staff were expected to know which channel to use, how to categorise an issue, and which specialist to address — so most of them simply wrote to whoever they knew. Follow-ups landed as new threads, resolved problems came back as fresh messages, and nothing could be measured. A conventional rollout — “everyone must now use the ticket portal” — had already proven unrealistic in a plant environment.

Solution

  • Kept the interface people already use. Requests are accepted as plain-language email (via Microsoft Graph) and as Microsoft Teams messages. Nobody has to learn the ITSM tool, its categories, or the org chart.
  • An LLM turns messages into tickets in a self-hosted service-desk platform over its REST API — creating a new ticket, asking a single short clarifying question when key detail is missing, or appending to the right existing ticket when a user continues an earlier thread.
  • Thread- and conversation-aware routing. Email chains and Teams conversations carry state, so a late reply becomes a comment on the original ticket rather than a duplicate, and a message that continues an already-resolved issue reopens it instead of starting over.
  • NetBox as the source of truth. Devices, addresses, sites and contacts are looked up from the CMDB during triage, so a request is tied to real infrastructure. After a ticket is resolved, the assistant can propose a CMDB journal entry — always subject to explicit operator approval before it is written.
  • Technicians work from Teams: listing the active queue, opening ticket detail, posting public comments, recording a resolution, raising a ticket straight from a chat conversation, and requesting an internal diagnostic hypothesis grounded in CMDB data.
  • Cost-aware model routing. Simple requests go to a lightweight model and only genuinely complex ones reach the larger model, keeping inference spend proportional to the work.
  • Security designed in, not bolted on. Input guardrails block prompt-injection and secret-extraction attempts before anything reaches the model; output guardrails redact secret-like values before replies, ticket writes and audit storage. The model receives sanitised message text only — never environment files, shell access or filesystem tools. Attachment downloads are restricted to validated external HTTPS targets with a size ceiling.
  • Identity and operations. Web sign-in through Microsoft Entra SAML SSO with directory-password login disabled; automation authenticates by scoped API token only. Deployment and configuration are handled with Ansible and systemd units, with idempotent retries and message-level deduplication so a transient failure can never double-post a ticket.

Result

Requests from two very different channels now land in one auditable queue, each tied to the infrastructure it concerns, with the full conversation mirrored onto the ticket. Triage that previously depended on a person reading every incoming message is handled automatically, and technicians resolve work without leaving the collaboration tool they already have open. The multilingual workforce writes in whichever language it prefers. The system runs in production against live traffic while general rollout is staged department by department, and every automated decision is recorded so a wrong call can be traced and corrected.