Para crear nuestras soluciones cloud, desarrollamos nuestras propias aplicaciones empresariales. Este dominio del software refuerza nuestra independencia y proporciona las herramientas más efectivas a nuestros empleados. Recientemente, un equipo recibió carta blanca para desarrollar las herramientas de asistencia de Infomaniak. Te contamos este proyecto a través de los ojos de nuestros desarrolladores.

Nos gusta nuestro servicio de asistencia al menos tanto como a ti

Nuestros agentes de asistencia son el vínculo entre todo lo que hacemos y nuestros usuarios. Son ellos quienes recogen vuestras sugerencias, vuestros problemas y los que permiten que nuestros productos evolucionen de acuerdo con vuestras prioridades. Sin su apoyo, Infomaniak no sería Infomaniak.

Escuchar. Identificar. Priorizar. Escribir código. Ajustar.

Para mejorar nuestras herramientas, nuestros desarrolladores han trabajado con sus colegas del servicio de asistencia, en grupos pequeños y sin intermediarios. Todo comenzó con una reunión entre asistencia, desarrolladores e ingenieros de sistemas. El equipo identificó una infinidad de áreas de mejora para optimizar:

  • satisfacción del cliente
  • gestión interna del servicio
  • eficiencia del proceso
  • comodidad de trabajo y satisfacción de los agentes

Era necesario encontrar juntos el equilibrio entre lo factible y la visión ideal imaginada. Cada desarrollo funcional se presentó a los usuarios finales para recopilar sus comentarios e impresiones con el fin de realizar los ajustes finales.

Responder a problemas específicos del servicio de asistencia

Pedimos a los desarrolladores que nos hablaran sobre las nuevas funciones que han creado para el servicio de asistencia:

1 – Fluidez en la espera

Para acortar la espera en caso de indisponibilidad en ciertas colas, un sistema «fallback» redirige la llamada de los clientes al primer operador disponible en su idioma. Los horarios de cada cola se controlan individualmente para cada día de la semana según los especialistas o idiomas disponibles. Para informar a los clientes lo antes posible, nuestros agentes pueden generar mensajes de audio dinámicos para transmitir según las condiciones: cola, problema técnico por producto, idioma.

2 – Análisis y mejora de la productividad

Hemos implementado estadísticas y nuevos indicadores (KPI) para producir una vista general del estado del servicio de asistencia durante períodos determinados. Los agentes de asistencia pueden:

  • identificar los problemas más rápido
  • acercarse a las expectativas del cliente
  • ayudarse mutuamente en tiempos de mayor ocupación para responder más rápido a los clientes

3 – Gestión dinámica de la central de asistencia

Los responsables pueden añadir/eliminar agentes de las colas, designar y cambiar su rol, ver su estado y establecer un número interno (lo que antes no era posible). También pueden establecer una música en espera, modificar los diferentes umbrales de alerta y definir plazos:

  • antes de llamar a otro operador
  • entre cada llamada
  • de activación de «rush time» y «fallback»

Ahora, se pueden redirigir las llamadas automáticamente a los móviles para procesar las solicitudes, incluso si un agente no está presente en el sitio (períodos de permanencia).

En el corazón del desarrollo

Cuando se trata de asistencia, cada detalle contribuye a la experiencia final del cliente. Por lo tanto, lo hemos hecho todo internamente, de acuerdo con nuestras limitaciones tecnológicas y nuestros objetivos futuros.

Este proyecto es un muy buen ejemplo de la realidad cotidiana de nuestros desarrolladores. Confronta y desafía las elecciones tecnológicas en relación con las mejoras concretas que queremos aportar al usuario, al tiempo que ofrece una libertad muy fuerte en las diferentes etapas de ejecución. Julien Viard, VP of Engineering en Infomaniak

El Frontend

El desarrollo de la interfaz de administración y las interfaces de asistencia en directo (pantallas de control en tiempo real de la central) se ha realizado con el framework AngularJS. Es la tecnología histórica de la aplicación con la que han trabajado los desarrolladores.

Varios componentes se han hecho a medida para facilitar el uso, tales como:

  • selección de usuarios para asignarlos a colas
  • cambio a la interfaz de cuenta del cliente
  • desplazamiento automático en las interfaces de asistencia en directo

Para la asistencia en directo, hubo que tomar una decisión: configurar sockets (IPS) o usar pooling con un call backend cada 3/4 segundos. La segunda solución fue elegida por razones de ecodiseño y facilidad de implementación. En lugar de mantener un canal constantemente abierto entre el frontend y el backend para actualizar los datos, manejamos los cálculos en el lado del servidor. El frontend extrae información de caché disponible en intervalos de 3 segundos (en lugar de 1) para limitar las llamadas al servidor y los cálculos redundantes. Para proporcionar una imagen suave y agradable a los agentes de asistencia, simulamos una actualización en tiempo real con incrementos visuales cada segundo.

Las estadísticas (KPI) requerían la implementación de varios gráficos y tablas que se pueden mostrar en escalas de menor o mayor longitud. Si es en un día, las estadísticas se muestran por hora y si es en un mes, por día.

El Backend

