GauravSharma.

Your BSS Transformation Will Fail Unless You Fix Your Business Journeys First

I've watched BSS transformation programs go sideways more times than I'd like to admit. And almost every time, the root cause is the same. The team picked the platform before they understood the business.

Not the business in some abstract strategy-deck sense. I mean the actual, step-by-step journeys that a customer, a retailer, or a call center agent walks through every day. Prepaid activation. SIM swap. Plan transformation. Dunning. Number porting. The stuff that keeps an Telecom service provider running.

When those journeys aren't mapped, documented, and agreed upon before transformation begins, you end up building a system that looks great in a demo and falls apart the moment real operations hit it.

The pattern I keep seeing

Here's how it usually goes. A telecom operator decides to replace their aging BSS. They run an RFP, evaluate three or four vendors, pick one based on feature checklists and pricing, and kick off the project. The implementation team starts configuring modules. Billing, CRM, product catalogue, OCS. Everyone's busy. Timelines are tight.

Six months in, someone from operations asks a simple question: "How does a customer who's been terminated get reactivated?" And nobody in the project room can answer it end to end. The CRM team knows their part. The billing/OCS team knows theirs. But the handoff between them, the notifications, the grace period logic, the outstanding balance check, the status update back to CRM? That lives in tribal knowledge. It was never written down. And the new system has no idea it exists.

This is where projects start bleeding time and money. Not because the technology is wrong, but because nobody forced the hard conversation about how the business actually works before they started configuring how it should work.

Why technology selection is a terrible starting point

Vendor demos are seductive. You see a clean UI, pre-built workflows, a catalogue that auto-provisions in seconds. It looks like the answer. But a demo environment has maybe five or six journeys configured, all running on clean data with no edge cases.

A real telecom service provider operates 25 to 35 distinct business journeys, sometimes more. Prepaid alone might have 15 to 20 if you count activations, top-ups, balance transfers, plan changes, SIM replacements, number porting, suspension, reactivation, and the various flavours of barring and unbarring. Postpaid adds bill disputes, dunning sequences, credit limit adjustments, and contract renewals.

Each of those journeys touches multiple BSS modules. A single prepaid activation might flow through your digital channel, hit the product catalogue, trigger provisioning, set up the subscriber profile in OCS, initialise a wallet, and fire a welcome notification. If any of those handoffs are wrong or missing, the customer either can't activate or activates into a broken state.

When you select technology first, you're essentially choosing an answer before you've finished writing the question. The inevitable result is that you discover gaps during UAT, which is the most expensive possible time to find them.

What "journey-first" actually means in practice

Journey-first doesn't mean drawing some high-level process maps and filing them in a SharePoint folder. I mean something more specific and more useful.

For every business journey your telecom service provider supports, you need four things documented before the transformation project starts configuring anything.

First, the end-to-end flow. Not just "customer activates SIM" but every system interaction, every API call, every status change, every notification. Who initiates it. What validates it. What happens when it fails. This is the call flow, and it needs to be detailed enough that a developer who's never seen your business can follow it.

Second, the business rules. What's the grace period after a payment fails? Can a barred customer still receive calls? Is a SIM swap allowed while a number port is in progress? These rules are almost never in a single document. They're scattered across policy memos, helpdesk scripts, and the heads of people who've been around for a decade. Getting them out and onto paper is uncomfortable, slow work. It's also the most valuable thing you can do before spending a single dollar on configuration.

Third, the exception paths. The happy path is easy. Every vendor can demo the happy path. What matters is what happens when the top-up gateway times out, or the MNP request gets rejected, or the eSIM profile download fails mid-provisioning. These exception scenarios cause the majority of post-go-live support tickets and the bulk of customer complaints. If your transformation doesn't account for them, you've migrated the happy path and left operations to figure out the rest.

Fourth, testable acceptance criteria. Every journey needs clear, scenario-based test cases: positive ones that prove the journey works, and negative ones that prove it fails gracefully. If you can't test it, you can't sign off on it. And if you can't sign off on it, you're going live on faith.

