Generación Automática de Llamadas

De Asterisk Wiki
Saltar a: navegación, buscar

La generación de llamadas, automática o manual, suele moverse dentro ámbito del Marketing, como el concepto subyacente del lanzamiento de llamadas telefónicas, a un público objetivo controlado por nosotros. Eventualmente esto puede hacerse mediante la incorporación de operadores específicos y la utilización de marcadores de todo tipo. Esta funcionalidad gracias a Asterisk puede extrapolarse a muchos más ambitos de utilidad, como la posibilidad de lanzar llamadas automáticas como avisos de cualquier índole más allá de la estricta utilidad que ha venido siendo más usual, recordatorio de tareas, incidencias, eventos de calendario, etc.

A este nuevo conpceto, podriamos seguir denominandolo Generación Automática de Llamadas, o Marcación Desatendida.

Propósito General

Históricamente, uno de los medios de comunicación más eficientes en el entorno de acceso al mercado del consumidor directo, suele ser la telefonía, dado que, contrario a otros métodos publicitarios el contacto se establece exclusivamente con la persona con la que tratamos de establecer el contacto especifico.

Gracias a las nuevas técnicas y tecnologías como la Minería de Datos, en combinación al potencial que puede aportarnos esta funcionalidad de nuestro sistema Telefónico, podríamos avanzar un nuevo nivel en las estrategias dentro del mundo del Marketing gracias a procesos automatizados que ahorrarían ingentes cantidades económicas en costes de personal, y una extensiva gran mejoría en la producción de los sistemas, dado que podríamos acotar los potenciales clientes interesados, frente a la inmensa mayoría que no muestra ningún interés por nuestros productos.

El perspectiva común que se ha establecido en la historia para la formalización de prospectos [1], el proceso típicamente seguido era el de la creación de una lista de potenciales clientes (en base a una selección previamente estudiada de personas que probablemente mostrarían algún tipo de interés por e producto a través de sus preferencias de consumo, o sus posibles necesidades cercanas), y aportar esta lista a una serie de Agentes Comerciales, los cuales dedicarían su tiempo a contactar con todos y cada uno de los teléfonos de dicha lista para intentar conseguir el resultado esperado. En este proceso incurríamos en una serie de mecanismos que con las tecnologías actuales era posible mejorar:

  1. El más evidente, el tiempo de marcación de los dígitos, y como es normal, la posibilidad de errores.
  2. El tiempo de espera hasta que el cliente respondía la llamada
  3. Lidiar con eventos varios como, cliente comunicando, cliente no disponible, número erróneo, líneas de Fax, etc.
  4. La atención con clientes que no mostraban ningún interés potencial, e incluso se sentían reacios o molestos a establecer este contacto telefónico (entre todos los puntos, quiza el mal menor, dado que realmente este también podía ser uno de los propósitos de los Agentes Comerciales, hacer cambiar de parecer).

Curiosamente, considerando todos estos factores, llego a observarse que el TTH (Talk Time per Hour, tiempo en conversación por Hora), era muy inferior al resto del tiempo de "Improductividad", cuando realmente esta era la principal función de los Operadores.

Por otro lado hay que considerar que el uso de la generación de llamadas automáticas puede ser extendido a otros ámbitos. Por ejemplo:

  • Notificación de una advertencia: Tenemos un sistema de monitorización tipo [www.nagios.org Nagios] conectado a nuestra máquina Asterisk. En el momento que se cae un servidor, podría hacernos una llamada, y nosotros tan pronto ver el Identificador de Llamada (ejemplo: 1111 <Alerta Servidores>) podríamos urgentemente dejar lo que estemos haciendo para atender la incidencia máxima prioridad. Muchísima más potencia que por ejemplo una alerta por e-Mail convencional, y lo mejor es que no tienen que ser mutuamente excluyentes
  • Notificación de Tareas: Utilizando eventualmente un sistema de Texto a Voz podríamos realizar llamadas por determinados eventos de una agenda de un usuario sincronizada con nuestro asterisk, y recordar una determinada tarea al usuario utilizando una Voz TTS del sistema Asterisk.
  • Eventos de Calendario: Similiar al sistema de notificación de Tareas, pero para eventos de un calendario, citas, reuniones, etc...
  • Alarmas: Si por ejemplo, somos un hotel, y nuestros usuarios nos piden que les despertemos por teléfono a una hora determinada podemos ofrecerle este servicio con este sistema.

