Demo Scenario

Churn signals before the customer leaves

A telecom operator learns about churn when the contract is already cancelled. We link billing, tickets and usage to see the risk in advance.

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

Find subscribers whose churn risk is rising and hand them to retention while they are still customers.

Constraints

  • Billing and support data live in different systems with different identifiers.
  • Personal data never leaves the company perimeter.
02Solution

Solution

  1. 01

    An identifier mapping for each subscriber across systems.

  2. 02

    A weekly risk model on usage, payment and ticket features.

  3. 03

    The high-risk list goes to the retention team’s CRM with the reason.

03Architecture

Architecture

Architecture: Churn signals before the customer leaves
  1. Billing → ETL · ID mapping
  2. Support desk → ETL · ID mapping
  3. Usage records → ETL · ID mapping
  4. ETL · ID mapping → Data Warehouse
  5. Data Warehouse → Churn risk model, Churn dashboard
  6. Churn risk model → Retention CRM
  7. Retention CRM
  8. Churn dashboard
Integrations
Billing · Support desk · Usage records · CRM
Stack
PostgreSQL · Python · SQL · Docker
04What it demonstrates

What it demonstrates

Demonstrates: joining data from systems with different identifiers and turning a forecast into a concrete action list for a team.

Want an AI agent to prepare an offer for each at-risk subscriber?

AI agentsAgentZone