The real cost of skipping this

I worked closely with many telecom service providers that were into a BSS replacement. CRM, Billing and OCS were configured. Integrations were built. UAT had started. And then a tester raised a defect: the dunning workflow wasn't matching production behaviour. When someone actually went and documented the existing process, it turned out there were 11 distinct steps that varied by customer segment, payment method, and contract type. The new system had three. Nobody had checked.

Fixing it took four months and blew the budget badly enough that the project nearly got cancelled. Four months of rework. Three weeks of documentation effort if someone had done it at the start. That ratio still bothers me.

That's not an unusual story. In my experience, transformation projects that skip journey mapping spend 30 to 40 percent of their total timeline on rework that was avoidable. The time you "save" by jumping straight to implementation, you pay back double in UAT fixes, go-live patches, and post-launch firefighting.

Journey mapping also exposes what you should stop doing

One side benefit that catches people off guard: when you actually sit down and map every business journey, you find processes that shouldn't exist. Workarounds that were built to compensate for limitations in the old system. Manual steps that someone added eight years ago because of a bug that was fixed five years ago. Approval chains that serve no purpose except to slow things down.

Transformation is the one time you have permission to question everything. But you can only exercise that permission if you've laid out what "everything" actually is. Without a complete journey inventory, you'll faithfully replicate broken processes in a new system, which is an expensive way to change nothing.

How I approach it

When I work with operators on BSS transformations, the first thing we do is build what I call the Journey Baseline. It's a document, not a slide deck. It covers every business journey the operator runs, organised by domain: prepaid, postpaid, retail, customer service. For each journey, we produce a detailed write-up, a call flow diagram showing the system interactions, and a set of UAT test cases.

The document becomes the single source of truth for the transformation. When the implementation team asks "how should dunning work?", the answer is in the baseline, not in someone's memory. When UAT testers need scenarios, they're pre-written. When disputes arise between business and IT about expected behaviour, there's a reference point that both sides agreed to.

This isn't theoretical. I've documented 32 business journeys across prepaid and postpaid for a telecom service provider engagement, with 320 UAT test cases and call flow diagrams for every one of them. That baseline became the foundation for the entire platform evaluation and implementation plan. Nothing got configured until the journeys were reviewed and approved.

The uncomfortable truth

Journey mapping is slow. It requires pulling busy people into workshops. It surfaces disagreements about how things should work. It forces decisions that teams have been deferring for years. Nobody enjoys it while it's happening.

But here's what I keep coming back to: every BSS transformation that I've seen succeed had this work done upfront. And every one that spiralled had skipped it or done it superficially. The technology matters. I'm not arguing otherwise. But technology is the second decision, not the first. The first decision is whether you're willing to do the unglamorous, detail-heavy work of understanding your own business well enough to explain it to a new system.

If you're about to start a BSS transformation, or you're stuck in the middle of one that's drifting, try this: ask anyone on your project team to walk you through the full dunning journey, or the MNP journey, end to end, across every system. Not the happy path. The real one, with exceptions.

If they can't, that's your answer. The platform isn't the problem yet. The preparation is.

I've sat through a lot of BSS vendor demos. Billing gets a full session. OCS gets another — real-time charging, policy control, spending limits. The product catalogue team brings slides. Sometimes there's a dedicated deep dive on mediation.

Campaign Management usually gets twenty minutes at the end, when everyone's tired. The vendor shows a drag-and-drop interface, clicks through a few offer templates, says something about personalized customer engagement. Heads nod. Nobody asks hard questions.

I want to talk about why that matters.

This module sits at the intersection of every commercially important thing your BSS does — pricing, customer lifecycle, retention, offer eligibility, revenue recovery. Most operators treat it like a tool for sending promotional SMS. It's not. Configured properly, it's how you keep customers from leaving, how you recover subscribers who've stopped recharging, how you move prepaid customers into higher-value segments. When it's under-configured, you lose revenue every day and the dashboard doesn't show you where.