Como podemos ver, existen una gran cantidad de usos aparte del más común que comentábamos al principio.

Tipos de Generación

Existen múltiples formas de generar llamadas automáticas en Asterisk, entendiendo estas, como aquellas que no requieren la marcación de los dígitos por un usuario en su dispositivo.

Las tres formas más reconocidas son:

  • Aplicación y Recurso Originate
  • Scripts de Generación de Llamadas
  • Marcadores

Originate

La idea de Originate es "forzar" a que un dispositivo llame una extensión o ejecute una aplicación especifica. Existen dos formas de conseguir este efecto, y es gracias a la aplicación y al recurso Originate, tanto para el Plan de Marcación, como para la interfaz CLI.

El nombre del módulo de la aplicación es app_originate.so, y la posibilidad de lanzar llamadas desde CLI, se consideraría un módulo de tipo recurso llamado res_clioriginate.so

La sintaxis de ambas opciones es muy parecida:

  • Para el caso de Lanzar una llamada automática:
    • Para la Aplicación: Originate(<canal>/<dispositivo>,exten,<contexto>,<extension>,<prioridad>)

Ejemplo: Originate(SIP/ext11,exten,extensiones,101), en este caso, el dispositivo ext11 por el protocolo SIP, llamaría (in)voluntariamente, a la extensión numero 101 del contexto extensiones.

    • Para la interfaz CLI: channel originate <canal>/<dispositivo> extension <extension>@<contexto>

Ejemplo: channel originate SIP/ext11 extension 101@extensiones, conseguiriamos el mismo efecto que el caso anterior

  • Para el caso de Lanzar una aplicación específica:
    • Para la Aplicación: Originate(<canal>/<dispositivo>,app,<nombre_aplicacion>,<variables>)

Ejemplo: Originate(SIP/ext11,app,Queue,marketing), en este caso, el dispositivo ext11 por el protocolo SIP, ejecutaría la aplicación de introducirse en una [Colas|Cola] llamada "marketing"

    • Para la interfaz CLI: channel originate <canal>/<dispositivo> extension <extension>@<contexto>

Ejemplo: channel originate SIP/ext11 applcation Queue marketing, conseguiríamos el mismo efecto que el caso anterior

Originate con AMI

En esta aplicación se basan las aplicaciones que interaccionan con el AMI para crear sistemas de marcación automática como los Marcadores, por ejemplo, utilizando la aplicación Originate para llamar a una extensión, que en este caso podría ser, un teléfono de un cliente, de manera involuntaria para el Agente dado que sería el propio Marcador el que realizaría esta labor de ejecución de la aplicación.

Es posible lanzar comandos a la interfaz AMI de tipo Originate, siguiendo esta sintaxis:

Action: Originate Channel: <canal>/<dispositivo> Application: <nombre_aplicacion> Data: <variables>

Para los casos utilizados anteriormente podemos poner el siguiente ejemplo:

Action: Originate Channel: SIP/ext11 Applicaton: Queue Data: marketing

Scripts de Generación

Podemos crear un pequeño script en nuestro sistema, llamado fichero de llamada (Call File), y con este, ejecutar una serie de comandos, para ejecutar Aplicaciones Específicas con respecto a una extensión en concreto. Es muy parecido al uso que se puede dar a la combinación del Comando Originate con AMI según explicado en el anterior apartado. Ese fichero de llamada suele tener la extensión .call

Una vez hayamos creado el fichero de llamada que queramos ejecutar, tenemos que depositarlo en un directorio por defecto del sistema Asterisk: /var/spool/asterisk/outgoing/