La tecnología histórica de la central de asistencia es Asterisk (protocolo SIP) y AngularJS para las herramientas preexistentes. Era necesario aprovechar la base de datos de Asterisk para recuperar cierta información sobre la marcha, manipular a los agentes de asistencia y crear todas las funciones correspondientes. Como parte de estas herramientas, solo procedemos con rutas API (REST) que se ejecutan desde la interfaz.

En general, este proyecto ha dejado mucho margen para la creatividad. Con Asterisk y una base de datos en tiempo real ha sido posible hacer un poco todo lo que queríamos. Una función interesante es que un agente puede pinchar en una cola en la que inicialmente no está (por ejemplo, otro departamento o idioma) para atender una sola llamada de esa cola. Simplemente hay que añadir dinámicamente al agente a la cola y luego retirarlo interceptando su próxima llamada recibida (utilizando el sistema de gestión de eventos).

Hemos implementado un sistema de gestión de eventos: el servidor telefónico realiza llamadas API con ciertos parámetros y realiza las acciones correspondientes en el lado del backend. Con este tipo de evento es posible ver la cuenta de cliente vinculada (dependiendo del número de la persona que llama) en la interfaz, al atender una llamada. Este sistema recupera los datos almacenados en la solicitud, luego envía las tareas para que la respuesta de la API sea muy rápida y no retrase la atención de la llamada en sí.

Para la gestión de mensajes dinámicos, el texto se transcribe en voz y luego se despliega directamente en un repositorio Git: la central usa este último y puede acceder a los mensajes en tiempo real. Ha sido una función muy divertida de desarrollar, ya que se puede crear rápidamente un pequeño repositorio de mensajes de voz y acceder a ellos desde una interfaz dedicada para escucharlos/editarlos.

Algunas rutas API se consumen directamente desde los scripts de nuestros administradores del sistema. Los parámetros difieren un poco de los utilizados por nuestra interfaz ya que las funciones no son 100% idénticas. En una línea de comandos, se puede ver el estado de una redirección y modificarla indicando solo el número interno y externo que se deben usar. Esto permite administrar automáticamente las redirecciones de guardias.

Desarrollo interno: un reto y una palanca

Es raro tener tanta libertad en un proyecto. La proximidad máxima a los usuarios finales ha permitido crear una emulsión de productividad para obtener unos resultados rápidos, buenos y pertinentes. Florian Grenier, desarrollador Frontend

El reto y también el interés de este proyecto es su flexibilidad que permite la máxima autonomía y eficiencia. Los usuarios finales son nuestros propios colegas, lo que nos permite hacerlo de otra manera. El equipo deliberadamente minimalista ha trabajado en un grupo pequeño durante 2 meses. Hemos hecho la integración continua (CI) con un servidor de staging 1 por 1 servidor de producción y la implementación automatizada en un servidor de prueba se enviaba a través de un script interno.

Framework viejo con rendimiento nuevo

Aunque hay una API integrada en el servidor Asterisk, decidimos no usarla. No satisfacía nuestras necesidades y no podíamos cambiar su comportamiento. Así que desarrollamos nuestras propias API.

El desafío técnico de este proyecto fue hacer malabarismos entre las funciones disponibles, los desarrollos existentes y los específicos, con plazos de producción bastante cortos y una calidad notable.

Los ajustes necesarios

Fue difícil lanzar pruebas en condiciones reales de producción: muchas más llamadas a la vez/llamadas largas/más tiempos de espera. Todo esto expuso al equipo de desarrollo a condiciones que nunca antes habían tenido y que requerían pequeñas correcciones, por ejemplo, en términos de pantallas en tiempo real.

Uno de los mayores problemas no se presentó de inmediato. Pasaron varias semanas antes de darse cuenta de la gran cantidad de logs generados por la central. Esto ha tendido a ralentizar demasiado la generación de estadísticas y las diversas acciones. Se ha configurado un sistema de flush automático, acompañado de un sistema de caché para evitar el recálculo de datos que no necesitan actualizarse con la misma frecuencia.

Los desarrolladores del proyecto

Florian Grenier, desarrollador Frontend: Me incorporé a Infomaniak hace dos años como desarrollador Frontend. Mi experiencia es bastante extensa: desarrollador PHC, luego C#, contacto breve con la app móvil Ionic, gestor de proyecto junior y luego desarrollador Java. Me diplomé bac+ 5 en Y-NOV en 2016, donde participé en muchos proyectos y concursos de desarrollo, también fuera de la escuela. En cuanto a recursos, visito muy a menudo este sitio para tomar ideas. Me encantan los tutoriales de Grafikart en YouTube.

Puede ser frustrante lidiar con tecnologías antiguas (deuda técnica). La realidad de un desarrollador es lidiar con lo existente, que no es necesariamente muy sexy al principio, para entregar al final una solución de calidad con un impacto real en la velocidad de la empresa.

Noé Fleury, desarrollador Backend: soy desarrollador Backend en Infomaniak desde hace aproximadamente 1 año. He aprendido varios lenguajes (PHP, C, Python, SQL, etc.) por mi cuenta y he validado mis conocimientos con un título de ciencias de la computación en la escuela de ingeniería (HES) hace 2 años.

Este proyecto demuestra que podemos desarrollar herramientas altamente efectivas sin recurrir a soluciones externas menos flexibles. Dado que la interfaz está dedicada solo a uso interno, ha sido posible añadir pequeñas funciones que no estaban planificadas, pero que en última instancia son muy útiles en la vida diaria.