Note 27: Operational Billing / Provisioning Models

Posted: 31 March 2007

Different operational models for Billing

Ordering, billing and the network can be arranged in three configurations to manage the provisioning process. Where a biller operates multiple networks, a different approach may be implemented for each network. The three configurations are:

Ordering to billing via network provisioning: The customer's order is passed to billing through network provisioning
Ordering to network provisioning via billing: Network provisioning is driven from billing
Ordering managed centrally to both network provisioning and billing: A centralised manager drives the network provisioning and billing processes

These configurations can be adapted to pass internally generated orders (e.g. disconnections due to non-payment) directly to billing, avoiding the network provisioning and 'ordering' applications.

processing flow outline of three provisioning / billing models

Ordering to billing via network provisioning

This configuration passes orders through the network provisioning application to billing. Once any network changes are complete, the order is passed to billing where the billing arrangements are established or modified. Order confirmations are passed back through network provisioning to the ordering application.

Under this approach:

Orders are passed through the network application even though they may not modify the network.
The network application may need modification when the order's format or content is changed. e.g. when new information is passed to billing. This may build an ongoing review cost into planned order changes to allow the network application's support team to review planned changes and identify the level of impact.
The network provisioning application must recognise and process the correct parts of an order and ignore the parts that apply elsewhere (e.g. in billing). Order fields required only by the network will be passed to, and must be avoided by, billing.
Billing must recognise and process the correct parts of an order and ignore the parts that apply elsewhere (e.g. the network). Order fields required only by billing must be avoided by the network provisioning application.
Billing must wait until the network application has finished with the order before its processing can be performed. If the order is delayed in the network application, network usage may be received by billing. In such circumstances the usage may be errored (i.e. due to the lack of a billing arrangement), or be processed incorrectly due to outdated billing details (i.e. unmodified by the delayed order).
Staff and customers may find it difficult to track an order's progress without an interface built into both the network provisioning and billing applications.
Additional processing steps are difficult to introduce (e.g. fraud detection, data warehouse feeds). The steps must be placed in a fixed location before or after existing steps in the sequential pipeline.
The network application must be aware of how the billing application's interfaces work, and vice versa. Each application is likely to be significantly impacted if the other is replaced.
Bundles that include elements from multiple networks cause processing difficulties. For the bundle, which are the correct network applications? How is the one order sent to all relevant network provisioning applications? How will billing know when the bundle has completed its processing successfully across all networks?

Ordering to network provisioning via billing

This configuration reverses the order of the first configuration and passes orders through billing before the network provisioning application. Once any billing changes are complete (if required), the necessary order information is passed to the network provisioning application. Order confirmations are passed back through billing to the ordering application.

This places the burden on billing to know which orders result in network changes, and what the appropriate network requests are to initiate those changes.

Under this approach:

Where multiple networks are involved, billing must decide which network application(s) to interface with, and must manage the order's completion in the network. If an order's request errors in the network, billing must capture the error state and support the biller's staff as they fix the problem.
Billing will have modified its arrangements before the network updates have been performed. Network errors may require billing update its details to reflect the true start date of a change in the network.
No network change can be applied until and unless billing has processed the order.
Billing is complicated with non-billing functionality. The billing application may need modification when network processing is changed. e.g. when new features are enabled. This may build an ongoing review cost to allow the billing application's support team to review planned changes and identify the level of impact.
Unless billing removes 'billing-only' fields, the network provisioning application must recognise and process the correct parts of an order, ignoring the parts that apply elsewhere (e.g. in billing). Order fields required only by the network must be passed to, and avoided by, billing.
Staff and customers may find it difficult to track an order's progress without an interface built into both the network provisioning and billing applications.
Additional processing steps are difficult to introduce. The steps must be placed in a fixed location before or after existing steps in the sequential pipeline.
The billing application must be aware of how the network application's interfaces work, and vice versa. Each application is likely to be significantly impacted if the other is replaced.

Ordering managed centrally to both network provisioning and billing

This configuration uses a centralised order manager to decompose the order and pass the network-specific details to the provisioning systems and billing details to the billing systems. The processing arrangement (schedule) of each interface is independent of the others, and can be reordered for different transactions. Order confirmations are passed back to the order manager which then passes a single confirmation to the ordering application.

The burden is placed on the order manager to know which orders result in network and billing changes, and the appropriate requests to initiate those changes. This configuration becomes more advantageous when bundles with multiple networks are involved.

Under this approach:

Billing and network provisioning are called independently. When one is replaced or modified, the impact on the other is reduced or avoided.
The order manager decides which network application(s) to call, what their interface requirements are, how to schedule the calls, and how errors are addressed. If a network errors an order's request, the order manager must capture the error state and support the biller's staff as they fix the problem. Any delay this causes may impact the requests sent to other networks or billing depending on the scheduling of an order's processing.
Billing may be called first, after all changes are completed in the network(s), or even when errors have occurred. Different options are available due to the functions' independence.
Network provisioning and billing processes are not complicated with unnecessary functionality. Changes that only impact billing (or the network) can be reviewed by the one support team, not all support teams.
The order manager can provide information that supports order tracking for staff and customers. An order's progress can be tracked in the order manager by examining its completed steps.
Additional processing steps can be introduced more easily due to the independence of each function's requests. New steps can be placed in different locations within a processing schedule depending on the type of order.