Party, Customer & Account

One person, many roles and accounts: individual, customer, billing account and the subscription on each line — and why one person often ends up as several customer records.

Every later step — the quote, the credit check, the order, the bill, the complaint — hangs off a small set of records about who the customer is. Telcos model these differently from most industries, because the person who pays, the person who uses the line and the place the service is delivered are often not the same. Get this model wrong and every convergent offer, family plan and data-protection request becomes a reconciliation exercise.

The model, from person to line

From a person to the lines they pay for

Party — the person

TMF632

An Individual (or, in B2B, an Organization). Name, identification, contact details. A party exists before it buys anything and can play several roles.

Party role — Customer

TMF669 / TMF629

In TM Forum’s model, Customer is a role a party plays, not a kind of person. The same individual can also be a contact on someone else’s account, or a user of a line they do not pay for.

Account — who pays, how

TMF666

A billing account holds the payment method, bill cycle and balance. One customer can have several, for example one for home broadband and one for mobile.

Product — each subscription

TMF637

Each line or service the customer has is a product instance in product inventory, attached to a billing account and, often, to a different user.

Customer is a role, not a person

The distinction looks academic until a parent pays for a teenager’s line, a customer dies and a relative takes over the account, or a contact on one account becomes a customer in their own right. In each case the person stays the same and only the role changes. A model where “customer” is the person has to copy or merge records to express any of this.

One household, explored

One household with home fibre and two mobile lines on a family plan. Switch views to see the same people as parties, customers, accounts and subscriptions — and then as a legacy estate typically holds them.

Two people, each an Individual party with their own identity and contact details. Neither is a “customer” yet; that is a role.

Ana — Individual

Identity verified (passport)
Email, mobile number
Address: 12 Harbour Road

Ben — Individual

Ana’s son, 16
Mobile number only

Who holds the record

Entity	System of Record	System of Engagement	System of Reference	Notes
Individual (party)	CRM or customer master (MDM)	All channels	Billing, COM	One owner, declared in writing. Other systems hold a reference, not a copy
Customer (party role)	CRM	—	Billing, product inventory	—
Contact details and preferences	CRM	Self-service app, contact centre	—	Marketing consent lives here too (TMF644)
Billing account	Billing	CRM	—	Usually created in billing; CRM shows and requests changes
Subscription (product instance)	Product inventory	—	CRM, billing	What the customer has. Section 4.6 builds on it

Reality: one person, several customer records

Most operators did not build this model once. Prepaid mobile often runs on its own platform, which holds a phone number and little more. Postpaid mobile and home broadband were frequently sold from different CRMs, sometimes inherited through acquisitions. The same person therefore exists as several customer records, with different spellings of their name and address, and nothing reliably linking them.

Convergent offers break first. A discount for having both broadband and mobile depends on knowing the two belong to the same customer. If the link is a manual flag, it is wrong in both directions: some customers miss the discount, others keep it after cancelling.
Data-protection requests become a search. A request to see or delete someone’s data must find every record of them. Without a link between records, that is a manual search across systems.
“Single customer view” projects stall on matching, not screens. Showing one view is easy once the records are linked. Linking them — deciding that two records are the same person — is the work, and it never finishes, because new duplicates arrive every day.

Anti-pattern: no declared customer master

Every system keeps its own customer

CRM, billing and each legacy platform create and update their own customer records, and integrations copy changes between them in whichever direction the last project needed.

Why organisations choose it: it is the default. Each system shipped with its own customer table, and declaring an owner means one team gives up control.
What must hold true for it to work: each customer exists in only one system, or the copies never change.
How it fails: an address changed in the app reaches CRM but not billing; the bill goes to the old address; the customer complains about a change they already made.
Long-term cost: permanent reconciliation jobs, a data-quality team, and a transformation that has to clean customer data before it can migrate anything.

What declaring an owner solves: every other system knows where to read from and where to send changes. What it does not solve: the duplicates already there; those need matching and merging, which is a separate, ongoing piece of work. What it adds: one system on the critical path of every customer change, which must be available whenever any channel is.

TM Forum mapping

TMF632 Party Management — individuals and organisations, their identification and contact media
TMF669 Party Role Management — the roles a party plays
TMF629 Customer Management — the customer role and its characteristics
TMF666 Account Management — billing and other accounts
TMF637 Product Inventory — the subscriptions each account pays for
TMF644 Privacy Management — consent and privacy preferences

Section 4.2 Key Takeaways

A person is a party; customer is a role the party plays; accounts say who pays; product instances say what they have
The payer, the user and the place of service are often different, which is why telcos keep these apart
Legacy estates usually hold one person as several customer records, and convergent offers and data-protection requests expose it first
Declare one owner of the customer record; every other system references it
Anti-pattern: every system keeping and updating its own customer