What operators think it does

The standard assumption is that Campaign Management handles batch messaging. You upload a list, attach a message, schedule a send. Marketing uses it. The BSS team ignores it.

That assumption leaves most of the module's value sitting idle.

Campaign Management Is the Most Undervalued Module in Your BSS Stack

I've sat through a lot of BSS vendor demos. Billing gets a full session. OCS gets another — real-time charging, policy control, spending limits. The product catalogue team brings slides. Sometimes there's a dedicated deep dive on mediation.

Campaign Management usually gets twenty minutes at the end, when everyone's tired. The vendor shows a drag-and-drop interface, clicks through a few offer templates, says something about personalized customer engagement. Heads nod. Nobody asks hard questions.

I want to talk about why that matters.

This module sits at the intersection of every commercially important thing your BSS does — pricing, customer lifecycle, retention, offer eligibility, revenue recovery. Most operators treat it like a tool for sending promotional SMS. It's not. Configured properly, it's how you keep customers from leaving, how you recover subscribers who've stopped recharging, how you move prepaid customers into higher-value segments. When it's under-configured, you lose revenue every day and the dashboard doesn't show you where.

What operators think it does

The standard assumption is that Campaign Management handles batch messaging. You upload a list, attach a message, schedule a send. Marketing uses it. The BSS team ignores it.

That assumption leaves most of the module's value sitting idle.

A proper implementation — using something like CRM and Product Catalog working together — runs lifecycle-triggered campaigns in real time. Not weekly batch jobs. Not manual lists. Event-driven logic that monitors subscriber behaviour and responds: a prepaid customer whose balance drops below a threshold gets a targeted top-up offer within seconds. A postpaid customer who's been on the same plan for three years gets an upgrade path before a competitor does. A subscriber who hasn't recharged in 12 days gets a winback sequence calibrated to their history, not a generic promotional SMS that treats them the same as someone who recharged yesterday.

This requires real time integration between Campaign Management, the OCS/rating engine, the product catalogue and CRM. In most implementations I've reviewed, those connections exist in theory and are half built-in practice. So, you have a module that can technically execute all of this but in operation fires messages that customers delete without reading.

The journey problem no one talks about

Campaign logic can't be configured in isolation. It depends on decisions that were supposed to be made earlier in the transformation — and usually weren't.

Think about what a winback campaign actually requires. You need to know what triggers "at risk" status for a subscriber. Is it zero recharge in 10 days? 15? Does it vary by segment? You need to know what offer is eligible at that moment, which means product catalogue eligibility rules have to exist before campaign logic can reference them. You need rules about subscribers already in an active retention flow, so you don't send competing messages to the same person. You need a defined success metric and a way for the system to record it.

None of that is a Campaign Management question on its own. It's a business journey. And if you haven't mapped that journey across every system and every status transition, you can't configure the campaign correctly. What you end up with is a module that's live, technically ticked off the go-live checklist and commercially inert.

The pattern I keep seeing: an operator launches a new BSS, Campaign Management is configured in the final weeks because it wasn't on the critical path, the setup is essentially templates and segment lists and six months later someone in commercial asks why churn hasn't shifted. The answer is a module that nobody owns and no one fully understood when it was built.

Who actually owns this thing

That ownership gap is its own problem. Campaign Management doesn't have a natural home in most operator org structures.

Marketing wants to use it but doesn't understand the BSS dependencies underneath. The BSS team built it but considers it as a marketing responsibility. Product owns some of the offer logic but isn't in the room where campaigns are configured. Customer operations have strong views on retention journeys but rarely get consulted.

The result is a module everyone touches partially and nobody understands fully. Campaigns get created in silos. Eligibility rules get manually overridden because someone doesn't trust the system logic. Reporting is inconsistent because three teams measure campaign success differently and none of them talk to each other.

You can't always fix this with a reorganization. But you can document the journeys that Campaign Management is supposed to execute, get agreement across all the stakeholders who touch it and build configuration that reflects those agreements. It requires the same journey-first thinking I'd apply to any other part of a BSS transformation. It almost never gets applied here because Campaign Management isn't treated as transformation critical.

