sobre el proyecto
El producto del cliente es SaaS en el ámbito B2B, que opera con un formato de tarifa de suscripción. El usuario se registra, pasa la autorización, repone su cuenta y utiliza el servicio.
Nuestra tarea es ayudar al cliente a "recopilar" análisis. Para hacer esto, era necesario construir procesos de centro de llamadas, implementar CRM y "reunir" análisis de extremo a extremo por indicadores clave.
Estructura de proceso
Antes de realizar análisis, debe preparar un panorama para recopilarlos: estructurar los procesos de ventas y configurar integraciones con los servicios. Encontramos varios problemas en los procesos:
- Los gerentes se distrajeron con etapas innecesarias del embudo de ventas y su trabajo no fue monitoreado de ninguna manera;
- Los informes de ventas se descargaron manualmente desde el panel de administración todos los días;
- Hubo pocos eventos de conversión para recopilar análisis.
A continuación, hicimos un mapa con la estructura de la interacción de todos los sistemas.
Muestra qué lógica deben seguir los eventos y en qué etapas se encuentra el analista. Tomamos los datos principales de CRM y los correlacionamos con datos sobre publicidad y conversiones. Poniéndolo junto en myBI, renderizándolo en Power BI.
Embudos de ventas
Las ventas a clientes se realizaron en Enybox CRM, las transferimos a amoCRM para facilitar la integración. Logramos recopilar la lógica de ventas en tres embudos.
Tres embudos sucesivos
El primer embudo es la consulta. Necesitaba traer al cliente para registrarse en la plataforma. El segundo embudo está arreglando los primeros pagos. Entonces el usuario confirmó su registro. Y nosotros, a su vez, celebramos el momento del pago y cada nueva reposición.
Cómo se suponía que funcionaba la analítica
| "Eventos" iniciales | "Eventos" finales |
|---|---|
| Formulario de comentarios | Formulario de comentarios |
| Alta en el servicio | Alta en el servicio |
| Primer deposito | |
| Prueba (opcional con una pequeña reposición) | |
| Recargas repetidas | |
| Negativa a usar (calentamiento a través del OP) |
Para que el sistema de análisis funcione normalmente, debe recopilar todos los eventos = marcar las acciones de conversión. Los eventos ya ingresaron al sistema de análisis, pero inicialmente solo había dos tipos de ellos, lo que no es suficiente para los informes.
Visualización de datos
Ejemplo de un cuadro de mando
Después de recopilar datos sobre conversiones, era necesario realizar un informe a partir de ellas. La principal herramienta de visualización de datos es Microsoft Power BI.
En el momento de la conversión, se generó una ID separada en el sitio para sincronizar los sistemas de publicidad y CRM. Mediante esta identificación, vinculamos los datos de gastos e ingresos. Así que correlacionamos los datos y pudimos crear informes sobre ellos.
Economía unitaria. Retencion
El gráfico continuo de retención del servicio de 1 a 12 meses de
retención muestra la cantidad de usuarios que participan en la aplicación y la frecuencia con la que regresan. Pero debido al hecho de que el servicio funciona en forma de reabastecimiento, tuve que cambiar este indicador a retención continua. Muestra lo mismo que retención, pero implica que todo el tiempo que el usuario no reponía la cuenta, también usaba el servicio.
Conversión al primer depósito
La conversión dependió en gran medida de la cantidad de nuevos clientes y del inicio de sus pagos. Durante los primeros 9 meses, recibimos alrededor de 430 nuevos registros y 90 pagos de nuevos usuarios cada mes. La conversión a compra en el mes de registro fue del 20%, según datos de 12 meses.
Además de los indicadores estándar
Fue posible ver análisis sobre el toque del cliente tanto en el momento de una simple transición al sitio como en el momento del registro y los pagos posteriores. Acumulamos datos para encontrar la mayor cantidad de cadenas de conversión: el
usuario vio el anuncio → fue al sitio → después de un tiempo entró y miró en el contexto → se registró, pero no pagó → calentó con una carta → ofreció una prueba de manejo → probó → el OP “dio el primer pago” → 3 años pagos estables.
Algo salió mal
Al principio, los iniciadores del proyecto pospusieron el inicio hasta el otoño (aplicaron en la primavera). Tales "lagunas" en el trabajo se produjeron más de una vez. Pero no lo pensamos y lo dimos por sentado. Los principales problemas fueron la comunicación y la burocracia en los procesos de nuestro cliente. Así es como puede representar todo el período de tiempo de trabajo en un proyecto:
Desarrollo lento
Las brechas en el desarrollo se debieron a la estructura del trabajo del cliente. Trabajamos en conjunto con el equipo del cliente y algunas de las tareas solo se podían realizar por su parte debido a la alta seguridad de los procesos.
Perdí dos sprints, perdí un mes
Todos los gerentes y desarrolladores de su lado trabajaron en iteraciones de dos semanas. Pero constantemente priorizan nuestro proyecto en último lugar y, a menudo, nuestras tareas no caen en el "sprint".
Mala comunicación y falta de experiencia
Durante el proyecto, el gerente del cliente (parte interesada) ha cambiado cinco veces. Probablemente todo el mundo sepa esa sensación cuando el proyecto en el que estás trabajando de repente deja de ser interesante para el cliente. Pero incluso eso se puede resolver.
Fue más difícil lidiar con la incompetencia de las partes interesadas. Uno de ellos era un gran ejecutivo que conocía bien su producto. Pero ni siquiera entendía los principios básicos de la construcción de procesos de ventas. Pasamos varias reuniones para persuadirlo de que quitara el escenario con el estado "¿Cómo estás?" Del embudo de ventas.
Imagina un embudo de ventas como el de la imagen de arriba. En una etapa, los gerentes deben averiguar "cómo le va al cliente". ¿Qué crees que pasará con la analítica de conversión de dicho embudo?
Los gerentes averiguarán "cómo estás" del cliente en lugar de moverlo a través del embudo, el estado no es trivial. No es obvio cuándo ponerlo: después del primer contacto o después de la calificación. Como resultado, las ofertas "saltan" de un lado a otro a lo largo del embudo o simplemente se paran, en lugar del movimiento secuencial.
Durante el proceso de venta, es imposible establecer etapas intermedias en las que se acumularán las ofertas. De lo contrario, todos los análisis se convertirán en un desastre y los gerentes perderán muchos contactos.
Fakapas de nuestro lado
No tomamos en cuenta el ancho de banda del sistema. Para un evento de plataforma en el pico, enviamos hasta 10 solicitudes a amoCRM para ejecutar la lógica de los procesos comerciales.
100.000 eventos por día * 10 solicitudes a amoCRM = 1.000.000 de solicitudes por día
1.000.000 de solicitudes por día / 10 solicitudes por segundo (límite de AMO) = 100.000 segundos = ± 27 horas
Resultado: la sincronización nunca terminará
AmoCRM seleccionado inicialmente, como "pasar" el límite de solicitudes al sistema. Pero en el transcurso del desarrollo del proyecto, los requisitos y funciones se han incrementado y "topamos" con el límite.
Hemos elegido la herramienta incorrecta. AmoCRM no es apto físicamente para manejar una gran cantidad de solicitudes.Además, el error fue que desarrollamos todo en GO, y un especialista fue responsable de esto. Cuando se fue, había una montaña de códigos heredados que nadie pudo descifrar. Pero, lamentablemente, o afortunadamente, esto no fue necesario.
Todo esta roto de nuevo
Este caso es otro ejemplo de un proyecto que ha sido enterrado en aprobaciones y un montón de gestión innecesaria.
Carecíamos de experiencia técnica. Para el cliente: estabilidad en la gestión y deseo de completar el proyecto.
Pero esta es la experiencia. Gracias a él, ahora esas tareas parecen tan triviales como sea posible y ya hemos reproducido una solución similar en otro proyecto.
¿Cómo se podría evitar el fracaso?
Para no repetir este tipo de casos en el futuro, hemos destacado los aspectos que se deben tener en cuenta al trabajar con clientes empresariales.
- : ; . , .
- . — . — . . .
- . KPI — .
- Pensar en el futuro. Incluso al desarrollar un MVP, debe tener en cuenta los cuellos de botella que pueden surgir en el futuro. El proyecto está siempre en expansión y es importante proporcionar una estructura para no reescribir todo el código desde cero.
El autor del artículo es Fedor Anisimov, comercializador de LAND PRO.