Implementing Siebel CTI
By R. R. Dailey
Introduction
A well-designed Contact Center is a hub for effectively managing customer communications. Each element
of customer contact - such as telephone calls, emails, and Web chat - must be carefully coordinated
to successfully carry out this mission. Siebel provides sophisticated contact center functionality
by deploying an interface for Computer Telephone Integration (CTI) that provides this coordination
among types of customer contact. With CTI implemented, the customer’s record "pops" on the contact
center associate’s screen when a connection is established and a record of the contact is logged as an
activity.
This article provides basic information on effectively implementing CTI with Siebel. The author’s
experience is based on the Avaya CentreVu ® CT Integration for Siebel eBusiness applications. However,
the article is not specific to that product. Readers will find the anecdotes relating actual problems
encountered during implementations (and how to avoid these pitfalls) are of particular value.
Four key topics areas are covered in this article. First, the basic hardware components of a CTI sys-tem
are described along with how they interact in establishing a connection. Next, the essential elements
of the Siebel CTI configuration are highlighted. A discussion of configuring each of these elements
is presented. Finally, several important caveats are presented to aid your implementation efforts.
HARDWARE COMPONENTS OF CTI
In a typical configuration, the primary hardware elements of a Siebel CTI system are the telephone
switch (ACD or PBX) and the CTI middleware server. (For the remainder of this article we will use
the shortened terms switch and CTI server.) In the Siebel product, the associate desktop is called
a teleset. The teleset always includes a physical telephone extension connected to the switch. The
associate is also equipped with a PC running the Siebel client, with CTI enabled. The Siebel servers
provide the database of customer information and store the CTI configuration. The switch is responsible
for establishing voice connections between the customer and the associate. These voice connections can
be either inbound or outbound.
In the process of establishing a connection, switch events occur. A switch supplies dozens of events
data types to support reporting, and each switch manufacturer uses its own labels for these events.
Typical names are "OnIncomingCall", "OnRinging", and "OnConnect". Associated with events are data such
as calling number, type of call, and call direction (Inbound or Outbound).
A CTI-enabled PC can issue commands to the telephone switch (through the CTI Server) to handle activities
like placing a call, transferring a call, or answering a call. A switch contains support for dozens of
these commands, and each switch manufacturer uses its own labels for these commands. Typical names are
"MakeCall", "InitiateMuteTransfer", or "AnswerCall".
The switch is configured with a standard internet protocol (IP) network port for communication with the
CTI server. The switch is configured to post all events to and accept commands from this port. Therefore,
we strongly recommend that clients configure their contact centers on a private network to prevent a
hacker from taking control of the switch.
The CTI server is configured with a second network connection on the public network. This CTI server
monitors the events posted by the switch on the private network over this connection and relays them
to the appropriate client PC on the public network. It also accepts commands from client PCs and relays
them to the switch. The client PC is loaded with a CTI driver (specific to the switch.) This driver
is installed to monitor the network connection for CTI events and post CTI commands. The interaction
of the PC with the CTI Server is controlled by the configuration of Siebel CTI.
ESSENTIAL ELEMENTS OF SIEBEL CTI
In Siebel CTI, a contact center is defined by one or more configuration alternatives. Every
teleset in the contact center is defined in exactly one CTI configuration. Each configuration
contains four elements to be configured:
-
Telesets define the associates and extensions to be handled by this configuration.
-
Parameters specify the basic hardware definition, such as the name of the CTI Server
and the name of the switch.
-
Events define how the client PCs in this configuration will respond to the switch events received.
-
Commands define what instructions and supporting data to send to the CTI server under various situations.
The configuration is stored in the Siebel database. When an associate logs into Siebel, the
configuration is read and cached in the PC’s memory for faster response. Changes to the
configuration do not affect an associate until they log out and log back in to Siebel.
Configuring Siebel CTI does not require access to Siebel tools. Configuration starts
with the CTI Configuration View
MenuBar> Screens> Communications Administration> CTI> All Configurations.
The two most used views for configuration will be the Configuration Parameters
and Telesets view and the Configuration Commands and Events view. Refer to the
Siebel CTI Guide in the bookshelf for specifics in navigating the views.
If a configuration does not already exist for your contact center, create one,
specifying the proper switch name and middleware. It is an excellent idea to
set up a query for the name of your configuration. A common error is to enter
information while the wrong configuration is selected.
CONFIGURING CTI PARAMETERS
Defining parameters is critical but straightforward. Enter the information appropriate
for your installation as supplied by the middleware vendor. The parameter Driver.LogFileName
specifies the name of the log of all Siebel events. If this is not a fully qualified name,
the log will be created in the Siebel bin directory.
Siebel stores all US phone numbers as a 10-digit number.
(International numbers must include a leading "+" for an 11th digit.) Dialing filters
must be configured in parameters to define the rules for processing of phone numbers.
When calling a phone number, each filter is examined successively until one is found
that fits. That filter is used and processing stops.
Dialing Filter examples: The client has 1000 internal phone numbers in each of
two ranges, 111-222-7xxx and 111-222-9xxx. Area code 111 does not use
10-digit dialing so it is not necessary to dial 111 before each phone number.
To reach an outside line, a leading 9 must be dialed. The following Dialing
Filters are set up:
Dialing:Filter.Rule01 1112229 -> 9
Dialing:Filter.Rule03 1112227 -> 7
Dialing:Filter.Rule90 111 -> 9
Dialing:Filter.Rule99 -> 91
Rule01 and Rule03 drop the first 6 digits when dialing internal numbers. These
two rules can be entered in either order. If these rules were not in use, then
any call to an internal employee would tie up both an outgoing and an incoming trunk.
Rule90 drops the first 3 digits when dialing a number in the local area code, and
it adds a 9, necessary for placing outbound calls. If this were called Rule00,
it would precede Rule01 and Rule02. When a caller dialed an internal number,
the CTI processing logic would match on Rule00, so Rule01 and Rule02 will
never be reached. Then all calls to area code 111, including internal numbers,
would be dialed as external calls. This would tie up and outbound trunk and
an inbound trunk.
Rule99 should always be the last rule in your configuration. This rule provides
the application with instructions to follow if nothing else matches. In our example,
Rule 99 will direct the application to dial the number as an outside long distance call.
What if some exchanges within the 111 area code need a leading one dialed for
long distance? The telephone switch itself will take care of this. Ignore
this in the consideration.
What if area code 111 goes to 10-digit dialing? Change Rule90 to
Dialing:Filter.Rule90 111 -> 9111.
Suppose the client adds a new site, with 100 phone numbers in the
range 222-111-53xx. Further suppose there is a tie-line to this site and
the switch is configured so these numbers can be dialed internally as 88xx.
What rule would handle this? Any rule before Rule99 will work as
this is for another area code. This should work:
Dialing:Filter.Rule10 22211153 -> 88.
By examining the log file specified in the parameters, you can determine
what commands were executed, including the phone number. This examination
will tell you if your Dialing Filters are working as expected.
GARBAGE-IN GARBAGE-OUT
Siebel expects exactly 10-digits in the phone number field for US numbers. One
client carefully added dashes into the 100,000 client phone numbers being mechanically
loaded into Siebel. Clearly, Enterprise Integration Manager (EIM)
was not used for the final load!
The Siebel application did not complain about this formatting error. In fact,
the application displayed the phone numbers correctly (nnn-nnn-nnnn). But
queries for client phone numbers failed and screens did not pop. The problem
was not picked up during implementation testing or training because the
phone numbers used in those phases had been entered directly into Siebel by hand.
The failure of screens to pop was quite disappointing when the client went live!
CONFIGURING CTI TELESETS
"Call Center 1" is one of the sample configurations provided by Siebel. In this
sample, each teleset has two extensions, and is named after one of them.
Each teleset also has an associate assigned to it (in the employee field).
Beginning with the Siebel 2000 release, hoteling is supported. The hoteling
feature allows any associate to work at any teleset. To configure the hoteling
feature, each teleset has the name of the Siebel client PC stored in the Host
field and the extension stored in the extension field, but no associate
specified in the Employee field. To define all of the associates to Siebel,
one extra teleset is defined. It can be named anything, but "hotel" is a
handy descriptive name I usually use. The "hotel" teleset does not
have an extension or Host defined in it. It does have every associate
using this configuration defined in it.
CONFIGURING EVENTS
By configuring events in Siebel CTI, the implementer specifies how switch
events are to be handled. The sample configurations provided by Siebel
CTI provide a full set of events for "vanilla" Siebel. They form a
good basis for understanding how Siebel CTI handles switch events.
By analyzing one of these events, you can quickly see how you can modify any event
to work more effectively in your Siebel implementation.
Each event configured for handling in Siebel CTI needs up to three entries.
A good example of configured events can be found in the Siebel sample
configuration "Call Center 1":
-
The EventHandler entry filters the switch events received from the CTI Server
based on parameters associated with the event. For example, if a caller is
prompted to press "1" for Sales and "2" for Service, then a field
called "CollectedDigits" contains the number pressed. The EventHandler
can filter on CollectedDigits and deliver the call to the appropriate
EventResponse. Siebel CTI sequentially matches each switch event with
every EventHandler in the configuration until a match is found. The "order"
parameter is critical, as it specifies which EventHandler will be examined first.
If two EventHandlers have the same order number, they are examined in
alphabetic order. The most restrictive event must have the lowest order number.
For example, if the first EventHandler filters for automatic number
identification (ANI), and the second filters for ANI and CollectedDigits,
the second EventHandler will never get control.
-
The EventResponse entry responds to the call handed to it by the EventHandler.
Usually this consists of popping a screen and specifying an EventLog to use.
Suppose that for a service call, the objective is to pop the Account Screen
based on the calling phone number. The calling phone number is stored
in a switch event parameter called ANI. So a QuerySpec could be defined
(in the proper Business Component and Object) as:
QuerySpec ‘Work Phone #’=’{ANI}’
There are three possible outcomes to the query: a single record is found,
multiple records are found, or no records are found. Parameters in the
EventResponse specify what Siebel view to pop in each case and what EventLog to use.
If no record is found, the view popped is usually a find dialog box.
-
The EventLog entry generates an activity record, specifies how to populate
the fields in the activity record, and associates the activity record to
a master record (such as account). The association to a master record is
done manually by storing the ID of the master record in the appropriate
foreign key field in the activity record.
CONFIGURING COMMANDS
The sample configurations provided by Siebel CTI provide a full set of commands
for "vanilla" Siebel. Using these commands, the associate can login to the switch,
make calls, answer calls, and transfer calls. Commands for making a call
are briefly discussed here.
When the "Make Call" Icon in the CTI toolbar is selected, Siebel looks at
the cursor location in the current screen to determine which phone number to use.
>From an Account view, the application might use the Account main phone number,
an account contact phone number, an Account activity phone number, or the number
in the Phone number field in the CTI tool bar. Alternately, a list of employees
may be "popped" so the associate can select one to call. Similar processing
happens for the various transfer call icons.
Siebel determines the phone number to use by examining the commands defined for
the MakeCall icon. Commands are configured in two parts: the Command itself
specifies the context in which to make the command active. The CmdData provides
additional context information, and allows parameters to be specified for a particular call.
The sequence in the command matters, just as it does in an event. Each command is
examined in order until the proper context is found. Each command can be restricted
to an active Business Component, a required field, or the cursor being on a
field as well as other restrictions.
The description parameter can be used to populate the ToolTip and easily identify
which command Siebel has matched.
To allow for a screen pop on transferred calls, the AttachContext CmdData parameter
is set to true. This generates a SiebelViewBmk in the switch event. The EventHandler
can filter on this to cause the receiving associate to see the same screen as the
sending associate.
To assure that calls are properly transferred, it is often useful to specify parameter
information in the CmdData, such as Id of the master record. An EventHandler
can filter on this and eventually associate the activity log record for
this call with the master record.
CAVEATS
1. Don’t use the phone! When CTI is enabled, the associate can control the
telephone station set (make calls, answer calls, put calls on hold) either through
CTI commands or from the telephone station set itself. There is a mechanism to keep
the CTI server synchronized with the switch and telephone set, regardless of
the source of the command.
However, this synchronization may lag, especially during busy periods, Symptoms
include an inability to use the CTI ToolBar to get in and out of "After Call Work"
or an inability to place a call on hold and retrieve a call on a second line. With
either of these issues, there is no impact to the customer since these activities
can still be accomplished using the telephone station set. But this usually happens
when CTI is first implemented and it causes the associate great frustration and
leads to distrust of the CTI.
The immediate corrective action for these problems is for the affected associate
to log out of Siebel and then to log back in. This guarantees that the CTI server
and the switch are synchronized. This always resolves synchronization problems.
One common cause of this synchronization problem is associates using the telephone
set to "login" to the switch when arriving at work. It is second nature to most
associates to reach out and press a physical telephone push-button in order to log in.
This is a very difficult habit to break. Some CTI clients have taped paper over
the phone buttons to help break the habit.
2. "Why do the screen pops come so slowly?" This is actually a relatively
rare question. But knowing the answer and how to demonstrate the answer before an
excited client starts asking about it is advantageous.
Screen pops are the result of a Siebel query. To establish a baseline for screen
pop performance, try manually entering and executing the query. The response
time for the manual query will be identical to the response time for CTI running
the query.
In every case that I have observed, problems where the screen pops slowly have
been isolated to a single PC, or at most a very few random PCs. Moving the agent
to another PC has provided a temporary solution. The long-term solution has been to
reload the PC in question from the ground up with a new copy of the operating system
and applications software.
3. Why don’t CTI commands and events work? Minimal syntax checking is available
when configuring Commands and Events in the CTI server. You may get an unbounded pick-list
for parts of some items. All of the rest of both sides of the parameter is filled in manually.
This is an error-prone process that leads to time-consuming and frustrating error sessions.
Consider this example. You configure an EventHandler and in it specify:
Response SalesCallReceived
Then the EventResponse named SalesCallRecieved will never be invoked!
(Did you note received was misspelled in one of the above definitions?)
This problem is compounded by the way Events need to be ordered from most
restrictive to least restrictive. A less restrictive EventHandler may
handle an event with an error. This leads to looking at the wrong
EventResponse, and obfuscates the real cause of the problem.
One good practice is to always specify an EventLog for every
EventResponse (at least during test). Populating the Description
or Comment field of the activity record with the name of the
EventResponse will help you focus on the real problem.
For Commands, use a slightly different Description with similar commands.
Then you can look at the ToolTip and know exactly which command is being invoked.
One of the more frustrating challenges I have encountered in this type of
debugging occurred when I was trying to determine why
EventResponse SalesCallReceived
was never invoked from the EventHandler with the parameter
Reponse SalesCallReceived
After carefully checking all the order and the spelling of all the filters, my boss pointed out that
"response"is spelled with two "s’s.
4. Is there a better way to edit Commands and Events? Yes, but you must
take precautions.
There are numerous similar commands and events, many of which need the same parameters.
Using your favorite text editor, like notepad, to cut and paste these parameters between
similar commands or events is a very effective tool.
Commands and events can be exported to a file that has the extension ".def" and imported again.
Export and Import are two buttons on the Configuration Commands and Events View.
However, Siebel deletes the existing command and event data before importing occurs.
Unfortunately, Siebel is extremely sensitive to the order of the lines imported.
If any error is detected, the import stops and the rest of the file is lost and
you are left with only a portion of the configuration installed.
To prevent losing the data, I use the following procedure:
a) Insert any new Commands and Events. Also insert any additional parameters within
one of the similar high-level events.
b) Export the Commands and Events to a file called ConfigNameEX.def. This file will
be in the correct order.
c) Open the ConfigNameEX.def file using notepad and immediately store it using
the name ConfigNameMOD.def. This file can be edited at will and then imported.
If the import fails, look to see what was last imported. The next item is in error.
Now, import again with the original. Correct your error in the modified file.
SUMMARY
This article has provided a high-level overview of the components used in Siebel CTI
and how they interact. The basic Siebel CTI structure is reviewed for the purpose
of understanding how Commands and Events in Siebel CTI can be configured
to meet specific business needs.
Specific recommendations are made regarding configuration of Siebel CTI so
the reader may learn from the experience of the author and avoid expensive
time-consuming errors.
ABOUT US
Mr. Dailey is a Siebel Certified consultant retained by CRP Solutions. CRP
is a valued Siebel partner as well as a Strategic Avaya partner for their
Siebel CTI Solution. He is a member of the on-site implementation team for
Siebel CTI as well as general Siebel implementation.
Mr. Dailey may be reached at rrd@nilenet.com or ddailey@CRPSolutions.com
CRP Solutions may be reached at
303-526-4440,
www.crpsolutions.com
602 Park Point Drive, Suite #280
Golden, CO 80401
For more information:
Siebel CTI Guide in the Siebel 2000 Bookshelf
Sample Configurations provided with Siebel CTI.
Does your company already subscribe?
You might be eligible for a free subscription!
