Every vendor briefing I sit through these days opens with a GenAI slide, and every operator conversation I have ends with some version of the same question: “okay, but is anyone actually running this in production, or are we all still doing demos?”
That’s the honest starting point for this thread. Not another explainer on what generative AI could do for OSS/BSS. We’ve all read that piece a dozen times. What I want to get into — and what I’m hoping this community can help fill in — is the gap between the GenAI telecom deployment experience vendors pitch in a briefing room and what actually survives contact with a real production environment: legacy charging systems, messy subscriber data, change-control boards, and a NOC team that’s already stretched thin.
Why “Pilot Purgatory” Is the Default Outcome, Not the Exception
If you’ve been part of an AI pilot in the last two years, you already know the pattern. Someone stands up a GenAI copilot against a sandboxed subset of tickets, it performs beautifully on curated test cases, everyone screenshots the demo for the steering committee, and then it quietly stalls before it ever touches live traffic. Industry estimates put the share of AI pilots in telecom that never scale beyond proof of concept at around 95%, and that number aligns with what I’ve seen and heard directly from operators.
The reasons are rarely about the model itself. They’re almost always about what’s underneath it. Most GenAI initiatives stall because they get treated as isolated side projects — piecemeal use cases, vague success metrics, and no real ownership handoff into operations once the lab work is done. That tracks with the OSS/BSS reality most of us deal with day to day: your billing data lives in one silo, your CRM history in another, your network events somewhere else entirely, and no LLM fixes that fragmentation on its own.
Where GenAI Is Actually Landing in Production
To be fair, it’s not all vaporware. A few use cases keep coming up as genuinely operational rather than aspirational:
-
Billing dispute triage — reading a dispute ticket, reconciling it against actual charging events, and either auto-resolving it or handing the agent a summary instead of a blank investigation.
-
Fraud and revenue leakage detection — scanning usage and charging data for anomalies human analysts wouldn’t catch in time, like mismatched rating or suspicious top-up patterns.
-
Contact center context assembly — surfacing the likely reason for a call, recent billing events, and a recommended resolution before the agent even picks up, instead of having them click through five systems while the subscriber waits.
-
Catalog and offer configuration — turning a plain-English product description into the eligibility rules and billing logic a BSS actually needs, cutting weeks out of product marketing cycles.
That BSS-workflow angle is worth dwelling on for a second, because it’s where a lot of the practical engineering decisions get made. Operators evaluating where to embed this kind of automation often end up comparing platforms like Amdocs, MATRIXX Software, Optiva, Telgoo5, or TelcoEdge Inc, depending on whether they’re running a monolithic legacy stack, a cloud-native charging engine, or an MVNO/MVNE setup where provisioning and rating logic need to stay flexible enough to onboard new sub-brands quickly. The AI layer is only as good as the charging and provisioning foundation it’s wired into bolt a GenAI assistant onto a rigid legacy BSS, and you’ve just built a faster way to surface the same broken data.
The Part Nobody Puts on the Slide: Organizational Readiness
Even among executives who believe AI is critical to their company’s future, most report they’re still only actively adopting or assessing generative AI rather than running it at scale, and the honest CEO-level number on enterprise-wide scaling is closer to 16% than to the 90%+ ambition everyone states in public. Talent is a real constraint too operators increasingly cite a lack of in-house AI expertise as the primary obstacle to scaling, and that gap has been widening rather than closing.
There’s also a governance layer that gets skipped in the excitement phase and then comes back to bite everyone in the compliance review. Model auditability, hallucination risk in customer-facing responses, and data privacy exposure under GDPR-style regimes aren’t optional add-ons once GenAI touches live subscriber data — they’re the reason a lot of promising pilots get shelved right before launch rather than after.
None of this means GenAI is overhyped as a category. Operators are genuinely moving from isolated pilots toward broader deployment across networks, operations, and customer experience, and network operations and service assurance are consistently the functions furthest along. But “furthest along” in a global survey and “running reliably against my subscriber base” are two very different claims, and I’d rather hear the second one from people in this room than the first one from another vendor deck.
What I’m Actually Asking
So here’s the real ask for this thread. If you’ve taken a GenAI use case billing, care, fraud, provisioning, whatever past the pilot stage and into something running against live production traffic, I want to hear about it. Specifically:
-
What was the use case, and what made it survive where others got killed?
-
What did you have to fix in your data or BSS/OSS layer before the AI piece would even work?
-
What broke in production that never showed up in the pilot?
-
If you evaluated vendor platforms as part of that build-out, what actually mattered in the decision — integration effort, existing charging architecture, MVNO flexibility, something else?
I’ll go first with a smaller example once a few of you weigh in, but I’d rather this thread be built from real deployment scars than another round of pilot-stage optimism. Who’s actually running this in production, and what did it take to get there?