Household and lifecycle offers rarely fail on ideas. They fail on identity, shared counters, and data freshness.
Why household offers are harder than they look
On a whiteboard, the idea takes five minutes. Reward loyal, converged households before a competitor does: say, households with more than five years of tenure and less than 80% of their combined monthly allowance used get a 72-hour premium data pass — or a variant where the discount on extra usage scales with the household’s combined tenure or spend.
Commercially it is sound. Converged households churn less, and rewarding headroom rather than overage feels generous instead of punitive. Yet offers like this stall in delivery far more often than slice deals do, and the reason is rarely the promotion logic itself.
It is the plumbing underneath: who exactly counts as “the household,” where the combined usage number comes from, and how fresh it is at the moment a price decision is made. This is not a 5G problem. It is an identity, shared-state, and rating problem — and it deserves to be designed as one.
A customer, an account, and a household are not always the same entity
BSS platforms model customers, accounts, and subscriptions. A customer is a person or organization. An account is a billing relationship. A subscription is a service instance. A household is usually none of these.
It is an approximation assembled from account hierarchies, shared addresses, family plans, or payer relationships. After a merger or two, the two mobile lines, the broadband, and the TV service of one family can easily sit in different accounts or even different systems.
So the first design decision is definitional, and it is the backbone of everything downstream: what, operationally, is a household? A billing hierarchy under one payer? A declared group the customer manages? An address-matched inference?
Each answer has different coverage, different error modes, and different maintenance costs. Pick deliberately, because an offer built on a fuzzy household definition will compute precise numbers about the wrong group of people.
Where lifecycle and usage data come from
The inputs to a household offer live in different places and move at different speeds.
Tenure and lifecycle state come from the CRM and contract records: start dates, renewals, and win-back history. These are near-static. They change on the scale of months.
Usage is the opposite. It originates in charging and mediation, per service: real-time for online-charged mobile services, often batch-delivered for broadband or TV. Discount and benefit state — which promotions the household already enjoys — lives in the catalog and billing.
The distinction that matters for design is static attribute versus live state. Tenure can be read once and cached for a month without harm. A consumption threshold cannot; it moves all day. Offers that mix the two need an architecture that respects both speeds.
Why a CRM field alone is not enough
A tempting shortcut is to let a nightly job compute an eligible_for_promo flag on the customer record and have rating read the flag. It works — right up until the eligibility condition involves live consumption.
The 80%-of-allowance threshold changes during the day. A flag computed at 02:00 can be wrong by lunchtime, which produces the worst kind of customer experience: a “you qualify” message for a household that has already crossed the line, or a benefit that fails to trigger for one that just dropped below it.
Stale flags also multiply — one per campaign — until the CRM quietly becomes a second, undocumented rating engine. The healthier pattern is for rating to evaluate the condition at decision time, against attributes and counters it can read directly.
That, in turn, raises the practical question: how do you keep a combined, cross-service number that rating can actually trust?
How shared usage counters work across services
A shared counter, or shared balance, is an object that multiple subscriptions contribute to and that rating rules can read. Getting one right involves four ingredients.
Four design ingredients
- Identity linkage: the household definition decides which subscriptions feed the counter.
- Contribution rules: the design decides what counts: all data, only domestic usage, or only certain services.
- Cycle alignment: the members’ billing cycles may not coincide, so “this month’s combined usage” needs an explicit anchor, typically the payer’s cycle.
- Concurrency: several sessions update the counter at once, and rating must read a consistent value.
Freshness is the honest trade-off
A blended household counter is only as fresh as its slowest input. If mobile usage streams in real time but broadband usage arrives once a day, the combined number has daily granularity, whatever the dashboard implies.
That is not a flaw to hide but a parameter to design around. Either the eligibility condition tolerates the lag, such as a threshold checked near cycle end, or the offer is scoped to real-time sources only. Stating the freshness SLA explicitly is what separates a promotion that behaves predictably from one that generates complaint tickets.
Combining customer attributes and usage state in rating
With the definitions and counters in place, the rating layer is where the offer finally becomes simple again.
In Tridens Monetization, rating rules can reference customer, account, and subscription attributes — including custom fields such as a tenure band or a household group identifier — together with shared balances and counters that accumulate across services, and the fields carried in the charging event itself.
A condition like tenure ≥ 5 years AND household counter < 80% of combined allowance is then one rule combining a static attribute with live state, configured in the product catalog rather than coded. The outcome can take whichever commercial shape the campaign calls for: a price modifier on extra usage, a bonus allocation into the shared balance, or the activation of a time-boxed pass.
Because charging and billing are converged in the platform, the same logic flows through to invoices and customer communications without reconciliation between systems.
Example: a retention offer for a converged household
Put the pieces together for the whiteboard offer.
The household is defined as the billing hierarchy under one payer: two mobile subscriptions, home broadband, and TV. The shared counter aggregates the two mobile lines in real time and broadband with daily delivery, anchored to the payer’s billing cycle. TV is excluded from the counter but its presence contributes to the “converged” qualification.
Tenure is computed as the earliest start date among active services — a custom attribute refreshed monthly. In the final week of the cycle, rating evaluates the condition. Qualifying households receive the 72-hour premium pass, activated as a plan change and announced through the CVM channel.
Because broadband data is daily, the threshold check is scheduled after the nightly feed — a small design choice that makes the promise reliable.
Privacy belongs in the design review
One more ingredient belongs in the design review rather than the fine print: privacy. Combining several individuals’ usage into a household view is processing of personal data across persons. That calls for a clear lawful basis, transparency about what is combined, and care in presentation — a qualification banner should not reveal one member’s consumption to another who has no business seeing it.
Working with aggregates, minimizing what any interface exposes, and involving your privacy team early keeps a well-meant loyalty offer from becoming a complaint of a different kind. This is a design consideration, not legal advice. Review the specifics with your DPO.
Ready to get started?
See how Tridens Monetization connects customer attributes, usage state, rating, and billing.
From isolated promotions to reusable decision logic
A promotion hard-wired end to end dies with its campaign. Modeled as attributes, shared counters, and rating rules, it leaves building blocks behind: the next campaign changes thresholds and rewards, not plumbing.
The household group, the combined counter, and the tenure band become part of the platform’s vocabulary — reusable in a winter data promo, a broadband upgrade nudge, or a save-desk offer, each a configuration exercise.
Two cautions keep the picture honest
Charging cannot repair identity data quality. If household linkage is wrong, every downstream number is confidently wrong, so CRM hygiene is a prerequisite, not a nice-to-have.
And as in Part 1, the boundary is worth naming: rating decides prices and benefits; campaign orchestration, consent management, and channel delivery remain their own disciplines.
Across both articles the principle is the same: pricing agility is set by what your rating layer can reference. In the enterprise slice story, that meant network context mapped into commercial terms. Here, it means identity and shared state made available to a rule. Different offers, same foundation.
If a household or lifecycle offer on your roadmap keeps stalling in delivery, Tridens can walk through the counter and identity design with you.
FAQ about shared usage counters
Shared usage counters FAQ
What is a shared usage counter?
A shared usage counter is an object that multiple subscriptions contribute to and that rating rules can read, such as the combined monthly data usage of all members of a household group.
Why not compute eligibility in the CRM or campaign tool?
Precomputed flags go stale when a condition involves live consumption. Evaluating conditions at decision time against attributes and counters keeps behavior more predictable and auditable.
How fresh can household usage data realistically be?
It is as fresh as the slowest contributing source. Real-time mobile usage combined with daily broadband feeds yields a counter with daily granularity.
Do providers need consent to combine household members' data?
Combining individuals’ usage into a household view is cross-person processing of personal data. It requires a lawful basis, transparency, and careful presentation, with privacy and legal teams involved early.