Hay que considerar que Asterisk tiene un demonio de sistema Linux, con el cual, hace múltiples comprobaciones por segundo dentro de este directorio. Simplemente con colocar el script .call dentro de este directorio, si no tiene errores de sintaxis, ejecutara el comando con la aplicación en cuestión, y el fichero será "absorbido" (es decir, ejecutado y eliminado) ipso-facto. Tanto es así que si ejecutamos un comando Linux de copia del script al directorio outgoing, es muy probable que el fichero solo sea leido parcialmente, y no se ejecute el comando correctamente. Por ello, todos los ficheros han de pasarse a este directorio con el comando de Mover del sistema Linux:

# mv ./mi_fichero.call /var/spool/asterisk/outgoing/


Esto ocurre, porque el comando cp es relativamente más lento que el comando mv. La esencia es que el comando cp crea un nuevo fichero, y copia el contenido secuencialmente de uno a otro, en ese intervalo de copiado, si Asterisk realiza una comprobación, puede quedarse a medias, mientras que mv, solo renombra la ubicación (según la estructura de directorios del sistema *NIX en una estructura de arbol, única modifica donde apuntan los punteros relativos), acción que es prácticamente instantánea.

Estructura del Script

El fichero de llamada, debe crearse siguiendo la siguiente estructura, y sintaxis:

  • En primer lugar, a que dispositivo conectar y sus opciones:
    • Channel: <canal>/<dispositivo>, sería el dispositivo al que queremos llamar, ejemplo SIP/ext11
    • CallerID: <identificador>, sería el identificador de llamada que queramos especificar, ejemplo "Alertas Servidor" <1111>
    • MaxRetries: <numero>, número de intentos de llamada antes de abandonar.
    • RetryTime: <tiempo_segunods>, tiempo en segundos entre reintentos
    • WaitTime: <tiempo_segundos>, tiempo de "timeout" antes de abandonar al dispositivo que estamos tratando
    • Codecs: <codec1>[,<codecN>], codecs que queramos utilizar
    • Archive: <yes/no>, si queremos que el fichero de llamada se guarde en un subdirectorio llamado "outgoing_done".
  • Si el dispositivo acepta la llamada, entonces lanzamos la extensión o la aplicación a voluntad, muy parecido al Originate:
  • Si elegimos llamada a una extensión:
    • Context: <nombre_contexto>
    • Extension: <numero_extension>
    • Priority: <prioridad_extension>
    • Set: <variable>: Muy parecido a la aplicación Set del Plan de Marcación
  • Si elegimos llamada a una aplicación:
    • Application: <nombre_aplicacion>
    • Data: <variables_aplicacion>: Las variables que queramos pasarle a la aplicación

Un ejemplo muy sencillo para crear y lanzar este fichero de script podría ser:

Archivo: ./mensaje.call
Channel:SIP/ext11
Application:Queue
Data:marketing


# mv ./mensaje.call /var/spool/asterisk/outgoing/


El resultado sería exactamente el mismo que con los ejemplos de Originate que vimos anteriormente.

Marcadores

Los marcadores son herramientas de software, específicamente diseñadas para sistemas de telefonía, que requieren de algún tipo de CTI (Computer Telephony Integration), como es AMI en caso de Asterisk, y ampliamente utilizados por los Call-Centers.

La intención principal de los mismos es la automatización del proceso de marcado a números de teléfono externos de forma desasistida, para intentar aumentar la productividad de los agentes. Como veíamos antes, estaba bastante comprobado que el hecho de ofrecer una lista de prospectos y ofrecer la oportunidad a los Agentes Comerciales de realizar el marcado manual, suponía una ingente cantidad de tiempo consumido sin utilidad rentable para el Comercio.

Existen varios tipos de Marcadores, los más destacados:

  • Marcadores Manuales
  • Marcadores Predictivos
  • Marcadores Progresivos

Marcadores Manuales

Por un lado consideramos, la marcación puramente manual, como un tipo de Marcador, independientemente de su eficiencia.

Con la evolución de los sistemas, surge un nuevo tipo de Marcación, llamada Marcación por Previsualización del Prospecto, que es ofrecida gracias a la integración de diversos CRM con las máquinas de telefonía para lanzar las llamadas directamente desde la pantalla del ordenador del Agente Comercial.

