Inbound Calls

This article gives you an overview and knowledge needed to manage inbound calls in FrontStage. In addition to the conditions for functional inbound calls, you will here find explanations of the individual rules for routing calls, their distribution and how to set up a minimum functional environment.

Overview

In order to manage inbound calls through FrontStage, several conditions must be met.

Extensions on the PBX, ProServer and FrontStage

A necessary component.

Extensions of pilots, redirectors, IVR inputs, waiting queues and other extensions must be set correctly on the branch exchange, registered in ProServer and in FrontStage.

Pilot

A necessary component.

The Pilot is a collection number where all calls you want to manage via FrontStage come. The job of the branch exchange ends with the pilot, FrontStage learns about the call and takes over control. Without a correctly set pilot, inbound calls will not work.

You can do the configuration in the administration section PBX and IVR –> Pilot numbers.

Redirector

Optional - only for branch exchanges like Aastra A5000.

It can be used as a FrontStage entry number. It is used in a branch exchange where the CSTA licenses are charged. Unlike the pilots, the redirector does not require a CSTA license.

The redirector is used exclusively for call redirection to the pilot. This is a way to use multiple input numbers that are all routed to a single pilot. FrontStage is able to distinguish individual redirectors and use them to run different rules according to the input phone number (IVR, skills, waiting queues, etc.)

You can do the configuration in the administration section PBX and IVR –> Redirectors.

IVR entry

A necessary component only when the IVR is used.

The IVR script is one of the available actions when executing input, distribution, and wait rules. Within the IVR script activation system, it means transferring a call to one of the free IVR inputs.

In some exchanges, such as Cisco Unified Call Manager, the call is physically transferred via the SIP trunk to the IVR server. At the end of the IVR, the call is again transferred via the SIP trunk back to the PBX. In PBXs such as Mitel, the call is parked on the PBX line referred to as the IVR input. At the end of the IVR input, the call is transferred to the pilot number again.

You can do the configuration in the administration section PBX and IVR –> IVR Entries.

See also

IVR Programming

Announcements

An optional component.

It is mainly used for installations where the IVR is not implemented, and it is necessary to use e.g. a welcome message or out-of-hours message (“Hello, you have reached …”).

You can do the configuration in the administration section PBX and IVR –> Announcements.

Waiting queue

A necessary component.

At least one waiting queue must be defined.

See also

Call distribution and waiting queues.

Agent workplaces

Necessary if agents are to handle calls and the it is not just an IVR self-service system, it is necessary to create agent extensions.

See also

Workplaces.

Routing inbound calls

FrontStage processes calls that appear on the pilot number. The pilot number can be directly called, or the routing from the redirector is set on the branch exchange.

When the call appears on the pilot number, it is further controlled by FrontStage. ProSever records the call occurrence because it monitors this line using CSTA/JTAPI. The ProServer service communicates with FrontStage by means of the ServiceSync synchronous service. ServiceSync creates a new row in the InboundCall table for each intercepted call.

Important

If a call is made directly to another number registered in FrontStage, such as an agent extension, waiting queue, IVR input etc., then the call in FrontStage is not registered or managed.

Routing rules

Each inbound call can go through up to four types of rules, which, if they meet the specified conditions, can perform some actions or change the data associated with the call.

Form for entering rules

The rules can be inserted or adjusted by using Inbound Calls, Waiting of calls, and other visual editors. All the available editors can be found at Visual editors

Pre conditions

ServiceSync will begin to apply the input rules in their order until it finds those that match the restrictions. Only one entry rule is executed per call. If the action did not finish the processing, the execution is always followed by a project rule.

Specifies conditions under which an announcement, IVR or call termination is run on the pilot number before a new inbound call is processed, or merely proceeds to process a project rule.

The restrictions include e.g. language, proficiency, number is from phone book, pilot etc. For example, you can skip the IVR if no free IVR input is available.

To see their list and particular items, go to administration Inbound calls –> Pre conditions section.

Project conditions

Once the entry rule has been executed, ServiceSync begins to go through the project rules in their order until one is found that matches the restrictions. Only one project rule is executed per call. The execution is always followed by a distribution rule.

Specifies conditions under which the initial project is selected. Allows you to specify a preferred agent.

The restrictions include e.g. language, proficiency, number is from phone book etc. Project rules have no actions but can change information such as the set project, priority, skill, proficiency or, as the case may be, the preferred agent or language.

Their list and individual items can be found in administration section Inbound calls –> Project conditions

