Request received via web ticket (Enterprise customer, 3 years: Mark Williams). Subject 'Problem with order 22345 — urgent'. Type: urgent technical support. Priority HIGH.
Incoming requests reach the right role, in seconds.
Inbound Triage receives tickets, chats and messages from any of the customer's channels. It reads the content, recognises the request type, identifies the priority, routes to the right team role under the configured declarative rules. The native channels active from day one are Slack, Telegram, WhatsApp and HTTP; email integration is delivered during the project.
Inbound Triage at work.
Routed to Elisa Ferrara (senior technical support, on duty). Context attached: profile, product, last 3 tickets, message extract.
Received. Responding within 15 minutes.
Recorded. SLA started. Event traced in audit.
Why it exists.
The inbound flow of a mid-large company is massive and weakly structured. Tickets from the site, messages on work channels, product-page chats. Everything lands with the first team that intercepts it, which spends time reading, classifying, forwarding to the right colleague. The operational problem is the time lost in horizontal handoffs between teams and the risk of requests slipping through the cracks.
How it routes in seconds.
Inbound Triage activates on every new request. In seconds it classifies the type (commercial request, technical support, complaint, refund, general question), identifies the priority, routes to the operator with the context ready. For standard requests, the agent can respond on its own with a configured action.
The decision stays with the operator.
For standard cases configured by the team, the agent can respond on its own (informational material, appointment confirmations, recurring FAQs). For requests that require human judgement, it routes to the operator with the context ready.
Head of customer service, operators, head of operations.
Head of customer service
Sees the first-level inbound handling time shrink. Routing is automatic; the first level of the team concentrates on cases that require judgement.
Team operator
Receives only the requests relevant to their role, already classified and with context ready: customer profile, purchased product, previous tickets, keywords extracted from the message. Reclaims the time of manual filtering and responds faster.
Head of operations
Sees the inbound flow in a structured way (volumes, types, priorities, average SLAs) to correctly allocate resources. Customer service capacity is sized on real data, not on perception.
An urgent request arrives Monday morning. The operator receives it already classified.
The agent is integrated with the intake channels via webhook.
For a mid-market B2B company with an inbound volume of four hundred requests a day (web tickets, chats, work channel messages), the agent is integrated with the intake channels via webhook and with the ticketing system.
Urgent technical support, high priority, context ready.
At ten on Monday morning a ticket arrives from a customer registered for three years. Subject 'Problem with order 22345'. The customer reports a product malfunction and declares urgency for an afternoon meeting. In seconds the agent classifies as 'urgent technical support', identifies high priority for the combination of declared urgency, Enterprise customer, and problem keywords, and routes to the on-duty operator with the context ready.
The operator receives the notification with everything already extracted.
The operator receives the notification on their work channel with everything already extracted. They respond within half an hour. The event — request classified, routing, operator response — stays in the audit registry for team performance analysis.
Configuration and technical resources.
The Inbound Triage rules are declarative. The customer's customer service team defines the request taxonomy (possible request types, mapping to team role), the priority rules (what is urgent, normal, low — with configured criteria), the automatic response rules for standard cases. The rules live in the customer's repository, versioned.
The native channels active from day one are Telegram, Slack, WhatsApp, and OpenAI-compatible HTTP (for form, chat, ticket webhooks). Integration with corporate email inboxes is delivered during the project by the Exelab team via an IMAP/webhook adapter. The same applies to proprietary ticketing systems (Zendesk, Freshdesk) and social listening channels.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, prompt-injection, topic-guardrail, message-length-limit
- Native intake channels
- Telegram, Slack, WhatsApp, OpenAI-compatible HTTP (webhook form, ticket, chat)
- Corporate email as intake channel
- integration delivered during the project (IMAP/webhook adapter); not available from day one
- Ticketing system integration
- dedicated adapter delivered during the project (Zendesk, Freshdesk, proprietary systems)
- CRM integration
- HubSpot native
- Memory
- persistent per instance, pgvector + PostgreSQL FTS on customer context
- Registry
- immutable, queryable with a standard SQL client
Frequently asked questions about the agent.
The taxonomy is declarative, written by the customer's customer service team. The typical pattern includes: request categories (technical support, commercial, complaint, information, administrative), priorities (urgent / high / normal / low with configured criteria), category-to-team-role mapping. Modifying the taxonomy does not require Exelab team involvement.
No. The native channels active from day one are Telegram, Slack, WhatsApp, and OpenAI-compatible HTTP. Integration with corporate email inboxes (generic customer service mailboxes, certified email) is delivered via an IMAP/webhook adapter during the project. The discovery qualifies which channels to activate for the real case.
For standard cases configured by the team, yes: sending informational material for basic requests, appointment confirmations, responses to recurring FAQs. For requests that require human judgement, the agent routes to the operator with the context ready. The automatic response rule is declarative.
The typical pattern is 4-6 weeks. Discovery one week, taxonomy and priority rule configuration two weeks, channel and ticketing integration one to two weeks, hand-off to the customer service team one week. The actual duration depends on the number of integrated channels and the depth of the taxonomy.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Inbound Triage would configure to the customer's case. Which intake channels, which request taxonomy, which priority rules.