Demo Scenario

Telecom self-care bot

Balance, plan, top-ups and support requests in Telegram — working with a legacy billing system and handing over to operators.

This is a demo scenario: how we would build the solution. Names and data are illustrative — it is not a specific client’s story.

01Task

Task

Take routine subscriber questions off the call centre — balance, plan, bundles, top-ups — and leave operators only the complex cases.

Constraints

  • Billing is a legacy system with a SOAP API and a request quota.
  • Peak load in the first days of the month, when monthly fees are charged.
  • Subscriber personal data: access only after the phone number is confirmed.
02Solution

Solution

  1. 01

    Subscriber identification by the phone number shared in Telegram, linked to the billing account.

  2. 02

    An adapter to SOAP billing with a cache and a queue, so peaks stay within the request quota.

  3. 03

    Top-ups through a payment provider, confirmed by webhook.

  4. 04

    Complex questions go to the CRM as a ticket with the conversation history.

03Architecture

Architecture

Architecture: Telecom self-care bot
  1. Telegram → Bot API
  2. Bot API → Self-care backend
  3. Self-care backend → Billing adapter, Payments, CRM · tickets
  4. Billing adapter → Billing · SOAP, Cache · queue
  5. Payments
  6. CRM · tickets
  7. Billing · SOAP
  8. Cache · queue
Integrations
Billing (SOAP) · Payment provider · CRM
Stack
Node.js · TypeScript · PostgreSQL · Redis · Telegram Bot API
04What it demonstrates

What it demonstrates

Demonstrates: password-less subscriber identification, working with legacy billing through a quota-aware adapter, webhook-verified payments and operator handover with context.

Want to see which questions subscribers ask most often?

Request analyticsDataZone