[ Home ] [ Table of Contents ] [ About Lee Goeller ] [ Search ]

Voice Communication in Business Volume 1
Essays on telecommunications, 1969-1980

Chapter 10
Those Awful PBX Proposals:
System & Console Features

Although we have spent a good deal to time in previous chapters on system descriptions and what the PBX customer ought to know before he buys (or rents), the features offered by the system command the most interest and seem to be the most important in a proposal. This is not unreasonable: what the system does is, to the customer, more important than how it does it. The fine points—or even the gross, basic points—of system architecture leave many customers cold, but the availability of message accounting or call pick-up can be translated directly into money and satisfaction.

Unfortunately, endless lists of feature names, with features arranged in alphabetical order whether they are related to the attendant position, the station user, or the system itself leave much to be desired. Just as all electronic systems are not time-division and all time-division systems are not digital and all digital systems are not T-compatible PCM, we also find great variety in feature implementation. So let us now wander through the wonderful world of features and try to make dollars and sense out of what we see.

SYSTEM FEATURES

System features, summarized in Table 3, page 42, are those that relate to the system as a whole and are wired or programmed in so as to be independent of station or console operations. Many of these features have been available on PBXs for a long time. Some, however, are done so much better with modern technology than they ever could be with relays that they seem like something new.

Translation

One of the most fundamental properties of any switching system (except step-by-step) is translation. E. C. Molina got the basic patent in 1906, and various improvements have been made in concept and implementation over the years. In general, translation in the sense we are talking about here refers to the relationship between the extension number and the identity of the terminal on the switching matrix to which the extension connects. In step-by-step, where the extension number and the switch position are identical because of the way the system works, there is no translation. But in all systems where the caller dials into a memory and the system then relates the dialed number to the desired network terminal, opportunities for translation exist.

The most useful advantage of a completely flexible arrangement between number and position is traffic balancing. Users can be reassigned from one position on the switching matrix to another to even up the calling load, but they can retain their familiar directory numbers. With direct inward dialing, where the directory number is part of the nationwide numbering plan, this may be quite important.

Another thing that complete flexibility in translation permits is the assignment of everybody in the accounting department to numbers starting with 2, everybody in the customer service department to numbers starting with 3, etc. This can be an advantage in sorting message accounting outputs, and it can make internal calling easy. With computer control, where translation is just a matter of a look-up table, the ease of implementing and updating translation information makes just this sort of thing possible. And when the full range of numbers can be used, independent of the actual number of extensions, many conveniences can be set up. Keep in mind, however, that DID extension numbers, being locked into the nationwide numbering plan, impose certain limitations on translation independent of PBX capabilities.

The question a proposal should answer for you is this: can any extension number be assigned to any line-port on the switching matrix? If not, what are the limitations? If you cannot use the full range of numbers or if some groups of numbers must be associated with some switch inputs, your future plans may well be limited before you even start.

Hunting

Hunting might equally well be considered a station feature, but, because of its long inclusion in PBX systems and its close relation to translation, we'll put it here. Hunting is a function, built or wired into the program or system, that lets a call to a busy line reach an alternate line. Hunting differs from the station feature, "call forwarding on busy," in that the latter is usually programmed by the station user as required.

There are three main kinds of hunting in general use today, and many more possibilities that are, as yet, untapped. But circular, terminal and secretarial hunting are good examples to start out with. Circular hunting says that every line in a group will be tried for busy when a call is to be completed to any given line (or a pilot number) in that group. In terminal hunting, by contrast, the system will start at the particular number in the group that has been dialed, and go from that number to the end of the group and stop, omitting any numbers that may have preceded the dialed number. Secretarial hunting is a form of terminal hunting where any one of several numbers or groups of numbers can hunt to a common number or group of numbers. As an example, one secretary may serve three salesmen. Each salesman's number will hunt, when busy, to the secretary's number, without hunting through the numbers assigned to the other salesmen. It is possible for the secretary to have two lines in hunt so that she can handle more than one overflow call at a time. Or, one of the salesmen might have two lines in hunt, either circular or terminal, with hunting to the secretary's number only if both are busy.

