Discussion Thread View
Expand all | Collapse all


  • 1.  Callback

    GCAP Member
    Posted 10-08-2019 14:03
    We are looking to implement the callback feature, and we were looking for feedback from others that may have implemented this feature.  Do you offer the option before it routes to the workgroup or once it is in queue?  Do the callbacks route to a separate workgroup?  If so, is the service level different between calls and callbacks?  Any issues that you've encountered?  Do you just have the customer enter the phone number or do they speak their name as well?

    Any feedback you can provide would be appreciated.


    Stacy Darling
    Amica Mutual Insurance Co.

  • 2.  RE: Callback

    Posted 10-09-2019 09:26
    Callbacks are typically offered after the call in the workgroup for a period of time.  If you have agents available, they should be taking the call, if all your agents are busy and calls are waiting for over a minute or some other threshold, that's typically when callbacks are offered.
    Service Levels for Callbacks can be adjusted on the Workgroup - Configuration page, using the 'Configure Service Level' button.  Each Interaction Type has a service level definition.
    Callbacks are created by replacing the call in the workgroup with a callback, so the callbacks stay in the same workgroup.
    The callback number can be verified from the inbound ANI or requested from the caller.  If the caller's Name is received on the original call, it will be present on the Callback, so there is no need to ask for the name (if you did ask the caller for a name, you would have to perform speech to text translation to see the name as a string)

    Paul Reininger
    Avtex Solutions, LLC

  • 3.  RE: Callback

    Posted 10-09-2019 11:00
    It is also possible to use a Logical Transfer operation in Attendant to force the caller to a callback if the current estimated wait time is over a particular threshold. You could even do a three-level approach, so (for example) if the current estimated wait is under 2 minutes, put it in the Queue. If it's between 2 and 5 minutes, give the caller the option, if it's over 5 minutes, force a callback.

    This could be in addition to periodically asking the caller, while waiting in Queue, if they would prefer to be called back.

    Paul Simpson
    Senior Technical Instructor

  • 4.  RE: Callback

    Posted 10-09-2019 11:21
    We also use a time check. Using logical transfer, we turn off callback if 1-hour before closing time, simply because that is what the client wanted.

    In addition, we used to offer the option to call them back on the number thy called in with or give them the option to enter the number to call them on via keypad. However we discovered so many calls where they selected to call back on the number they called from, only to discover it was hidden, blocked, or a generic switchboard number that we removed this option completely and only offered for them to enter the number (still get invalid numbers sometimes!)

    We use a check while in ACD, before the call queues, to check how many agents are available. If Available agents = 0, we offer callback, if >0, then bypasses callback.

    Philip Last
    Arvato Limited

  • 5.  RE: Callback

    Posted 10-10-2019 10:06

    When using callbacks, also remember about the subsequent reporting data.  In a typical callback scenario there are really 3 interactions that are related:

    The original inbound call
    The callback created as a result of that inbound call
    The outbound call from the agent, that is created when the "Make Call" button is pressed on the callback itself

    There is no way, OOB, to tie together those three legs of the callback scenario.  However, with a little elbow grease and perusing of the Interaction Attribute Technical Reference, you can easily log the three related InteractionIDs to the InteractionCustomAttributes table in the PureConnect database.

    Attribute Technical Reference.

    Have a look at the following attributes.  I think they will get you started in bringing together all data necessary data points.  After they are logged, a custom report or BI solution could "tell the story" of your callbacks:


    Callbacks are a great tool, for sure.  But any sort of analytics around that media type will need to be custom logged prior to a report being created.

    Trent Vance
    Avtex Solutions, LLC

  • 6.  RE: Callback

    GCAP Member
    Posted 10-10-2019 13:57

    Hi everyone,


    Thank you for all of your responses.  In our testing, we haven't seen that it holds its place in queue.  It is viewing it as a new interaction within the same workgroup and it is restarting the queue time.  Any suggestions?




    This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. Contact us if you have any questions related to the content of this email or if you have received it in error. Confidential and personally identifiable information should not be transmitted to Amica via email or email attachment. Amica is not responsible for the loss, use or misuse of confidential or personally identifiable information which is sent to Amica via email or email attachment. Contact us if you have any questions about our policy.

  • 7.  RE: Callback

    Posted 10-10-2019 14:09

    This goes back to the original call that requests the callback interaction.
    Is the call itself flowing out of the queue -> creating the callback -> and then the callback is getting placed back into the queue?

    Or is the flow itself that the call stays in queue and essentially "morphs" into the callback object?

    In the initial example, that is as intended.  The system sees it as a new and different interaction.
    In the latter example, that would be an issue.  You'll want to confirm that the call interaction is correctly morphing into the callback interaction.  You can see the literal "morph" text in the IP log when this happens.

    So, as with most things when it comes to callbacks... ."It depends!"

    Trent Vance
    Avtex Solutions, LLC

  • 8.  RE: Callback

    GCAP Member
    Posted 10-29-2020 12:33

    Can you help me out and explain how you setup the option to call them back on the number they called in with or give them the option to enter the number to call them on via keypad. I can only seem to get to work one way or another.


    Christian Belli
    Dollar Bank, FSB

  • 9.  RE: Callback

    Posted 10-10-2019 23:47
    Hi Stacy,

    Here's some learnings that we discovered with Callbacks:

    1. Manual Answer agents and using Logical Step to check for 'Available agents'
    If your agents are using 'Manual Answer' for interactions, having a Logical step check for 'Available' agents offering a Callback (as per comment from @Philip Last) will not always work correctly with legitimate calls not being offered a Callback.​

    Reason for this is that the Logical step in Attendant checking for 'Available agents' seems to look at whether any agents in the Workgroup are in the 'Available' status - but not whether they are actually ACD Available (i.e. based on their Utilisation score).

    For for example:
    - manual answer Agent goes into 'Available' status
    - Interaction 1 already waiting in the Workgroup is offered to the Agent (alerting/ringing)_
    - Interaction 2 still being processed in Attendant performs a Logical step to check Agent Available in the Workgroup (offer Callback if agent not available)
    - Attendant tells the Logical step that agents are 'Available' in the Workgroup - so the step doesn't offer a Callback
    - However when the Agent answers Interaction 1, they are 100% utilised and not actually ACD available
    - Therefore Interaction 2 which should have been offered a Callback, was not offered one.

    We soon found out that this was occurring in our setup, where calls were not being offered callbacks even though our wait times were 10+ minutes and staff where 100% occupied.

    To work around this, we had to add another Logical step so that if Attendant says 'Agents available' then query the Workgroup if 'Interactions Waiting' as well:

    Agent Available = 0 then offer Callback
    Agent Available >= 1 and Interactions Waiting = 0 then don't offer Callback
    Agent Available >= 1 and Interactions Waiting >= 1 then Offer Callback

    In 99% of cases, this resolved the issue. Occasionally the system will offer a Callback when there really was someone Available (i.e. more staff are Available than the number of Interactions Waiting at the time the Attendant step checks).

    2. Staff confusion of what a 'Callback' interaction was versus the separate 'Outbound call' interaction
    Agents took some time to understand that the 'Callback' interaction is essentially a 'virtual post-it note' with the details of the Customer to call back. The Callback window cannot control the call once it's been made, it has to be manually selected from My Interactions.

    3. Staff not selecting the separate 'Outbound call' interaction to control
    Staff initially thought by pressing 'Hold', 'Disconnect' and 'Private' in the Callback window would control the call - but this is incorrect. As mentioned above, the Outbound call has to be manually selected from My Interactions and then use the Call Control buttons outside of the Callback window.

    4. Staff not disconnecting 'Outbound call' interaction after leaving a voicemail/message
    Similar to point 3, staff who pressed the Make call button but then reached a voicemail/message service would leave the message but then forget to actually Disconnect the Outbound call (and would just press the 'Retry Later' or 'Attempt Failed' button within the Callback window). This would then result in:
    - consultant leaving a really long voicemail with them talking for the entire period
    - going 'Available' but not receiving any new interactions (because the Outbound call is still in progress but it's hidden behind the disconnected Callback interaction until the disconnected interaction disappears), or
    - all of a sudden an ''Call' appears in their My Interactions but without any audio = even though they didn't go into Available (because the Outbound call is still in progress but was hidden behind the disconnected Callback interaction until it disappears after 2 minutes - which then brings the Call to the front)

    5. Screen recordings are not triggered by the 'Callback' interaction
    If you're using Screen Recordings through Interaction Recorder - you won't get any recording occurring until the Outbound call triggers the recorder policy.

    Therefore if you have staff disconnecting the Callback without making the Outbound call, there will be no Screen Recording of what happened. Additionally if you have staff not immediately making the Outbound Call, there won't be any Screen Recording between the period of time the Callback interaction was routed until the call was made (could be anywhere from 1 second to 10 minutes!).

    6. Callbacks created outside of a Queue Operation cannot have an 'ACD Priority' assigned
    If you're using ACD Priority value on your Group Transfers (Queue to Workgroup), Callbacks will only inherit the ACD Priority if they have been created within the Queue Operation step.

    If you create a Callback request through any other Attendant operation (before the Group Transfer and not as a Queue Operation), you cannot set the ACD Priority. (Even if setting the Interaction Atttributes Custom_ACDPriority or Eic_AttDynamicWorkgroupPriority first and you've got the Server Parameter 'Callback Default Priority' set - the outcome will always be 0)

    7. Reporting and real-time visibility is 'challenging'
    If you're offering a Callback to an Interaction that is already in the same Workgroup and the customer accepts, you'll end up with 2 Interactions showing as 'Offered' into the Workgroup reporting - and no easy way of determining which was which. You kind of have to use the 'Flow-outs' value to assume that most of the Flow-Outs where the Calls being converted to Callbacks - but it's not an exact number as 'Flow-outs' also occur if calls are manually cherry-picked from a Workgroup or a handler is de-queuing them (i.e. during an emergency).

    Also unless you're looking at the list of interactions waiting and manually counting each Media type (i.e. Calls vs Callbacks), the real-time statistics for 'Interactions waiting' cannot be split by Media Type.

    That's all I can think of right now :)

    Jeff Hoogkamer
    City of Gold Coast

  • 10.  RE: Callback

    GCAP Member
    Posted 10-30-2020 10:30
    +1 to all of these answers, adding my own 2 cents as well.

    We tell the customer EWT is greater than 5 minutes or greater than 10 minutes (rather than actual EWT).  By doing this, we don't get complaints that the estimation was incorrect.

    Priorities and Skills did not transfer as expected, we had to modify a handler to make this work.

    Agents figured out call avoidance relatively quickly (don't press the dial button for a long time), so we wrote a report that show the delay and attempts:

    select ins.InteractionIDKey [callbackID], dateadd(second, ins.StartDTOffset, ins.ConnectedDateTimeUTC) [Connected],att.LastAssignedWorkgroupID, ins.LastLocalName [Agent],
    att.InteractionIDKey [Outbound Attempt CallID], att.RemoteNumberFmt, DATEADD(second, att.StartDTOffset, att.StartDateTimeUTC) [Attempted],
    DATEDIFF(SECOND, ins.ConnectedDateTimeUTC,att.StartDateTimeUTC) [Delay], att.LastLocalUserId, att.LastLocalName, att.CallEventLog
    from InteractionSummary ins
    join InteractionSummary att
    on att.StartDateTimeUTC between ins.ConnectedDateTimeUTC and ins.TerminatedDateTimeUTC and att.RemoteID = '+1' + ins.RemoteID
    and att.Direction = 2
    where ins.StartDateTimeUTC between '10/01/2020 13:01' and '10/13/2020 06:10'
    and ins.MediaType = 6
    order by ins.ConnectedDateTimeUTC, att.StartDateTimeUTC

    Tim Cannon