Hi Trevor,
To outline the problem
You have a variable CallerNumber you want to feed to your screenpop
On Inbound you want CallerNumber to be Call.ani
On Transfer you want CallerNumber to be original call.ani
and on Outbound you want CallerNumber to be DNIS
You already have a fix for inbound and transfer, just not outbound.
With outbound, unless its a Dialer, I would assume staff would open the customer record manually before calling the customer.
For dialer or other times when outbound call is done first in genesys before CRM record can be opened.
There might be more eloquent solutions out there, but my initial thinking is just to use a dynamic variable in your agent script
and set it so if the call type is outbound then set the CallerNumber variable to DNIS, otherwise set it to what CallerNumber already is, you could do something similar for inbound/internal.
Or if it is a Dialer, have the call go to an Outbound flow and just set CallerNumber to the dialed number, which should be a variable from the calling list you can access.
------------------------------
Anton Vroon
KiwiBank
------------------------------
Original Message:
Sent: 08-03-2021 13:45
From: Trevor Hervey
Subject: Buildin logic to gather customer ANI: specific to warm transfers and calls that originate internally
We use a simple screen pop function to launch our crm and use the incoming call.ani variable to locate the customer. We are trying to solve for situations where customers call into queue A and the agent completes a warm transfer to queue B, and the agents number is now set as call.ani (as designed, makes sense) among a couple other scenarios I will describe later. My first pass was to variablize the call.ani into a separate variable and then pull it in our internal transfer queue, so instead of call.ani being used, Flow.CallerNumber was being used. This worked, but only for scenarios that were customer initiated and transferred in that manner. The difficulty we are having is that we have scenarios where calls are initiated by agents outbound, then transferred to an internal queue, so then we need to pickup a different variable, probably use DNIS and set it to Flow.CallerNumber, or times where users are calling directly into our transfer queue (we have a few situations like this).
Its such a small overall problem that we basically are having a hard time figuring out how to properly fix. If there was a variable that automatically took call.customernumber or something where the system just takes whatever is not the internal agents info and used it, this would be rather simple to fix. Basically looking for direction on how to potentially sort these different scenarios initially to be able to capture a customers number so our screenpop always uses the proper information and creates the most efficient customer experience we can.
#ArchitectureandDesign
#Routing(ACD/IVR)
------------------------------
Trevor Hervey
IGS Energy
------------------------------