An order is finished when the link is live.
Between a signed enterprise order and a working circuit sit a feasibility check, provisioning, a last-mile install and acceptance testing, usually spread across teams and partners. We build the business layer that tracks that path and keeps the customer informed.
Five systems, one order, no single status.
Sales books a dedicated internet line for a customer's branch office and the CRM marks it won. Provisioning has a ticket in the network team's tool. The fibre partner has a job card on a phone. Billing waits for a ready-for-service date that nobody has sent, while the customer emails the account manager every other day.
Each of those systems is right about its own step. Nobody owns the whole order, so delays show up as customer complaints long before anyone inside sees them.
A sensible first release covers one product line, perhaps enterprise broadband in one city: the order record, the partner completion form and customer status messages. Voice, wholesale circuits or tower site work can follow once the states have proved themselves on real orders.
We build the order record that follows every step, and each step's own system stays in charge of it.
What the business record tracks, and from where.
How we would approach the build.
Map states before screens
We list every order state your teams use, including unofficial ones like 'waiting for the society's permission letter'. Each state gets one owning system and one person who moves it forward.
Connect instead of copying
Through API integrations or scheduled imports, the order record listens to the CRM, the provisioning tool and the field app. Where a system has no interface, we agree a manual update with a named owner and say so plainly.
Give partners their slice
Installation partners use a partner portal showing their assigned jobs, site contacts and a completion form that wants test readings and photos before it accepts anything.
Tell customers only facts
Status updates and notifications fire from dependable events alone, so no one gets a 'your line is live' message for a job still waiting on a splice.
Events that arrive twice, late or wrong.
Duplicate completions
A partner taps submit twice on a weak connection. The order should advance once, with the second event logged and ignored.
Updates out of order
Provisioning reports done before the field job closes. The record waits for both instead of releasing billing on half the facts.
Failed visits
An install fails because the premises were locked. That reschedules the task and pauses the customer's delivery clock; the order stays open.
Changes mid-order
The customer upgrades bandwidth before activation. The amended order keeps its original history, so commercial and network teams agree on what was sold.
Close relatives of this problem.
What operators and ISPs ask.
Will this replace our OSS or BSS?
No. Those systems keep doing provisioning, inventory and billing. We build the order view and the partner and customer screens that sit across them, reading their status through whatever interfaces they offer.
Can enterprise customers see all their sites in one place?
Yes. A customer with many branches can see every order and service request across its sites, limited to its own account, with the same stages your teams use internally.
Trace one stuck order with us.
Pick an order that took too long and we will map where it waited and what would have flagged it sooner.