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

Two Years With Harry, 2

As customers began to realize that they couldn’t “leave it to the telephone company” anymore and had to do the whole job of specifying and selecting a PBX, and then monitoring its installaion themselves, the Request for Proposal (RFP) process took on a life of its own. My second column, in the April 1983 Teleconnect, took a look. Again, Harry renamed it.

...And There Are Also Awful RFPs (Writing it Right)

I have frequently had occasion to comment on the less than satisfactory nature of proposals for PBXs and other expensive telecommunications equipment. However, I would be less than honest if I did not make some note of the bizarre requests for proposals often visited upon unsuspecting vendors. RFPs should give some clue as to the wants and needs of the customer. Contrary to present practice, they should not be vehicles to demonstrate that the communication manager or his consultant knows the names of 2687 standard PBX features.

Few consultants, in particular, seem to realize that, while a big RFP, bristling with tricky specifications and questions, may impress the client, a complete and accurate proposal in response will require examining each and every item presented, and from several vendors! Not only is the proposal expensive for the vendor to produce, it will be doubly difficult for the consultant to evaluate.

I have seen RFPs composed of questions concerning all the features and functions listed in my own BCR Manual of PBXs, plus all the items in several other similar manuals. One might suppose that reading the comparison manual of one’s choice might be more productive than copying questions already answered, but a big RFP seems to have the same appeal as a fat proposal. Why waste time asking about features and functions known to be present?

The most important thing that should be in an RFP is the size and growth anticipated for the system. It is the responsibility of the customer to know how many extensions and trunks will be needed at cutover, and to provide the estimated number that will be required at one, three, five, seven and perhaps 10 years later. Further, busy hour call attempts (including retries, aborted calls, feature activations, etc.) must also be estimated for the same period. A light traffic system may offer real opportunities to save, while a heavy traffic system must be anticipated to prevent disappointment or disaster.

When speaking of traffic, it is not uncommon for the naive to specify a non-blocking system “to make sure important calls can always get through.” One specifies a non-blocking switching matrix to eliminate the administrative cost and bother of traffic balancing, to permit “nailed up” connections to be established (particularly for data) without affecting the traffic handling capacity of other extensions and trunks, and to permit switching high-traffic facilities such as tie-trunks or ACD stations.

But even so, a non-blocking matrix will not guarantee that the call “can always get through.” If you don’t have enough DTMF signaling detectors, a call will be delayed. If all trunks are busy, you can’t get out. And if you dial a busy extension, there will again be a blockage or delay. There is seldom any point in paying extra for the ability to reach busy lines or trunks. On the other hand, today’s technology has so reduced the cost of a non-blocking matrix that in many cases the slight differential in initial cost can easily be justified in terms of administrative savings over the life of the system.

Rather than listing all possible features, an RFP should point out special or unique needs or operations within the company that will interact with the telephone system. The existence of a catalog order or service department, for instance, should be noted, along with the need for direct access from outside and call distribution. The number of multi-button sets, too, and the reasons for their use can be better defined by the customer than the vendor. Indeed, any customer who thinks that only single line sets will be needed should be made aware of what modern telephone sets can mean to his operation.

What can be done to encourage better RFPs? Let me offer a suggestion to vendors: Include in mail advertising and/or glossy brochures a sample RFP containing a list of questions whose answers would help you better serve the customer. Ask about growth, traffic, special requirements and the like. There is no harm in asking if the customer needs exactly those things your system does best; after all, the customer will read similar ads from others who have different specialties. Do you have an energy or property management package? Do you have a really user friendly administration panel to facilitate moves, changes and ARS modifications? Encourage the customer to ask you about them. He may not even know they exist.

Telephone systems for business are quite remarkable these days, but they are nothing compared to what they could be. Encouraging the customer to ask for what he or she needs and the vendor can deliver might be good for everyone. How will customers ever be ready for tomorrow if they don’t know how to take full advantage of what a modern system can do for them today?

Unfortunately, we still did not have utopia. Both RFPs and Proposals continued to have their problems. But I had at least lit my small candle even as I cursed the darkness.

[ Top ] [ Next ] [ Table of Contents ]