A practical test

Pick one campaign running in production right now — a winback sequence, a retention offer, a recharge promotion. Then trace it properly: what triggers it, what eligibility check runs before the message sends, how the offer is sourced, what happens when a customer responds, how the outcome gets recorded, and who reviews that data.

If you can answer that end to end with confidence, your Campaign Management setup is in reasonable shape. If the answer involves "I think marketing manages that" or "we use a segment file that comes weekly," you're leaving revenue on the table and you probably don't know the number.

Twenty minutes at the end of a demo was never the right amount of time for a module that touches every commercial outcome your operator cares about.

Every telecom conference I've attended in the past two years has had the same energy. AI is going to predict churn. AI is going to optimise network slicing. AI is going to personalise offers in real time. AI is going to automate the contact centre.

Fine. But I have a question that tends to kill the mood: where's the data coming from?

Because in most telecom operators I've worked with, the answer is uncomfortable. Customer data sits in CRM. Usage data sits in the OCS. Billing records live in a separate system. Product definitions exist in the catalogue but don't always match what's actually provisioned. And the CDRs that feed mediation don't reconcile cleanly with what billing says the customer consumed.

You can't build intelligence on top of that. You can build dashboards, maybe. You can build reports that look plausible. But actual AI, the kind that makes decisions or triggers automated actions, needs data that is consistent, connected, and trustworthy. Most operators aren't there yet. And pretending otherwise is how you end up with expensive AI pilots that quietly get shelved after six months.

The five-system problem

I call it the five-system problem because that's roughly how many places a typical telecom operator stores information about a single customer. CRM has the profile and contact history. The OCS has the real-time balance, active offers, and usage counters. Billing has the invoice records, payment history, and dunning status. The product catalogue has what the customer should be subscribed to. And the provisioning layer has what's actually active on the network.

In theory, these systems sync. In practice, they drift. A customer changes their plan through the self-care portal, and the catalogue updates, but the provisioning layer takes 48 hours to catch up. Or a payment comes in, but the OCS doesn't clear the bar status because the integration between billing and charging has a known lag. Or the CRM shows a customer as "active" while the network has already deactivated them because the grace period expired on a different clock.

These aren't hypothetical edge cases. They're Tuesday. Every operator I've worked with has some version of this data fragmentation, and most have learned to live with it. The problem is that AI can't learn to live with it. A churn prediction model trained on CRM data that doesn't reflect actual usage patterns will predict the wrong customers. A personalisation engine pulling offers from a catalogue that doesn't match provisioned services will recommend things the customer already has, or can't use. A revenue assurance algorithm comparing billing and mediation records that were never properly reconciled will flag thousands of false positives and nobody will trust it after the first week.

Why this is a BSS problem, not an IT problem

It's tempting to frame data quality as an IT issue. Get the DBAs involved. Run some ETL jobs. Build a data lake. But in telecom, the data mess is a BSS architecture problem. It's structural.

When BSS platforms were built 10 or 15 years ago, they were designed for a specific set of workflows: activate a SIM, rate a call, generate a bill, handle a complaint. Each module optimised for its own job. CRM was built to manage customer interactions. OCS was built to do real-time charging. Billing was built to produce invoices. They were never designed to share a single, coherent view of the customer, because nobody needed them to. A customer service agent could pull up the CRM, check the billing screen, and piece the picture together manually.

AI doesn't have a customer service agent's patience. It needs one truth, not five versions of it. And most BSS stacks don't provide that.

This is why I get sceptical when vendors pitch "AI-powered BSS" as an overlay. You can't bolt intelligence onto fragmentation. The AI layer will only be as good as the data layer underneath it, and if that data layer is a patchwork of batch syncs, stale caches, and manual reconciliation, the AI will produce confident-sounding nonsense.

The data problems I see most often

I'll name the ones I run into repeatedly when operators try to operationalise AI.

