Multichannel Conversational AI Assistant

Outcomes

Context

Inclusive access means designing for feature phones and call centers, not only smartphone web chat.

Challenge

Citizens and customers reach services through chat widgets, phone IVR, USSD, and voice. A single FAQ bot could not cover channels, languages, or handoff into human ticketing.

Approach

We assembled a channel-aware stack: conversational engine, ticketing integration, telephony (Asterisk), speech recognition/TTS including regional language support, USSD, message broker, and observability. Chat widgets and knowledge processes connected to the same orchestration backbone.

Architecture

Rasa dialogue stack, Zammad ticketing, Asterisk telephony, DeepSpeech and TTS/STT services, USSD gateway, RabbitMQ, PostgreSQL, Traefik, ELK-style logging, and embeddable chat clients.

Scope

• —Dialogue management
• —Chat embeds
• —IVR and voice
• —USSD flows
• —Ticketing synchronization
• —Speech recognition and synthesis
• —Knowledge base operations

Constraints

• —Multiple low-bandwidth channels
• —Language coverage beyond English
• —Need for human escalation
• —Telephony operational complexity

Solution highlights

• —Channel adapters into a shared dialogue core
• —Ticketing as the escalation system of record
• —Speech services treated as deployable infrastructure
• —Broker-based decoupling between channels and NLU

Technologies

Results

• —One assistant programme spanning chat, voice, IVR, and USSD
• —Human handoff into ticketing instead of dead-end bots
• —Speech pipelines for more than a single majority language
• —Operational logging for dialogue and channel failures

Lessons learned

• —If USSD is in scope, your dialogue design must shrink — not your ambition.
• —Bots without ticketing create abandoned citizens.
• —Speech models are infrastructure; treat them like databases, not plugins.