Este es un primer paso para la automatización, dado que por un lado ya se establece esa interconexión PC-PBX y por otro lado, eliminamos la posibilidad de marcaciones manuales (que son costosas en tiempo total), y la posibilidad de errores en la marcación (que aunque parezca extraño, es relativamente elevada en la mayoría de los operadores).

En contra partida, es el operadora Manualmente, quien gestiona el resultado de esa llamada (en caso que no haya un cliente disponible detrás de la misma).

Marcadores Predictivos

Marcadores Predictivos

Aquí subimos un escalón bastante importante en la escala de los marcadores automáticos. Los marcadores predictivos basan su funcionamiento, en bases de datos de teléfonos a llamar, y lo hacen como su nombre indica de una forma "predictiva".

Esto quiere decir que entra en juego un algoritmo basado subyacéntemente en estrategias estadísticas, las cuales toman múltiples variables del Centro de Llamadas y calculan diversos factores para poder poner en contacto a los Agentes Comerciales con los potenciales clientes de la manera más eficiente posible.

Por regla general, la principal utilidad y ventaja para los Marcadores Predictivos radica en el volumen de llamadas de los Centros en los que se basan, dado que al estar fundamentos en técnicas estadísticas, su máxima fiabilidad redunda en la Ley de los Grandes Números. Es por ello, que en Call-Centers de carácter reducido son bastante poco recomendados por su funcionamiento base.

En esencia, la idea conceptual detrás de los marcadores predictivos es la siguiente:

  • Primero ha de calcularse el tiempo ideal para lanzar llamadas a clientes utilizando estrategias estadísticas de diversa índole, entre las que se incluyen:
    • Calculan el tiempo medio por cada llamada que resulta en éxito, y cada llamada que resulta en fracaso.
    • Calculan la proporción media de llamadas resultantes en éxito y en fracaso y con ello se pondera un tiempo medio estimado para todas las llamadas en general
    • Utilizan otros factores que influyan en los tiempos, como el tiempo medio de preparación para aceptar otra llamada de cada agente

Cuanto más sofisticado sea este algoritmo, mejor en términos generales será el Marcador Predictivo. De hecho este es uno de los factores clave que determinara su éxito en un futuro. Muchos Algoritmos predictivos se basan en la distribución de Erlang

  • En segundo lugar, se lanzan llamadas a los números almacenados en la base de datos, respetando este tiempo calculado:
    • Con las llamadas en curso, el Marcador Predictivo debe ser capaz de identificar si existe algún tipo de inconveniente para no poder contactar con el cliente, principalmente por el tipo de tono que se recibe, según la convención de tonos a nivel nacional del país en concreto. [2] [3]
    • También ser capaz de detectar Tonos de Fax y otras posibilidades que también sigan algún tipo de estándar
    • En caso que ocurra un evento de este tipo, dependiendo del evento, la aplicación ha de ser capaz de marcar el teléfono apropiadamente en función de lo ocurrido:
      • Si ha sido llamada ocupada, volver a intentarlo pasados unos minutos
      • Si ha sido llamada no atendida, volver a intentarlo pasadas unas horas
      • Si ha sido linea errónea, linea de fax, etc, borrar la linea de la lista e informar al responsable de la gestión de la base de datos de números de teléfono.
    • Además la capacidad de detectar Buzones de Voz dado que por regla general son símbolos de "No Disponible", para volver a intentar la llamada más tarde. La detección es relativamente fácil, en función del tiempo total de respuesta de voz, dado que la mayoría de las respuestas de personas físicas suelen ser, un simple "Hola?", mientras que los contestadores suelen ser una frase bastante larga.
    • En el momento que recibe una llamada atendida, se la pasa a la cola de los Agentes Comerciales para que sea atendida con brevedad.

Con este sistema, los agentes solo quedan a la espera de que la máquina haga su trabajo, y por regla general, no tienen la posibilidad de elegir si desean responder la llamada, sino que esta se pone directamente en comunicación con el Agente.

