Gestión de llamadas y procesos en background
En los últimos meses nuestros compañeros de Webphone publicaron un post en el que nos explicaban qué es un centralita virtual y los beneficios de emplearlas. En esas mismas líneas podéis ver que la atención telefónica es el método de contacto preferido por los clientes.
Teniendo en cuenta este hecho, debemos pensar que a mayor número de llamadas atendidas por los agentes, mayor es el trabajo de gestión que tienen que realizar. Si analizamos esto nos daremos cuenta que este proceso nos lleva a que los agentes tengan un menor tiempo de disponibilidad para atender llamadas y por lo tanto los clientes estarán un mayor tiempo esperando a ser atendidos.
Cómo mejorar los tiempos de gestión de llamadas
Una vez que nos hemos puesto en situación vamos a ver qué podemos hacer para minimizar este impacto lo máximo posible. Para ello vamos a poner un ejemplo práctico.
Contamos con una centralita Asterisk en la que un agente atiende una llamada: tras finalizarla, tiene que remitir un correo electrónico al cliente indicándole que ha recibido una llamada, además de la fecha y hora de la misma, para que le quede constancia por escrito del contacto realizado. Este es un caso sencillo, pero al agente le restará unos minutos tras la llamada que podría dedicar a atender a otro cliente.
¿Qué podemos hacer para ayudar al agente con este tipo de procesos y facilitar su trabajo lo máximo posible?
Ejecutar un script
Asterisk nos permite ejecutar comandos del sistema desde el propio plan de marcado utilizando la aplicación System(). Si por ejemplo queremos ejecutar un script en bash, nuestra línea del plan de marcado será como esta:
same => n,System(sh /ruta/de/nuestro/script.sh ${VARIABLE1} ${VARIABLE2} ${VARIABLEN})
Esta solución nos aporta cierta rapidez a la hora de implementarla, ya que un script lo vamos a hacer en un tiempo razonablemente corto (en función de lo que queramos ejecutar) y simplemente tenemos que incluir una línea adicional en nuestro plan de marcado para que se ejecute.
Pero también tiene ciertos aspectos negativos. Por ejemplo, puedes estar manteniendo canales activos en tu centralita de forma innecesaria. Si no has tenido en cuenta todos los patrones a la hora de finalizar una llamada, también es posible que tu script no se ejecute (por ejemplo, ¿quién finaliza la llamada: el agente o el cliente?), por lo que tendrás la incertidumbre de si la solución que has aportado está funcionando correctamente en todos los escenarios posibles. Además estarás cargando a tu centralita con un trabajo extra para el que no está diseñada, por lo que te puede terminar generando problemas de rendimiento.
Conectar la centralita a una BDD
Para la segunda alternativa que proponemos en este artículo debemos tener nuestra centralita conectada a una BDD. Si la tuya aún no lo está, merece la pena realizar este proceso, ya que te ayudará en tu día a día y te brindará nuevas posibilidades.
Si este es nuestro escenario, la solución es algo más elaborada que la anterior, pero tendrás una mejor respuesta en todo tu entorno y una mayor garantía de que tu solución funciona perfectamente.
Cuando una llamada finaliza, en la tabla de tu BDD donde estés registrando las llamadas se va a escribir una nueva línea con los datos correspondientes. Ya tenemos una nueva llamada en nuestra BDD, ¿y ahora…? La forma más eficaz de tratar estos casos es generar un nuevo servicio en nuestra centralita, para ello nos dirigimos a la ruta en la que tengamos alojados los servicios de nuestro sistema y con nuestro editor favorito creamos servicio.service (aquí le daremos a nuestro servicio el nombre que deseemos):
[Unit] Description=Descripción de nuestro servicio After=network.target <- De esta forma lo ejecutamos una vez se inicien los servicios de red StartLimitIntervalSec=0 [Service] Type=modo en el que ejecutamos nuestro servicio (simple, fork, idle, notify, etc…) Restart=always RestartSec=1 User=asterisk ExecStart=ruta en la que está nuestro ejecutable [Install] WantedBy=multi-user.target
Una vez creado debemos de habilitarlo para que se ejecute una vez se inicia el sistema. Para ello ejecutamos sudo systemctl enable servicio.service y, para que funcione, debemos tenerlo iniciado: sudo systemctl start servicio.service.
Ejecutando procesos con sendEmail
En el ejecutable de nuestro servicio podemos realizar el proceso que necesitemos. Para realizar el proceso que pusimos de ejemplo al principio tenemos que realizar lo siguiente (en función del lenguaje que empleemos para nuestro ejecutable y de la estructura de nuestra BDD este cambiará sustancialmente, por lo que os indicaremos los pasos a seguir).
Obtener el número de teléfono del cliente
Esto es, el origen o destino de la llamada, dependiendo de si la llamada es entrante o saliente.
Una vez que tenemos el teléfono del cliente, en nuestra BDD debemos de tener una tabla con los datos de los clientes. Esta tabla se irá nutriendo con cada contacto que vayan realizando nuestros agentes, para poder consultar el correo electrónico al que tenemos que realizar el envío.
Realizar el envío del correo electrónico
Para ello usaremos el agente de transferencia de correo electrónico que prefiramos.
En este punto vamos a realizar una recomendación: sendEmail. Su manejo es sencillo, dispone de todas las opciones necesarias para realizar este tipo de contactos y con una simple línea podemos realizar el envío:
/ruta/sendEmail -f cuentarigen@nuestrodominio.tld -t cuentadestino@dominiocliente.tld -s mail.nuestrodominio.tld -u \ "Asunto de nuestro correo" -m "Cuerpo de nuestro correo" -v -xu cuentaorigen@nuestrodominio.tld -xp nuestracontraseña
Pero podemos realizar infinidad de procesos como pausar una extensión tras una llamada. Esto no sería lo mismo que aplicar un wrapuptime en una llamada, ya que en ese caso únicamente aplicaría a llamadas recibidas a través de una cola y no le dejaríamos al agente la potestad de finalizar la pausa si lo precisara . Tampoco aplicaría para las llamadas salientes.
También podemos enviar un mensaje a través de un bot de una aplicación de mensajería instantánea, para que el responsable del agente esté informado en todo momento de qué sucede.
Y, por último, vamos a añadir un punto extra por la que creemos más adecuada esta solución, y es la de poder monitorizar el servicio desde nuestros sistemas de monitorización. De esta forma, si en algún momento el servicio dejara de funcionar, gracias a esta solución podremos actuar de forma rápida sin tener que esperar a que el cliente nos reporte que algo no está funcionando de forma correcta.