Manufacturing
AI Phone Assistant with Slack Routing
Challenge
A manufacturer had introduced an AI phone assistant that answers calls and records the caller's concern. But the summaries ended up in a mailbox from which they had to be forwarded to the right person by hand.
Solution
We developed a microservice that receives the phone assistant's webhooks, analyses the concern with an LLM, determines the responsible person from the organisational structure and sends them a direct Slack message. When the system is unsure, the case goes to a fallback channel with interactive buttons for manual assignment.
Result
Calls reach the right person without anyone sorting in between. The service runs on the existing Windows Server behind an IIS reverse proxy with HTTPS, containerised with Docker Compose.
Starting point
The AI phone assistant answered calls reliably and delivered a structured summary for every conversation via webhook. The last step was missing: who in the company is responsible for this concern, and how does that person find out without someone screening a mailbox and forwarding? Exactly this manual intermediate step was holding back the assistant’s value.
How the router works
The microservice receives the assistant’s webhook and passes transcript and metadata to an LLM. The model classifies the concern: is it about an order, a complaint, a technical question, a job application? The service then matches the result against the stored organisational structure, meaning departments, roles and deputies, and determines the responsible person.
That person receives a Slack direct message with the summary, callback number and the key facts of the call. Within seconds, the call is where it belongs.
Handling uncertainty
No classifier is perfect, and that is exactly what the fallback is built for. If the assignment falls below a defined confidence threshold or the organisational structure is ambiguous at that point, the service posts the case to a fallback channel. Interactive buttons there let a person set the responsibility with one click. This keeps the automation honest: it decides where it is sure and asks where it is not.
Technology and operations
The service is implemented in FastAPI and runs in Docker Compose on an existing Windows Server. An IIS reverse proxy terminates HTTPS and forwards the webhooks to the container. The solution fits into the existing infrastructure with no new servers, no cloud dependency and the familiar operating processes of the internal IT team.
Transferability
The pattern is generic: an event comes in, a model interprets it, a rule set determines the recipient, and a human stays in the loop when in doubt. The same works for web forms, incoming email or support requests.