Contents

How does Attendant work?

In a nutshell, here's how Attendant works:

Interaction Attendant uses profiles and schedules to determine which operations it should perform to interact with a contact. The basic steps are as follows:

The IC server gives Interaction Attendant a call to process. Most often, this is an inbound call, or a call that was routed to an operator. But it could be an outbound call that was placed by Interaction Dialer or a custom telephony application.
Attendant analyzes the call to accumulate information about it. It determines whether the call is inbound or outbound. If the call is inbound, it acquires the telephone number that was dialed (DNIS), the caller's telephone number (ANI), and the line or line group that the call is on.
Attendant compares these call characteristics to predefined profiles for that server. It gives control over the call to the profile that most closely matches the call.

A profile is a collection of predefined call characteristics that Attendant compares to an interaction, to figure out how to process it.

Profiles are best understood by example. Suppose that your company offers two levels of technical support: Silver and Gold. Silver members call 555-1111, and Gold members call 555-2222. To tell Attendant how to handle support calls, you would use Attendant to create an inbound profile for each telephone number. For now, don't worry about how that is done.

Each profile filters calls to match one of the numbers. When callers dial 555-2222, their call is processed by the profile for Gold support. When callers dial 555-1111, their call is processed by the profile for Silver technical support. In this scenario, Attendant uses Dialed Number Identification Service (DNIS) to determine the number dialed. Since Attendant knows the dialed number, it can perform unique processing on the call. For example, it might play special messages or offer alternate menu choices.

The main idea is that profiles are compared to calls to see if the call matches a profile characteristic of some sort. E.g.: Was this particular number dialed? Did they call our 800 number? You can define as many profiles as you wish. Let's look at another scenario.

Suppose that Marketing needs special call routing. They want to automatically route calls from their biggest customer directly to the person who manages that account. To catch these calls, you would define a profile that examines the caller's telephone number, rather than the number dialed. A profile of this type uses a process called Automatic Number Identification, or ANI for short. ANI is sometimes called Caller ID, and it is the opposite of DNIS. DNIS indicates the number that was called. ANI provides the caller's telephone number.

Profiles don't have to be very specific. They can examine a wide range of incoming call characteristics, using wildcards, and a combination of ANI, DNIS, and line criteria. When a profile is evaluated, the logical OR operator is used. If more than one criterion is specified, the interaction matches the profile if any of the profile's criteria are met. But what happens if you don't create a profile for every conceivable type of call?

The answer is that Attendant provides a default profile that catches calls that don't match user-defined profiles. You can customize a default profile to play a wave file, but its filtering criterion are disabled. This insures that the default profile will match all calls that get past your custom profiles.

Since profiles merely set up comparisons, they do not carry out actions, such as transferring a call. The tasks that Attendant can perform are called operations. Operations do work of some sort, such as prompting a caller to enter an account number, or reading back an account balance that was retrieved from a database.

But, what if your best customer calls at midnight, when the account rep is not there? Or, what if someone calls Technical Support on Christmas, when the entire company is on holiday? What if it snows, and you have to suspend operations for a day or two? As you can see, operations are time-sensitive. Attendant handles these considerations rather nicely. Once a matching profile is given control of a call, Attendant evaluates schedules to select an appropriate set of operations to perform.

A schedule determines whether a menu of operations is active, based upon a date, range of dates, time, or special event.

A profile may have many schedules attached to it. Schedules stipulate when a menu of operations can run. You can define schedules to handle recurring events, holidays, or special situations, such as your regular business hours, after-hours support, or an office closing due to poor weather conditions. But what if you don't think of every contingency?

You guessed it—every profile has a default schedule. Attendant creates it for you automatically. The menu attached to a default schedule is given control of the call when no other schedule in the profile has precedence.

A default schedule ensures that all calls are processed, should a call arrive during a period that is undefined by custom schedules.

Since the default schedule is designed as a catch-all, you can't edit it to define a start or end date, or to specify daily, weekly, monthly, yearly, unplanned, or system events. Those items can only be configured in a custom schedule form.

When call flow is passed to a schedule, the schedule's menu operations are executed.  Up until now, call processing has been largely invisible to callers.  But from this point forward, callers interact with menu operations attached to the schedule.  You've probably guessed that Attendant allows you to define as many schedules as you need to perform whatever actions are appropriate for a given date, time, or situation.

You can even set up unplanned schedules and activate them over the phone.  For example, you might create an unplanned schedule for a "snow day" to tell customers that your business is closed.  In a weather emergency, you can remotely activate the schedule from home.

Menus are created when you associate operations with a schedule.  Attendant provides dozens of operations that help you build menus.  For example, you can create menus that allow callers to dial by name, dial by extension, or transfer a call.  Attendant even provides an operation that creates a submenu.  However, Attendant is not limited to mundane tasks.  For example, it can obtain data from a caller, look up information from a database, and update records.  If you need functionality that Attendant does not offer, you can call custom handlers from Attendant.  Handlers are custom programs created using Interaction Designer—the CIC's visual programming tool.  Handlers can perform just about any conceivable data processing task.  They extend the PureConnect platform to meet unique business requirements.  But most people find that Attendant provides all of the tools that they need to create robust IVR interactions.

Related Topics