Price plan factory: how to launch tariffs faster without billing chaos

The story of one launch

Marketing came up with a tariff. The concept is attractive, the audience is clear, a competitor just released something similar and obviously needs a response. The team gathers, builds a deck, sets a target of “in market in 6 weeks”.

Then the typical story unfolds. Billing says: this combination of packages is not in the existing catalogue, the rating rules need changing, that is a release with an 8-week queue. CRM says: a new product type has to be added, change request, another 4 weeks of testing. Dealer system: new fields needed, release in a month. The app: new card, design plus dev plus QA, 5-6 weeks. Finance: new revenue accounts to agree with the auditor.

By the time all approvals are in place, three months have passed. The competitor is already retiring its response, the market has moved, and the tariff coming out now is a solution for last quarter’s situation. Marketing gets a result far below expectations and blames “the slow systems”.

This pattern repeats at most operators in the region. The issue is not the speed of individual teams — each works within its constraints. The issue is that a tariff structurally requires coordination across 4-6 systems, and there is no shared layer that can absorb a new product as a whole and propagate it across systems automatically.

Where the time is lost

If the typical path from a tariff concept to its availability is decomposed, three bottlenecks stand out.

First — no single product definition. Marketing describes the tariff in Word or PowerPoint. Billing translates that into rating rules. CRM into its product entity. The app into UI. Finance into accounts. Each team translates from text to its own configuration manually, and that is the main source of delays, errors and discrepancies.

Second — each system has its own release cycle. Billing releases every 4-8 weeks in large batches. CRM has its own cycle. The app has store-release timing. If those cycles are not synchronised, the tariff waits for the slowest system.

Third — no test environment for a new tariff before it is approved. The idea travels through long preparations before anyone actually checks that it can technically be assembled. By the time “we cannot” is discovered, weeks of approvals are already spent.

What “product catalog” means as a solution

The idea is simple. There must be a single layer in which the tariff is defined once, machine-readable, with all attributes — packages, limits, rating rules, eligibility, validity period, prices, discounts, UI metadata. This layer is the source of truth for every consumer: billing, CRM, app, dealer system, finance.

When marketing describes a new tariff, it is described in the catalog. All downstream systems pick it up automatically — through API or event stream. Billing loads the rating rules and applies them without a separate release. CRM creates the right entity. The app gets the card definition through API.

This changes the launch economics. The tariff goes through “define — test — launch” inside one system, not through “approve — distribute to 5 systems — collect feedback — sync releases”.

Why product catalog often does not get built

Several typical reasons.

Billing considers catalog its internal system. Some catalog logic does live in billing. But if catalog is bounded by billing, downstream systems do not get definitions automatically. A real catalog has to live separately or be architecturally extracted.

The catalog project looks large — a year of work, serious investment in architecture and integrations. Boards do not love big projects with long time-to-value, and the project gets pushed in favour of “more urgent” initiatives.

The CRM vendor, the billing vendor and the app vendor each propose their catalog. Picking any one of them as the hub means losing vendor neutrality, and a vendor change (a normal story over 5-7 years) becomes very painful.

The catalog needs discipline in the product team — describing tariffs structurally, not in free form. That is a skill change, and the team resists.

What a working catalog covers

A real product catalog in telecom covers several layers.

Base components. Minutes, gigabytes, SMS, services (roaming, messengers, content). Each component has attributes — unit, volume, price per unit, limits, period.

Packages. Compositions of components with a package price, validity period, activation conditions.

Tariffs and tariff plans. Bundles of packages with rules for how they apply.

Eligibility rules. Who is allowed which tariff — by segment, region, status, previous tariff.

Lifecycle rules. What happens at activation, expiry, low balance, upgrade.

Promo and discount rules. Temporary price modifications, conditions, periods.

UI metadata. Description for the dealer, description for the customer in the app, marketing wrapper.

If each of these elements exists in a unified form and is propagated downstream, launching a new tariff becomes a configuration change, not a multi-system release.

A realistic build roadmap

Catalog cannot be built in a quarter. The realistic path looks like this.

Months 1-3. Foundation. Audit existing tariff definitions in each system. Describe the target catalog model. Pick the architectural approach — a separate service, integrated into billing with an external API, hybrid.

Months 4-9. Build the core catalog. The catalog service. Integration with billing on rating rules. Integration with CRM on product entities.

Months 10-15. Downstream propagation. Integration with the app, dealer system, finance entities.

Months 16-18. Migration of existing tariffs into the catalog. A painful step — many historical tariffs have peculiarities.

Months 19-24. Operating model. The product catalog team as a separate function. Discipline of describing new tariffs. Decommission of legacy approval channels.

By two years in the operator has a working catalog. Time-to-launch for a new tariff is not three months but 2-3 weeks on average, days for simple cases.

When not to start the catalog project

If the organisation is in an acute phase of billing or CRM rebuild, adding catalog overburdens the roadmap. Core stability first, catalog second.

If product is not a function at all (tariffs are invented by marketing and go straight to delivery), the product owner role has to be created first, then catalog.

If the RFP for catalog cannot define ownership — billing, IT or product — the project will get stuck in political disputes.

If a vendor-specific catalog is selected without real assessment, migration starts in 3-5 years and the investment resets.

If the board is not ready to commit to an 18-24 month investment period, the catalog project will collapse into a quick win that does not solve the problem.

Discussion points for the committee

How long does it take from tariff approval to availability in market today? If hard to answer or above 2 months, the catalog has ROI.

How many tariffs are in the catalog and how many actively sell? If the catalog has grown into hundreds with low active share, rationalisation is needed.

Who owns the catalog as an entity? If there is no answer, the function does not exist.

What is the country strategy on vendor catalog versus neutral catalog? It affects the 5-7 year horizon.

Is the organisation ready for an 18-24 month rebuild without a visible quick win in the first 6 months? Without that readiness, the catalog dies in the foundation phase.

How SamaraliSoft can help

Product Catalog Architecture — analysis of the current state (where tariff definitions live now, what delays and losses exist), target catalog model with architectural trade-offs, build/buy/integrate selection, migration roadmap, and a 90-120 day pilot on one tariff product line.

Related reading

• /en/architecture/telecom-around-core-architecture/ — layer around BSS/OSS
• /en/insights/telecom-subscriber-intelligence-operating-model/ — operating model
• /en/insights/telecom-arpu-bundles-devices/ — where ARPU grows
• /en/insights/telecom-growth-after-connectivity/ — growth beyond connectivity

Sources

• Ministry of Digital Technologies — telecom infrastructure UZ
• Digital Government Portal — internet usage UZ
• UzDaily — telecom market
• MNP.UZ — number portability