CRM in Lead to Order
What CRM owns, what it only engages with, and why TM Forum’s architecture has no single “CRM” component. The eight Lead to Order steps on one map.
Lead to Order is the first stretch of Lead-to-Cash: from the first sign that someone might buy, to a confirmed commercial order handed to the fulfilment chain. CRM is the system most people picture for this stretch, and it is the one whose boundaries are most often misunderstood. In a telco, CRM is where the customer is known and where the conversation happens. It is rarely where the product is defined, where the quote is priced, where the credit decision is made or where the order is run. Knowing which of those CRM owns, and which it only uses, is most of what an architect needs to know about it.
There is no single CRM component
TM Forum’s Open Digital Architecture (ODA) breaks the work into components with one job each. None of them is called CRM. What a vendor sells as a “telco CRM” is a bundle of several of them, plus the screens the agent and the customer use.
What a “telco CRM” bundles, in ODA terms
| ODA component | What it owns | In a typical CRM product? |
|---|---|---|
| TMFC036 Lead and Opportunity Management | Leads and sales opportunities | Yes |
| TMFC028 Party Management | People and organisations, and the roles they play | Usually; sometimes a separate customer master |
| TMFC023 Party Interaction Management | Every contact: call, chat, store visit, email | Yes |
| TMFC002 Product Order Capture and Validation | Quote management, order capture and validation | Often, in telco-specific products; never in a horizontal CRM out of the box |
| Product catalog, billing, product inventory | What can be sold, what is owed, what the customer has | No — CRM reads these; it should not own them |
The eight Lead to Order steps
The sub-processes of Lead to Order, as they are usually drawn. For each, the map shows CRM’s part — owns, engages, or hands off — who holds the record, the TM Forum API, and where it is taught. Select a step.
Lead Generation & Capture
CRM ownsCaptures each enquiry, register-interest and abandoned basket once, with the consent given, linked to the person if they are already a customer.
- Holds the record
- CRM or marketing platform (declare one)
- TM Forum API
- TMF699 (leads) · TMF663 (basket)
- Taught in
- 4.3 Lead & Opportunity
What CRM owns, and what it only uses
Lead to Order, consumer: who holds the record
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Lead (enquiry, register-interest, abandoned basket) | CRM or marketing platform | Web, app, store, contact centre | — | Declare which one; two lead stores means two answers to “how many people asked for fibre in this town?” |
| Individual / customer | CRM or a customer master (MDM) | All channels | Billing, COM | Must be declared. Section 4.2 covers why it so often is not |
| Interaction (call, chat, visit) | CRM | Contact centre, store, digital | — | The record of what was said and offered |
| Product offering | Product catalog | CRM, web shop | CRM | CRM displays offers; it should not define them |
| Basket / quote | Commerce or CPQ | CRM, web shop | — | In consumer sales the basket does the quote’s job |
| Credit decision, identity proof | Credit engine / ID-verification service | CRM | — | CRM asks and stores the outcome; it does not decide |
| Product order | Commercial order management (COM) | CRM, web shop | — | CRM shows the order; COM runs it |
| What the customer has (installed base) | Product inventory | — | CRM | CRM shows it; product inventory is the truth |
| Case / complaint | CRM | All channels | — | Hands technical faults to Trouble-to-Resolve |
Horizontal CRM and telco CRM
A horizontal CRM — the general-purpose kind used by banks, retailers and software companies — already does contacts, leads, campaigns, quotes, orders and cases on a simple product list. Telco products, or telco layers on a horizontal CRM, add the things that list cannot express.
| Telco need | What a horizontal CRM has | What a telco CRM adds |
|---|---|---|
| Offers built from a catalog | A flat price book of products | Offerings and specifications read from the product catalog, linked to what the network must deliver |
| Several accounts per person | One account per customer | Customer, billing and service accounts kept apart, so the payer and the user can differ |
| “Can I get it here?” | Nothing | Address lookup and a serviceability check against the network before the offer is shown |
| Changing what someone already has | Sell a new product | Orders against the installed base: change plan, add a line, move home, cease |
| Handing over to fulfilment | An order record at the end of the sale | A product order sent to COM, which decomposes it into service and resource orders |
CRM is where the operator knows who the customer is and talks to them. It captures interest, identifies the person, shows them offers, takes the order and handles their questions and complaints afterwards. The offers themselves come from the catalog, prices and baskets from commerce or CPQ, credit and identity decisions from specialist services, and the order is run by COM.
The line between CRM and COM. CRM captures the customer’s intent and confirms it; COM owns the product order from the moment it is submitted, including its status, amendments and the point after which it can no longer be changed. CRM shows that status by reading it from COM, typically through TMF622 events. A CRM that holds its own copy of order status will, sooner or later, tell a customer something that is no longer true.
Replacing CRM changes the agent’s and customer’s experience and the party data. It does not, by itself, change what can be sold, how orders decompose or what the network does. If the catalog is not catalog-driven and COM does not decompose, a new CRM shows the same limitations on a better screen. The opposite is also true: a programme that rebuilds the catalog and COM but leaves an old CRM in front of them still has the old customer data, which is usually the hardest thing to clean.
What CRM does not solve
- It does not decide what can be sold. The product catalog does; CRM displays it.
- It does not decide whether someone can pay. A credit engine does; CRM records the answer.
- It does not run the order. COM does; CRM shows its progress.
- It does not know what the network delivered. Product, service and resource inventory do; CRM reads them.
What it adds: another place customer data lives, and a set of integrations whose ownership must be written down. Every field CRM copies from another system is a field that can disagree with it.
Anti-pattern: CRM as the product catalog
- Why organisations choose it: speed to market; the CRM team can ship an offer in days without waiting for catalog or OSS changes.
- What must hold true for it to work: every offer is simple enough that someone can fulfil it by hand, and nobody needs to change it later.
- How it fails: COM cannot decompose an offer it has never seen. Orders are fulfilled by manual tasks and side spreadsheets, and the first plan change finds no product instance to change.
- Long-term cost: two catalogs that drift apart, every new offer needing CRM and OSS work, and an installed base whose products cannot be traced to a specification.
Section 4.1 Key Takeaways
- TM Forum ODA has no single CRM component; a “telco CRM” bundles lead, party, interaction and often order-capture components
- CRM owns the lead, the interaction and the case; for the customer record, the owner must be declared
- CRM only engages with offers (catalog), baskets (commerce/CPQ), credit and identity decisions, orders (COM) and the installed base (product inventory)
- A telco CRM adds catalog-driven offers, separate accounts, serviceability, and orders against the installed base
- Anti-pattern: modelling offers in the CRM price book instead of the product catalog