A priori, este método puede ser ideal, y maximizar el TTH que comentábamos al principio, y realmente si estamos ante un Marcador Predictivo de calidad, es cierto esta premisa. Pero en contrapartida nos encontramos con algunos inconvenientes, que debemos sopesar, a la hora de elegir este tipo de Marcadores:

  • Si en el intervalo en el que el cliente atiende una llamada, y el operador la recibe, no hay respuesta, es muy probable que el cliente abandone la llamada. En este caso la mayoría de los marcadores predictivos, ponen el número para ser llamado en un futuro, pero podemos generar insatisfacción en el cliente por causas de molestia
  • Si lo queremos utilizar con fines comerciales de Empresa a Empresa, es posible que sea bastante ineficiente, dado que la mayoría de las empresas dispongan de un IVR el cual posiblemente impida que nuestro marcador predictivo cumpla su propósito en condiciones.
  • Como comentábamos, si tenemos pocas llamadas en el Centro, es posible que los algoritmos estadísticos no saquen cifras de calidad y por tanto ocurra mucho el primer problema, siendo un sistema muy ineficiente.

Marcadores Progresivos

En este caso bajamos un escalón con respecto a la máxima automatización, pero nos mantenemos en sistemas de llamadas puramente automatizados. Los Marcadores progresivos se basan en la disponibilidad de los Agentes, eventualmente indicada de forma manual.

Al igual que los Marcadores Predictivos, los Marcadores Progresivos son capaces de detectar todo tipo de eventos durante las llamadas, hasta conseguir dar con un cliente disponible y apto para ser comunicado con nuestro Agente.

Además también suelen ser capaces de tener la base de datos actualizada, y reintentar las llamadas más tardes en caso que sean eligibles para ser contactadas por eventos que no indiquen la no-disponibilidad perpetua.

La principal ventaja radica en que es muy improbable el evento de llamadas Abandonadas, por no existir un Agente a tiempo como ocurría con los Predictivos. Pero en contrapartida, el principal inconveniente, es que no se maximiza el TTH ya que la máquina solo empieza a cursar llamadas, en el momento que el Agente indica su disponibilidad. Por tanto esa espera, mientras que la máquina consigue dar con un cliente, aplicando sus técnicas de selección, es tiempo de no-conversación y reduciría significativamente la eficiencia del anterior TTH comentado. Muchas veces, ese tiempo de "espera", se utiliza para que el Agente pueda ver en pantalla los datos del cliente que esta siendo llamado, y así poder ofrecer un trato más específico destacando algunos puntos relevantes (por ejemplo, leer si existen posibles contactos pasados para poder hacer referencia a ciertos comentarios del usuario y establecer un trato más personalizado).

Los marcadores progresivos, suelen ser muy apropiados para los Centros con un volumen bajo o moderado de llamadas, donde no serían capaces de recabar suficiente información para alcanzar estadísticas fiables.

Además a nivel económico, los marcadores Progresivos suelen ser muchísimo menos costosos que los Predictivos, dado que la creación de los algoritmos predictivos con carácter estadístico, suele ser la tarea más especializada, y ya que en algunos casos, suelen ser verdaderas obras de ingenio, y se pagan en forma de patentes/licencias.

Generalmente, para tener un marcador predictivo con algoritmos malos, es mucho mejor tener un marcador progresivo. En la actualidad existen Marcadores Progresivos Open Source, que suplirían esta carencia. No existe ningún marcador Predictivo Open Source que pueda competir contra los que requieren una licencia profesional comercial.

Referencias

  1. ¿Que es un Prospecto, Jesús Hoyos (2007)
  2. Sistema de Señalización por Canal Común, en Wikipedia.
  3. Especificaciones Técnicas de Interfaces de Telefonía Conmutada Analógica y Digital, Telefónica de España S.A.U.

Véase también

Enlaces Externos

  • Vicidial es un marcador automático Open Source, tanto progresivo como predictivo, y muy popular en el mundo Asterisk.
  • GNUDialer es un proyecto para crear un marcador predictivo de calidad Open Source