Customer Lifecycle In Life

After the first order: plan changes, moving home, upgrades, renewals, churn, complaints and consent — and why all of them depend on knowing exactly what the customer already has.

The first order is a small part of a consumer’s life with an operator. Most of the work that follows — changing plan, adding a line, moving home, upgrading a phone, complaining, leaving — is a change to something the customer already has. Every one of those changes depends on one record being right: the installed base, the list of products each customer holds.

The installed base

The installed base is the product inventory (TMF637): one product instance per thing the customer has, linked to the offering it was sold from, the billing account that pays for it, and the services and resources that deliver it. CRM shows it to the agent and the customer; it is not the record. A CRM that keeps its own “assets” list alongside product inventory will, in time, disagree with it.

Asset-based ordering

Changes are ordered against the existing product instance — modify this line, add to this subscription, cease this service — rather than sold as something new. TMF622 expresses this as add, modify and delete actions on items that point at an existing product. It is what lets the network change only what changed, and billing prorate from the right date.

The changes consumers make

Change	What it touches	Where it usually goes wrong
Change plan (up or down)	Modify the product; billing prorates	A downgrade during a minimum term, where the contract rules are not readable by the system taking the order
Add a line or an add-on	Add a product to an existing account	The new line is created as a new customer and loses the family-plan discount
Move home	Cease at the old address, provide at the new one, keep the contract	The new address is not serviceable; or the old service is ceased before the new one works
Upgrade a handset	New device, often a new instalment plan, same line	Eligibility depends on contract end and instalments paid, held in different systems
Port a number in or out	Number portability with another operator	National porting processes have their own timings; a port-out can arrive before CRM knows the customer is leaving
SIM swap	New SIM on the same line	A favourite route for account takeover; identity is re-checked here for that reason
Prepaid to postpaid	Move a line between platforms	Credit and identity checks the prepaid customer never had; balances and numbers to carry across

Renewal, retention and churn

Contract end dates come from the agreement (TMF651), usage from billing and the network, complaints from cases. Retention offers need all three, which is why they are usually built in a marketing or analytics platform and delivered through CRM. The offer itself must exist in the catalog; a retention discount typed in by an agent is revenue that nobody can explain at the next price review.

Complaints and faults

A complaint or a question is a case in CRM, and CRM is its system of record. When the cause is technical — the broadband is down — the case hands over to Trouble-to-Resolve: a trouble ticket (TMF621) that assurance works on, linked to a service problem (TMF656) if the fault is in the network. The customer keeps talking to CRM; the fix happens in assurance. Section 11.1 covers the assurance side.

Marketing preferences and consents belong with the party (TMF644 Privacy Management) and must be honoured by every channel and campaign. Privacy law in many countries also gives customers rights to see and delete their data. Deletion meets other obligations: billing records and some communications data must be kept for set periods by law. Which wins, for which data, is decided per jurisdiction, and the answer has to be built into the systems, not into a procedure.

Reality: customers without lineage

Customers migrated from older systems, or sold before the catalog was catalog-driven, often have products with no link to a current offering, or no product instance at all — only a billing line. For them, asset-based ordering has nothing to point at. The usual workaround is to “re-sell”: cease what they have and order it again as new. It works, at the cost of new contract dates, lost discounts and complaints. These are also the customers who have been with the operator longest.

Anti-pattern: a CRM asset list beside product inventory

CRM keeps its own record of what the customer has

CRM holds an “assets” or “installed products” list, updated from orders it captured, while product inventory is updated by fulfilment.

Why organisations choose it: CRM products ship with an asset object, and agents need to see holdings before product inventory is ready.
What must hold true for it to work: every change goes through CRM, and no order fails or changes after CRM records it.
How it fails: an order completes differently from how it was captured, or a change is made directly in the network or billing; CRM offers changes to products that no longer exist.
Long-term cost: the billing truth, the service truth and the CRM truth diverge, and every in-life order needs a check across all three first.

Section 4.6 Key Takeaways

Most consumer orders are changes to what the customer already has, so the installed base (TMF637) decides whether they work
Order changes against the existing product instance (asset-based ordering), not as new sales
Complaints are cases in CRM; technical faults hand over to Trouble-to-Resolve as tickets
Consent sits with the party; deletion rights meet legal retention duties, decided per jurisdiction
Migrated customers often lack product lineage, which breaks in-life changes for the longest-standing customers