Pero en la práctica, aguardaban dificultades. Hablemos de lo que puede suceder si modifica un poco el diseño o pierde el relleno en su plantilla. Y cómo arreglarlo todo.
Quería beneficiar a los nuevos usuarios, pero naturalmente no se comportaron como se esperaba.
La principal herramienta de ventas de Skyeng es un video tutorial introductorio gratuito con un facilitador. Realizamos lecciones en nuestra plataforma, y sucede que un alumno intenta conectarse a una llamada, pero su micrófono o cámara no se captura.
Esto puede suceder por docenas de razones, desde un misklik banal en una notificación en el navegador (como en esta imagen) hasta casos completamente exóticos: por ejemplo, una vez que una persona intentó trabajar desde Tesla y allí su propio software que no admitimos.
Si no puede solucionar el problema rápidamente, se produce un desglose técnico de la lección introductoria:
- el alumno sigue siendo negativo,
- la lección del profesor se interrumpe,
- la escuela pierde la conversión a pago aquí y ahora (esta es la métrica principal de nuestro departamento), compensa la participación del profesor en la lección e inicia el proceso de transferencia de la lección.
Todo el mundo sufre. Por lo tanto, el año pasado comenzamos una serie de proyectos para reducir las interrupciones técnicas. Se probó cada idea: la empresa quería saber si la función estaba funcionando y si se recuperarían los costos de soporte.
Una de las soluciones que se tuvo que poner en la prueba fue la búsqueda de verificación de equipos. Originalmente era un widget, aquí están sus pantallas principales.
La idea es simple: no espere el momento para ingresar a la lección, pero invite al estudiante a verificar la cámara y el micrófono con anticipación, cuando dejó una solicitud de capacitación. Si algo sale mal, emitiremos un ticket al soporte técnico y los chicos tendrán varias horas para resolver el problema.
Cuando dividí a los usuarios en prueba y control, esperaba que las personas del grupo de prueba hicieran clic en el widget y completaran la misión. ¿Qué puede salir mal?
En el grupo de control ("A") todo siguió como de costumbre: las personas dejaron una aplicación y se dedicaron a sus asuntos. Pero después de la prueba, vimos que el porcentaje de fallas técnicas en los grupos "A" y "B" era similar a una centésima de porcentaje. Mmm, todos en el grupo de prueba pasaron por la misión, pero no ayudó, ¿o nadie entró? No lo sabíamos, no hubo registro.
Las dos etapas se fusionaron en una y resultó que no podemos separarlas. Tuve que reiniciar la prueba y registrar la etapa clave "ingresé a la búsqueda". Descubrimos que aproximadamente el 10% de los usuarios iniciaron sesión. No hubo un crecimiento significativo en la métrica: la búsqueda se ha hundido en el olvido, la verificación del equipo finalmente se incorporó a la incorporación durante un rediseño global. Y ahora verifico al principio si tengo datos sobre todas las etapas clave del embudo.
« - ?». ,
Además de los problemas técnicos, a veces el estudiante simplemente no aparece en esa lección introductoria tan gratuita, porque se quedó dormido, se volvió loco, se transfirió algo, etc.
Por lo tanto, antes de cada lección, el metodólogo necesita encontrar un alumno que esté listo para llamar: para esto, el sistema le da varios contactos y el profesor los llama. Esto "consume" entre el 12 y el 15% del tiempo que una persona puede dedicar a algo más útil o agradable.
Parece una buena oportunidad para la automatización: deje que el robot llame. Pero necesitamos una prueba A / B: después de todo, algunas personas, habiendo escuchado al robot, pueden colgar. La posibilidad de perder algo es obvia. Hicimos la prueba y al principio todo salió sorprendentemente bien, pero ... Nos decepcionó el perfeccionismo.
En una serie de escenarios, el robot tuvo que transferir llamadas a un operador humano: por ejemplo, si un estudiante quería cancelar una lección, el operador tenía que realizar cambios en el CRM. Y a veces, el robot simplemente se cruzó con interlocutores que hablaban: el sistema no fue diseñado para un reconocimiento de voz serio y soporte de diálogo, aquí también era necesario conectar a una persona.
Queríamos que la experiencia del usuario fuera lo más fluida posible.
Por lo tanto, decidimos cambiar esas llamadas inmediatamente a la línea telefónica entrante. Incluso si la pregunta no era urgente. Los metodólogos en los mismos casos dijeron: "Se le volverá a llamar en 3-5 minutos para reasignar la lección". Y los operadores tuvieron tiempo para distribuir la carga de trabajo y ayudar a todos.
Los operadores no pudieron estar de acuerdo con el robot y creó picos con varias llamadas urgentes por minuto. El circuito resultó ser no escalable.
En los momentos álgidos, la situación parecía un juego clásico) Gracias a Wikipedia y su colaborador perepelin30 por la foto .
Regresamos al esquema utilizado por los metodistas: si una persona expresaba claramente una solicitud de transferencia, el robot respondía "Te devolveremos la llamada". Solo los problemas potencialmente urgentes se transfirieron inmediatamente a los operadores. Después de estos cambios, la prueba tuvo que ejecutarse nuevamente, ya que el cambio podría afectar las métricas clave. Y ahora, antes de cada experimento, hacemos la pregunta: "Ok, si todo va bien, ¿podemos implementarlo?"
Lancé la prueba, verifiqué que todo iba bien, fui a rastrillar un montón de tareas actuales
Skyeng tiene una audiencia muy interesante y en crecimiento: estos son niños que enseñan matemáticas e inglés con nosotros. Pero no podemos realizar una lección introductoria para un niño si su padre no está presente. No podemos legalmente. Por lo tanto, si el niño se conecta solo, la lección se interrumpe. Entonces ya sabes: negativo, regrabación, etc.
Los padres siempre fueron advertidos sobre esto de forma oral, cuando llamaban, en el que se acordaba el momento de la lección. Pero el tiempo pasó de la llamada a la lección y, por supuesto, no todos recordaron este acuerdo.
Entonces llegó la solución: enviemos un recordatorio por SMS. Aproximadamente dicho texto se dejó a los padres más cerca del momento de la lección introductoria.
Un aumento en el número de lecciones introductorias sin interrupciones no significa un aumento en la conversión a pago. Necesita estimar el ROI. Para hacer esto, realicemos un experimento:
- Dividiremos aleatoriamente todas las solicitudes de referencia de los niños en dos grupos,
- no enviaremos nada a los padres del primer grupo; tienen un flujo regular,
- Los padres de otro grupo recibirán dos recordatorios por SMS: 24 y 1-2 horas antes del comienzo de la lección.
Comenzamos la prueba, hicimos la verificación el primer día y fuimos a limpiar el volumen de negocios.
Un par de semanas después, miro en el tablero y allí, además de los grupos de prueba y control, hay otros usuarios.
Si quisiéramos dividir 50 entre 50, entonces el gráfico rojo indica claramente que algo salió mal.
Resultó que la culpa era de un error banal: algo andaba mal con los eventos, no todo el mundo estaba enviando SMS con disparadores. El error se solucionó, pero la prueba tuvo que reiniciarse: al final, incluso si tiene el diseño de prueba correcto, con todas las plantillas llenas, etc., esto no significa que la prueba se ejecutará sin problemas. Y debería investigarlo con la mayor frecuencia posible.
PD : Realmente espero que este texto ayude a alguien a cometer menos errores en sus pruebas. Lo más probable es que tengas o ya tengas tus propios casos divertidos: ¡será genial si los compartes también algún día!
pps La publicación se basa en un informe de la comunidad de TI de Rostov RnDTech - Si vives en algún lugar del sur del país, únete, los chicos están haciendo un gran movimiento.