In older systems, terminal hunt was all that could be obtained, and numbers had to be consecutive for it to work. This shows the relation between hunting and translation. To be most useful, numbers should be assignable to hunt groups independent of their actual numerical value (423 should be able to hunt to 627, if desired), and independent of whichever position they occupy on the switching matrix (they shouldn't have to be on the same or adjacent line cards, for instance).

Pilot numbers are often used, particularly with circular hunt. Properly, one should use a pilot number when any member of the group will do, as in placing orders or reservations. Further, the system can arrange to start its hunt for a new call at the point where it left off after completing the last one ("distributive" hunting). This equalizes the traffic delivered to each extension in the group and, in light traffic, it equalizes the work load of the people receiving the calls. Note that one DID number can be used as a pilot number, while each extension within the group can be a normal internal extension. This saves DID numbers and minimizes personal calls.

Note that not all systems offering circular hunt with pilot numbers work this way. Some of them always start at the same extension, giving one person most of the work load. This is often undesirable, and it is something you may need to know before you buy. Sometimes, however, it will not matter. If a system does have load equalization on circular hunt, it should also permit any station in the group to be removed temporarily, as when somebody goes to lunch. There is no point in delivering traffic to an unmanned position when manned positions are available. Don't assume you have this feature; ask before you buy.

Restriction

Restriction is a function long associated with PBXs. Separate, stand-alone units have been used in the past. Both Stromberg-Carlson and North Electric make such units, and Phonetele has a very modern item on the market using ROM solid-state technology. Stand alone units simply monitor the digits going into the central office and, if they see somebody dialing a restricted office or area code, they block the call. They do this for all calls on the trunk group, independent of the person calling. To let some people be “unrestricted," it is possible in older PBXs to give them exclusive access to separate trunks which have no restrictor associated with them.

In passing, it should be noted that restriction is not the same as toll diversion. Toll diversion is a central office feature that checks a dialed number to see if it is toll or local, and if toll, prevents its completion. In contrast, the area covered by a restrictor can be set up to include local or toll calls or both, as desired by the customer.

Clearly, it is foolish to use external equipment or central office services to do what a PBX ought to do all by itself. One should not consider any new PBX that does not have full capability of limiting calling range. But, since the control of modern systems is so flexible, restriction must be given a new and much wider meaning.

In the first place, restriction should be able to offer different calling areas to different extensions on the basis of class marking. Some extensions should be limited to intra-PBX calls, others should be kept within the area of local calling, some should be permitted to go as far as the state line, others should reach the Band 1 WATS area, and a few should have the world.

But this is just the beginning. Almost everybody these days has FX lines, WATS lines, tie trunks and the like. Who should be permitted to use these facilities? More important, what kinds of calls should these facilities be permitted to carry? With automatic route selection (ARS), the question is eliminated since the system will route calls the proper way independent of the whims or memory of the user. But not all systems have this feature, while most have some form of restriction. So we have to be sure the system knows what it is doing.

To me, one of the most important functions of restriction is to make FX and WATS lines work economically. It drives me bananas to see somebody in Philadelphia use his FX line to New York to call Boston. For a 5 minute call, the difference via DDD from New York vs Philadelphia is 15 cents. Nobody can run an FX line in such a way that it averages out to three cents a minute; you lose your shirt.

Thus, a well designed PBX restriction system should prevent anybody from grabbing the FX line to New York and calling Boston. FX lines should only carry local calls, no matter who places them. Similarly, Band 5 measured WATS lines should not allow anybody to place calls on them to points nearer than about 300 miles. But do designers consider this? No way. If a station user is unrestricted, he can place any call he likes on any facility he chooses. Demand in your specification that restriction on anything other than the main outgoing CO trunk group be based on the trunk group rather than the caller. You won't get it, but we are building for the future.

Another thing that drives me nuts is three and six digit restriction. Back a million or so years ago, when translation was done with funny looking electromechanical equipment, both the routing of toll calls and the restricting of PBX calls was very difficult. The mechanical brains had to strain to perform at all, so their work was simplified as much as it could be. Thus, they would look at the first three digits to see if they made up an office code and, if not, they would look at the first six digits to get both area and office code. They would then find the required route, or decide to block the call.

With a computer, it should be obvious that sticking to three or six digits is like leading a dinosaur on a leash. We'll consider this further in connection with ARS, but right here we need to keep in mind the most obvious requirements of restriction. In particular, the system should be able to restrict on a full seven or ten digit directory number in the public network. Any consultant who has checked off calls to Dial-a-Joke or Off Track Betting knows just exactly what is involved here. It should be possible to block calls to a list of seven or ten digit numbers as a matter of course. Do you think you can buy this? Well, maybe some day.

Another restriction idea that I would like to see somebody offer is in connection with abbreviated dialing. One "common list" of abbreviated dialing numbers might be thought of as a permitted area, and anybody with a classmark for that area could call such numbers. This would allow calls to be made to specific telephone numbers in, say, San Francisco, Los Angeles, Chicago and Boston by people normally restricted to the local calling area. Allowing such abbreviated dialing numbers to override general areas could really be a money saver.*

[* Footnote: Since this article was first published, a number of PBXs have added the feature. But IBM, I found, has been doing it in Europe on the 3750 for years.]

Ringing

There are various kinds of ringing in use, and we have already considered tone ringing versus power ringing in an earlier chapter. What we want to cover here is immediate ringing and distinctive ringing. Ringing is normally on for two seconds and off for four. Thus you can be connected to the called party for up to four seconds before he knows it. With immediate ringing, ringing starts as soon as the switch connects to the called terminal. This speeds service, valuable particularly when a console attendant is staying on the line to be sure everything goes ok.

Distinctive ringing is a little different. With distinctive ringing, calls from outside, for instance, have one sound, while intra-PBX calls have another sound. Dimension gives the latter a conventional single ring, while outside calls get a double ring as in England. Dimension goes one step further: when automatic call back or trunk queuing is bringing you a connection you have been waiting for, ringing comes in triple bursts. Distinctive ringing turns out to be far more useful than one might suppose, particularly when queuing is available. When you answer the phone and get dial tone, it's nice to know you have the WATS line at last.

Trunk queuing

Automatic route selection tends to be quite complex and, as I have indicated, isn't offered on every system. Trunk queuing, however, is fairly simple and no new PBX should be considered if trunk queuing isn't offered. Trunk queuing can earn its keep even if you only have a single WATS line; it can also make use of a single FX line practical. Small trunk groups are very hard to load effectively without queuing, but with queuing, they can do wonders. Since the great majority of PBXs tend to be small, trunk queuing is one of the most important features available.

Now comes the problem. There are two kinds of trunk queuing: off-hook and call-back. With off-hook queuing, the caller, upon discovering that the facility he wants is busy, simply holds the phone. Usually, to keep him occupied, the "music on hold" feature comes into play. When the trunk comes free, the music goes away and the user has dial-tone from the central office.

Call-back queuing is more satisfactory if there is going to be a long wait. Consider how the Dimension does it. The user dials the access code for the facility he wants, but it is busy. The system gives him a special tone burst (confirmation tone) to let him know that he has been put in the queue for that facility, and he hangs up. When the facility comes free and the caller is next in line, he is called back with a distinctive ring. If the caller had not wanted to be in a queue, he would simply have stayed off hook about ten seconds after hearing confirmation tone, and the system would take him out of the queue and give him re-order tone to prove it (reorder tone is "fast busy").

This illustrates another point about stored program systems. The Dimension originally returned busy when the facility was full; the user then had to hang up and re-dial the access code along with a special code that told the system to put him in the queue. The new way strikes me as quite an improvement over the old. But the only thing that was changed was the program.

The use of queuing must be watched carefully. Do not, for instance, queue on a two-way facility such as a tie trunk. If you do, you are likely to freeze out callers from the other end, particularly if they do not have trunk queuing. If both ends have it, "glare" will occur much too frequently.

Perhaps the least mentioned aspect of queuing in proposals is what station actions take the user out of the queue. In some systems, he is bounced if he makes or receives a call. Being dropped from a queue when you do not know it can have you living in a fool's paradise.

Automatic route selection

Automatic route selection (ARS) is the biggie, the thing that separates the men from the boys. This feature is the most natural thing in the world to expect of a computer, but you have to know what you're actually getting and you have to plan carefully to make sure it does what you want. "Keep it simple" is a good rule to follow.

Some of the properties an ARS system should have are these: it should be able to hunt over several different trunk groups for an idle facility; it should be able to add or delete digits as required by a group (include the area code with a WATS selection, but if it uses the FX line, drop the area code); it should be able to modify its hunting rules as a function of time of day and day of week (DDD is less expensive than measured WATS after 5 PM and on weekends); it should be able to queue over several early choice trunk groups simultaneously, and it should be able to complete a call over a more expensive facility if desired at the end of a selected period of waiting in the queue if none of the lower cost circuits becomes available.

For ARS at its best, the user should dial the called number (usually after an access code) and let the system do all the work. That is the whole purpose of the system — to make sure the calls are placed properly without elaborate instructions to the users. But sometimes you run into weird things. For instance, Womack's system does everything you might wish except for one very minor point: it won't let the user dial the whole number. If it decides, after looking at the first three or six digits, that the call is to be queued, it immediately returns music to tell the user to stop dialing. Since only off-hook queuing is used and the call is advanced to a more expensive facility after a fairly short interval, the delay is usually not long. But the operation is annoying and serves no useful purpose whatsoever. This is typical of the kind of thing that gives designers no difficulties but drives customers batty. Hopefully, a change will come about shortly.

With any form of route optimization that uses callback queuing, it is obvious that the user should not have to re-dial the called number after getting the trunk. But if the system outpulses the number from a sender rather than "cutting through" and letting the user take it from there, there can be quite a delay, especially when dial pulsing is used.

Some systems provide dial pulsing to the central office so that they can allow station users to use pushbutton phones in areas not yet converted from rotary dials. Further, since dial pulsing is much more expensive for the telephone company to handle, trunks conditioned for pushbutton dialing cost the user a great deal more. In a medium to large system, the premium for using tones on trunks can amount to a lot of money. Thus, the user may want to use dial pulsing, extending the holding time of the central office equipment and slowing down the handling of the call.

To minimize the post-dialing delay (the interval between the end of customer dialing and the return of audible ringing from the called party, overlap outpulsing is used. That is, the PBX starts to outpulse digits as soon as it has a trunk, overlapping the first several digits outpulsed with the last few coming in from the caller. This, of course, cannot be done when a call is queued.

If calls are queued, the additional fifteen seconds required to transmit a 10-digit number is just too much. Obviously, tone outpulsing is desirable from senders, since it takes only one second. But, for obvious reasons, tone outpulsing should not be done in an overlap mode. The system should let the user finish dialing; then it should look for a trunk or a queue, and it should only start outpulsing after it knows what it is doing. A one second delay is negligible, and the number of senders needed, because of the very short holding time, will be very small; further, trunk holding time will be greatly reduced, an important matter when considering full period WATS lines. Note also that calls aborted by the caller for one reason or another before dialing is finished will never even seize expensive facilities.

Most ARS systems are designed to work only with the public network and CCSA. That is, they make a choice of which facility to use, outpulse seven or ten digits, and let the connecting system take over. When dial-tandem networks are encountered, the situation becomes much more complex. Dial tandems require variable numbers of digits, and they permit off-net access via distant PBXs as has been discussed earlier. Thus the route optimization system must either be able to decide if it should dial 415 plus a seven digit number into a WATS line to call San Francisco, or if it should dial four arbitrary digits into the dial tandem to reach the San Francisco PBX, then dial 9 to get outside, and then dial seven digits into the San Francisco central office. If you have a tie trunk network and you plan to add a modern PBX, approach the whole thing with great caution.

Automatic message accounting

Automatic message accounting is another of the features that are natural candidates to build into a computer-controlled PBX. After all, the PBX knows the calling extension, the dialed number, the facility used for placing the call and, in most cases, the time the call is placed and terminated. With all this information available as a matter of course in setting up the connection, it should be trivial to simply record it on tape for later processing. It boggles the mind to contemplate modern PBXs that make no provision for using this information. They simply throw it away and the customer must, if he wants message accounting, attach one of the many stand-alone monitors that are available.

What should a proposal tell you about message accounting? First, it should tell you exactly what is going to contain the recorded information. Is it a voice cassette, a data cassette, a 9-track computer tape, punched paper tape, or what? Does the recording gadget use spare tracks on the same medium that contains the system's back-up program, or does it have a separate mechanism? How many calls can be recorded? Then we come to the jack-pot question. Once the calls have been recorded, who will process the data and for how much? Who will remove the tape from the system and put in the back-up or alternate tape? Who will decide when to erase the data once it is processed? What happens if the tape or other medium cannot hold a full month's data? Who provides the weekly or semimonthly storage so that the information for a whole month can be accumulated for one computer run? The silence from vendors on these items is deafening.

There are a few other points. Provision should be made for the caller to enter a billing code so that calls can be billed to different projects or clients. If the switch is to handle tie trunks as well as local extensions, message accounting data for tie trunk-originated calls should also be recorded, along with a billing code to identify the remote extension. In place of the calling extension, of course, the system should record the identity of the incoming trunk. When a hub-type switch is contemplated, considerable attention should be given to the possibility of centralized WATS* and switchboard attendants; message accounting for remote locations adds very little incremental cost, but provides a great addition to service for calls handled via the hub.

[* FOOTNOTE: New WATS tariffs as of June, 1981, eliminated Full Business Day WATS and made centralized WATS much less attractive.]

Traffic recording

If the system can record call data, it can also record traffic data. Will it? If so, in what form? Occupancy and "peg count" per busy hour for trunks is helpful, and if this traffic is broken down by incoming and outgoing, it is even more helpful. But, if you are queuing calls for outgoing trunks, be they WATS lines, FX lines or whatever, the above data will not be enough. Once you have a queue, you must know how long people have to wait for service. If the queue is doing its job at all, during the busy hour you will have something like 0.85 erlangs per trunk. You can't get much more into the system, since a trunk must be free to be seized, and you can't afford much less if the whole thing is going to pay off. (Note that .85 erlangs is 51 minutes or 30.6 CCS). So the system should tell you the average delay in the queue and the longest delay in queue, or something equivalent. Otherwise you don't know much about your traffic. The system should also be able to give you an average holding time (occupancy divided by peg count), since traffic tables are all arranged to deal with delay in terms of holding times.

Other things that are nice to have are the wait in queue for the console, the number of line, trunk and service circuit busies hit during the hour (a service circuit is a tone source, dialing detector, etc.), and the number of times during the hour the PBX matrix was blocked. Busy hour call attempts, including both successful and unsuccessful calls, is also important to know. The central computer makes about the same effort on a call whether or not it goes through, and the real-time capabilities of any processor are limited.

Since we are no longer tied to traditional recording equipment, there ought to be new and novel ways to present data that would be meaningful, such as percentage of time during the busy hour when all trunks in a group are busy and, if various trick routing schemes are used, percentage of time that the last choice trunk (perhaps a DDD trunk) is busy or, better, how many calls overflowed the last choice.

Needless to say, you won't find this kind of information in a proposal, even when the system has some pretty good information available. Keep asking.

Tie trunk switching

This is a system feature that we have already covered under matrix design, trunks and message accounting. The basic requirements for accessing a tie-trunk network are much simpler than are the requirements for acting as a hub and providing tie trunk-to-tie trunk connections. Don't buy more than you need, but don't freeze out your future, either.

Direct data input

With so many PBXs operating internally in a totally digital manner, it seems logical that data line cards should be available, without A/D and D/A converters, so that a digital bit stream from a computer or terminal can enter the system directly. That is, without a modem. Voice line cards and data line cards should be interchangeable, and within the all-digital system, which might include directly interfaced T-carrier trunks, data could be moved quickly and easily. Note that remote switching units, part of the switching matrix but located in the terminal room or the computer room or elsewhere, would make data access easy. SL-1, Wescom and others are set up to provide remote switching units, and some day .. .

But what do we have today? If you want to put data through your system, you have to have a modem or an acoustic coupler or some such at each end of the connection. These gadgets turn digital data into digitally modulated analog signals to go through a voice bandwidth. Once inside the digital PBX, the analog signal is converted to digital, switched, reconverted to analog, and sent to a modem that turns it back into digital. There used to be a newsreel commentator in the old days who had, as a tag line, "Monkeys is the craziest people!" He had not, of course, heard of data transmission.

The only ray of hope along these lines is the Danray switch. It is space division with an analog PWM modulation scheme to make the use of solid-state crosspoints more effective. The last possible candidate you would expect for a data switch. But Danray has three pairs to the electronic subset, and one pair is for power. They have a little data box that can be put near the telephone set that accepts data directly and sticks it on the power pair. They also have a special switching matrix for data. The nice thing about all this is that you can use your telephone for regular calls while data is thundering back and forth on the station wiring.*

[* FOOTNOTE: Northern Telecom bought out Danray and added a modified version of this feature to the SL 1 Danray people formed Intecom and are offering even more Rolm followed a little later and others will doubtless fall in line.]

CONSOLE FEATURES

We have already discussed console displays and, to some extent, how consoles work. But console features, from Table 4, page 42, must also be understood. If you don't know what to look for, you won't know when you don't find it.

Straightforward completion

Straightforward completion means, very simply, that when you dial 0 and ask for help, the console attendant can extend your call for you and drop off. The alternative, frequently found on electromechanical PBXs, forced the attendant to ask the caller to hang up. The attendant would then set up the call and call back. If she forgot the-caller's extension, she was in trouble. Nobody in his right mind would think a PBX would be designed without straightforward completion. But the way things are is not always the way things should be.

Splitting

This is a feature that lets a console attendant, in the middle of a connection with two other people, talk to either one selectively. It can be very important when the attendant is screening calls, or any other time when she must confer privately with one party.

Priority access to trunk groups

Many electronic PBXs have this feature; it allows a caller to get the WATS line or the FX line without waiting for a queue or battling other people who are dialing the access code over and over. The attendant can gain access immediately as soon as the facility comes free, overriding others trying to get it or waiting in queue. If not abused, this can be a good feature.

Trunk group use monitor

Some systems provide a display for each trunk group that shows the attendant when there are only X or fewer trunks available in a given trunk group. This gives the attendant some idea of which trunk groups are overloaded, and also warns when to expect priority access to trunk groups to be invoked by users getting all-trunks-busy signals.

Camp-on

In a cord board, if the called party is busy, the cord normally used to connect to the multiple can simply be left free, reminding the attendant that someone is waiting. When you have a console, you don't have any cords, and something has to be done with an incoming call when the caller is willing to wait to reach his party. Camp-on is the answer. The attendant simply assigns the call to the desired number and releases. The calling party is on hold, for all practical purposes, until the call in progress is terminated.

Camp-on with indication provides a tone to the called party to let him know that he has another call stacked up. Hopefully, he will terminate his present call more quickly. However, there is an interesting problem here. Does only the called party hear the tone, or do both parties? If they both hear the tone, as seems to happen on many PBXs, which one should go after the call? What happens if the wrong party goes after it? Few proposals provide any guidance on this interesting issue.

Does camp-on override hunting? Sometimes it does, and sometimes it doesn't. Similarly for call forwarding and other exotic station features. You will have to find the answers sooner or later.

Timed recall

This is a good feature in that it prevents camped-on calls from waiting forever for the existing call to be over. It also works in ring-no-answer situations when the attendant has set up the connection. The more interesting question here deals with DID and tie trunk calls. Do these calls, after a ring-no-answer interval, get "recalled" to the console? Whether they do not should be a customer option, or maybe even a station option. Until you try it on most machines, you never know.

Transfer

To me, transfer is one of the main features that make a PBX differ from a small central office switch. When you get a wrong number in the public network, you expect to hang up and try again, but when you call a business and get a wrong extension, you expect to have your call transferred to the proper party.

Since the year one, PBXs have been able to transfer calls set up by the attendant. One would simply flash the switch-hook, and the attendant would enter the connection for instructions. When cord boards vanished, replaced by consoles, attendant transfer became more difficult. Some of the fairly late-model electromechanical switches permitted either station transfer or attendant transfer, but not both. Ideally, the station user, wishing to have the attendant transfer the call, should simply flash and dial 0; the attendant should then be connected into the existing call for instructions as with a cord board but with a lot more complex switching. Since only the attendant will have an up-to-date extension list, you must have attendant transfer, even if station transfer, to be discussed later, is available.

Conference

Any connection among three or more people is a conference. Thus a transfer operation tends to be a conference of sorts. Most PBXs have a station feature, three-way conference, built in; if you need conferences with four or more people, the appropriate circuitry and setup control is usually associated with the console. Multi-party conferencing is needed less frequently than many designers realize. But if you need it, be sure it is available.

Paging and parking

Paging is one of the most important features a PBX can have if people, such as programmers, engineers and technicians, salesmen, etc., are not at their desks for an appreciable percentage of the day. If you need paging in your new system, be sure you understand how it will work. Can the console attendant access the paging amplifier easily? Is Zoned Paging available, so that the search can be carried out in specific areas rather than overall? How does the paged party respond?

Response is interesting. If the called party simply picks up any nearby phone and dials 0, he should reach the console attendant who should then be able to tell him about the call. He can then decide whether or not he wishes to accept it. It should then be easy for the attendant to connect the calling and called parties.

"Parking" is an interesting approach to this problem. If the attendant is busy, she should be able to "park" the call on a dummy line and then tell the called party, via the paging system, to "pick up" on the dummy line number. Some systems will allow a call to be parked on the called party's line without ringing so that the page can request the called party, wherever he may be, to pick up his own line. Note that with either kind of pick-up, the attendant does not enter the call or screen it further. When the called party picks up, he gets the calling party directly. Note also that if there is no response to the page, timed recall must come into play to return the call to the attendant. But just because it must, doesn't mean it will. Or that your proposal will let you in on what actually happens.

In many systems, paging and parking are also station features. In such instances, the answering party puts the incoming call on hold (as will be discussed below), dials up the paging amplifier and announces the call. The called party then calls back the paging party who has hung up. The pager announces the call, does whatever the system requires to produce a conference, and then hangs up. On the other hand, instead of putting the incoming call on hold, the pager can simply park the call on a real or dummy line and request that that line be picked up.

Heavy traffic overflow

Most PBXs have and need only one console. However, there will be times when there will be too much traffic for one attendant to handle. A useful feature is one that overflows incoming calls to selected telephones where specially alerted secretaries answer the calls and use station features to transfer them to the desired extensions. Heavy traffic overflow can go into operation automatically, or at the push of a button on the console. Distinctive ringing can be a useful feature here so that the regular extensions will know the difference between an outside call and an intraPBX call.

Universal night answer

Universal night answer is a feature very similar to heavy traffic overflow. When the console is closed down for the night, special bells around the company are activated. An incoming call causes these bells to be rung. Any user hearing the signal can go to any phone and dial a code (seldom the pick-up code, unfortunately) to get the call. The call can then be transferred using station features.

A rather nice feature on the Womack locks in UNA when the attendant's head set is removed. In particular, nothing can be done with the console at such times. This is a great help if unauthorized people, cleaning people, etc., have access to the reception room or other console location. They cannot make unauthorized calls or accidentally turn off the UNA.

Fixed night answer

On PBXs without DID, it is sometimes desirable to take certain extensions and connect them to specific central office trunks when the console is closed down. In older systems, this was an actual connection, either with cords or with the switching matrix, and the station could not be used for intra-PBX calls. With newer systems, there is no need to put more than a notation in system memory. On incoming calls, ringing is repeated at the specific extension; upon answer, the path is cut through directly. On outgoing calls, the specific extension will get the specified trunk upon dialing the outside code. This technique is particularly useful when the regular dial-9 trunks are toll diverted, but the incoming central office trunks are not. Normally, the incoming trunks can place outgoing calls only with the help of the attendant.

Note that universal and fixed night answer should not be mutually exclusive. It is often desirable to use the first two or three trunks for UNA, and let calls on the remainder be patched through (or the program equivalent) to specific extensions. But do not expect systems to work this way as a matter of course; many of them don't, as your proposal will not tell you.

Alarm display

Most systems have major and minor alarms, and display them at the console. Sometimes the system can give further information via alarm displays. This is a good feature to know about.

Operate without a console

Can the system operate without a console? Considering the power of station features, particularly when electronic key sets are used, this is a worthwhile question. Not only can you sometimes save money by not having a console, but you can also solve certain personnel problems. In particular, anybody who can operate station features on a regular phone can operate the phone that is used as a "console." Personnel cannot give the excuse that they have not been checked out on the complicated machine.

If alarm displays are normally on the console, find out where they will be if the console is removed.

Maximum number of consoles

In larger installations, more than one console will be required, regardless of the efficiency of the system. Thus, it is important to know how many consoles can be added, if the system will distribute traffic evenly over the consoles in service, and if some consoles can be taken out of service when traffic is low enough to permit. It is interesting to note that not one PBX manufacturer that I have contacted knows how many calls per busy hour one of his consoles can handle. Thus, nobody really knows when the breakpoint between one, two, three or more consoles takes place. Judging by earlier systems, 400 calls per busy hour is probably about tops. If your console runs slower, I will not try to console you.

A note on WATS

Prior to June, 1981, WATS lines came in two varieties: Full Business Day and Measured Time. A Band 5 FBD WATS line, covering the 48 contiguous states except for the state in which the line located, cost about $1,700 a month and could be used for 240 hours before additional use added overtime charges. A Band 5 MT WATS line cost about $250 a month, including 10 hours of service, after which overtime usage was charged at a flat rate.

At the moment (Jan., 82), WATS lines cost less than $40 a month, but all usage is charged at "tapered" rates that decline somewhat with usage and are also discounted after business hours. This changes the strategy needed for queuing, ARS, and other aspects of networking. But fear not. Tomorrow everything will change again.

[ Top ] [ Next ] [ Table of Contents ]

Voice Communication in Business Volume 1 Essays on telecommunications, 1969-1980

Chapter 10 Those Awful PBX Proposals: System & Console Features