General

Variables a Configurar

AM: si esta activado la deteccion de Answering Machine, esta variable llega ${am} en 1 o 0 y es posible en el flujo utilizarlo para usar la actividad amd para cortar las llamadas de maquinas.

SOUND: Audio o concatenación de audios (con &)

DIALSTRING: como se marca Ej: DAHD/G1/ o SIP/TEST/

CONTEXT: contexto donde va ir luego de contactado el destino

EXTEN: habitualmente ${EXTEN} que es donde se marca, el flujo es de tipo _X. para matchear cualquier destino y lograr tener un CDR completo.

VARIABLES: variable1:valor1;variable2:valor2;

TIMEOUT: tiempo máximo de espera al llamar a una destino. 

CALLERID: Numero con que salen las llamadas.

MAXCHANNELS: Maxima cantidad de llamadas simultáneas.

DNCR: Do Not Call Registry, se encuentra en la tabla black_list

CALLINGPRES: Calling Presentation para poder dar numero Privado

TBC: Time Between Calls, es el tiempo que que se espera entre llamada y llamada, la idea es que cuando por ejemplo tomo 100 canales para discar y el servidor no puede manejar tantas solicitudes al mismo tiempo le ponemos un tiempo entre llamada y llamada Ejemplo: 300 ms
Habitualmente esta en 0 que es dejar el discador en su maxima velocidad.

Proceso

El sistema inicia segun el scheduler creado.

Basicamente al arrancar el sistema Crea una Tarea para Cada Campaña definida en el sistema (tabla dialer dialertype broadcast), las mismas arrancan y terminan de acuerdo al schedule que tengan (Es posible ver del portal el status de la misma si esta activa o parada y si esta dentro del schedule, así tambien como sus datos procesados).

Es posible en cualquier momento parar o volver a prender la campaña manualmente. Es posible reschedular las campañas en cualquier momento. Cabe Destacar que conviene una vez parado un discador esperar a que se terminen sus llamadas activas para poder

Entonces por schedule se ejecuta la tarea, esta tarea es la encargada de hacer las llamadas enviando llamadas obtenidas del spool (tabla calls_spool) para la misma, estas son obtenidas de acuerdo a la cantidad de canales disponibles para esta campaña y son marcadas de acuerdo al string de marcado de la misma (puede ser por TDM o Voip) cabe destacar que solo va a funcionar en lineas Digitales, Voip o Analogicas con Disconect Supervision (o sea inversion de polaridad). Al ejecutar la llamada esta se cambia de estado.

Estados

STATUS: 0 - PROCESSING (se esta discando)

STATUS: 1 - TO PROCESS (esta en spool lista a ser procesada, son las que toma el discador)

STATUS: 2 - EXCEEDED RETRIES (si tiene telefonos alternativos empiezo a usar el primero, sino la borro del spool)

STATUS: 3 - BLOCKED (bloqueado por DNCR)

RETRY: 0 inicialmente, > 0 cantidad de intentos a ese número

Las llamadas son borradas del spool si son atendidas o superan la cantidad máxima de reintentos.

Cuando llega algún evento de que el sistema pudo procesar la llamada esta se borra de la tabla, si fue ocupado o no answer o algún problema de que no había canales esta llamada es nuevamente insertada en el spool, incrementando el retry, esto para que no sea tomada inmediatamente y se procesen otras antes de volver a intentar con ella. Cabe destacar que entre llamada y llamada espera el tiempo TBC en milisegundos el cual habitualmente es 0 (sin delay) si el servidor no aguanta y/o son muchos canales simultaneos es mejor poner el delay en por ejemplo 300 ms para lograr que cuando genera un lote de llamadas de golpe no sean demasiado rapido y el sistema no las pueda procesar correctamente.

Es importante no solapar cantidad de canales, si disponemos de 30 canales y tenemos 2 campañas al mismo tiempo con un máximo de 20 va a resultar en posibles errores del marcador pudiendo repetir algunas llamadas. Tambien al tener mas de 1 campaña para mejor performance es buena idea dejar 1 canal de pivote ya que al ser un sistema asincrónico basado en eventos es posible que en algún milisegundo se esten marcando en otras campañas y todavía no se tiene dato de que la misma esta realmente activa ocupando un canal, por lo tanto en el caso de borde es posible que pueda pasarse una de las campañas de todas formas si se llegara a pasar y al sistema no le fuera posible crear un canal porque no hay, este se va a procesar mas tarde cuando se terminen de procesar las existentes en el spool ya que la misma va a quedar con un intento mas. Hay que tener habilitado en cdr.conf unanswered=yes para poder tener todos los datos necesarios.

