This Solution Center deals specifically with "next-gen"
phone systems, aka. communication servers and/or communication
appliances and/or UnPBXs and/or server-based PBXs...; whatever
you want to call it, there's no question that in the last few
years a new breed of telephony system has risen that brings the
LAN client/server model and its implied voice/data convergence
to the basic business-class applications of "private branch"
telephone-call switching/control as well as voice/fax messaging.
Naturally, there are some differences in the way vendors are
creating systems under this rather broad technology heading, with
the biggest dividing line being drawn between those systems founded
on the traditional "Wintel" PC platform and those being
created within the Cisco-like network-appliance form factor.
And while all of these systems plan on incorporating Voice over
IP and IP Telephony (they all, of course, feature TCP/IP connectivity
by definition), some platforms attempt to merge voice / data within
business premises. The result is a brand new market for what some
have awkwardly dubbed "one-wire wonders", i.e. platforms
that put voice on the LAN via VoIP, regardless of what wide-area
network (PSTN or IP or Internet or a combo therein) they presently
employ to speak with the rest of the world.
Overall, unlike the architecture of traditional PBXs, these systems
have programmed logic that can be modified by both end users and/or
third parties. Because most supply desktop call-control GUIs,
they also support full feature-access from generic analog telephone
sets, i.e. no matter what kind of phone is used, the client/server
link with these systems provides a well-defined signaling and
control relationship with the system's common control equipment.
Further, integration of LAN databases are actually expected to
define system call-control parameters.
First and foremost, of course, you must need (to use or resell)
a new business phone system (because you're starting a new business
or opening up a new office, sick of or grown out of your old PBX/key,
looking to resell one of these more modern platforms, etc.).
If this is the case, we absolutely recommend that you look at
the systems included in this Solution Center; we think they offer
definite benefits over traditional key telephone system (KTS)
and private branch exchange (PBX) equipment.
The big reason why is, we think, fairly apparent: they give businesses
much more intelligent, flexible and manageable control over their
telephonic needs.
They also provide features that not even the most advanced PBX
platforms can and they often do it at key-system prices (see the
Interactive
Comparison Tool).
Conventional PBXs are still largely sold on their maximum reliability;
they should be. But next-gen phone systems shouldn't be lacking
here; nobody wants a fancy phone system that's not also extremely
reliable.
Besides questioning the vendor deeply about reliability and
fault tolerance, one other thing to note here are those features
that are invoked if the system does in fact go down (it happens).
These include:
Automatic line bypass (aka. Power Fail Call Handling)
-- This will let trunk lines still ring-through to stations
as the system reboots. Several lines should be available for
this kind of performance;
Fast Power Outage Recovery -- it shouldn't take 10 minutes
to reboot a system either.
All systems should also have a Visual "Trunk-Okay"
Indicator and a real-time monitor that shows overall system
performance.
PBX-like Least Cost Routing.
Besides reliability, one of the more (still honest) barbs you
can make against this new breed of phone system is its lack
of sophisticated (at least when compared to 10-year-old switching
platforms) LCR features.
PBX-like Call Accounting and Traffic Reporting.
The system should absolutely log call activity and include
tracking/billing/accounting software to process this data. It
should also generate reports on system performance/use and let
third-party experts integrate their systems as well.
A very un-PBX-like desktop call-handling GUI.
All LAN-based phone systems should provide a desktop call-handling
GUI that can be configured as a worldwide web interface and/or
a native Windows client. This GUI should show a minimum of 20
line appearances and let you click to take calls, place calls
on hold, send them to voicemail, send them to voicemail and
monitor messages, conference calls by clicking on participants,
conference calls by dragging and dropping participants, transfer
calls by either clicking, or dragging and dropping call appearances,
click on a last number redial key, put callers on hold, park
calls, pick up parked calls, go on/off do-not-disturb and set
up call forwarding.
The GUI should also let a user on a call put a second caller
on hold without ever answering that call -- instead, the system
will play a pre-rerecorded "I'll be right with you"
sound file.
The GUI should also provide a Visual BLF that shows colleague
status. Again, it should also let users drag and drop or click
on these extensions to place, transfer and conference calls.
The GUI should provide visual unlimited speed-dial lists --
personal and system wide. It should also include pauses in speed-dial
strings to get through distant auto attendants.
The system should provide some form of caller-ID screen pops
upon capturing CLID or PINs from callers. The system should
also provide third-party PIM Integration.
The GUI should provide PC screen Messaging Waiting Indications.
The system should include Visual Voicemail at a minimum, with
GUI based auto callback from the inbox when caller is identified.
From messaging GUI, can should be able to dump someone into
voicemail and listen to what they're saying. If you like what
you hear, you should be able to pull the person out with an
icon click. Callers can also mark their messages "Urgent",
which automatically sends them to the front of the queue when
callers dial into mailbox via TUI or to the top of the inbox
when messages are checked visually.
Subscribers should be able to save, trash or forward multiple
messages simultaneously by selecting them all and hitting a
command.
The system should also provide browser access to messaging
mailboxes and voice streaming to remote web clients.
Embedded Documentation / Help.
There should be no worries about about misplaced manuals. They
should be stored on the server.
Scalability.
Like traditional PBXs, all of these systems have finite design
limits and capacity limitations in terms of traffic, processors,
memory, and line and trunk ports. Obviously, you want to make
sure that the system is properly sized and, more importantly,
can grow with you. Some of these systems are really only for
very small (under 40 phones) businesses.
T-1 connectivity.
This is something you don't think about when it comes to modern
day phone systems (they've been there and done that), but some
of these systems haven't yet introduced digital (T-1 / E-1)
interfaces. This is a glaring shortcoming and seriously affects
a system's ability to scale up; analog trunk interfaces are
also sketchy at best in terms of quality performance.
IP Telephony Support.
You might not need this yet, but definitely find out what the
vendor's plans are here. Most of the systems found in our Interactive
Comparison Tool include VoIP/IP Telephony Support
War-Room Wiring.
How does the system connect to trunks? How does it connect
to station wires? Are there any patch-panel-type strategies
that make sorting this all out easier. Is there any special
Automatic Line Bypass blocks that the vendor has developed.
Call Conferencing.
How many max parties (internal or external) can be added per
call and how many simultaneous conference calls can be supported
per system? It's not unreasonable for this technology to support
up to 8 parties on a single call. This should all be configurable
from call-handling GUIs, of course.
Music/Messaging On Hold.
How is this done exactly? Is there a standard RCA audio jack
on the PC hardware / key service unit (KSU) to plug an audio
source into? Does the system play files off the CT cards / proprietary
guts themselves? Do you use up a station port for MOH and, if
so, do you need a special cable / adapter box?
Make the system can reasonably provide MOH; it's important.
Paging Integration.
The system should be able to handle simple outdialing for message
notification.
Voice Prompt Format.
What does the system use? Is there an included conversion utility
for converting .wav files to appropriate formats? Can .wav files
be used? It's shocking how proprietary systems limit choices
and professionalism here.
These system should make it very easy. We like systems that
use .wav files... or at least let you store voicemails as .wavs.
Automatic Speech Rec Support.
These systems should have definite plans for support of ASR
auto-attendant at a minimum. It would be nice to make it available
from the TUI too.
Text-To-Speech Support.
If the system supports -- and you need -- unified messaging,
you'll need TTS. Great for remote e-mail reads.
Caller ID Support.
This should be standard -- knowing who's calling is often key
to automated and intelligent processing.
Multiple Language Support.
You should be able to make each channel, trunk or mailbox language-selectable.
Type of Telephone Instrument Support.
Generic 2500-set support is key. But some people like fancy
business phones (and you know who you are); in this case, ask
if the vendor has cut any OEM deals wherein they have "mock"
PBX business phones with LCDs, feature keys, softkeys, message-waiting
light, etc. Many do.
Number of Auto Attendants.
You should be able to develop a different auto attendant app
for each incoming line into the system. This is very handy.
Auto Attendant Greetings.
There should be more and types -- based on hour of day, day
of week, holidays, etc. -- than you'll need.
Fax Auto Detection.
The auto attendant(s) should detect CNG tones and route fax
calls accordingly. Useful for saving lines in small offices.
Dial-By-Name.
Should be commonplace in any auto attendant.
CLID / PIN Routing.
The platform should offer system-wide custom call-routing based
on CLID or PIN. After all, why should your phone system treat
everybody (from your worst enemy to your best customer) the
same?
Toll Restriction.
The system must restrict long distance calls, international
and 900/976 number access on a per trunk, per extension and
system-wide basis.
Automatic Call Distribution.
The system should provide simple ACD-like call distribution
and reporting features.
Distinctive Ringing.
To distinguish between internal extensions and outside callers.
Useful.
Personal Operator Support.
Every system should provide it. This is not just company-wide
operator, in this case each user can program in special departmental
secretary, assistant or any extension as the place to "zero"
out calls.
Caller Screening.
Here, the caller is asked to say his or her name before getting
routed. On the subscriber end, the system plays back the recorded
name ID and asks if the call should be patched through or sent
to voicemail. This should be standard on these systems.
It should also be standard that caller screening is turned
off if CLID or PIN is captured and call ID is matched.
Call Waiting.
These systems should support call waiting tones and virtually
unlimited call appearances (blocked only by overall system capacity)
to desktop extensions.
Follow Me Call Routing to Multiple Numbers.
These systems should allow authorized users to "cascade-forward"
(Joe isn't answering his desktop phone, would you like to try
his cell phone...?) callers to up to four numbers. This should
all be managed from both a system GUI and TUI, where users can
set up follow-me schedules and establish special connection
passwords.
On-Hold Outlet.
The system should callers on hold the option to go to voicemail
at programmed time intervals ( 10 seconds, 30 seconds, etc.).
An excellent TUI.
Yes, the desktop GUI stuff is sexy and useful, but perhaps
the most crucial aspect of a telephony / voicemail system for
day in and day out use is the telephone user interface (TUI).
Users and callers will spend many hours per month listening
to prompts and pressing DTMF keys to navigate and control the
system, both at their desks (if they're not running a Visual
Voicemail client) and from remote locations.
Menu structures should be logically organized, with the most
common functions listed first in each voice prompt. Consistency
is key.
TUIs should allow DTMF digits to "punch through"
voice prompts, which is good when it allows callers or users
to rapidly navigate well-known paths.
Private Messaging.
Callers should be able to enter special PINs to get secret
messages out of subscriber mailboxes.
Subscriber Greeting Parameters.
Mailboxes should support virtually unlimited greetings. These
should be able to be recorded and managed through a TUI and
a GUI. Hopefully, different greetings can be played per mailbox
that are based on time of day, day of year, and automated caller
identification.
Voicemail Scan.
This lets users get into voicemail queue, hit a DTMF command
and hear just the first five seconds of each voicemail message
until they hit something they want to really listen to, whereupon
they hit another DTMF and the feature is turned off and plays
that message in its entirety.
Messages Appending.
This lets people record a header onto a received message and
forward it other users.
Auto Callback Messengers.
If the system captures CLID and associates it with a message,
subscribers can hit a DTMF or callback icon and speed-dial the
number.
Auto Re-Queue.
After an automatic callback from the message stack, this lets
subscribers hit a touchtone sequence to drop back where they
left off in their message queue -- ala AltiGen's excellent "Boomerang"
feature... not really needed with visual voicemail GUI, but
great for remote message or plain TUI access.
TUI Message Access.
Can users adjust the way messages are presented to them in
the TUI -- or is it simply last in, first out. How 'bout playing
urgent messages first, etc. or first in, first out? Can this
be sorted according to subscriber taste?
Messaging Stats.
The system should generate reports on Mailbox Usage, Mailbox
Status, etc.
Audiotext.
The system should allow creation of information-only media-processing
"trees" that go as far down as you need.
Q&A Mailboxes.
The system should be able to ask callers virtually unlimited
automated questions, with the answers given via voice, touchtone
"0-9", or "1" for "Yes" / "2"
for "No". When played back, one contiguous message
heard should be heard.
App Creation Tool.
Some systems offer a GUI based app gen for creating advanced
interactive voice / fax apps and audiotext for the platform.
This is more important for call centers.
Multiple trunk support -- including TDM circuits.
Whether or not you want IP functionality, you should have multiple
network transport options. Modern business phone systems should
boast ISDN PRI/BRI, T-1/E-1, PSTN, frame relay, and (in some
cases) ATM links.
Call Center functionality.
We sort of gloss over this here (we need another Solution Center
to cover everything here). But many of the systems here do boast
bundled or add-on contact center functionality -- from call
logging, reporting, and billing to multimedia customer support;
from skills-based routing to remote agent monitoring.