Download By Larry Loveland, Telcomp, Inc

By Larry Loveland, Telcomp, Inc
C
alled into a call center lately? Diligently followed the
prompt to enter your telephone number and then get
transferred to a real live human only to be asked again for
your phone number? Caller ID was introduced in 1987, so why is
this the state of many call center applications?
Understanding of the Public Switched Telephone Network
(PSTN) services used to provide Caller ID, Automatic Number
Identification (ANI) and Dialed Number Identification Service
(DNIS) by database application developers is at best marginal. So
how is it that the local pizza parlor can know who you are, where
you are, and that your last tip was a bit on the small side before
they even say hello? Their database has been designed to accommodate the idiosyncrasies of the Caller ID service. This is easiest
to do in a residential to business application where the customer
is calling into the call center (Yes, the pizza parlor is a call center,
so is the florist, your taxi company, your physician, the electrician
and the plumber – you get the point) mostly from the same telephone number, be that a land line or a cell phone. From the call
2
TelecomFinders.com | June 2009
center perspective, how do we maximize the customer record recall hit rate?
There are several facets to making screen pop technology useful so that it provides a worthwhile ROI. We will discuss how to
apply this technology in a series of short articles that will deal
with the various aspects that make up a successful Computer
Telephony installation. This first installment will provide insight into database design for simplifying the user interface. In
following articles we will deal with the various Computer
Telephony interface technologies adopted by different PBX
and key system manufacturers. Then we will examine the provisioning of services by carrier and trunk providers and how
these services work in North America for screen pop and lead
source tracking.
Not all databases are created equal. Several considerations
need to be realized by the database developer to take advantage
of the number provided by Caller ID.
First, is Telephone Number the Primary Search Key or a Secondary Search
Key? Are telephone numbers in your database
even in indexed fields? Is a telephone number
unique to a customer or does your business have the
same telephone number in multiple records?
Most customer service applications use something other
than the telephone number as the primary key for maintaining customer records. Something as arcane as an arbitrarily
assigned account number is quite common. Many popular CRM
products don’t even have a unique customer record key. ACT,
Goldmine, and Outlook fall into this category. So, how is a search
constructed to most effectively find a customer record by telephone number?
ers, call campaigns, etc. and ideally should be configurable
for the type of business.
These options appear obvious when taking the time to analyze
what can happen with the Caller ID information, but most database applications don’t do these simple things because it was
not conceptualized that telephone number would be used as a
primary lookup mechanism.
Secondly, database developers need to maintain the integrity
of the data in the phone number fields. Validation rules need to
be established and enforced by the application to avoid dirty data
in the phone number fields. Items such as how many digits, area
codes, alpha lockout or alpha to phone number conversion prevent numerous problems with automatic lookup mechanisms.
(The importance of this really becomes apparent when trying to
get the application to dial a customer – a topic for in depth discussion in another article.)
Here are two of the best types that we have seen implemented.
In the first type, the CSR is waiting at a customer information
screen that is blank and focused at the telephone number field
Lastly, the search should perform a cascading search through
which is used as the primary lookup
all telephone number fields in the
key. This generally works best in a
customer record. This will insure
residential to business application
that the customer record will be
such as a pizza parlor.
Most customer service appli- found no matter which telephone
number the customer is calling
cations use something other from (assuming that you have reThe second type provides a separate search box entry that can be
corded as many of the customer’s
than the telephone number
accessed via a single keystroke or
numbers as you can gather in the
as the primary key for mainmouse click, providing a focused
record) thereby maximizing the
entry for the telephone number.
hit rate. ACT and Goldmine do
taining customer records.
not do this. Consider how this
When the number is entered
affects hit rate results. ACT and
it is best not to do a character by
Goldmine both allow you to keep
character narrowing search – while this may be good for names, three contact telephone numbers in the database, but the search
it unnecessarily slows the search for a telephone number. When mechanism in either of these programs only searches one field at
the telephone number search entry is complete, one of several a time. As an example your telephone number search hit rate will
results is possible.
likely only be 33% unless you use some additional product to cascade the search through the two additional telephone number
A unique record is found and the customer information is im- fields. Many of the newer SQL based programs provide cascadmediately brought to foreground in a new customer record or ing searches – Tigerpaw and Salesforce.com do this very well and
transaction window, leaving intact any other processing that the Tigerpaw even searches the numbers that are maintained anyuser was doing before answering the phone.
where in the customer record.
Multiple records are found and a selection box with name,
address, etc is presented to allow the CSR to select the customer
record from the matches. Selection then proceeds to the customer record or transaction window, again leaving all other processes intact.
No record is found and an option to add a completely new record,
or to lookup an existing record and add this telephone number to
that existing record should be provided.
Some of these actions may be skewed by the type of business
activity and factors such as the number of repeat vs. new callers,
residential callers vs. business callers, demographics of the call-
This quick overview should give database designers a few ideas
and users some criteria by which to judge their customer service
and relationship management applications. Maybe in another
20 years all customer service databases will do these things well.
In the next issue, we will discuss various interface approaches and how they differ in ways
such as 1st party and 3rd party,
TAPI, TSAPI, CSTA, Serial,
TCP, and even some proprietary methods. |TF|
June 2009 | TelecomFinders.com
3