Customer identification on incoming calls

Presentation

Incoming calls can invoke a customer identification node in order to ask to caller for its identification number or client number, then this input will be process to choose the internal destination for the call, being able to involve the CRM on the choose that destination, through the interaction between OMniLeads and the defined CRM system.

In its most basic operation, the module implements the possibility of play a recording prompting callers its client number by entering DTMF tones and then route call to two different destinations (if the callers was input a valid number or not). In addition we can configure the module for launch an interaction with the CRM, so the CRM can wiil take control of incoming calls routing.

In both scenarios (basic mode and CRM interactive mode), the call is allowed to enter Agent with the customer ID as an index to get all the customer data and render it on the agent view (either on the contact view or in the external CRM configured for the campaign).

The module allows three configuration modes:

Basic behavior

In this scenario, an identification request is launched through an recording played on the customer telephone channel, and then simply validate whether or not the customer entered a value and thus make a choise about route between two possible destinations; destination A if an identification or destination B has been entered if the caller did not.

_images/customer_id_mode_1.png

Figure 1: Customer id without CRM interaction

CRM interaction true or false

In this scenario, an identification request is launched through an recording played on the customer telephone channel and this entered value its deliver inside a http-request to the CRM web service.

_images/customer_id_mode_2.png

Figure 2: Customer id with CRM interaction true/false

Then the CRM decides in some way the routing of the customers who call the company. Because after receiving the caller’s identification key from OMniLeads, the CRM must respond to the request received with a response of the true or false type, then OMniLeads must route the calls to each of the two possible previously configured destinations destination A if the CRM returns true or destination B if the CRM returns false.

An example could be to consult the CRM if the call must be sent to an incoming campaign to be answered by an agent or instead be sent to another destination.

The external CRM choose the OMniLeads destination where route customer calls

In this scenario, an identification request is launched through an recording played on the customer telephone channel and this entered value its deliver inside a http-request to the CRM web service.

_images/customer_id_mode_3.png

Figure 3: Customer id with interaction and destination chosen by CRM

Then the CRM choose the OMniLeads destination for the customers who call the company. Since after receiving the caller’s identification key from OMniLeads, the CRM must respond to the request received with a OMniLeads internal destination like response, finally OMniLeads must route the calls to the destination selected by CRM

An example of this functionality could be to notify the CRM about the customer number entered on call and then the CRM choose the OMniLeads incoming campaign where to route this call. The destination choice can be base on the type of customer subscription plan.

Create a new customer identification node

To generate a new node, you must access the menu item: Telephony - Customer identification

_images/customer_id_mode_form.png

Figure 4: New customer id node

The form fields are detailed below:

Field Description
Name Object reference name
Interaction type
  • Without CRM integration: just ask for identification
  • CRM interaction true or false
  • The CRM choose the OMniLeads destination for each customer caller
CRM web service URL here we indicate the web service address where send the requests from OMniLeads to CRM
Audio to be played on caller channel This is the recording that we can choose to request the customer identification
Maximum acceptable number of digits We can set the maximum acceptable number of digits for the customer id input
Timeout Enter the amount of time (in seconds) the system should wait for the caller to enter your customer id on their phone keypad. If this amount of time passes without the caller entering anything, it will be considered a timeout. After a timeout, the system follows the unsuccesfull destination defined below.
Retries Number of times to retry when receiving an invalid or null input from the caller
Successfull destiny Destiny for successfull calls. This option apply to Destiny for successful calls. This option apply to basic behavior setting mode or CRM interaction true or false.
Unsuccessful destiny Destiny for unsuccessful calls. This option apply to basic behavior setting mode or CRM interaction true or false.

Important

In order to implement the configuration modes that imply interaction with CRM, you must consider the fact that the management system has a web service to receive requests of this type.

For developers who wish to enable this integration in their CRM, you can find more information in our API documentation Routing request to the external CRM.

Routing request to the external CRM

OMniLeads send an HTTP-POST request (plain/text) to the URL of the external CRM inside the Create a new customer identification node module.

This post sent to the external CRM must be in this way:

_images/api_customerid_post.png

The “User-Agent” must be “OMniLeads” and the body of Post must be the id number sent in the call identified by “idContact”.

Answer generated by the web service’s external CRM

The service receives from OMniLeads the HTTP Post request the customer id number and must generate an answer to the request. The system has the possibilitie to generate three kinds of responses:

  • true
  • false
  • X,Y: where “X” is the int number and corresponds to the type of destination to send the call identified and “Y” is the punctual destination inside the type. For example (1,3) indicates that the call will be routed to an inbound campaign (1) which id is (3). The key associated to the response is “response”.

The response’s format must be “JSON”.

  • JSON response

    Content-Type: application/json
HTTP/1.1 200 OK

 {
   "status": "ok",
   "destination": "value"
 }

Where “status” can be ok or fail and “destination” can be any of the three responses specified above.

Important

The system must respect the format and name of parameters (status and destination).

In case of generate a response with routing destination, the types of destinations are:

  • 1: Inbound campaign
  • 2: Conditional based on time
  • 3: IVR
  • 5: Call hangup
  • 9: Solicitud de identificación

In the future an API endpoint will be coded to list all the destinations per destination type. Meanwhile, the developer that desires to make the call routing based on call identification and request generated by OMniLeads, could make this in the web interface and inside each destination type could list the same and check the id

Example of response with call destination: is desired to validate each id sent to OMniLeads and answer with two possible destination routing type. In a side the inbound campaign called “gold customers” and other called “bronze customers”.

By that we suppose that exist two inbound campaigns as indicated in the image.

_images/api_customerid_choice_dst_1.png

With just move the cursor in the campaign name, you can check the “id” of each one.

Therefore, knowing the “id” of each campaign the CRM could evaluate each call and indicate to OMniLeads the route that will have the call, returning the “X,Y” pair.