Inbound Call Handling

Owned by Scott D Child
Last updated: Oct 30, 2024
8 min read

Overview

The feature allows inbound calls to be played messages, queued and passed to agents. It also allows calls to be associated with campaigns. This association will be based on DDI. Generically a DDI is a dialled  number associated with an incoming call. Within the dialler specifically, a "DDI" is an entity consisting of a set parameters that defines how an inbound call associated with that DDI number is to be handled. 

For agents to handle inbound calls a DDI must be associated with a campaign. DDIs can be created dynamically by a campaign when a campaign is opened, or they may be predefined independently of campaigns and later associated with a campaign when the campaign opens and nominates a predefined DDI as its DDI. Dynamic DDIs have the same lifetime as the campaigns that create them. Predefined DDIs are permanent. This means that dynamic DDIs can offer no call handling intelligence when the associated campaign is closed. Predefined DDIs can offer call handling intelligence independently of the lifetime of any associated campaigns; this includes things like out of hours rejection messages.
If supported by the CATI integration, the association of a campaign to a DDI can be configured in the CATI. If the CATI partner system does not explicitly set an association of a DDI with a campaign at any point in the campaign life-cycle, the association can also be made through the INVADE Web Console on a campaign basis. This association can be stored in the Campaign Parameters file on the dialler. This file may be created via Web Console following the opening of a campaign, and may contain values edited in the Web Console 
While DDIs can be predefined with given behaviours, the DDI is related to a campaign in one of two ways.

  • If supported, the DDI can be set via the CATI.
  • Otherwise the "DDI" numeric string can be set in CampaignParams.xml

The primary operation of  inbound call handling is call distribution and queuing. Call distribution is based on longest idle.
Functionality supporting inbound handling will transparently apply to both exclusive-inbound and blended-inbound, although some minor differences may apply. In general, exclusive-inbound campaigns require a subset of operations required by blended. In blended campaigns, dialled (customer soliciting) calls must take priority over inbound (customer initiated). In the case of inbound calls, ‘abandoned’ means the call is dropped by the caller either pre-connect or post-connect. Once an inbound call is accepted it should not be ‘abandoned’ by the dialler. However, on arrival an inbound call may be rejected if:

  • no campaign is associated with a DDI,
  • no agents are logged onto a campaign associated with a DDI,
  • explicitly configured inbound conditions are met, and inbound calls can be rejected. See MaxQueueTime

A call may be optionally played a rejection message at this point.

If a call is accepted (offered ringing) and some automated audio handling is configured, inbound calls may be connected to an audio message before being connected to an agent. This can occur pre-queuing, or during queuing.
‘Agent logon’ and ‘agent state progression’ required to support Inbound handling are the same as those required for outbound call handling:

  • WAIT, INCALL and WRAP states applying.
  • UNAVAILABLE also applies if the CATI campaign manager supports the use of preview/predictive blending.
  • WAIT state indicates availability to receive dialler or inbound calls.

Any campaign, regardless of dial mode, may have a DDI associated with it and by that association will be able to handle inbound calls as either an exclusive inbound campaign or a blended inbound campaign. However, if a campaign is set to run as a predictive or progressive dial mode campaign, the dialler will request sample from the CATI and blending will result. If no dialled call blending is required, then sample requests should be avoided. This can be done by setting the dial mode appropriately in the CATI or by setting it to INBOUND in WebConsole and saving this setting. Please note that this INBOUND dial mode does not “turn on” inbound handling ability, this is made active by a DDI association. The INBOUND dial mode simply prevents sample request and effectively “turns off” dialler-based outbound calling.
For exclusively inbound campaigns, calls may be distributed to agents prior to queuing or immediately after the call is queued. For blended campaigns, an additional delay is added. This allows the dialler to give priority to any progressing outbound call that might connect during this delay. During this period the over-dial aggressiveness of the predictive algorithm is "governed" in recognition of the likely connection of the inbound call.
DDIs are predefined in the dialler under the "DDIs" directory. Each DDI has a set of parameters and files stored in its own subdirectory. The existence of the DDI directory is enough for the DDI to exist. If no parameters file is in the directory, the default values will be used. If a campaign becomes associated with a DDI, the settings and files within the DDI's subdirectory will become associated with a campaign. A "default" DDI can be predefined. Any campaign that declares an association to a DDI that does not exist in the list of known DDIs effectively creates a dynamic DDI that will adopt the parameters of the default DDI. This allows for a generic set of operational parameters and audio messages that can be used dialler-wide as defaults.
To permit effective operation of inbound handling in accordance with the above, the following parameters and files are available:

  • DDI – Numeric digits and "+" only. This should be the name in the DDI directory. This will become associated with the campaign on a longest prefix match basis. eg if DDIs "85" and "851" exist then campaigns declaring the following DDI string will get the following DDI associations:
    "859027634" -> DDI "85"
    "8510978344" - > DDI "851"
    "8906467731" - DDI "default"
  • RejectMessage - is the name of an audio file to be played to a call before it is dropped. The file is located in the specific DDI directory. If not set the rejected call will be dropped with a BUSY cause, without being answered. Call centre managers should be aware of any premium rate or similar charges that will preclude the answering and rejection of a call in such a way. Answering higher charge rate calls to offer a rejection message may be illegal in some regions and costly in others.
  • CompulsoryIntroMessage - is the name of an audio file to be played by the telephony platform on call arrival. The file is located in the specific DDI directory. The file is played entirely and uninterrupted before the call is eligible for queuing or distributing. If set, the call will be answered after 3 seconds to permit network signalling (audio and digital) to propagate. If the file is not present the call will begin to queue immediately.
  • InitialQueueMessage - is the name of an audio file to be played by the telephony platform on when the call is initially queued. The file is located in the specific DDI directory. There will be a delay before the file is played. The file will be played 5 seconds after the call is queued. Unlike the CompulsoryIntroMessage, the message may be interrupted if the call can be transferred to an agent.
  • QueueMessage - is the name of an audio file to be played repeatedly on the queue after the initial file, and until the call is distributed off the queue, or drops. The file is located in the specific DDI directory. between each play there will be a specified gap. This gap may have MessageOnHold or ringing
  • MessageGap – the number of seconds between file play cycles. This parameter is specified in a Params.xml file in the specific DDI directory. The default value is 20
  • MaxQueueTime - This is the maximum wait time in seconds permitted before the queue is frozen. This parameter is specified in a Params.xml file in the specific DDI directory. The maximum number of calls on the queue will be frozen from the time the limit was exceeded until the longest wait time of any call on the queue drops below the limit. Any call that arrives and cannot be queued due to this condition will be rejected; this prevents callers into the system being accepted but having to wait for long periods. This should be used when supervisors regard call rejection as preferable to long queuing. If no rejection condition is wanted, this number can be set very high. Rejected calls may be played a file before being rejected. 
    Here is an example of a Params.xml file. The default value is 0 (not applied)
    <?xml version="1.0" encoding="utf-8"?>
    <Parameters xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><MessageGap>20</MessageGap><MaxQueueTime>0</MaxQueueTime></Parameters>
    Inbound calls history is available via DiallerConsole and WebConsole. They are marked as "Inbound". Any call that is dropped by the caller before it reaches an agent (eg, while queuing) will be marked as FASTDROP, similarly outbound calls that might be dropped (in the short time) between answer and drop.

