Incoming Caller ID
Última actualización
Última actualización
Within the flow of an incoming call, a node with the functionality of customer identification can be added. That is, to launch an identification request on each incoming call processed, implementing in turn the possibility of consulting an external CRM management system and waiting for the latter to determine a decision on routing incoming calls from outside, through an interaction between OMniLeads and said management system. In its most basic operation, the module implements the possibility of requesting the identification of a customer who has contacted the company by entering DTMF telephone tones, then checking whether any value has been entered, and finally sending the call to a specific destination if positive, and to another destination if the result was negative. If the configuration involves interaction with CRM, then the module sends the number entered by the customer to the CRM and waits for a response from it, to decide where to route the call.
In both scenarios (basic mode and interactive mode with CRM), the call is sent to the agent with the customer ID as an index to obtain all the customer information and display it on the agent screen (either on the contact view or in the external CRM configured for the campaign). The module allows 3 operating modes, which are explained below.
Under this configuration, when an incoming call is sent to this node, an identification request is launched through an audio played over the telephone channel of the client that originated the call, to then simply validate whether or not the client entered a value, and thus make a routing decision towards the 2 possible alternatives: Destination A if an identification has been entered, or Destination B if the caller did not do so.
Figure 1: Customer ID without CRM interaction
Under this configuration, when an incoming call is sent to this node, an identification request is launched through an audio played over the telephone channel of the client that originated the call, and then a query is launched to a previously configured web service (CRM).
Figure 2: Customer ID with true/false interaction with CRM Here, the CRM management system takes the lead in routing customers who call the company, since after receiving the caller ID key from OMniLeads, the CRM must respond to the request received with a true/false response, so OMniLeads must then route the calls to each of the 2 possible destinations previously configured (Destination A if the CRM returns true or Destination B if the CRM returns false). An example could be a company that checks if the "customer number" is up to date with service payments, and based on that, route the call to a campaign with higher or lower priority in terms of queue waiting time.
Under this mode, when an incoming call invokes the execution of the node, the latter proceeds with the identification request and then validates whether or not the client entered a value, and if they did enter it, a query is executed to a previously configured web service (CRM).
Figure 3: Customer ID with selected CRM destination interaction The CRM management system takes a position regarding the routing of a customer who calls the company, since after receiving the caller identification key from OMniLeads in real time, the caller must respond to the request received with a response containing the OMniLeads destination node to which to route the calls, with the possibility of an inbound campaign, an IVR, a time validation, a personalized destination, etc. An application of this functionality could be to notify the CRM about the entered customer number and for the latter to decide which OMniLeads inbound campaign to send the call to, using as a criterion the subscription plan contracted for that customer number.
To generate a new node, you must access the Telephony -> Customer Identification menu:
Figure 4: Customer ID form The fields in the form are detailed below:
Expected ID Length: You can specify the expected length of the identification code.
Audio: This is the audio played during the incoming call to request the identification.
Identification Service URL: Here, you specify the web address of the service where the identification number is sent. External Interaction Type 2: The client ID is sent and a destination is expected in response. External Interaction Type 1: The client ID is sent and "true/false" is expected in response. No Interaction: It simply checks if an entry was made and its length.
Type of Interaction: Name: Reference name of the node.
Destination if NOT correctly identified: Type of destination and specific destination for that type, to which "negative" calls are routed in the interaction types "no interaction" and "external interaction type 1".
Destination if correctly identified: Type of destination and specific destination for that type, to which "positive" calls are routed in the interaction types "no interaction" and "external interaction type 1".
Attempts: The number of incorrect attempts allowed for entering the identification.
Timeout: The time in seconds that the system waits for the identification to be entered. If this time expires, it is checked whether the number of retries has already been exceeded to thus execute a new request or route the call to the unsuccessful destination.
Important In order to implement the methods that involve sending the identification to an external web service, waiting for a response from it and then executing the routing of the call, it depends on the management system implementing a web service to receive requests of this type. For developers who wish to enable this type of interaction in the management system, they can find the format in which OMniLeads sends the identification to the web service in the following section: Routing request to the external CRM system.
Éste POST enviado hacia el sistema de gestión CRM, tiene el siguiente aspecto:
Como podemos observar el campo «User-Agent» debe llegar como «OMniLeads», y en el cuerpo del POST, el número de identificación ingresado en la llamada se envía como «idContact».
Respuesta que debe generar el servicio web del sistema de gestión CRM
El servicio recibe de OMniLeads el request HTTP-POST con el número de identificación del cliente, y debe generar una respuesta a dicha solicitud. El sistema tiene la posibilidad de generar 3 tipos de respuestas:
true
false
X,Y: Donde «X» es un número entero y se corresponde con el tipo de destino hacia a donde enviar la llamada identificada, y donde «Y» es el destino puntual para ese tipo de destino. Por ejemplo (1,3) indica que la llamada será enrutada hacia una campaña entrante (1) y puntualmente hacia la campaña entrante cuyo ID es (3). La clave asociada a la respuesta es «response».
El formato de respuesta debe ser «JSON».
Respuesta JSON
Donde «status» puede ser ok o fail, y «destination» podrá ser cualquiera de las 3 respuestas especificadas arriba.
Importante
El sistema debe respetar el formato y nombre de parámetros (status y destination).
En caso de generar una respuesta con el destino del enrutamiento, se deben conocer los tipos de destino:
1: Campaña entrante.
2: Validación horaria.
3: IVR.
5: Hangup de la llamada.
9: Solicitud de identificación.
En un futuro se implementará un endpoint de la API para listar cada destino posible por cada tipo de destino. Mientras tanto, el desarrollador que desee implementar el enrutamiento de llamadas basado en la identificación ingresada en la llamada y el request generado desde OMniLeads, podrá ingresar a la interfaz de OMniLeads y en cada módulo (tipo de destino) listar los mismos y observar el ID.
Ejemplo de respuesta con destino de llamada
Se desea validar cada ID enviado desde OMniLeads y responder con 2 posibles tipos de destinos de enrutamiento. Por un lado una campaña entrante llamada «clientes gold» y otra llamada «clientes bronce».
Para ello, suponemos que existen las 2 campañas entrantes como se indica en la siguiente figura:
Tan sólo con posicionar el mouse sobre el nombre de la campaña, podremos dilucidar el «id» particular de cada una.
Por lo tanto, a partir de conocer los «id» de cada campaña, el sistema de gestión a partir de su lógica de negocio, podrá evaluar cada llamada e indicar a OMniLeads hacia donde encaminarla devolviendo el par «X,Y».
Ésta interacción implica que OMniLeads ejecute una solicitud HTTP-POST (plain/text) hacia la URL del sistema de gestión especificado dentro del módulo , es decir en la definición de un nodo «identificación de clientes».
