AGENT · INBOUND TRIAGE

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.

02 · AGENT IN ACTION

Inbound Triage at work.

Context

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.

What it does

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.

Supervision

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.

03 WHO IT SERVES

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.

Claim type Auto liability
Severity Medium
Adjuster Dr. Ferrari · Northeast
Initial reserve € 4,200
Routed ✓

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.

WhatsApp «I had an accident, this is Rossi»
Type Auto liability · medium
Policyholder Rossi Marco
Policy #IT-2024-04471
Case opened · CRM updated

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.

Cross-channel · 7d 1,420 mentions
Site chat NPS 7.2
Reviews top theme: shipping
Social · IG sentiment +0.4
Brief to the brand owner
04 EXAMPLE OF A PROCESS

An urgent request arrives Monday morning. The operator receives it already classified.

The integration

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.

The classification

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 response

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.

05 CONFIGURATION

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.

SPEC SHEET
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
06 FREQUENTLY ASKED QUESTIONS

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.