Post conditions

Once the entry rule has been executed, ServiceSync begins to go through the distribution rules in their order until one is found that matches the restrictions. Then the call is distributed to a suitable agent, or the system looks for a waiting rule if no agent is available.

Specifies conditions under which an announcement or IVR will be triggered once a project has been selected when the initial project is known. It also allows you to change the project.

The advantage is that the distribution rules offer other restrictions than the previous rules, e.g. “fewer subscribed agents than”, “expected wait time longer than” and so on. The purpose of the distribution rule is to perform actions such as replay an announcement, run an IVR script (e.g. offer a callback), end the call and so on. It can make changes in the target project, language and default preference time.

Their list and individual items can be found in administration section Inbound calls –> Post conditions

Wait post conditions

If no agent can answer the call, the system searches the wait rules according to their order until it finds the one with matching restrictions.

If a waiting queue is set in the rule actions, the call is transferred to the line of the selected waiting queue . Restrictions can include, for example, whether it was a transferred call, waiting time is longer than …, fewer registered agents than … and so on. Changes allow you to set priority, target project etc.

Their list and individual items can be found in administration section Inbound calls –> Wait post conditions

Cyclic processing

Since the call can wait for a suitable agent for rather a long period of time, it is possible to process another waiting rule according to the following principle:

1. The system searches for the first rule that matches and remembers its order (database column Rank).

2. The rule is executed (information related to the call changes and/or actions are performed).

3. In the next cycle (set to every 10 seconds by default), the waiting rules processing ignores all subsequent rules in the same hundred series (Rank) and searches for the same rule as in the previous cycle, sequentially in one of the following hundred series.

4. This is the procedure applied in every cycle - the system recalculates all the subsequent rules. It never returns in the rule order. If the last suitable rule is found, the system remains on that rule in subsequent cycles.

Example:

1. cycle: The default rule has a rank of 123, i.e. a rank of series 100, which is executed.

2. The cycle ignores rank 101-199.

3. cycle: Looks for a suitable rule with a rank of the 200 series. If there is no such rule, it searches for one with a 300 rank, etc. Note: It is the hundred series and the appropriate rule that matters, not the rank number. So the next suitable rule may have a rank of e.g. 745.

Call distribution and waiting queues

Distribution is the point at which FrontStage looks for a matching agent for a call (or message or chat). When there is no free agent, the system looks for a wait rule.

Searching for a suitable agent is performed by a ServiceSync algorithm called distribution loop, which handles data in the database from the RankedInCalls (inbound calls if thereis separate distribution) or the Queue (unified queue) table.

The waiting queue is a telephone line on which calls are parked prior to distribution to a free agent. The ringing tone is usually an announcement with music. The announcement can be interrupted at any time once the call is distributed to the agent.

Separate queue (classic queue)

Originally the only available queue in FrontStage was separate, so it is sometimes called the classic queue.

The distribution loop runs over and over again and requests are assigned separately from each communication channel. Communication to be processed is looked up in the corresponding database view by channel type:

• inbound calls according to view RankedInCalls

• inbound calls according to view RankedInCalls

• messages according to view RankedMessage

• WebChat according to view RankedChat

One round of the distribution loop can take several seconds.

The RankedOutCalls view will display outbound calls that meet the following conditions:

• project call

• Scheduled status

• Enqueue or AgentOfferMissed phase

• No time scheduled, the time has not yet come or is about to occur at this time

• The campaign must run

• If the call is from a campaign import, the import must be in the paging status

• If the campaign is batch processed, the current rank must be less than the rank barrier

Single queue

The distribution loop runs over and over and the active communication from all channels is assigned together in the order of the Queue table. The opposite is a separate queue, where each group of channels is distributed separately, independently of the others.

One round of the distribution loop can also take several seconds.

Waiting queues configuration

You can configure waiting queues in the administration section PBX and IVR –> Waiting queues.

Procedures

Minimum required inbound call settings

You must set up at least the following areas so that inbound call processing in FrontStage works properly.

1. Set one or more extensions on the branch exchange for:

   • pilot numbers

   • waiting queues

   • agent workplaces

2. Create or set up the following required items for agents in FrontStage administration

   • agents

   • agent statuses

   • projects

   • projects skills

   • agent seatings

3. Create or set the following items in FrontStage administration for the routing rules:

   • pre conditions

   • project conditions

   • post conditions

   • wait post conditions

Next   Previous