A WhatsApp message has arrived from a Mark Jones about a billing problem. I have no context.
AGENT · MULTI-CHANNEL HUB
The same customer, one conversation, across all channels.
Multi-Channel Hub unifies the dialogue with the customer when the customer writes on the company's different channels — email to customer service, WhatsApp Business, web chat on the product site, LinkedIn messages. Recognises the customer, retrieves the history of the previous conversation on any channel, keeps the consistency of the replies.
Multi-Channel Hub at work.
Customer recognition complete. Mark Jones → CRM contact 4821. Cross-channel history: Monday email on April invoice discrepancy, partial reply from colleague Martin, ticket "awaiting reply". Now writing via WhatsApp: "I re-read but the problem isn't resolved". Unified thread below.
Perfect. I'll reply here — can you close the ticket?
Reply sent via WhatsApp. Ticket updated, status → "resolved, awaiting customer confirmation". Full cross-channel trace (email + WhatsApp) in the audit registry.
Why it exists.
The average customer of a mid-large company writes on channels in an unstructured way. A request arrives via email to customer service, the follow-up arrives via WhatsApp Business, a later question on the web chat of the site. For the customer it is one conversation; for the company they are channels with different teams and systems.
How it unifies channels.
Multi-Channel Hub receives every new message from the configured entry channel (Telegram, Slack, WhatsApp native; corporate email and other channels via adapters), recognises the customer through matching on email, phone or CRM identifier, retrieves from the shared memory the history of previous interactions on any channel, and proposes to the operator the reply consistent with the full context.
The decision stays with the operator.
The operator sees the entire cross-channel thread, replies from the unified work channel. The reply goes out on the channel where the customer wrote. The shared memory updates. The agent does not close tickets nor write to the customer on its own: it sets the context.
Who it serves and where it applies.
Customer service operator
Sees in seconds the history of all previous conversations of the customer on any channel, ordered temporally. No more asking the customer to recap what had already been discussed. Average reply time falls and the customer does not repeat themselves.
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
Customer service lead
Sees a reduction in duplicate customer thread errors, lost requests between different channels, and inconsistent replies between teams that see only their own channel. Service quality stops depending on the entry channel.
Switch window · 7d 240 customers
High-value cluster A callback prio 1
Dedicated offer €8/month · 12 months
Engagement < threshold escalation to operator
Expected win-back rate: 22%
The customer
Recovers the fluidity of the relationship. Replies are consistent with everything they have said and written, even if the last conversation was on a different channel from the one where they are writing now.
Week 23 Aggregated churn
South · offer X churn +14%
Center · offer Y stable
North · offer Z +2 points
Brief to the retention director
A concrete example.
A customer reports a problem via email.
For a B2B SaaS company with customers writing via customer service email, WhatsApp Business, and web chat on the customer portal, the multi-channel flow is daily. A customer reports a problem with a product function via email. A first-level operator replies with a workaround, marks the ticket as awaiting customer confirmation. The case does not close.
Two days later the same customer writes via WhatsApp.
Two days later, the same customer writes via WhatsApp Business: they tried the proposed solution and it does not work. The message arrives at the Multi-Channel Hub agent. The agent recognises the customer — matching on phone number, CRM contact, registered email — and retrieves from the shared memory the history of the interactions: opening email, proposed workaround, "awaiting confirmation" status.
The operator sees the full thread on the work channel.
The operator sees the unified thread on the work channel, replies via WhatsApp with the new solution, escalates to level 2 technical support for the unresolved problem. The CRM ticket updates with the new step. The full event — cross-channel messages, customer recognition, retrieved context, operator's decision — stays in the runtime audit registry.
Configuration and technical resources.
The Multi-Channel Hub rules are declarative. The customer's customer service team defines in a readable format the cross-channel matching rules (which customer identifiers are reliable, how to handle ambiguous matches), the temporal depth of the memory (e.g. conversations from the last 12 months), the format of the unified thread the operator sees. The rules live in the customer's repository, versioned, validated at agent startup.
- 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, credential-detector, prompt-injection, topic-guardrail
- Native channels
- Telegram, Slack, WhatsApp, OpenAI-compatible HTTP
- Corporate email and other channels
- integration delivered during the project
- Shared cross-channel memory
- pgvector + PostgreSQL FTS per instance, configurable retention
- CRM integration
- HubSpot native; other CRMs delivered during the project
- Registry
- immutable, queryable with a standard SQL client
Frequently asked questions about the agent.
When the customer is not recognised at the first message — a new email from an address not in the CRM, a new WhatsApp number not linked — the agent starts a minimal identification conversation (name, company, reference contact) and creates a new profile in the CRM with the collected data. The customer's memory starts from the first message.
When the matching has multiple candidates (the same WhatsApp number is associated with two CRM contacts), the agent marks the conversation as "match to confirm" and proposes the candidates to the operator. The operator confirms the correct match; the declarative rules learn the pattern for next time.
The runtime's native channels are Telegram, Slack, WhatsApp, and OpenAI-compatible HTTP. Microsoft Teams requires dedicated integration, delivered during the project by the Exelab team. The same applies to other corporate channels (Workplace, proprietary chat systems).
Retention of the shared memory is configurable per instance according to the customer's GDPR constraint. Typical patterns: rolling 12-month retention, anonymisation after 24 months, total deletion after 36 months. The customer exercising the right of access to their data (Art. 15 GDPR) receives a reply from the audit registry queryable via SQL.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Multi-Channel Hub would configure to the customer's case. Which channels, which matching CRM, which memory depth.