But don't begin until you count the cost. For who would begin construction of a building without first getting estimates and then checking to see if there is enough money to pay the bills? Otherwise, you might complete only the foundation before running out of funds. And then how everyone would laugh at you! - Luke 14:28-29.
In this series of articles I will be describing important topics to consider when building, purchasing or outsourcing a billing system for processing telephone calls. Along the way I will describe other systems that can be built using the same data that is required for maintaining a billing system.
I have built and researched various billing systems during my time at an international wholesale long-distance telecom company. There are various flavors of billing systems that reflect the business model of the company using them. Sometimes a billing system may dictate or limit the flexibility of a company to modify its business model.
One key is to look forward and try to purchase or build a system that meets the needs of the business now and far enough into the future that one does not have to start over with a new system down the road. There always seems to be a trade off between speed and functionality so one could end up with various types of billing systems to do different jobs. What you want is maximum flexibility at the speed that is necessary to keep up with demand for billing calls.
Some of the flavors are wholesale, retail and calling card. Within those broad categories are international, US domestic and foreign domestic. Sometimes a billing system will have to handle all of these different types of phone calls. Many times a company will end up with more than one billing system to process the different types. The way one rates and invoices a wholesale call is different than a retail call. In addition some systems were not built to handle international calls and can only deal with domestic calls and visa-versa. On top of this are dealing with taxes and other government surcharges. I will be going into more detail on these issues in future articles.
The components of a telecom billing system as with most software fall into three categories, input, output and processing.
For input we have three major types of data, the CDR, rates or prices and the dialed number to country / city dictionary.
CDR stands for Call Detail Records. This is the output from the telecom switch. All CDR should contain: number being called (B-number), number called from (A-number), start date and time of call, duration (or end date and time), incoming trunk group, outgoing trunk group. This is the minimum amount of data needed to determine how to bill a customer. With wholesale billing you do not need the dialing number and with retail you may not need or have the incoming trunk group.
There are additional fields in the CDR that will be helpful for other purposes such as providing call statistics. Some switches are set up to provide the ring (hold) time. This is roughly the time from when the call is dialed until it is answered. The CDR may also contain in and out circuit numbers.
The rate or pricing information is inputed into the system via a user interface. This would include information such as customer contact information and which numbers or trunk groups belong to which customer. The rates must be attached to particular localities unless you have some sort of worldwide flat rate (Boy, that would make billing easy.) And of course a rate or price is also associated with a particular customer or groups of customers.
It may be important for you to make sure the user interface fits your needs. Some companies may want the sales people to update the rates as they negotiate with the customer. You may want to have two types of user interfaces, one for complex agreements that have discount mechanisms and one for the simple basic contracts.
It is very difficult for people to associate a number with a particular locality so there must be a dictionary that maps the first digits of a telephone number to a locality. Of course your business model determines the depth of this mapping. What I mean by that is, are you going to charge a customer at a country level, a state or providence, a city or one section of a city? Along with the rates being entered a table must be maintained of the first digits of the dialing codes with a description of the location at whatever level is needed. (More on this later.) For numbers in the US we use the terms NPA and NXX.
There must be some way of taking a dialed number, and then figuring which rate is associated with it. That brings us to the middle piece- processing. This is what I call the rating engine. You may need to build more than one due to the differences between retail and wholesale rating.
The processing part of the system will also be involved with translating the dialed number into a locality name, determining the duration of the call and rounding it into billable units of time. Most rates are expressed as an amount of money per minute but there are different ways the fractions of a minute are rounded that effect the final charge to the customer. Other billable costs may come into play here. Things such as taxes may have to be figured on a per call basis for various reasons. Then the cost to the customer of each call will be stored so that it can later be invoiced.
This brings us to the output. The most common output of a billing system is of course the invoice. Sometimes this data is in a raw form and passed to a financial system for additional processing.
Other output could be various reports needed to monitor the health of the business or your telecom network, auditing bills from vendors or quarterly reports. If you have large-scale reporting needs it may be best to migrate the data into a data warehouse so reports can be built quickly on demand without taxing the performance of the billing system.
The things listed above are only the core things that a billing system must do. There are other optional things that can be done with the data gathered in a billing system to make the business more profitable. I will go into detail more on these later but some of the items are:
- Calculating cost to the company from the vendors. (The rates or prices give you the amount to bill your customer but having the costs in the system allows you to determine what your vendors should be billing you.)
- Get statistics on the performance of the network by calculating ALOC (Average Length Of Call) and other helpful numbers for a NOC.
- Calculating gross margin.
- Providing various reports to customers via a web site.
- A mediation system to compare your CDR with a vendors copy of the CDR and invoice.
- Automated rate changes based on changing costs
- Provide information to a system that can determine the least cost routing for the switch(s).
A basic telecom billing system is not really that complex. The hard part is determining how to obtain one that meets your needs at the right cost. The the details of your business situation can make it complex especially if the system is built to handle a certain type of call and then it is asked to do something it was not originally designed for. I hope to cover most of the options for a billing system so that one can be chosen or built that meets your needs.
In the next article I deal with batch vs. near real time billing and rating. Real Time Vs. Batch Telecom Billing
Referenced in: Advice of Charge in Telecommunication Services
- Bradley Johnson ©Copyright 2003- email@example.com
Scripture quotations are taken from the Holy Bible, New Living Translation, copyright © 1996. Used by permission of Tyndale House Publishers, Inc., Wheaton, Illinois 60189. All rights reserved.