Three deployments that show the shape of the work: what was broken, what we built, how long it took, and what changed afterwards. Customer names are withheld at their request; named references and written reference letters are available under NDA.
A note on these figures. Everything below is drawn from delivered projects. Where a number is an internal measurement rather than a customer-published figure, it is described as such. We would rather publish three honest case studies than twelve impressive ones.
A Tier-1 operator in a Deutsche Telekom group market was running an MMSC from a vendor that had ended support. The hardware was out of warranty, the maintenance contract was priced against traffic volumes from a decade earlier, and every change request was quoted in quarters.
MMS traffic was declining but nowhere near zero, and picture messaging failures still generated care contacts. Replacing the platform was not strategically interesting to anyone — which is exactly why it had been deferred for three years.
Shadow deployment first: the new stack received a mirrored copy of live traffic and answered nothing, for several weeks, while behaviour was compared message by message against the incumbent.
Then a canary on a single number range, then a ramp by traffic share, then cutover. The legacy platform was kept warm for a further period before decommissioning.
A core network operations team had comprehensive element monitoring and a service quality management layer above it, and still found most signalling degradations the same way: through the complaint queue.
The gap was specificity. Their KPIs could tell them that a service had degraded in a region. They could not tell them that MAP dialogues toward one roaming partner had begun retransmitting, which SCCP route was responsible, or which subscriber segment was affected — so every investigation started with a packet capture and a hypothesis.
A fixed-price proof of concept on two tap points, with a success criterion agreed in advance: detect, ahead of the complaint queue, a degradation that the existing toolchain had missed.
Nothing new was introduced into the operations workflow. The team kept their Grafana, their alerting channels and their runbooks; only the quality of the underlying signal changed.
An MVNE running a mature BSS for a growing tenant base kept losing the same part of every deal. Onboarding, rating, billing, product and partner management were all in place. Messaging, RCS and entitlement were not, and were referred out to the host operator or a third party.
Two consequences followed. The margin on that part of the deal left the building, and the MVNE could not evidence the messaging SLA it was contractually offering, because it had no visibility into a layer it did not own.
Deployed behind the existing BSS rather than beside it. The BSS was not modified; it gained a set of provisioning endpoints and a set of assurance feeds.
One tenant first, as a pilot, with the commercial model proven on that tenant before the platform was opened to the rest of the base.
References are anonymised at the customer’s request. Named references and written reference letters are available under NDA.
„We were finding signalling degradations from the complaint queue. ProBee moved that left by roughly forty minutes — we now see the retransmission pattern build before the first customer calls. It is the same Grafana our NOC already lives in, so nobody had to learn a new console.”
„Our BSS was complete and our network layer was not. Mobees dropped in the messaging core and the TS.43 entitlement server behind our existing provisioning, per tenant. We stopped referring those deals out.”
„They are the people we call when a transformation programme hits SS7 or CAMEL and the schedule is already tight. Small team, no layers, an answer the same week.”
Written reference letters and direct customer introductions are available under NDA. Ask and we will arrange it.