Tecnico

El sistema lleva Tablas de Hash Sincronizadas para lograr tener cantidad de llamadas por campaña y el total de llamadas del VoiceBlaster.

Dentro del Callerid(name) se encuentra VoiceBroadCast:Campaña:Numero a Marcar Esto permite el seguimiento de eventos del sistema para saber cuantas llamadas activas por campañas y permite volver a poner en el spool llamadas que no pudieron contactar al destino.

Carga de Contactos

Archivo CSV donde se encuentra: campaña, numero de telefono, status, datos El formato correcto es MSDOS CSV (esperado por ; y los saltos de linea \n)

campaña	teléfono	status	datos	telefonos alternativos	reintentos	idcontacto
prueba1	098344484	1	variable1:valor1;variable2:valor2;	099111111:099121212	0	autonumerico

VoiceBroadCast

Introducción

El sistema de VoiceBroadCast es para realizar campañas de discado automatico, se sube una base de datos de telefonos y estos son dirigidos hacia un flujo IVR el cual puede ser para reproducir avisos, audios, de forma dinamica o estatica, tambien puede lograr realizar encuestas automáticas estáticas o dinámicas.

En este caso lo importante es setear la cantidad de canales ya que el VoiceBroadCast utiliza todos los posibles la mayor parte del tiempo.

Flujo Standard

exten=> _X.,1,Answer(0)   
exten=> _X.,2,Background(${sound},,,)                   
exten=> _X.,3,Hangup()

Variables que llegan al flujo: ${sound}, ${am}, todas las variables configuradas para esa campaña. Luego con eso es posible en vez de hacer un simple Flujo de BroadCast, es posible diseñar IVRs donde se generen dinamicamente encuestas automáticas.

Marcadores Progresivos

En este caso es un escalón mas abajo 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.

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 ocurre con los Predictivos. Pero en contrapartida, el principal inconveniente, es que no se maximiza el TTH ya que la máquina solo empieza a realizar 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.

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.

Basicamente llama al agente y cuando este atiende ejecuta la llamada, esto hace que muchos intentos puedan ser ocupado, numero equivocado, etc.

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.

Marcadores Powerdialer

A diferencia del marcador Progresivo nuestro Power Dialer no llama primero al agente y luego realiza la llamada sino que es un híbrido entre un predictivo y un progresivo.

Lo primero que realiza el sistema es marcar mientras existan agentes disponibles para atender llamadas en la campaña, ejemplo si hay 2 agentes disponibles va a realizar 2 llamadas simultáneamente y así hasta que contacte a alguno, una vez contactado

un cliente se envia a la campaña, en el 99% de los casos debería tener agente libre para atender al instante. Esto nos evita tener que entregarle al agente llamadas de números ocupados o inexistentes y entregarle llamadas solamente que fueron atendidas. La forma de trabajar es exactamente la misma en todos los discadores ya sea VoiceBroadCast, PowerDialer,Predictive lo único que cambia es la cantidad de llamadas

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.

- 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 VoiceMail 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.

Marcador SMS

Basicamente trabaja de forma similar al resto de los discadores que tenemos, se peonen en memoria 50 mensajes de state 1 de la tabla sms_spool ordenado por la posición de ingreso de los mismos, se fija si esta en la black_list, si esta no lo envía y lo pone en estado 3,

cabe destacar que las blacklist son por campaña, el sms es enviado y borrado de la tabla (este queda el registro en el repositorio como enviado), si existe un error entonces pasa a estado 2.

Estados

STATE: 0 NONE
STATE: 1 TO PROCESS
STATE: 2 BAD NUMBER OR DEVICE
STATE: 3 BLOCKED

campaign	destination	message	device	state	idm	data
prueba1	098344484	este es mi sms	Dinstar	1	autonumerico	datos extra

Browser not supported