Un piloto empieza a alargarse cuando cada conversación añade una función y nadie sabe qué resultado permitiría darlo por terminado. Antes de ofrecer una prueba a una empresa, conviene acordar qué se va a observar y qué decisión tomaréis después. Ese acuerdo hace más útil el piloto B2B tanto para quien propone la solución como para quien dedica tiempo a probarla.
Strategyzer explica su Test Card como una forma de concretar hipótesis, prueba, medición y umbral. Tomamos ese principio de diseño de experimentos como referencia, sin reproducir su plantilla. La ficha de este artículo es una propuesta operativa propia y no sustituye las condiciones comerciales o contractuales que deban acordarse.
Una prueba necesita una pregunta pequeña
«Ver si gusta la herramienta» deja demasiado espacio para interpretar el resultado. Una pregunta más concreta podría ser si una persona responsable consigue localizar el estado de un encargo sin preguntar a otro compañero. Ya puedes describir una tarea, una persona y una observación.
Antes de empezar, comprueba cómo se resuelve hoy esa tarea. Sin conocer el punto de partida será difícil explicar qué ha cambiado. Si aparece un problema ajeno a la prueba, anótalo; no amplíes automáticamente el encargo para resolverlo también.
La ficha que debe caber en una página
Si alguna columna no cabe, desplaza la tabla lateralmente.
| Campo | Qué debe quedar claro |
|---|---|
| Pregunta | Qué incertidumbre concreta se quiere resolver |
| Alcance | Tarea, usuarios, información y funciones incluidas |
| Responsables | Quién prueba, quién atiende incidencias y quién decide |
| Observación | Qué se registrará y con qué referencia se comparará |
| Cierre | Fecha de revisión, condiciones de parada y siguiente decisión |
Añade expresamente lo que queda fuera. También debes aclarar qué ocurre con el acceso y con la información utilizada al finalizar. Una prueba temporal no debería convertirse, por falta de una conversación, en una dependencia indefinida para el negocio.
Ejemplo ficticio: consultar encargos sin interrumpir
Un equipo inventado prepara una vista de encargos para un taller ficticio. Decide probarla con un conjunto de datos de demostración y tres tareas de consulta. El objetivo de esta primera prueba es comprobar si el recorrido se entiende; todavía no mide ahorro de tiempo en producción.
Se registran las tareas que cada participante completa, las dudas que aparecen y los errores que impiden continuar. Antes de invitar a probar, el equipo define qué resultado permitiría pasar a otra fase. El umbral debe responder a esa decisión y al riesgo de la tarea, no copiar una cifra de otro proyecto.
Cerrar significa elegir qué hacer con lo aprendido
En la revisión final, separa los registros de las opiniones. Una tarea completada con ayuda continua no es la misma observación que una tarea completada sin intervención. Si no se pudo probar por falta de preparación o disponibilidad, el resultado es incompleto; no se convierte en éxito ni en fracaso de la solución.
La decisión puede ser corregir y repetir una parte, ampliar la prueba de manera acordada o detenerla. Si hay una propuesta de continuidad, detalla su alcance en un presupuesto comercial con partidas. Para conservar la forma de trabajar acordada, una instrucción de procedimiento evita depender solo de lo hablado.
Referencia metodológica de Strategyzer, publicada el 5 de marzo de 2015 y revisada el 14 de noviembre de 2026. Ficha y ejemplo inventados por Negociario; no documentan un piloto ejecutado ni resultados medidos.
