Hoy dia la integración del CRM con la telefonía tiene una importancia vital. Si el cliente está escuchando el saludo automatico demasiado tiempo o si no le devuelven la llamada después de que ha dejado su solicitud en la página web - el cliente se va.
Vamos a ver cómo creamos el producto masivo para integración de Bitrix24 y Asterisk usando FreePBX y que obtuvimos como resultado.
Antecedente
A finales de 2016 teníamos prácticamente hecha la solución para los centros de contacto basada en la versión self-hosted de Bitrix24 y Asterisk. En aquel momento no funcionaba SIPML5 que se utiliza para el tratamiento de WebRTC en el navegador.
Estábamos planeando las pruebas finales y el lanzamiento del producto a edición cuando en diciembre en REST API de Bitrix24 apareció el soporte de telefonía. Nuestro equipo tuvo que integrar Asterisk y Bitrix24 utilizando los nuevos métodos REST API .
Mientras tanto la necesidad de esta integración aumentaba. La conexión por medio de VoxImplant incluía un eslabón innecesario, exigía configuraciones complicadas tal como se dice en la esfera de la tecnología IT bailes con pandero y limitaba la libertad de acción de los especialistas de Asterisk. Debido a que la parte de la lógica de procesamiento de la llamada con tráfico SIP y RTC se iba por un sistema externo.
Decidimos que los centros de contacto podían esperar y que estábamos cumpliendo un pedido concreto. Según los resultados íbamos a lanzar un producto de integración para todos los que deseaban.
MVP
Resultó que los colegas habían utilizado tres versiones de Asterisk: una con contextos customizados, dos conectadas a la primera. Esto complicó la tarea que de hecho era simple: definir a la persona responsable, abrir el formulario, grabar la llamada en el CRM.
“En realidad la tarea no es tan difícil”-, van a decir ustedes. Tal vez tardaría unas cuatro horas de trabajo en resolver. Así es, si lo hacen para sí mismo cuando los escenarios necesarios están limitados. Pero cualquier paso hacia otra dirección añade otras cuatro horas. Sin embargo, lo estábamos haciendo para todos. Significa que nuestro objetivo no era un camino fácil para el desarrollador si no que el camino fácil sería para el usuario.
La solución está basada en framework de FreePBX v.13. que era la más popular en el mercado de aquel tiempo. El módulo se desarrollaba rápidamente ademas incluía todo lo necesario para nuestra solución.
La parte principal fue realizada como un módulo de FreePBX. Las ventajas de la versión 13 de FreePBX que usamos: interfaz actualizada, notificaciones pop-ups en la configuración del módulo, soporte de AJAX , el proceso de actualización del módulo era simple con los cambios estructurales de la tabla.
Lo más importante para el funcionamiento del módulo es determinar los contextos correspondientes a la integración. Cada cliente tiene su propio esquema de procesamiento de llamadas.
Hoy día trabajamos principalmente con los contextos ext-did-001, ext-did-002 y macro-dial-one- para las llamadas entrantes, outrt-, macro-dialout-trunk -para las llamadas salientes.
Integramos Bitrix24 y Asterisk en dos meses. Y ahora CRM de Bitrix24 vigila a todas las llamadas entrantes y salientes.
Hemos obtenido una buena experiencia de colaboración en proceso de trabajo mutuo. Muchas discusiones de diferentes escenarios no habían pasado en vano. Algunos informes de los fallos los íbamos cerrando durante el día. A finales de marzo la versión beta apareció en Marketplace de Bitrix24.
Primeros resultados
Cuando estábamos creando MVP nos orientamos a una lógica sencilla y transparente. Por ejemplo, la hora de inicio y de fin de la conversación está vinculada a un canal de un abonado externo (en tiempos de llamada entrante - el primer canal abierto, en tiempos de llamada saliente - el canal en que se encuentra el número de llamada). El soporte de Ring Groups y FollowMe aun así no entraron al registro del resto de trabajos MVP. Pero esto no afectó a la funcionalidad porque se sustituyen por las colas.
El resultado no tardó en llegar: desde los primeros días recibimos 15-20 instalaciones al día. Para nosotros esto era una prueba de la hipótesis. La primera versión beta tenía MVP básico pero funcionó para los usuarios. Por lo tanto, este resultado nos dio fuerzas y confianza. También animó a los usuarios a dejar sus comentarios muy valiosos en el primer canal abierto.
Cuidando a los usuarios
La mayoría de instalaciones de Asterisk son apartadas del mundo y funcionan perfectamente detrás de NAT. Sin embargo, es bastante sorprendente recibir unas decenas de preguntas de los administradores del sistema de como configurar Firewall para la integración.
“El reenvío de puertos? Claro, escuchamos. Y que se reenvía? A donde? Para que?”
El problema no estuvo en la calificación de los usuarios sino en la presentación de los datos. Era muy importante y no se podía resolver solamente con algunas correcciones añadidas a la instrucción. Semejantes preguntas se terminaron al transformar la interfaz.
Se supone que a administrador del sistema no le importa con qué tipo de interfaz trabajar. Este punto de vista no ha superado la validación de la práctica. No importa quien, un usuario, un administrador del sistema, una ama de casa. Si la interfaz es simple y fácil para entender a más usuarios les gusta. Pero era increíblemente difícil la tarea además contando con los cambios regulares. En el periodo de pruebas beta hicimos mucho esfuerzo para producir no menos de una actualización a la semana.
Evolución de la interfaz del módulo
Cada semana se añadía una funcionalidad nueva y la lógica interna se cambiaba.
El producto se desarrollaba muy rápido. El análisis realizado el cual habíamos recogido durante una semana se volvía inservible cuando salía nueva versión. De vez en cuando las novedades técnicas adelantaban a los cambios de la interfaz. Entonces teníamos que editar y reconsiderar los escenarios de los usuarios. Y eso llevaba a cambios graves de la interfaz.
La alta dinámica de desarrollo impone una restricción en el diseño de interfaces. Nos planteamos una tarea muy ambiciosa - crear una aplicación de integración de Bitrix24 con Asterisk más cómoda. Y lo logramos - ahora cualquier persona puede integrarlos fácilmente.
En vez de epílogo
Gracias a nuestro equipo de soporte durante un mes y medio de pruebas beta probamos multitud de hipótesis y realizamos decenas de escenarios. Rechazamos los tickets y el correo electrónico. Este tipo de comunicación no supone una reacción rápida y la respuesta a una pregunta simple puede durar varios días.
Nos ayudaron mucho los Canales Abiertos de Bitrix24. Así que nosotros y los clientes usamos el mismo producto. El cliente siempre puede encontrar nuestro canal abierto en la lista de sus chats y ver todo el historial de la conversación. Tenemos las tareas, la comunicación interna y la comunicación con el cliente en el mismo lugar.
Nuestros clientes reciben la respuesta a su pregunta, en un promedio de tres minutos. El cliente satisfecho comparte no sólamente problemas, sino también las ideas de como mejorar el producto.
Con el lanzamiento de la versión estable tuvimos que reducir artificialmente la dinámica en favor de la calidad: la responsabilidad delante de los usuarios comerciales no permite experimentar en versiones anteriores.
El ensamblaje, las pruebas, la instalación y el funcionamiento del módulo en Docker-contenedores fueron automatizados en GitLab CI. Las actualizaciones se envían ahora una vez a la semana y todos los experimentos fueron llevados a beta-branch. Beta-testers son bienvenidos!
Así se termina el cuento pero la historia de nuestra solución apenas está empezando.
