Telecomm Billing

Category: Past projects

Between 1992 and 2011 we had the pleasure of running a billing support system for a large telecomm company. The contract started off between us and GTE Labs when they were called in to help speed up processing for past due accounts. Over time we switched from working with Labs to working directly with receivables management, the part of the company that handles past due bills.

Originally the process was a simple one to automatically review accounts based on their appearing on an aging report. If the account met certain criteria, we automatically performed a “temporary disconnect” to shut off the customer’s phone until they paid their bill. The problem to this point was that the reports listing the past due accounts were printed and each one manually reviewed by a telephone representative to see if the customer should be “treated” (in this case, that means disconnected until payment).

The problem was that they couldn’t keep up with the volume and so fell further and further behind. Our solution was to set up small Unix servers in the customer contact facilities. These servers had synchronous serial cards that communicated with their mainframes and pretended to be a printer (so we could get the reports of overdue accounts) and as a representative so we could examine accounts online and check to see if there was any reason not to disconnect them.

These two techniques are “print scraping” and “screen scraping” respectively. Both of them count on the fact that classic mainframe programs are very rigid in their input and output. The reports generated followed a pattern so that once you detect headings in the reports, you can then determine where each data value appears on the page.

Similarly the screens used were IBM 3270 style displays, 24 x 80 screens with a mixture of “protected” and “unprotected” fields. Working with these involved typing input or commands into the unprotected fields and then pressing a function key to transmit the changed fields to the mainframe.

Over time our system took over more and more interpretive functions, some as simple as reading reports and summarizing them, some as complicated as cloning existing telephone account records.

As time went by we switched from Unix to Windows, from serial communications to TN 3270 (a standard Telnet protocol for communicating with mainframes) and most importantly to using XML as our definition language for our screen and print scraping techniques. In our final versions the XML would be compiled into C++ pseudo code for use in our libraries. This gave us the ability to quickly adapt to undocumented changes on the mainframe yet keep up the high speed processing we needed.

By mid-2010 all of our processing had switched to automatic service order generation with most of the billing and interpretation done externally. By the end of 2010 all processing had been brought in-house.

Calling Card Billing

Category: Past projects

One large scale billing project started for us in 1999. Unlike our other projects we were the front end billing system. The product involved was a post-paid calling card connected to a credit card. The rewards plan was free calling minutes – the more you used the credit card the more free minutes you got.

Although this started off small, this project ramped up quickly until our servers were working thousands of calls per hour. The customer service reps for this task connected to our system using web browsers to our site over a secure connection to a large server-side JavaScript system. Over time additional features were offered to customers such as pagers, home long distance and – for a short amount of time – cell phones.

The growth of the cell phone industry was the end of this project, however. Between 1999 and 2004 the number of cellphone users in the US doubled to 70%. The original market for these calling cards/credit cards was students – for making long distance calls from their dorm rooms, in particular – and with cell phone demographics skewed towards the 18-29 group, the drop was even more evident.

Over the life of the project (through 2006) millions of accounts and calls were processed, encompassing the life of the account from creation, through billing through collections.

ADSL Provisioning

Category: Past projects

In mid-1999 we started another project for Genuity, a networking company. The goal of the project was for them to be the middleman in DSL provisioning. Effective a customer would purchase DSL service from their ISP. That ISP would then communicate to Genuity that the service was to be installed and then Genuity (via Flying Duck) would contact the local phone company (the “LEC”, local exchange company) to get the service installed.

The system we developed had a front end that written in JavaScript under Windows ASP which allowed a customer service representative at the ISP to place an order for service. We would then determine the local service provider and determine the level of service available. Communications between the representative dealing with the customer, Genuity and the LEC were all provided by our system.

There were numerous complications particularly since no two LECs had the same format for requests. Genuity had wanted to gain the market share to be the sole interface between multiple ISPs and the LECs but that goal was never reached. The project was discontinued in 2002.