CallScripter 4.5.53 for Interactive Intelligence

Please email training@callscripter.com for omissions or errors.
×
Menu

Working with Dialer Interactions

This purpose of section is to clarify how Dialer can be controlled by CallScripter.  It is important to understand why, when and how to work with Dialer to achieve the results you desire.
CallScripter communicates with Dialer through a special variation of a standard Interaction termed a “Dialer Interaction”.    A Dialer Interaction (DI) allows extra functionality over a standard Interaction to cater for extra Dialer features:
·     Work with Call List data
·     Dialer Staging
·     Get / Set Dialer Attributes
·     Reschedule records
·     Set Outcomes or Dispositions
 

The Open Window

Please consider the DI as an open window through which CallScripter speaks to Dialer.
·     If the window is open, Dialer is listening and will react if you speak to it. 
·     When the window is closed, you cannot communicate and any attempt to (for instance setting the outcome) would be lost.  Dialer cannot hear you.
 
The interesting part, and something that you must understand and plan for, is that the window can be closed at times you might not expect.  
 
Remember: once this window is closed you lose the ability to talk to Dialer. 
 
The DI arrives in a users queue, bringing a “data pop” event.  This is the window opening.  CallScripter can set outcomes and can interact with call list data, etc.   At some point the DI is removed from the user queue, closing the window.  Communication is now not possible.
 
Normally the DI stays present for 120 seconds after the call has been disconnected (this can be adjusted in Dialer 4.0 https://my.inin.com/products/pages/kb-details.aspx?entryid=q137892303504060).  Other circumstances also cause the DI to be removed.  
·     Blind or Consult Transfer Complete
·     Conference
·     2 minutes after call is disconnected or when the default time elapses.
·     No answer when transferring to a workgroup
 
This could be confusing to the user: they may even still be speaking on the call and following a scripted process, but if the DI is gone and CallScripter tries to speak to Dialer that message will not be heard.
An example might be setting an outcome for the record and rescheduling a call.  Unless this is done whilst the DI is present Dialer will not accept that instruction and fall back to default behaviour.  Symptoms of losing the DI:
·     Ambiguous Dispositions
·     Reschedules not working
·     “Set Dialer Attribute” error toasts
·     Call List data not being updated
 
Some example scenarios:
 
Call to a mobile phone. The signal is bad and the call drops.  Agent calls the number back manually and proceeds through the script as normal.
X             Ambiguous outcome as the manual call is not the DI.
X             Call list data is not updated after the DI has gone
 
Possible Remedial Action: Reschedule call to the same agent in a few minutes.  Provide method to do that in the script using simple controls.
 
Agent intends to reschedule a call.  They get caught up in another task for 3 minutes.  They then set the reschedule time and close the script down as normal.
X             No reschedule set as DI removed after 2 minutes.  
X             Ambiguous outcome
 
Possible Remedial Action: Ensure agent finishes the script in the right time period before doing other tasks,  OR if there is a suitable place in script that you could set the right outcome – then set it prior to the post call action so that outcome will be set as the DI is finalised on removal.
 
Agent makes a high value sale.  They pause, leave their desk to ring the “sales bell” and celebrate the deal.  They return to their desk and complete the script.
X             Outcome / Disposition of Sale doesn’t make it to Dialer – defaults to “Ambiguous”
 
Possible Remedial Action: Ensure agent finishes the script in the right time period before doing other tasks,  OR if there is a suitable place in script that you could set the right outcome – then set it prior to the post call action so that outcome will be set as the Interaction is finalised on removal.
 
Agent patches in an IVR using a transfer: Standard terms and conditions need to be played to customer, who also needs to type a response or authorization code into the IVR.    Agent uses the transfer mechanism to connect 3-way to the IVR.  They then hang up.
X             DI is removed during the Complete Transfer, no outcome can now be set and default of Ambiguous would be left.
 
Possible Remedial Action: Ensure that an outcome or disposition is set prior to completing the transfer or conference.
Inbound call comes in over an outbound call.  Inbound call hits an agent taking priority.  DI stays for 2 mins, but the agent is busy on the inbound call. 
X             DI is lost after 2 mins, record is dispositioned as Ambiguous.
 
Possible Remedial Action: Ensure agent state is controlled to ensure no inbound at the wrong time. 
 
 

Under the Hood

CallScripter will react when an event is passed showing the DI is “removed” from the agent Interaction queue, or as the script is finished. Note this event does not happen in all circumstances when a DI is removed.
When this removal event is detected CallScripter will “Finalise” the record (from version 4.5.45 onward).  It is the last chance CallScripter can speak through the window.  Finalising will cause the record to have the last notified disposition as set by the user or script as the outcome.
A special circumstance is catered for upon completion of blind or consult transfer with script. The Interaction is removed from queue immediately but CallScripter hangs onto it internally and will disposition the call as transferred (provided no other disposition has been set) once the transfer is complete and the CallScripter script shuts down. This procedure also releases the agent from the record, allowing them to continue receiving new calls.
 

Best Practice

In order to avoid Ambiguous outcomes, rescheduling issues and confusion plan and set outcomes at relevant parts of the scripted process via a csCommand or Outcome control.  
 
This means that if you do lose the DI you ensure the most recent outcome will be set as it is removed.