What is CRM in telecom, and which records does it own?

CRM in telecom is the customer relationship management software an operator keeps its customers in: each account, the people on it, every conversation, the open trouble tickets or a view of them, and what the customer might buy next. A CRM shows a customer’s bill and how far an order has progressed, but billing produces the bill and order management carries the order out. The phrase also covers linking an office phone system to a CRM, a separate subject this guide leaves aside.

What a telecom CRM holds

A household account lists the account holder and anyone authorized to make changes, how to reach them, and whether they have agreed to hear from the operator. A business account carries more: several sites, the people allowed to sign or change the contract, and sometimes the reseller or partner that sold the service. Against each account sit the interactions, whether they happened in a store, on a call, in web chat or during a technician’s visit. Open tickets sit there too, and so does the sales side: opportunities and quotes, with their renewal dates.

The term reaches further in an operator’s process model. eTOM, TM Forum’s business process framework, which ITU-T also published in 2007 as Recommendation M.3050.1, places ordering, problem handling and billing in the same customer-facing block as customer relationship management. It describes processes, and the CRM application is one of several systems that carry them out.

Which system owns which record

Ownership is settled field by field, and one record is often split: the CRM holds the contact details while billing holds the bill cycle and credit class. TM Forum, the telecom industry body, publishes Open APIs that treat the customer, the billing account, the product order, the service order and the inventories as separate resources. Where an operator’s platform exposes them, an integration should be built against them.

Record	Where it usually lives	What the CRM does with it
The customer account and its contacts	CRM	Owns them
Interactions and trouble tickets	CRM, or a ticketing system shared with network operations	Owns the interaction and tracks the ticket
Plans, prices and eligibility rules	Product catalog, in some stacks part of billing or the CRM suite	Reads them to quote and sell
An order once submitted	Order management	Hands it over, then reports its status
Products the customer has and the services behind them	Product inventory, with service and resource inventory beneath it	Reads them, and changes them only by placing an order
Billing accounts and bills	Billing	Creates billing accounts, reads bills and requests changes that billing records
Appointments and work orders	Workforce or field service management	Books through it and tracks progress

Suites draw these lines differently, so the map is drawn for each operator from the systems it actually runs.

How does the CRM work with billing?

The CRM sits in front of billing. A customer who calls about a bill reaches an agent working in the CRM, and the agent answers from billing’s data. Behind that, mediation gathers usage records from the network, a charging system prices them, and billing turns them into bills and records the payments.

One customer can have several billing accounts, one per site or per line of business, so how a CRM account links to its billing accounts is a design decision. A new billing address has to reach both systems. A new payer is a different matter: a change of the responsible party that travels as an order, often with a credit check.

The CRM writes to billing as well. It creates billing accounts and raises the credits, adjustments and payment arrangements that billing then records, and a plan change reaches billing through the order flow. Rating and invoicing stay with the operator’s billing vendor, and the portals and integrations that read from billing are what we build.

How an order gets from the CRM to a working service

Activation, SIM provisioning and number porting turn up in CRM vendors’ feature lists. In an operator’s systems, that work happens after the CRM. The CRM or the portal captures the order and hands it to order management, which owns it from then on, changes and cancellations included. Order management breaks the product order into service orders, and service order management works out what each one needs and hands the network steps to the operator’s activation platform or element managers. A new SIM follows that path. A number port also sends a request to the losing operator, and that request can be rejected, so the CRM has to surface the rejection and let the customer correct the details.

Each step reports its status back, so the agent and the customer see the same state. A step that fails lands in a fallout queue, the list of stuck orders a person works through, and the CRM marks the order as held.

Does a reseller need the same CRM as an operator?

Not always. A reseller that buys lines wholesale and sells them under its own name has no network, so provisioning becomes an order placed with its supplier, and it prices the supplier’s usage files at its retail rates to produce its bills. One platform covering sales, orders and invoicing can be enough, and some reseller billing platforms include a CRM for that reason.

A larger operator that runs billing apart from order management and inventory splits the records as the table does, while many smaller ISPs run one platform that covers most of it. Mobile virtual network operators (MVNOs) range from branded resellers, where the host network or an enabler runs almost everything, to full MVNOs with their own SIMs and billing, to whom most of the table applies. Scale and the systems already in place decide how much of that split you need.

A telecom edition or a general CRM

Some CRM vendors sell a communications edition: Salesforce describes its Communications Cloud as a catalog-driven business support system (BSS) suite, so that vendor can also own the product catalog and the order. Amdocs, a BSS vendor, combines Microsoft’s sales and service capabilities with its own in its Customer Engagement Platform. A general CRM can be extended with an operator’s records and connected to the systems in the table.

The catalog usually settles the choice. An edition fits when its catalog and order model match how you sell. Where both already live elsewhere, a connected general CRM is simpler to run and change. We have integrated Salesforce, Microsoft Dynamics 365, HubSpot, Zoho CRM and Pipedrive for clients outside telecom, as part of our CRM integration and extension work.

Mapping the connections before anything is built

The CRM, the portal and the field app tend to drift apart. A customer entered twice, an order status that never came back, a work order that changed after the technician left: most of these trace back to data nobody formally owns.

Before we build anything around an operator’s CRM, we write down every connection: the system that owns each record, which way the data moves, how often, and what happens when the connection fails. Where a vendor platform offers only file exports, the import runs on a schedule and logs each run. The first call is free, and a short paid assessment produces that written map and a fixed, itemized quote. The people who scope the build are the people who build it.

As a telecom software development company, we build the portals, order flows and field apps around an operator’s CRM.

The full service behind this post: Telecom Software Development Services & Solutions.