Voice
Communication in Business Volume 1
Essays on telecommunications,
1969-1980
Chapter 14
Do-It-Yourself Programming
for Call Detail Recorders
Most of
the early recorders and/or routers simply provided the customer with
a roll of magnetic tape at the end of the month; getting it
processed was his problem. After helping several companies set up
in-house systems for handling their telephone bills, grudgingly made
available on tape from the telephone company, or happily offered in
various states of disarray by interconnect vendors, I decided to
write down some of the simpler things that should be known by
anybody starting out on such a task in the future. This article,
which ran in the January-February, 1978, BCR, is the result.
***
Call detail recording is
available today built into many of the new PBXs; in the form of an
external monitor, it can also be added to older switching equipment.
Such recording systems capture the calling extension, the called
number, the date, time and duration of each call and, sometimes, the
identity of the facility used. So far, so good. But at the end of
the month, the corporate communication manager finds himself in
possession of a tape which must be processed before it can be of any
value to him.
Some consulting
companies process call recorder tapes for a fee, but many PBX users
with in-house computer facilities can process their tapes themselves
at a considerable saving. Because the cost of a consultant's program
can be prorated over many clients, considerable sophistication can
be built in. Often, however, such sophistication is not needed. This
chapter describes the simplest useful processing approaches that
provide for basic cost allocation and communication management
needs. Obviously, it is possible to go far beyond the techniques
described here—but it is not always necessary.
In general, processing a
call detail recorder tape consists of two different kinds of sort:
sorting on the calling extension, and sorting on the dialed number.
The former is useful for cost allocation, and the latter permits
analysis of calling patterns, selection of cost-saving facilities,
and management of such facilities once they are installed. However,
before any meaningful information can be obtained, certain data base
information must be made available.
Determining the cost of calls
To process call detail
information, the first step is usually to convert the tape (or other
output) obtained from the telephone system into a form which can be
read by the local computer. This step is shown at the top left of
the flow chart in Fig. 1;
if the system output is compatible directly with the computer, this
step can be omitted.
Once the data is in
computer-usable form, one piece of information must be added to each
call: the cost of that call. This requires the construction of a
data base (Data Base I in the flow chart) that relates each called
number to a cost calculating rule defined by a tariff. Costs depend
on the time of day (8 a.m.-5 p.m., 5-11 p.m. and 11 p.m.-8 a.m. on
weekdays), type of call (DDD, operator handled, person to person)
and distance between the calling and called party. It is also
desirable to add some sort of discount factor for calls known to
have used WATS lines, FX lines or other cost-saving facilities.
When many locations
originate calls, as is the case when the telephone company, a
consultant, or a large business user with many locations processes
many different tapes, a general program must be developed to
calculate distances between all possible pairs of calling/called
locations. A smaller customer, with one or two locations, need not
go to this kind of trouble. It is usually sufficient to find an
average distance to each remote area code and use that distance to
select a rate-zone.
As a specific example,
there are 14 rate zones in the continental United States (excluding
Alaska). All calls that go between 1,911 and 3,000 miles are in rate
zone 14 and cost 54 cents for the first minute, DDD, during the day,
and 38 cents per minute thereafter. If your PBX is located on the
east coast, every area code in California, Washington, Oregon and a
number of other western states will cost this amount to call. Draw a
circle with a 1,911 mile radius on the map, as is done for New York
in Fig. 2, and you'll
find very few area codes that are cut in half. In these, of course,
you may be in error by as much as two cents per minute, but the
impact will almost certainly be negligible. Only when you get to
nearby area codes, where the "equal cost circles" come much closer
together, is a larger error possible, and even here, it is not all
that important.
In any event, each area
code is assigned a rate zone, based on the AT&T interstate tariff,
and the AT&T cost can easily be calculated without involved distance
measurements. This part of Data Base I can be assembled in a few
minutes.
For calls to nearby area
codes, where distance may be a factor, and for local message unit
and intrastate calls, a similar procedure must be followed, but
based on office code rather than area code. Even so, a rate zone can
be quickly selected. Again let me emphasize that, if you had many
call-originating locations, this would not be the way to approach
the problem.
Once the rate zones (and
WATS and/or specialized common carrier discount factors) are defined
and each area (or office) code is assigned to a rate zone, the cost
per call can be calculated and added to the record. We are now ready
to start producing useful outputs. For the purpose of this
discussion, we will start down the left-hand leg of the flow chart,
and sort by calling extension.
Once this sort is made,
the per-extension bills can be printed. For each extension, each
call can be printed out, giving date, time, duration, cost and
facility used. There is no particular need to have calls in any
particular order, but sometimes it is convenient to lump together
all calls to each called number. This obscures the chronology of
calls, but if the number of calls and total minutes and cost are
presented, just about as much useful information is available and
abuse can more easily be detected.
In any event, total
calls, total minutes and total dollars should be provided as a
"bottom line" for each extension. As in any process, the grand total
for all extensions, along with average holding time and average cost
per call, should also be calculated.
Turning now to the
right-hand branch of the flow chart, the calling extensions are
ignored and calls are sorted by called number. Once sorted, all
calls to a given number are summarized (number of calls, number of
minutes and cost) and only one line per called number is printed
out. As an option, the program can be arranged to print out only
those numbers that receive more than N calls, where N can be
selected as desired.
As part of this report,
all calls to a given office code are added up and printed out as one
level of subtotal, and the total to each area code is printed out as
another level of sub-total. The overall grand totals from the called
number sort should, of course, match the grand totals from the
extension sort.
A most convenient report
that can be obtained with little additional effort is the 20 (or
other convenient number) of most-called lines, central offices, and
area codes. A fixed number can be selected for each category, or any
line, office or area with fewer than a given number of calls can
simply be omitted. The selection process can also be made on the
number of minutes or the dollar value, rather than the number of
calls.
This exhausts the common
reports which can be generated without additional data base input.
Company hierarchy
Returning to the left
leg of the flow chart, we come to Data Base II. In its simplest
form, this data base assigns every extension to a department, every
department to a division, etc., with as many hierarchical levels as
the structure of the company requires. What we do for the department
level report, for instance, is print the bottom line for each
extension within the department. Then we print the bottom line for
each department in the division report and the division totals. We
will ultimately come to the grand totals (calls, minutes, dollars)
which should agree with the grand totals previously calculated.
While the computer is running, it is also useful to calculate the
average cost per call and average number of calls, minutes and
dollars per line in each department, division, etc.
For the more intrepid,
Data Base II can be expanded to associate names and room numbers with
each extension, include department and division names, etc. This
makes it possible for the system to print out internal directories
when needed, and makes the bills and summaries a lot more convenient
to read and deliver. It also requires a lot more programming. On the
other hand, if personnel files are already computerized and access
can be limited to the pertinent data, the job can be simplified.
Specific numbers
With the left-hand
branch of the flow chart completed, there are still a number of
things that can be done on the right. An easy and desirable report
concerns calls to specific numbers. There can be several lists of
such numbers: company branch offices, employee home telephones
(perhaps, again, from the personnel file), customers, vendors, trash
calls (Off Track Betting, dial-a-joke), etc.
At this point in the
flow chart, all the calls have already been sorted by called number
and placed in numerical order. If the specified numbers, regardless
of list, are also kept in numerical order, with each list identified
by a descriptive letter or word (B for branch, C for customer, H for
home, T for trash), the matching process in the computer should be
fairly simple. Adding the list-identifying letter or word before
printing out any reports in the right leg of the chart is desirable;
the ability to print out any one specific list as desired, giving
numbers called, total calls, total holding time and total cost for
each number in the list can provide management with a thoroughly
useful tool.
It should be possible to
update the lists quickly and easily. Unidentified numbers receiving
many calls will immediately be found when the "Most Called Lines"
report is generated, and identification of these numbers for future
checking may be important in selecting facilities or limiting abuse.
Any number in this report that is not identified should be checked
immediately.
It is helpful to add
list-identifying letters or words to the call records when printing
out extension bills in the left leg of the chart. However, the
sort-order there may make this difficult.
Area code to WATS translation
The final data base
needed for our elementary reports is a translation table that
converts area codes to WATS bands. This is a very easy table to make
for any given location but it is different, of course, for locations
in other states, and often different for locations in other area
codes in the same state.
It is desirable to
assign all calls to a WATS band, even if synthetic WATS bands have
to be created to handle calls to Canada, Europe, 800 numbers, etc.
Further, intrastate WATS bands, (beyond the local area) must also be
accounted for.
The area code summaries
obtained earlier are the source for this translation. One simply
adds up the calls, minutes and dollars to each area code in a given
WATS band. If some calls are already going WATS, it may be
desirable, if the information is available from the call record, to
make two summaries: one for calls that did go WATS, and one for
calls that should have gone WATS. As usual, always calculate a grand
total and check it against grand totals calculated in other ways.
Specialized Common
Carriers can be handled the same way, but require Data Base IV to be
much larger. It must include the office codes within area codes that
can be reached.
Alternate source of information
The upper right-hand
corner of the flow chart shows the bill from the telephone company
as an alternate source for the right-hand leg of the chart. The bill
can be obtained on cards or tape (depending on number of calls), and
such information is a good check against the internal recorder. When
internal and external bills are compared, however, care must be
taken to cover exactly the same time interval.
Any bill from the
telephone company will contain classes of calls that cannot be
picked up on a call detail recorder tape: credit card calls, third
party calls, collect calls, etc. These should be sorted out, along
with any person-to-person calls, and a separate printout made
directly. Calls for each credit card should be printed out in
chronological order; sorting for other expensive calls can be done
in any way that is desirable.
The locally dialed
calls, including person-to person, can now be sorted via the right
leg of the chart. With no calling extension available, the left-hand
leg is out of reach. Users should be cautioned against ever using
person-to-person calls; violators of this rule can often be
identified by printing the call detail recorder tape in time-order,
and matching times and called number with the phone bill.
Note that the format of
the telephone bill will be quite different from the call detail
recorder format.
Further, each state will
almost certainly have a different format. It will be necessary to
construct various "front ends" to convert different call recorder
and telco formats to a standard for program operation. Note, too,
that WATS tapes from the telephone company differ considerably from
the regular toll bill tapes.
Conclusions
These are only some of
the simpler sorts and reports that can be obtained from call detail
recorder and related inputs. Many others can be arranged as desired.
Those discussed above, however, are the most important for cost
allocation and management. It is not even necessary to do everything
listed here; the communications manager can cut off the programming
at any point desired.
***
In
dealing with various programmers (excuse me—systems analysts) during
the construction of data systems, Goeller's first law of data
processing was revealed to me in a purple flash: Any printout you
can't lift is no damn good. The utter simplicity of this basic law
reveals the sharp difference between people who build and people who
use systems. The builders like the biggest results possible; in the
present case, every single telephone call detailed for observation,
preferably twice. The user (me), on the other hand, wanted 75,000
records reduced to not more than three pages of summary. A mere
three page output, no matter what its contents, is beneath the
dignity of anybody who really knows how computers can slosh data
around. In these battles, sometimes you win and sometimes you lose.
***
However, I did leave one
very important and basic summary out of the article in the interests
of simplicity. I'd like to put it back now, because time has shown
it is one of the most important pieces of information that can be
generated while the computer is still running.
In a telephone system,
like almost everything else, business does not come in at a uniform
rate. It ebbs and flows, subjecting equipment and people to hurry up
and wait situations. The "busy hour" is often used in design to make
sure enough trunks are available to handle the calls that must be
made. However, not all busy hours are created equal. Some are busier
that others, and more trunks are needed, more attendants are
required at consoles, agents at automatic call distributors, etc.
When one studies any
given company's traffic patterns, cyclic variations leap out.
Sometime traffic is heavy at the end of the month and light at the
beginning. Sometimes Mondays are very heavy, and the rest of the
week is a breeze. But whatever the pattern, there is usually a
reason for it; it is seldom a statistical anomaly.
Most data available to a
communication manager comes in by the month in the form of bills
from the telephone company or reports from his own PBX or
stand-alone equipment. There has been a tendency (I have done it
myself) to use an "average" busy hour in design, obtained by taking
a proportion of the monthly traffic. Although one month is often
equal to 22 business days, and one day's traffic often approximates
six times the traffic occurring during the busy hour, cyclic
variations sometimes make it dangerous to divide monthly traffic by
22 X 6 = 132 to get hourly traffic for use with standard traffic
tables.
But what is the
alternative? Get the right information, of course. And that is what
I left out of the article. Another printout is required, suggested
by the blank form on the next
page. Here we have days of the month running down the page,
and hours of the day running across. If we just count total calls in
each hour of each day and put the number in the appropriate spot on
the form, we can see our cyclic patterns quite clearly. If we want
to get fancy, we can make three such printouts, one for calls (peg
count), one for total call duration (in minutes, CCS or hours), and
one for cost. We can also divide traffic up by message unit,
intra-state toll, and interstate toll. If incoming traffic can
somehow be captured, it should be handled separately on a form of
its own.
All this gives me a
chance to mention Goeller's second law of data processing: always
add across and down, and take subtotals and averages at the drop of
a hat. For each day, we want to know the total traffic during
business hours, during evening hours, and at night when rates in the
public network are really low. And we want the daily total, or
course. This covers the rows. For the columns, we would like to be
able to insert a subtotal and average for each hour in each business
week (not shown because weeks vary in terms of date from month to
month), and total and average by hour for the entire month. The
computer should always do these across and down calculations while
the data is in the machine; if you have to reach for your pocket
calculator as you study a printout, Goeller's second law has been
violated.
[
Top ] [ Next ] [
Table of Contents
] |
