In this and the previous newsletter I prescribe how to get CPE telephony products out of the dark ages. This advice is no less heed-able today as when I first gave it. So there you have the benefits of glacial progress: stuff you thought of years ago can be restated as completely up-to-date advice. The bursting of the Internet bubble and the general weariness of the CPE telephony business ensure that outside of a few small corners of the industry, it won't be galloping away from this position any time soon, either.
Newsletter #20: Envisioning the Telephony Future, the Enterprise Edition
In newsletter #19 we visualized IP telephony for the small business customer. Now we’ll try on the large size enterprise suit. I had promised to discuss moving IP telephony products through the small business channel, but we’ll take a side trip here, for the reason that IP telephony in the enterprise has different and in many ways simpler requirements for formulating the product to the correct channel.
This is very unlike small business: the large enterprise has money and people to apply to the matter of why to do IP telephony. The large enterprise has proven needs, and an institutional memory. The large enterprise, if well run, measures what it does, and so can understand benefits that look alienatingly theoretical to the small businessman.
In many ways, the large enterprise is an ideal place to start selling IP telephony.
But there is a catch: Where visualizing the problems with selling to small business clearly illustrates the problem with a product that is in many instances unfinished, there is a temptation to use the enterprise market as a gradual on-ramp to a complete product vision. This is a false hope. The properties that make the enterprise market more receptive to the technical sell of IP telephony make it correspondingly more demanding that the technology deliver measurable benefits. On top of this, the enterprise customer demands sophistication that many IP telephony systems lack at this time.
Where the small business customer has simple, but demanding needs, no time for chit-chat, and less patience for products that are not full replacements for conventional technology, the enterprise has complex needs that go beyond what the conventional technology can deliver. Each enterprise comes into these needs through its business functions, but we can obtain a good approximation of what the enterprise customer wants by conducting a thought experiment into what a telephone system is.
A telephone system transports audio from station to station, it arranges and manages the connections that do this, and it provides other services, such as call answering, conferencing, logging, accounting, directory services, and a management console. A large part of the impetus toward IP telephony comes from the fact that tools for managing networks have become more evolved in data networks than they are in voice networks, and the unification of management tools centers on standards bred in data networks. With the increasing multimedia content of the Internet, objections to putting voice on data networks have become mostly obsolete. So the functions of a telephone system can be implemented at least as well on a data network as they can on a voice network.
As with our small business customer, you still can’t expect an enterprise customer to forgive lousy station sets, kludgy interfaces, and difficult system configuration. These are the telltales of an incomplete product, and if the basics are not complete, the customer has every reason to expect the nifty stuff to be substandard as well. Risking antagonizing his users by installing dicey new technology is also something the enterprise customer has little or no incentive to hazard.
On the plus side of the ledger, there are things the enterprise customer pays attention to that the small business customer does not. But these are not the features typically touted in the collateral for IP telephony products. One wire to the desktop has no attraction for a company that is plenty well wired. Instead, look inside the company’s IT organization. What does a modern IT department do? It creates solutions based partly on technology they buy, and partly on technology they build. These solutions are distributed systems, and communicate via DCOM, CORBA, or Java RMI technologies. The bought technology must provide interfaces compatible with these distributed software interfaces, and must provide functions that are valuable in creating solutions. If you want your IP telephony product to be part of this picture, it must integrate with solutions created by a company’s IT department.
So far, this picture is much simplified. Reality is much grittier. Lots of enterprises are nowhere near the level of sophistication described above. Their needs are much more like the small business customer, who must be shown a simple benefit that goes straight to the bottom line. But we will continue to assume for our purposes that enterprise customers can be quite sophisticated so as to illustrate how such customers are different, and represent a different opportunity. One simplification made by omission here is that the classic problem of selling IP telephony, the split between data and voice, no longer exists. This is a simplification, but it is also correct for the type of customer we are painting a picture of: one with enough IT savvy to make use of the distributed software technologies he finds in other products.
What would an IT department want to do with a phone system? One place we can look for ideas is the penetration of modern enterprise planning and fiscal management software from SAP, PeopleSoft, Baan, and others. These software systems enable the enterprise to link, via databases, all the important activity in the firm. When orders are taken, new materials are ordered, transportation arranged, etc. This revolution in enterprise fiscal management and planning turns what had been lumpy, un-integrated processes into a continuous, always-up-to-date, whole. This improves efficiency because the management’s view of corporate activity is instantaneous. The CEO doesn’t have to wait until the end of the quarter to discover that sales turned good or bad. He doesn’t even have to rely on projections, or “feel.” He’s got the numbers from the last day, or last hour if he chooses.
Linking telephone activity into such a system would enable lead tracking, funnel reports, and information about when, exactly, a customer ordered a product to be used in the planning and management processes. Some of this is as simple as integrating call accounting so that up-to-the-minute data on telecom costs flows into the system, other uses are more imaginative, such as measuring the sales response to out-calls and fax broadcasts. It is in this type of application of IT to business processes that the value of IP telephony will be realized in the enterprise. This is potentially very important. If enterprise fiscal management software enables an enterprise to track business processes from the moment a product is ordered to the time it ships, linking telecom information into such a system could make it not only perfectly responsive to requirements for materials, etc., but also anticipative of coming requirements. Different patterns of telecom activity can be linked to sales results, and used to detect problems with selling a product, channel stuffing to cover for problems, as well as anticipating a better than expected response and ramping up manufacturing to meet it.
What about scalability? Isn’t that an important part of selling something to the enterprise customer? Yes, but this is one place where enterprise requirements are not absolute. Departmental systems that meet requirements for integration with enterprise IT initiatives are valid products in the enterprise space. Scaling down is important, since the life cycle of an enterprise purchase is likely to include a technology demonstration phase where a departmental deployment is made. If this requires all of Hannibal’s elephants to accomplish, it won’t look good. And the key to scaling up is modularity. IP telephony does not have some of the physical limitations of distributed switched circuit systems, and in practical terms, integration with a corporate data network make being distributed much easier. As long as the system is designed to work as a manageable whole even if it is divided among several servers, you have a good scalability story until you start to tun into large scale network design issues. At that point there is no substitute for having built and tested multiple large configurations.
Since the requirements, like integration into IT strategies and initiatives, and advantages, like the ease with which IP telephony blends in with network management, closely resemble the positive characteristics of other enterprise IT systems, this broadly hints at how IP telephony should be sold into the enterprise: In the small business example of the previous newsletter we ran into the problem of the reseller channel. How do you get the interconnects and small business VARs to understand IP telephony. By and large, you don’t, and you must be able to sell IP telephony as if it were conventional telephony. But in the enterprise, you have a natural ally in the systems integrator. If your system is complete, and if your system is responsive to the IT activities systems integrators support, then you have a path to building a channel for IP telephony in the enterprise market that understands IP telephony and understands its advantages.
To sum up:
The enterprise has different requirements, but can’t be considered a shortcut to marketability for incomplete products.
The enterprise is going through changes in the way software is used to control the fisc and business processes. This is what IP telephony and telephony servers have to link in to in order to get the attention of the enterprise customer.
Not all enterprises are progressive and managed using modern tools. Target the ones that are.
The systems integrators are your natural ally, but you have to have the end user’s requirements in place before attempting to build this channel.
Go get ‘em!
Copyright 1998 Zigurd Mednieks. May be reproduced and redistributed with attribution and this notice intact.