Five years ago, TMC, the parent company of this publication, set out to
purchase a new phone system that could handle the needs of all 30 employees
and would grow as the company grew. We had a great telecom manager who was
adept at exploring the many options available to us, and he identified
systems from the likes of Nortel
Networks and Comdial Corporation,
as well as an unlikely option called ISDN Centrex.
Having recently spent a few years in Germany, my able telecom manager
espoused the virtues of ISDN and told me that this type of Centrex would be
less costly to our company than any hardware alternative, while also
insulating us from being stuck with a phone system that would soon be
obsolete.
He attempted to schedule an appointment with Southern New England
Telephone (SNET), the company that
provided local telephone service and ISDN Centrex in our area, and much to
our disappointment, we would have to wait a month or so to get a demo of the
system in action. It seems that a single salesperson handled this particular
type of Centrex, and he was booked solid. In the meantime, we met with
salespeople representing just about every other phone system you can
imagine. When the time came to visit SNET, our salesperson had become very
ill and our appointment was postponed.
It was at this point that I began to suspect traditional service
providers (or at least the one handling Connecticut) weren't equipped with
the necessary tools to sell anything but long-distance, even when they had a
better solution to sell us. All of the existing phone companies were fat and
happy. After all, they had a great business model -- charging high prices on
long-distance service -- something that doesn't cost them very much.
So we ended up with a PBX and within a few years, the newly invented
PC-PBX offered more flexibility than our PBX at a great price. Soon
thereafter the IP-PBX made the PC-PBX obsolete in terms of features. In
about three years, our "state-of-the-art" PBX was two generations
behind in technology. Over the last few years, I have often thought to
myself that if a smaller, nimbler company had been in charge of selling us
ISDN Centrex service, we probably would have chosen this option and would
likely still be very happy with it. Outsourcing our phone system made so
much sense to me at the time.
THE CASP PROLIFERATION
A few years back, another type of outsourcing became popular and the
term application service provider (ASP) was born, referring to companies
that outsourced applications, which typically meant software. I devoted
little gray matter to this new term, as it seemed like it was more
applicable to word processing than anything in the communications space. But
was I ever wrong.
About a year ago, I met with representatives from Telera,
who demonstrated that they could outsource communications functions that
were familiar to all of us, but at the same time leveraged XML to allow
developers to design applications of incredible power and simplicity.
A simple example of this type of application is the ability to set up a
voice portal that can be programmed on the fly to stream media such as radio
stations and conference calls to telephone users. Other examples are the
ability to use predictive dialing technology to immediately send a (variable
or static) message out to large groups of people by phone, especially useful
if you are an airline and your flights are frequently delayed (obviously
this applies to all airlines). My favorite example is voice enabling a Web
portal, allowing users to schedule wake-up calls filled with customized
information such as traffic conditions, the weather, and perhaps stock
market futures information.
Then, about six months ago, I met with an old acquaintance of mine who
was working for congruency, a
company billing themselves as a communications ASP (CASP). What really
impressed me about their service was that it was based on IP telephony and
made use of a Web browser-enabled phone that I would liken to the Ferrari of
telephones in terms of looks and performance. congruency was using the CASP/phone
combination to automate hospitality applications and other vertical markets
in the communications field. I immediately saw the potential of the
communications ASP market and I knew it would be huge... I was truly wowed.
It was at this point that the idea for this magazine began to take shape.
congruency was really making good use of IP telephony and providing
unprecedented and flexible services. This was great to see, as I have been
involved in the IP telephony market from the beginning... And now most
everyone who knows about communications knows that the public telephone
infrastructure is undergoing a radical shift to IP-based or packet-switched
networks. We have all heard about the virtues of IP telephony-based networks
-- these networks are not only less costly to build and maintain than their
circuit-switched counterparts, they also enable services like Web-based
unified messaging or more granularly, being able to push data such as an
e-mail or Web address on any call. congruency and Telera showed me how much
potential there was in the market of providing enhanced telephony services.
Analysts have been predicting that new services would drive the
communications market forward and the growth of new service providers would
be unstoppable. I have followed these announcements closely and I have been
waiting for the advent of these services to begin... After all, the IP
telephony market rapidly exploded with growth... Why does it take so long to
deploy a myriad of new services beyond the basics like Web-based unified
messaging that we have all seen from a variety of service providers?
I believe that the age of new communications services is finally here --
we have a new category of company that will be tasked with providing
customers with the latest communications technology on a leased basis. These
companies will be called communications ASPs or CASPS.
CASPs already provide services that make any variety of Centrex very pale
in comparison. CASPs have the potential to do extremely well in the market
because customers will not be required to purchase costly telecom equipment
that becomes obsolete, and they won't need armies of technical people to
configure and reconfigure closets filled with telecom equipment. Moreover,
CASPs allow customers to pay for just the number of users and features they
need at any given moment as opposed to purchasing equipment with more ports
than they currently have the need for.
THE CHANNEL OPPORTUNITY
As I found with ISDN Centrex, it does no good to have the best solution
on the market if you have no idea how (or desire) to sell it. There are new
communications ASPs getting tremendous amounts of VC money even in these
tumultuous capital markets because the need for communications ASP services
has never been greater. All that is needed now is a way to sell these
services to the public.
Simply put, many CASPs need a channel to sell their services to end users
and the existing competitive local exchange carrier (CLEC) market is the
perfect place to begin with. Recently, CLECs have fallen out of favor with
Wall Street, but CASP services are the undiscovered source of golden eggs
for these providers. I expect there to be many other service providers
selling CASP services as well... building local exchange carriers (BLECs),
cable companies, and wireless providers are just a few that come to mind.
But how will these service providers know what CASP opportunities are
available to them, which products they need to purchase, and which services
to resell?
THE PURPOSE OF COMMUNICATIONS ASP MAGAZINE
This publication will serve many purposes, but primarily it will be
devoted to the opportunities available to CASPs and the channels that resell
these services, whether they be service providers themselves or
interconnects with a regional interest in selling services as opposed to
hardware-based solutions. It will focus on the hardware needed to become a
CASP, as well as the services that are already developed that would make
great opportunities for any type of reseller. As we have come to expect with
just about every new technology, the CASP market will evolve very rapidly.
It is my desire to keep Communications ASP magazine the leading authority
on the CASP opportunity in the marketplace. If you have any suggestions on
how we can improve this publication or comments worth sharing with your
fellow readers, please address them to Communications ASP editorial
director Laura Guevin or myself.
Thank you for reading and for your support of TMC publications.
[ Return
To The January/February 2001 Table Of Contents ]
|
An Interview With Telephony@Work's Ed
Margulies
Two companies I believe are worth watching in the communications ASP space
are Alliance Systems and Telephony@Work.
In the case of the former, this company is very well known for delivering
industrial computer-based open communications solutions that take advantage of
the power and flexibility of DSP resource boards from the likes of Brooktrout,
Natural MicroSystems, and Dialogic
(an Intel company). Alliance sees a great opportunity to become a leader in
hosting CASP services for others, after all, they have the experience in
building fault tolerant telephony solutions on a grand scale -- why not offer
their services for others to take advantage of? I liken their approach to
attempting to become the Exodus Communications
of the CASP space. (For more information on Alliance, see the Emerging Services
Spotlight.) Telephony@Work is a company that develops contact center
solutions designed with CASPs in mind, and they have created an extremely
modular architecture that is ideal for this space. I thought it would be a good
idea to ask Ed Margulies, the company's chief operating officer, a few questions
about the CASP opportunity and market.
RT: Why is the communications ASP market going to boom?
EM: I think the single biggest market driver is the high expectations
consumers now have in terms of customer service. On the Internet, we can do our
banking, check stock prices, order flowers, and do schoolwork. No wonder
consumers who use call centers are demanding, and call center business managers
are scrambling to add "e" technologies like intelligent e-mail
routing, chat, Web callback, and Voice over IP (VoIP).
The largest segment of the call center market has under 50 agents and a mean
of 15 seats. This accounts for over 159,000 call centers, most of which lack the
economic wherewithal to purchase up-to-date infrastructure. The return on
investment just isn't there for them to add chat, Web callback, ACD voice mail,
VoIP, forms sharing, Web collaboration, ACD fax, etc. Yet the net effect of the
Internet exerts pressure to deliver communications over every media so these
call centers can offer superior services with blended agent seats.
These companies represent an enormous market opportunity in terms of pent-up
demand for the emerging communications ASP market. With a mean of 15 seats, this
"under 50" market represents 2.38 million seats, with baseline growth
of 4058 percent depending on which analyst you believe. Hosted communications
offerings will solve what was once a seemingly insurmountable problem for this
market segment, and will create the next generation "digital dial
tone" for emerging carriers and service providers.
RT: Which technological issues does a communications ASP have to be
aware of before starting their business?
EM: Perhaps the most important for any business with subscribers is
technology that provides 100 percent reliability and uptime. If you can't
guarantee 100 percent reliability to your subscribers, you really have no
business being an ASP. So technology that provides a mirrored, hot-backup of
every single process is critically important to the success of your business.
Here's the litmus test: If 2,000 chats are going on between subscribers' agents
and Web-browsing customers, what happens if the "chat server" function
fails? If the answer is all of the chats are disconnected, then it's not
mirrored hot-backup. If the answer is all of the chats continue regardless --
you've found mirrored hot-backup technology.
RT: Discuss technology blunders that you expect to see the first
communications ASPs making.
EM: The first and most common blunder made by service providers from
the outset is the trap of custom programming and systems integration. This stems
from the legacy mindset that nothing's good unless it's glued together from a
patchwork of disparate platforms in a so-called "best of breed" model.
Why is this a mistake? First, it requires establishing and maintaining as many
as 20 different vendor relationships just to identify the technology elements
needed to do a multimedia e-contact platform. Second, you've ruined your chances
of getting to market quickly, owing to as much as six months to over a year of
custom programming. Third, you're held hostage by whoever programmed your system
and the fact that each time a point technology comes along, you've got to
reintegrate, re-test, recompile, and debug all over again.
The second biggest blunder is getting into the trap of running a "server
farm." This means having to set up and maintain a separate server for each
and every subscriber, and stems from software that has no "host
partitioning" or "shared tenant" capability. Sadly, most
start-ups don't realize they've made this mistake until after they've signed up
a dozen or so clients, and then it hits them: "Oh no, if I add the 200 new
customers this month I anticipate, I'll need two more rooms full of
computers." It gets pretty ugly. Host partitioning allows you to share a
common network of computers yet still maintain private data stores, routing
rules, and libraries for each client. I know this sounds like a no-brainer, but
people actually fall into this trap over and over.
The third biggest blunder is to believe the "scalability" hype you
get from some technology vendors. The term applies to platforms that will
continue to grow without abandoning or outgrowing your initial hardware (and
software) investment. But the real hidden problem here comes after it's too late
(like the server farm) -- and that's what happens when you actually DO grow. In
most cases, when you have to add a process, a server, a node, or a service --
you have to reprogram, recompile, or otherwise disrupt service to do an
"upgrade." Not good. What's the sense in scalability if you have to
shut down service when you grow? What you really need to avoid this mistake is
"dynamic scalability" -- that is, the ability to add processes, nodes,
and services while the system is still running, without any service disruption
whatsoever.
RT: How can these emerging service providers avoid any major
blunders?
EM: The absolute best way to avoid big blunders as a service provider
is to dig deep, really deep, into the proposed architecture of the platform you
are considering. For true, carrier-class platforms, this is no threat to the
vendor. A viable architecture has certain attributes that are obvious once you
start asking the right questions.
Look for a distributed, network-based architecture. This means you are able
to spread out the power and processing capabilities of the platform over a wide
array (anywhere), thus providing not only the ability to grow to very large
densities, but to create systems that can be geographically dispersed for
disaster recovery reasons. Also look for SNMP or SNMP-like centralized network
management, so you have single-screen simultaneous access and control over the
entire platform -- even across dozens of sites. Nothing's worse than doing
individual maintenance dialups into thousands of computers.
Another important architectural attribute is the way the software is put
together -- the fewer the languages, layers of APIs, and shortcut programming
techniques and tools -- the better. Pure, C/C++ implementations are almost
always superior to those cobbled together with layer upon layer of third-party
APIs, tools, Com objects, and other shortcuts. The latter is fine for
enterprise-level, non-mission critical applications, but these don't offer the
same level of predictability and are too dependent on third-party tools.
Lastly, do your best to find vendors with "ASP-friendly" licensing
schemes. You should avoid "per logon," "per user," or
"per seat" pricing. These are based on enterprise-level assumptions.
True carrier-like pricing is based on the idea of "shared resources."
This means you should buy products whose licensing schemes are capacity-based,
not user-based. For example, if you have 10,000 users, only 4,000 of which are
using the system at any one time, it's much more economical to pay for a
capacity of 4,000 than 10,000. In addition, go for licensing schemes that allow
"cross-media" licensing, so the license can be applied across any
media type (voice call, chat, Web callback, fax, etc.) so you don't have to
maintain separate pools of separate technology licenses. Avoid paying
incrementally as you add media types. Get them all upfront if you can.
[ Return
To The January/February 2001 Table Of Contents ]
|