|
purebill.com Stephen Jones writing on billing and application migration |
![]() |
| . | Home | . | About | . | Archive | . | Links | . | Billing | . | Reference | . | Subscribe | . | Search | . | . |
Note 6: A Business' Key Billing FunctionsPosted: 23 October 2005 Five core functionsBilling's core functions activate the network for a customer, collect details of network transactions, determine the appropriate chargeable amounts, apply applicable discounts, format the bill, and send the bill to the customer. There are also supporting functions that transmit the billing details to the biller's internal and external systems, and provide access and maintenance of customer details for resolution of customer issues. These core functions also provide the raw data for secondary, though still important, billing functions. For example, a bill must have been generated and remain unpaid before credit management can act. Without the core billing processes that form and distribute the bill, there is no record of a debt to pursue. Of course, the credit management function is not involved in generating the bill. These introductory notes are intended to provide an initial context for those readers with little or no work history in billing.
Two supporting functionsThese two functions enable other parties, both internal and external, to access details of the billing process and the customer's billing arrangements. The account maintenance function is an online, interactive function that enables staff (and possibly customers) to inquire and update details of individual customers and transactions. The reporting / business support function uses consolidated, batch interfaces to supply details for all customers.
Activation / Service ProvisioningA customer order can be understood as a checklist that drives change in the network, which is later reflected in billing. This change may include the inventory reservation of specific equipment (e.g. telecommunication lines, electronic tollway tags) and its association with a specific customer. Such reservations ensure that future orders do not double-book the same piece of equipment. It is almost always cost-effective to automate the network modification (activation) process. Automation will both reduce the staff required to maintain network connections (particularly as the network or customer base grows), and provide the customer with more prompt network connections and updates. Despite validation in the ordering process, an order can error during network provisioning and require human intervention. Errors can be caused by a misalignment of validation processes between ordering and network provisioning, or can be due to a misalignment between the customer's details activated on the network and those already held elsewhere (e.g. billing, ordering). Some orders will not affect the network itself, but instead will change the customer's billing arrangements. For example, a telecommunications customer may select a new pricing plan with cheaper long-distance phone calls but a higher monthly subscription. This update does not affect the customer's network connection or where they can call, but when calls are made the new pricing plan will affect the amount the customer is charged. Orders not requiring network manipulation can be passed directly to the billing system for processing. Due to the diversity of possible networks, later notes will focus on the billing impact of different provisioning approaches, rather than the networks themselves. Transaction Collection / MediationTwo important considerations drive this billing function. First, it is difficult to communicate with complex and diverse networks. Second, the raw information collected from a network may be insufficient (or unreadable) for billing and require manipulation before it becomes useable. A large biller (especially in the telecommunications industry) may operate a network with different equipment vendors using various software programs across geographically diverse areas. To collect network information, the mismatches among the various network systems need to be systematically (and transparently) rationalised. The specific commands in one vendor's program are likely to be unique to its hardware. Even the same vendor may modify commands on new versions of its equipment's software causing subtle, but important, changes in the network's operations. The collection process must address these differences and isolate them from the rest of the billing process. Downstream billing processes must receive transaction records without worrying about how they were obtained. By doing this, the integrity of the billing process is preserved, even when new network equipment is installed. The raw information collected from the network may omit information required by billing. This can be because the network doesn't need it to deliver network services. Also, some network information may be in error (e.g. transposed phone number digits), require enhancement (e.g. additional field values based on the transaction), or require modification (e.g. time zone standardisation) before it is passed to billing. Data mediation thus serves to isolate the idiosyncrasies of the network from the billing process. The centralised transaction correction and standardisation performed in mediation reduces the maintenance effort expended downstream to pass existing transactions to billing, and the integration effort required when new transactions (and networks) are introduced. The standardised transaction format(s) generated by the collection / mediation function can be reused by other business functions. e.g. fraud detection, regulator reporting, network load analysis Tags: Billing, Functions, Activation, Provisioning, Collection, Mediation [ Share with others ] Post this page to a social bookmarking site:
Links to other NotesPrevious - Note 5: Operating Multiple Billing Systems Next - Note 7: Rating, Pricing and Bill Generation Recent Updates
Sign up to receive a brief text email when new purebill postings are published. JUMP TO TOP
|
. |
| Comments welcome: stephenjones(at)purebill.com | Stephen Jones © 2004-2010 - Copyright and reprint rules | Sitemap | . |