Skip to content

Find the missing detail behind a stalled service order

An order can sit in fallout because the premises address in the CRM does not match the supplier's address record, while the ticket explaining it sits with another team. Duvo links the order, its provisioning status and the ticket history, then prepares the correction request for the order owner.

Book a process call

Service order fallout

Delivery owner decision needed

Order SO-901

Order
Blocked
Records
Order and delivery ticket
Owner
Service delivery

The customer order and delivery ticket name different unit numbers for the same premises reference.

Next action

Request address check: send the reviewed discrepancy to order administration; no live order is resubmitted.

Escalate to owner: route both records to service delivery for investigation; provisioning remains unchanged.

Delivery owner approves each handoff

No correction request or escalation reaches another team or a supplier before the service delivery owner approves it.

View the wider product queue

Service order fallout

Stalled service orders linked to their tickets and supplier updates.

Adds cases
Service order export
Processes cases
Service order fallout
Total

24

Pending

5

Postponed

2

In progress

4

Needs input

3

Failed

0

Completed

10

Add filter
Case
Case Status
Order blocker
Scope
Decision
Exceptions
Next action
Order SO-901
Needs Input
Address mismatch
Fibre installation
Confirm premises
1
Order SO-902
In Progress
Supplier rejection unactioned
Business circuit
Trace supplier update
0
Order SO-903
Completed
Owner handoff recorded
Voice order
Request routed
0
Order SO-904
Pending
Milestones conflict
Access order
Reconcile status
1
Order SO-905
Postponed
Site contact missing
Site relocation
Await order owner
0

Showing 5 of 24 cases

  1. 1

    Approval

    Exceptions pause for the named owner

    Each exception carries the source records, applied rule, recommended action, and the person authorised to decide.

  2. 2

    Order blocker

    Order blocker is visible before the action

    The conflicting order detail and the handoff owner show before a correction request is sent.

From fallout to the owner who can clear it

When an order drops out between order management and provisioning, the reason is often administrative: a unit number that differs from the wholesale supplier's address record, a missing site contact, or a rejection from the access provider that nobody has actioned. The order stays open in one system while the explanation sits in a ticket or supplier update in another, and the customer's committed date keeps approaching. Fallout teams spend their time rebuilding that link before they can decide who acts next.

  1. 0101

    Link the stalled order

    Duvo reads the order from order management with its milestones and provisioning status, and links related service desk tickets and supplier order updates by order, service and premises reference.

  2. 0202

    Name the blocker

    Address mismatches, missing customer details, unanswered supplier rejections and conflicting milestone states are identified, and Duvo drafts the correction request or escalation for the owner who can clear it.

  3. 0303

    Your team decides

    Approve the handoff

    The service delivery owner approves the request or escalation before it goes to order administration, the customer team or the supplier.

  4. 0404

    Track the response against the order

    Duvo routes the approved request and records the reply against the order. A resolved request is logged as resolved; it does not mark the service as active.

Order, ticket and supplier records linked by reference

Systems and control details

Order status and milestones come from order management and provisioning, tickets from the service desk, and supplier updates from the wholesale portal or email. Where OSS/BSS systems expose APIs Duvo uses them; elsewhere it uses approved browser access. Customer data handling is agreed first.

Order management records, Provisioning status and milestones, Service desk tickets, Wholesale supplier order updates, Customer site details

  • Delivery owner approves each handoff

    No correction request or escalation reaches another team or a supplier before the service delivery owner approves it.

  • No changes to the live service

    Duvo does not provision, disconnect or reconfigure a service, change the network or resubmit a live order. Those actions stay with authorised operations staff.

  • Order and ticket states kept separate

    Each record keeps its source state and timestamp. Closing a ticket never marks the order complete.

What teams ask about Service order fallout

  • Does Duvo resubmit orders to provisioning?

    No. It prepares and routes the administrative correction. Resubmitting orders, provisioning and any change to the live service stay with your operations team.

  • How does Duvo link an order to tickets that use different references?

    It matches on order, service and premises references across the records. Where no reference links them, the order is flagged for the team rather than matched on a guess.

  • What access to our OSS/BSS systems does Duvo need?

    Read access to order status, milestones and tickets is enough to identify blockers. Sending requests needs the permissions your team agrees for each channel.

  • Can we try it on orders our team has already cleared?

    Export recently cleared fallout orders with their tickets. Duvo identifies the blocker for each, and you compare that with how your team resolved them.

Related processes