OMniLeads to CRM Interaction

Each campaign can invoke a CRM or particular view

OMniLeads will execute program calls or notifications to the CRM when using campaigns with external URL set from the administration level. This can occur in incoming campaigns, preview or predictive dialer.

_images/crm_oml2crm_camp_call.png

Figure 1: campaign calls and crm

The idea of ​​this interaction is that the agent counts on with a view of the contact information in the CRM. OMniLeads allows a CRM URL invocation involving parameters of the call, contact and / or custom parameters within the context of the campaign running the program call to the CRM.

Depending on the settings applied in the campaign configuration, the invoked URL may be embedded within the agent console , or a new browser tab can be opened for each program call. Another action is to simply send an HTTP-Post JSON to the CRM.

_images/crm_camp_embedded.png

Figure 2: CRM and agent console

Finally we must consider that the execution of the CRM URL by OMniLeads can be done automatically (i.e. when call attempt is performed) or triggered by the agent after pressing a button in the agent console.

All configuration details associated with this scenario of CRM Integration are covered within this section.

Activate a new External CRM entity

The first step to follow is to register the entity ” External CRM” with the related web address (URL) and the interaction settings we expect. For that, access to the menu Campaigns - External Sites - New Site.

_images/crm_oml2crm_new_external_url.png

Figure 3: new crm

As stated in figure 3, in this step we need to simply complete the resource name, define the URL of the resource to invoke, and the type of interaction (GET, POST or JSON) with external CRM. Finally we set if the system will open a new tab per connected call, make the request and embed the result within the agent console or send a notification (JSON) to the CRM with the call parameters.

Let’s list each form field (figure 3):

  • Name: reference name
  • URL: this is the web address to invoke on each call. Here we only declare the web resource to invoke. As we will see later, the parameters are customized per campaign.
  • Trigger: here you can select the way you are going to invoke CRM URL web address.
    • When “Agent” is selected, then when the call connects with an agent, this is the one who triggers the execution of the CRM URL through an AJAX request from the browser.
    • When “Automatic” is selected, the execution of CRM URL is performed at the time the call is delivered to the agent console, through an AJAX request from the browser.
    • When “Server” is selected, then a HTTP POST request to CRM is generated.
  • Method: the execution of the CRM URL can be done through GET/POST request.
  • Format: in case of using HTTP-POST, HTML format can be defined here.
  • Scope: if the “trigger” is set as Automatic or Agent, then the result of the request made to the CRM URL can be displayed “embedded” in the agent console or by opening a new “tab” in the agent browser.

Once the CRM with all the configuration parameters is generated, we can affect it to different campaigns so that the CRM can be invoked in each call delivered to an agent.

Campaign configuration with CRM Interaction

All OMniLeads campaign types are able to activate this CRM interaction per agent call. In his point we will see some examples on how to perform this configuration using the campaign wizard (figure 3).

All campaigns have the ability to trigger a form or a CRM Interaction at the time a call is connected to an agent. In this configuration you may indicate CRM Interaction and then define the External CRM entity that will take place.

_images/crm_campaign_2_crm_config_1.png

Figure 4: CRM campaign activate

Then it is necessary to assign the parameters to be sent to the CRM. This is also set in the campaign configuration. (figure 5).

_images/crm_camp_params.png

Figure 5: CRM campaign params

At this configuration phase, we can indicate the expected parameters available in OMniLeads System that must be sent to the CRM every time a call is connected to an agent. Those available parameters are grouped by four families:

  • Campaign data, conformed by the parameters:
    • id: id of the campaign.
    • name: represents the campaign name.
    • type: represents the campaign type.
  • Call data, conformed by the parameters:
    • call_id: is the transaction identifier within OMniLeads.
    • agent_id: this is the id of the agent that is processing the call in charged of triggering the request to the CRM.
    • telephone: is the contact telephone number.
    • contact_id: is the internal id of the contact in the campaign.
    • rec_filename: the name of the audio file that contains the recording of the call connected to the agent.
  • Contact Data, parameters available from the columns of the current campaign contact database. Any column can be chosen as a parameter to send to the CRM.
  • Fixed Parameter, you can set custom parameters to be sent on each call.
  • Dialplan data, it is a parameter that the Dialplan should send in SIP originate header.

With all parameters defined above, in the figure 5 we need to note that three fields still need to be completed per parameter in order to be sent.

  • 1st Field: corresponds to the parameter type (campaign data, call data, database data or fixed data).
  • 2nd Field: corresponds to the specific name of the parameter to be sent (for example “name” if it is a campaign data).
  • 3rd Field: is the name of each parameter, expected from the CRM side.

Example 1: CRM interaction using GET

Let’s assume the following URL needs to be executed: https://my_crm.domain.com?idClient=321321321&idCamp=11&lang=es&recordingFile=prev-115-20190604-2-4149014-1559667982.424.wav

