Allowing callers to request a Callback rather than waiting in queue is a great way to provide better customer service… assuming your agents actually place the requested return calls. CIC’s out-of-the-box reporting provides great Callback queue statistics (offered, answered, abandoned, service levels, etc.) just like other interaction types. But there are several questions that are commonly asked about these interactions that are not as easy to answer, such as:

  • What was the interaction ID of the inbound call that generated the Callback request?
  • What was the interaction ID of the outbound call placed on behalf of the Callback request?
  • Was the Callback completed or failed (which button did the user press on the Callback form)?
  • Were there any Callback requests for which agents did not place a return call?

Answering these questions is important! For example, it is incredibly frustrating for a customer to request a Callback and never receive a return call. If it happens, you will either hear about it in the form of negative feedback. Or worse yet, not hear about it because the customer went somewhere else to conduct their business.

So what to do? To answer these questions, more data about Callback interactions is needed. The system knows all of this information, it just needs to be written to the reporting database. There are several ways to accomplish this, but here’s a relatively simple one:

Enable custom attribute mappings

  • In Interaction Administrator, browse to System Configuration > Report Logs, and open Log ID 20 – Interaction Custom Attributes Log
  • On the Basic tab, verify that the Active checkbox is checked
  • On the Mappings tab, uncheck the Use default mappings checkbox
  • In the Map string field, add the following string (use different fields if needed):

CustomString1=CallAttribute(“Eic_CallbackCompletion”);CustomString2=CallAttribute(“Eic_CallbackOriginalCallId”);CustomString3=CallAttribute(“Eic_CallbackAssociatedCallId”)

Query the database for results

As new Callback interactions come through the system, the specified custom columns will not be populated with additional data about these interactions…

Here is what it means (this assumes out-of-the box Callback configuration):

  • CustomString1 = 83 The user clicked the Callback Complete button
  • CustomString1 = 70 The user clicked the Attempt Failed button
  • CustomString2 value Interaction ID of the call that generated the Callback request
  • CustomString3 value Interaction ID of the outbound call placed on behalf of the Callback request

Now that you have more data about callback interactions, database queries or custom reports can be used to start answering some of the questions listed above.

Was this information helpful? Do you need help setting this up? Is there something else you would like me to write about? Let me know!