Service Order Tracking

Service Order Tracking

Bottlenecks can occur on an interface due the following reasons:
   • LAN/WAN Congestion
   • Third party Switch/IN processor overload

Where this occurs the system action depends on the type of provisioning action in progress. For example, an account addition or deletion could be retried several times and then cancelled, the queue entry deleted and the failure audited.

This avoids queue congestion where queued commands have built up due to, say, network congestion. However, where money has been spent by the customer (e.g. a calling card recharge where the customer's credit card has already been deleted) the queue entry will never be deleted and will continue retrying until eventually it gets through.

It is also possible to prioritise queued commands by command type with transactions involving money being at the highest priority, call centre service orders at the next priority and batch transactions at the lowest priority. This avoids customers being kept waiting during heavy provisioning cycles.

Where bottlenecks occur it is important to be able to see the status of a customer's service order while it is in progress. Using a simple 'click and drag' operation for a given account or customer, the CSR can see:
   • All outstanding service orders
   • Current service order status
   • Provisioning source
   • Provisioning activity etc…

This allows the CSR to inform the customer of service order progress at each stage of the process.

The same functionality applies to the management of on-line payments. Where there is a bottleneck due to a third party system, all outstanding service orders can be tracked and viewed from the customer accounts screen. This allows the CSR to inform the customer of payment progress at each stage of the process.

Back