Loading
Catalogue, order capture, provisioning and billing each own part of the journey and none of them owns the whole of it. We connect them so an order either completes or lands somewhere a person can act on it.
Four systems · one order
Where it breaks
Sales knows it was sold, the network knows what was provisioned and billing knows what was charged. Between those three facts is where the margin quietly goes.
Pricing, eligibility and bundling live inside the billing platform, so a tariff the market wants next month queues behind whatever else is in the release train.
We put a catalogue-driven product model outside the platform, so a new offer is configuration rather than a code change.
A task fails between CRM and the network, the order stops, and the first person to notice is the customer on day four asking why the service they are being billed for does not work.
We decompose every order into tracked tasks, and a failure raises an owned exception rather than a log entry.
Mediation, rating and the network each count slightly differently. The gap shows up as a dispute, a credit note, or revenue that was earned and never invoiced.
One reconciliation path from network event to invoice line, and every gap it finds goes on a report.
How it works
We validate orders against the catalogue, break them into provisioning and billing tasks, retry them where it is safe and reverse them where it is not.
Scroll the diagram sideways →
TM Forum Open APIs where your vendors support them, a canonical product and order model where they do not, and REST and events for everything new. A new MVNO is a mapping against the same model.
The runtime sits on your cloud tenancy, in your data centre, or split across both. Residency and regulatory expectations usually make the decision, and we design to them.
Order throughput, fallout by stage and reason, provisioning success and reconciliation gaps all land on one dashboard. We can run it under a support agreement if you would rather not.
Products
MetricMonitor and DwaniAI read the same order and service model, so the answer a subscriber gets matches the one your operations team is looking at.
Order throughput, fallout by stage and reason, provisioning success, billing reconciliation and integration SLAs on one screen, with alerts on what your operations team watches.
Explore MetricMonitor →Billing questions, activation status, outage updates and plan changes over voice and chat, in the languages your markets use. It escalates to an agent when the answer is not simple.
Explore DwaniAI →How we work
No order ends its life in a log file. Every failure carries the stage it stopped at, the reason it stopped and the team that owns it, which is the difference between a fallout report and a fallout process.
It is included in every engagement. A new flow runs beside the existing one until the counts agree.
When a task fails halfway, the compensating steps are part of the flow. A subscriber is not left billed for a service the network never activated.
Whatever we replaced stays configured until you retire it. Reverting inside a change window means flipping a switch. There is nothing to restore.
Recent work
Anonymised at the client's request
A provider could tell you how many orders were taken and how many were billed, but not reliably what happened to the difference. Failed provisioning tasks were retried by whoever spotted them, and the count depended on who was on shift.
We decomposed the order into tracked tasks, gave every failure a stage, a reason and an owner, and put the catalogue outside the billing platform. Fallout stopped being a number people argued about and became a queue people worked.
Talk to us about your estate →Questions
The orchestration layer and canonical model go in first, usually on webMethods or Apache Camel depending on what you already run. Billing, CRM and provisioning keep working while orders move onto the new path one product at a time, and the old path stays live until you retire it.
Get started
Tell us where orders are getting stuck and what the billing platform will and will not allow. An integration architect reviews it and comes back within two working days.