Setup of inbound prefix

While inbound DDIs can be predefined with given behaviours, the DDI is related to a campaign in one of two ways.

  • If supported, the DDI can be set via the CATI.
  • Otherwise the "" numeric string can be set in CampaignParams.xml located in /var/lib/invade-genghis6/CampaignParams/

e.g. for a campaign called test setting prefix of 95 as inbound target

Dialler Setup

To activate the handling of inbound calls in the dialler, amend the dialler conf values under <Telephony>:

in /etc/invade-genghis6.conf the following configs need setting:

  • <ForeignCallHandling> set to false
  • <InboundCallHandling> set to true

Asterisk Setup

Any DDI ranges must be declared and received into the system with an AGI command

/etc/asterisk/extensions_invade_inbound.conf:

exten => _{inbound number prefix}.,1,noop()
exten => _{inbound number prefix}.,n,AGI(agi:async)
exten => _{inbound number prefix}.,n,Wait(60)

e.g. if all DDIs are prefixed with "95" the following needs to be added to following:

/etc/asterisk/extensions_invade_inbound.conf 

exten => _95.,1,noop()
exten => _95.,n,AGI(agi:async)
exten => _95.,n,Wait(60)

this allows agi commands from within the AMI.

"agi" must be added to the AMI read/write permissions in /etc/asterisk/manager_invade.conf this is normally set by default.

notes: that if inbound have contradicting dial plan this could cause issues. 


Unicom Intelligence Setup

To configure campaigns and unrecognised caller handling the following need to be added into the DPM.
In node:

Servers/<server>/Projects/System/<project>/mrInterview

the following properties should be present:

"DefaultInboundGroup" (text) this is the test name of the skills qualifier group to which inbound calls will be directed
"InboundNumber" (numeric text) the inbound number prefix of the DDI related to that project. The presence of DDI in the project activates inbound handling activity
"InboundMode" ("blended"/"inbound" ) Whether the project is to be inbound only or blended


The following DPM properties can be used by the Unicom CATI. To be usable they must me added:

InboundCallPhoneNumberFields (comma separated list of field names)
InboundCallMatchDigitCount (number of digits to match on)
InboundDeleteUnusedNewRecords (True,False)

In order to induce a look up an unknown caller's CLID the interviewer must code the call "InboundLookup". This code must be added to the projects samplemanagement node:
Servers/SampleManagements/<project> /Queuing/SampleRecordReturnCodes

FORSTA (Formerly ConfirmIT) Support

FORSTA CATI declares its own DDIs into the dialler. When a call comes in the dialler notifies the FORSTA CATI and it will determine how the call should be handles. Call acceptance and Interviewer selection can be optionally performed by the CATI. To avoid using the diallers own call acceptance and Interviewer selection mechanisms, the DDI should not be predifined in the dialler's own set-up. Valid FORSTA DDI numbers shall be declared by FORSTA only. See FORSTA documentation on setting this up. However, If a "default" DDI is set up, then the handling of a Call will use the default parameters unless overridden by FORSTA.

FORSTA is able to override the CompulsoryIntroMessage.

FORSTA also supports an array of call rejection messages. These are specified in the CATI supervisor. Please refer to the FORSTA documentation in this respect.

INVADE support for FORSTA inbound call handling also supports skill-set grouping. If the CATI requests interviewer allocation by the INVADE Solution, only interviewers with matching skill-set group allocations will be assigned to incoming calls.

FORSTA inbound is support in versions 6.4 and above for the INVADE Solution and 6.0.0 of the ConfirmitDiallerProyx.