Duplicate customer records. CRM systems that have been running for a decade without proper deduplication end up with the same customer appearing two, three, sometimes four times under slightly different names, numbers, or ID formats. Any analytics built on that data will overcount, misattribute, and confuse the model.

Inconsistent product definitions. The product catalogue says "30GB Data Plan with Unlimited Calls." The OCS has it configured as two separate components: a data bucket and a voice bucket. Billing invoices it as a single line item with a different internal code. When you try to answer "what product is this customer on?", you get three different answers depending on which system you ask.

Telecom Operators Don't Have an AI Problem. They Have a Data Problem.

Every telecom conference I've attended in the past two years has had the same energy. AI is going to predict churn. AI is going to optimise network slicing. AI is going to personalise offers in real time. AI is going to automate the contact centre.

Fine. But I have a question that tends to kill the mood: where's the data coming from?

Because in most telecom operators I've worked with, the answer is uncomfortable. Customer data sits in CRM. Usage data sits in the OCS. Billing records live in a separate system. Product definitions exist in the catalogue but don't always match what's actually provisioned. And the CDRs that feed mediation don't reconcile cleanly with what billing says the customer consumed.

You can't build intelligence on top of that. You can build dashboards, maybe. You can build reports that look plausible. But actual AI, the kind that makes decisions or triggers automated actions, needs data that is consistent, connected, and trustworthy. Most operators aren't there yet. And pretending otherwise is how you end up with expensive AI pilots that quietly get shelved after six months.

The five-system problem

I call it the five-system problem because that's roughly how many places a typical telecom operator stores information about a single customer. CRM has the profile and contact history. The OCS has the real-time balance, active offers, and usage counters. Billing has the invoice records, payment history, and dunning status. The product catalogue has what the customer should be subscribed to. And the provisioning layer has what's actually active on the network.

In theory, these systems sync. In practice, they drift. A customer changes their plan through the self-care portal, and the catalogue updates, but the provisioning layer takes 48 hours to catch up. Or a payment comes in, but the OCS doesn't clear the bar status because the integration between billing and charging has a known lag. Or the CRM shows a customer as "active" while the network has already deactivated them because the grace period expired on a different clock.

These aren't hypothetical edge cases. They're Tuesday. Every operator I've worked with has some version of this data fragmentation, and most have learned to live with it. The problem is that AI can't learn to live with it. A churn prediction model trained on CRM data that doesn't reflect actual usage patterns will predict the wrong customers. A personalisation engine pulling offers from a catalogue that doesn't match provisioned services will recommend things the customer already has, or can't use. A revenue assurance algorithm comparing billing and mediation records that were never properly reconciled will flag thousands of false positives and nobody will trust it after the first week.

Why this is a BSS problem, not an IT problem

It's tempting to frame data quality as an IT issue. Get the DBAs involved. Run some ETL jobs. Build a data lake. But in telecom, the data mess is a BSS architecture problem. It's structural.

When BSS platforms were built 10 or 15 years ago, they were designed for a specific set of workflows: activate a SIM, rate a call, generate a bill, handle a complaint. Each module optimised for its own job. CRM was built to manage customer interactions. OCS was built to do real-time charging. Billing was built to produce invoices. They were never designed to share a single, coherent view of the customer, because nobody needed them to. A customer service agent could pull up the CRM, check the billing screen, and piece the picture together manually.

AI doesn't have a customer service agent's patience. It needs one truth, not five versions of it. And most BSS stacks don't provide that.

This is why I get sceptical when vendors pitch "AI-powered BSS" as an overlay. You can't bolt intelligence onto fragmentation. The AI layer will only be as good as the data layer underneath it, and if that data layer is a patchwork of batch syncs, stale caches, and manual reconciliation, the AI will produce confident-sounding nonsense.

The data problems I see most often

I'll name the ones I run into repeatedly when operators try to operationalise AI.

