Telecommunications
BSS and OSS that keep pace with the products you sell.
Order management, provisioning, network assurance, and billing platforms for operators whose product catalogue moves faster than their stack was built for.
11
Operators served
88%
Orders auto-provisioned
6 wks
New product to market
99.99%
Billing accuracy
The pressure
What telecommunications teams are actually dealing with
A catalogue change that takes two quarters
Product definitions hard-coded across ordering, provisioning, and billing, so a new bundle means three projects rather than one configuration.
Orders that fall out and need a human
Fallout rates high enough to need a permanent team whose job is re-keying failed provisioning requests.
Assurance data that arrives too late
Network faults reported by customers before they appear in the operations centre, because correlation runs on a delayed cycle.
Billing disputes with no clean audit trail
Rating and mediation spread across systems, making it slow and expensive to explain a single line on an invoice.
What we build
What we build for operators
Standards-aligned where it helps integration, pragmatic where strict conformance would cost more than it returns.
Order & service management
Decomposition from commercial order to technical service with orchestration that handles fallout automatically rather than escalating it.
- Automated fallout handling
- Order decomposition
- Jeopardy management
Product catalogue
A single catalogue driving ordering, provisioning, and billing, so launching a bundle is configuration rather than a release train.
- Single source catalogue
- Configurable bundles
- Versioned offers
Provisioning & activation
Network and service activation across mixed vendor estates with idempotent, replayable workflows.
- Multi-vendor adapters
- Idempotent activation
- Rollback on failure
Network assurance
Fault correlation, performance monitoring, and service impact analysis that tells the operations centre what customers are affected.
- Event correlation
- Service impact analysis
- Proactive notification
Convergent billing
Mediation, rating, and invoicing with an auditable path from network event to invoice line for dispute resolution.
- Event-to-invoice trace
- Real-time rating
- Dispute tooling
Digital channels
Self-service and partner portals that reduce call volume by exposing the same order state the contact centre sees.
- Shared order state
- Partner APIs
- Self-service diagnostics
Compliance
The regulatory surface we build against
Controls are designed into the architecture and evidenced in the pipeline, so an audit is a report rather than a project.
Outcomes
What these engagements produced
Representative results from engagements in this sector.
- 01
Converged operator
Order fallout down from 19% to 4%
Rebuilt orchestration with idempotent activation and automatic retry, removing most of the manual re-keying team's workload.
- 02
Fixed-line provider
New product launch in six weeks instead of two quarters
Consolidated three product definitions into a single catalogue driving order, provisioning, and billing from one configuration.
- 03
Mobile operator
Faults detected before customers reported them
Real-time event correlation with service impact mapping moved the operations centre from reactive to proactive on the top fault classes.
How we deliver here
Three things that make telecoms delivery different
Product catalogue
Agility problems usually start in the catalogue
When launching a tariff takes two quarters, the constraint is almost never the network. It is a product model where every offer is bespoke configuration spread across billing, provisioning and CRM.
- Product model decomposed into reusable components
- Offer definition as configuration, not code
- One catalogue consumed by every downstream system
- Launch time measured before and after as the success metric
Scale
Volumes that break ordinary architectures
Event rates in telecoms are several orders of magnitude above typical enterprise workloads. Designs that work comfortably at ten thousand events a second fail in ways that are hard to predict at a million.
- Partitioning and ordering guarantees designed explicitly
- Back-pressure and shedding behaviour defined up front
- Load tested against real event distributions
- Cost per million events tracked as a first-class metric
Obligations
Retention and intercept shape the logging design
Lawful intercept capability and data-retention windows are statutory, and they interact awkwardly with privacy obligations that require deletion. That tension has to be resolved in the data model rather than in policy.
- Retention windows encoded per data category
- Deletion and retention obligations reconciled explicitly
- Intercept capability designed with restricted access
- Subscriber privacy honoured within statutory limits
BSS/OSS modernisation
Four routes, and the one most operators should take
Full-stack replacement is the most commonly attempted and the least commonly finished on plan.
| Route | Duration | Risk | When it is right |
|---|---|---|---|
| Catalogue-firstUsually right | Two to three quarters | Low — additive | Time-to-launch is the business complaint |
| Digital layer over legacy | Two quarters | Low — legacy untouched | Customer experience is the constraint |
| Domain-by-domain replacement | Two to four years | Medium — sequenced | Multiple stacks from past mergers |
| Full BSS/OSS replacement | Three to five years | High — very high failure rate | Vendor end-of-life leaves no option |
Catalogue-first
Usually right- Duration
- Two to three quarters
- Risk
- Low — additive
- When it is right
- Time-to-launch is the business complaint
Digital layer over legacy
- Duration
- Two quarters
- Risk
- Low — legacy untouched
- When it is right
- Customer experience is the constraint
Domain-by-domain replacement
- Duration
- Two to four years
- Risk
- Medium — sequenced
- When it is right
- Multiple stacks from past mergers
Full BSS/OSS replacement
- Duration
- Three to five years
- Risk
- High — very high failure rate
- When it is right
- Vendor end-of-life leaves no option
Questions
What operators ask first
Why we push back on full-stack replacement, mostly.
Modernisation
Why start with the catalogue rather than the stack?
Because it is where the business pain usually originates and it is additive rather than replacive. Decomposing the product model into reusable components typically takes two or three quarters and moves launch time materially, without betting the operator on a multi-year replacement. If the catalogue work does not move the metric, you have learned something important cheaply.
Can you work alongside our BSS vendor?
Yes, and in this sector it is almost always the arrangement. We are frequently the party building the digital layer or the catalogue above an incumbent stack, and part of the early work is agreeing interface contracts that survive the vendor's own upgrade cycle.
How do you handle our event volumes in testing?
By load testing against real event distributions replayed from your own telemetry rather than synthetic uniform traffic. Telecoms load is bursty and skewed, and a system that handles a flat million events a second can still fail on a realistic distribution with hot partitions.
Working in a different sector?
The engineering practice is the same across every vertical we serve. Browse the full list, or tell us what you are dealing with.
All industriesStart with the catalogue.
In our experience it is where most operator agility problems begin — and the cheapest place to start fixing them.