Cuánto tiene que durar una prueba antes de decidir si sirve
Parte de la serie sobre tiempo de respuesta a los contactos
Cuántos días necesita un piloto de automatización para decidir con datos y no con sensaciones. La respuesta no se cuenta en días, sino en repeticiones.
En marketing de suscripción hay una pregunta que se estudia con datos desde hace años: cuántos días debe durar una prueba gratuita. Y la conclusión que se repite no es la intuitiva. El punto óptimo no es «lo más largo posible»: pasado cierto umbral, más días no convierten mejor. Solo retrasan la decisión.
La pregunta se traslada casi sin cambios a otro sitio: cuánto tiene que durar un piloto de automatización antes de decidir si sigue.
Y el error es el mismo por los dos extremos. Demasiado corto y no hay datos. Demasiado largo y la decisión ya no la toma nadie.
Lo que mide una prueba no son los días
Aquí está el cambio de enfoque que ahorra tiempo: la duración útil no se cuenta en días, se cuenta en repeticiones del proceso.
Dos semanas en una empresa donde entran quince contactos al día son doscientas repeticiones: sobra para ver la mediana, el peor caso y qué pasa los fines de semana.
Dos semanas en un proceso que ocurre una vez a la semana son dos casos. No es una muestra pequeña, es que no es una muestra.
El criterio que usamos: al menos treinta repeticiones, y nunca menos de dos semanas naturales. Las dos condiciones juntas, no una de las dos. Las treinta repeticiones dan variedad; las dos semanas naturales meten dentro las noches, el sábado y el día que alguien está de baja, que es cuando los procesos fallan de verdad.
Por dónde se estropea si es corta
Tres días de prueba producen un número y una falsa sensación de certeza.
Lo que falta en tres días es precisamente lo que decide: el caso raro, el formulario a medio rellenar, el cliente que escribe a las once de la noche, el lunes a primera hora cuando se acumula todo el fin de semana.
Una prueba corta mide cómo funciona algo en condiciones normales. El problema es que los procesos no se rompen en condiciones normales.
Por dónde se estropea si es larga
Este es el fallo más caro, y casi nunca se ve venir, porque no parece un fallo: parece prudencia.
Una prueba sin fecha de cierre deja de ser una prueba. Se convierte en un estado permanente: el proyecto no ha fallado, pero tampoco cuenta. Nadie lo defiende porque todavía está en pruebas, y nadie lo mata porque tampoco ha ido mal.
Ese limbo tiene un coste doble. El obvio es el tiempo. El que no se ve es que mientras algo está «en pruebas», la organización no cambia alrededor: nadie rehace el procedimiento, nadie reasigna a nadie, nadie asume que esto es como se trabaja ahora. Y sin eso, la automatización mejor construida no produce ningún efecto.
Por eso la fecha de decisión se pone el día uno, antes de empezar, y con un nombre al lado.
Qué hay que tener escrito antes de empezar
Una página, tres apartados:
El número. Cuál es. No «que vaya mejor»: minutos de primera respuesta, horas al mes dedicadas a esa tarea, casos que se quedan sin atender.
Cuánto vale hoy. Medido antes de tocar nada. Este es el que se salta todo el mundo y es el que hace imposible defender el resultado después. Si el proceso son tiempos de respuesta, el método está en cómo medir tu tiempo de primera respuesta y no hace falta comprar nada para hacerlo.
Quién decide y con qué umbral. Una persona, y un número a partir del cual se sigue. Sin umbral escrito, cualquier resultado se interpreta según cómo haya ido la semana.
Qué más conviene tener por escrito antes de la prueba, y pedírselo a quien la monte —qué contesta y qué no, qué pasa si se equivoca, qué número se mira—, está en la checklist de qué preguntar antes de automatizar la respuesta a leads.
Qué cuenta y qué no
Dos definiciones que hay que fijar antes, porque decididas a mitad ya no valen.
Horas naturales, no laborables. Medir solo en horario de oficina hace desaparecer justo lo que estás buscando: lo que pasa cuando no hay nadie.
Mediana y peor caso, nunca la media. Un solo caso extremo mueve la media hasta dejarla sin significado. La mediana dice cómo va un día normal; el peor caso dice cómo va cuando se tuerce. Con los dos se decide; con la media se discute.
La respuesta corta
Para un proceso diario: dos semanas, con fecha de decisión escrita desde el primer día.
Para un proceso que ocurre poco: no midas ese proceso todavía. Empieza por uno que se repita, aprende cómo se comporta tu empresa con algo automatizado, y vuelve al lento con el criterio ya rodado.
Y antes de la prueba, el presupuesto: qué tiene que traer por escrito para que puedas comparar ofertas está en cuánto cuesta automatizar la atención a clientes.
Preguntas frecuentes
¿Cuánto debe durar una prueba piloto de automatización?
El tiempo necesario para que el proceso ocurra suficientes veces, no un número fijo de días. En un proceso que pasa varias veces al día, dos semanas dan datos de sobra. En uno semanal, dos semanas son dos casos y no permiten decidir nada.
La regla práctica que usamos: al menos treinta repeticiones del proceso, y como mínimo dos semanas naturales para que entren noches y fines de semana.
¿Por qué una prueba más larga no es necesariamente mejor?
Porque a partir de cierto punto ya no se está recogiendo información, se está retrasando la decisión. Y mientras la prueba sigue abierta nadie asume el resultado: el proyecto vive en un estado donde no ha fallado pero tampoco cuenta. Ese estado puede durar años.
¿Qué hay que tener escrito antes de empezar una prueba?
Tres cosas en una página: qué número tiene que moverse, cuánto vale ese número hoy, y quién decide mirándolo y con qué umbral. Sin el valor de partida no hay comparación posible; sin umbral, cualquier resultado se puede interpretar como se prefiera.
El valor de partida hay que medirlo antes de tocar nada, porque después ya no se puede reconstruir sin discutirlo.
¿Y si la prueba sale regular, ni bien ni mal?
Suele significar que se eligió un proceso que no se repite lo bastante, o que el número elegido no era el que importaba. Las dos cosas se arreglan replanteando la prueba, no alargándola: más semanas de un diseño ambiguo dan un resultado ambiguo con más decimales.
El diagnóstico gratuito es media hora mirando cómo entra hoy un contacto en tu empresa, quién lo contesta y cuánto tarda, contacto a contacto y con la hora delante. Ese número es el valor de partida de cualquier prueba posterior, y es tuyo, contratemos o no.
Lo que hacemos con él, cuando la respuesta es que sí, está en la página del sistema de respuesta a los contactos: primera respuesta con contenido en menos de 60 segundos a cualquier hora, la pregunta que falta hecha, y el aviso al comercial que le toca con el contexto preparado. Sin tarifa publicada: el alcance y el importe se cierran por escrito después del diagnóstico.