Duplicate customer records. CRM systems that have been running for a decade without proper deduplication end up with the same customer appearing two, three, sometimes four times under slightly different names, numbers, or ID formats. Any analytics built on that data will overcount, misattribute, and confuse the model.

Inconsistent product definitions. The product catalogue says "30GB Data Plan with Unlimited Calls." The OCS has it configured as two separate components: a data bucket and a voice bucket. Billing invoices it as a single line item with a different internal code. When you try to answer "what product is this customer on?", you get three different answers depending on which system you ask.

Missing or delayed event data. AI use cases like real-time offer personalisation depend on knowing what the customer just did. But if the event data pipeline has a 15-minute lag, or drops events during peak hours, the "real-time" promise collapses. I've seen operators where CDR delivery to the analytics layer was running six to eight hours behind during busy periods. Nobody noticed until they tried to trigger a contextual offer and it arrived the next morning.

No single subscriber timeline. To understand a customer's behaviour, you need to see their journey: when they activated, what they bought, when they called support, what their usage pattern looks like, when they were barred, when they paid. In most operators, assembling that timeline requires pulling from four or five systems manually. No unified event log exists. Without it, any "360-degree customer view" is marketing fiction.

What to fix before you fund an AI initiative

If I were advising a telecom operator's CTO on AI readiness (and I have, more than once), I wouldn't start with model selection or vendor evaluation. I'd start with four questions.

Can you produce a single, accurate subscriber record that every system agrees on? If CRM, OCS, billing, and provisioning show different statuses, products, or balances for the same customer, that's your first problem. Solve the identity and reconciliation layer before you do anything else.

Are your event pipelines real-time and reliable? Check your CDR flow, your notification triggers, your usage event streaming. If there are gaps, lags, or dropped events, no real-time AI use case will work. It doesn't matter how good the model is if it's making decisions on stale data.

Is your product catalogue the source of truth, or just one of several opinions? If what's in the catalogue doesn't match what's provisioned, what's billed, and what the customer sees in self-care, you have a catalogue integrity problem. Fix that before you try to automate offer management.

Do you have a data governance owner, or just data? Someone needs to own the definition of "active subscriber," "churn event," "revenue per user." If those definitions vary by department, your AI will inherit the confusion.

None of this is glamorous. None of it will generate a press release. But it's the work that determines whether your AI investment produces value or produces noise.

The uncomfortable sequencing question

Here's what makes this politically difficult inside an operator. The board wants AI. The CEO read a McKinsey report. The vendor is showing demos with impressive dashboards. And the person who has to stand up and say "our data isn't ready" looks like they're blocking progress.

But it's true more often than it isn't. IDC's 2025 telco transformation survey found that the biggest barriers to autonomous network operations were interoperability failures and the lack of a single source of truth in network data. Not a lack of AI models. Not a lack of ambition. Bad data.

PwC put it well when they pointed out that AI agents perform far better when they sit on top of a simplified, modern digital core with consistent data foundations. The implication is clear: if your core is messy, your agents will be too.

I'm not saying operators should finish some five-year data cleansing programme before they touch AI. That's impractical. But the sequencing matters. Pick one use case. Map every data dependency for that use case. Fix the data flows for that scope. Prove value. Then expand. Don't try to build a churn model on data you haven't validated and call it transformation.

What this means for BSS transformation programmes

If you're mid-transformation or planning one, build data quality into the programme from the start. Not as an afterthought. Not as a Phase 3 activity. From sprint one.

Define a canonical subscriber model that all BSS modules will share. Agree on the master source for each data entity: who owns the customer record, who owns the product truth, who owns the balance of record. Build reconciliation checks into every integration. Test data consistency as aggressively as you test functionality.

Because in two or three years, when the AI use cases are mature enough to deploy at scale, you'll either have a data foundation that supports them or you'll be back to square one, running another expensive pilot that produces outputs nobody trusts.

The operators who get AI right won't be the ones who adopted it first. They'll be the ones who fixed their data first. That's less exciting than a demo, I know. But it's what actually works.

© 2026 Copyright