As you can note in our example of URL, each execution must provide:

  • Contact ID
  • Campaign ID that will invoke external CRM
  • Parameter “lang=es”
  • Recording of the current connected call

How would we implement this requirement from what we have covered in this chapter?

Generate the new CRM

Figure 6 shows the implementation of the proposed CRM seen in our example.

_images/crm_oml2crm_newcrm_example_1.png

Figure 6: CRM definition

Therefore, campaign configuration now will proceed in order to invoke the CRM with the parameters specified above.

In Figure 7, we explain how to configure the campaign to work with the CRM of this example.

_images/crm_oml2crm_campcrm_example_1.png

Figure 7: Campaign and CRM

The last step has to do with the assignment of the related parameters for CRM interaction. In figure 8 we see an example of this step.

_images/crm_oml2crm_campcrmparams_example_1.png

Figure 8: Campaign CRM parameters

Finally we highlight the relationship between columns 2 and 3 for each parameter, since they make the assignment between system parameters and the expected parameter names on the CRM side.

Example 2: CRM Interaction using GET and Clean URLs

Let’s assume that you want to run a Clean URL : https: //my_crm.domain.com/idClient/idCamp/lang/recordingFile

For instance: https://my_crm.domain.com/321321321/11/es/prev-115-20190604-2-4149014-1559667982.424.wav

As you can note in our example of URL, each execution must provide:

  • Contact ID
  • Campaign ID that will invoke external CRM
  • Parameter “lang=es”
  • Recording of the current connected call

How would we implement this requirement from what we have covered in this chapter?

Generate the new CRM

The implementation of the proposed CRM is shown as an example in Figure 9.

_images/crm_oml2crm_newcrm_example_2.png

Figure 9: CRM definition with clean URL

The figure highlights the “holders” needed to work with Clean URLs. When generating the URL to be executed, parameters must be specified between brackets. Those Parameters will then be used when generating the campaign for that CRM interaction.

Therefore, campaign configuration now will proceed in order to invoke the CRM with the parameters specified above.

The main difference from the standard URLs (HTTP GET) that is exposed in the example 1, is that when assigning parameters in the campaign, “holders” need to be used instead of “Parameter Names”, as shown in figure 10.

_images/crm_oml2crm_campcrm_example_2.png

Figure 10: Campaign and CRM parameters

Finally we highlight the relationship between columns 2 and 3 of each parameter, within the scenario of “clean URLs “.

Levantar variables de canal personalizadas de Asterisk y pasarlas al CRM

Hay veces en las que el modelo de negocio implica la necesidad de ejecutar un plan de discado de Asterisk personalizado, en este solicitar el ingreso de algun valor DTMF o bien acudir a la posibilidad que nos brinda Asterisk de utilizar servicios de reconocimiento de voz para interactuar con la persona que llama al centro de contacto.

Vamos a intentar ejemplificar un workflow con un ejemplo.

_images/crm_oml2crm_chanvar.png

Entonces supongamos que se desea solicitar a un llamante que ingrese su numero de cliente. Por lo que se podria tomar unm DID de nuestro troncal SIP y enviarlo a un dialplan personalizado.

_images/crm_oml2crm_inroute2customdst.png

Luego vamos a trabajar en dar de alta el destino personalizado y su codigo.

_images/crm_oml2crm_customdst.png

Respecto al dialplan como tal, se recuerda que el mismo debe ser generado en el archivo: oml_extensions_custom.conf.

[customerdata]
exten => 41004100,1,Verbose(custom dialplan customer data)
same => n,Answer()
same => n,Read(Omlcrmcustomerid,customerid,1,,1,5)
same => n,Read(Omlcrmcustomerplan,customerplan,1,,1,5)
same => n,Set(OMLCUSTOMDIALPLANVARS=Omlcrmcustomerid&Omlcrmcustomerplan)
same => n,Gosub(sub-oml-dst-switch,s,1(1,5))

Vamos a analizar el dialplan en cuestion:

En primer lugar y como es de esperar habra una parte en donde el desarrollador captura la interaccion del llamante, en el caso del ejemplo es a traves de la aplicacion de dialplan READ.

Important

  • El nombre de las variables TIENE que contener el prefijo Omlcrm

  • Se TIENE que crear la variable OMLCUSTOMDIALPLANVARS que contenga TODAS las variables que se desean pasar al CRM concatenadas con el caracter &

  • Para enviar la llamada a un nodo de OMniLeads se debe invocar en el dialplan a: Gosub(sub-oml-dst-switch,s,1(X,Y)) donde X es el tipo de destino:

    • 1 campanana entrante
    • 2 condicional de tiempo
    • 3 IVR
    • 6 Encuesta

mientras que el valor Y hace referencia al id del objeto en cuestion. En nuestro ejemplo (1,5) el 1 hace referencia a una campana entrante cuyo id es el 5.

Finalmente en la campana en cuestion, se configura la integracion con CRM de la siguiente manera:

_images/crm_oml2crm_camp_view.png