Qué puede demostrar un periodo de prueba — y qué no

Un periodo de prueba mide con fiabilidad una sola cosa: cómo se siente el principio. El alta, la primera impresión, los primeros movimientos. No es poco, porque un principio que se hace cuesta arriba rara vez mejora. Pero tampoco es aquello de lo que depende tu decisión.

Lo que sostiene tu decisión es el comportamiento en el día a día: bajo presión de tiempo, con datos que han crecido, en el caso excepcional. Justo eso se le escapa por estructura a un periodo de prueba estándar; no por falta de honradez del proveedor, sino porque dos semanas con la base de datos vacía son un sistema distinto de dos años con la base llena. Quien lo sabe puede montar la prueba de manera que aun así demuestre algo.

Empecemos por lo que sí funciona, porque es más de lo que parece. Un periodo de prueba responde con solidez a cuatro preguntas, y las cuatro merecen respuesta.

¿Cuánto dura el principio? Desde el alta hasta el primer trámite real. Si a los noventa minutos todavía no has conseguido crear una cita, eso es un hallazgo y no una dificultad de arranque.

¿Te aclaras sin instrucciones? Haz clic a propósito sin abrir la ayuda. Donde te atasques ahora te atascarás también en el día a día, solo que entonces con público delante.

¿Cuánto tarda el soporte en contestar? Haz durante la prueba una pregunta real, no una pregunta de prueba. El tiempo de respuesta durante el periodo de prueba suele ser el mejor que vas a ver nunca; es tu techo, no tu media.

¿Qué tal sienta lo que haces más veces? No la función especial que se usa poco, sino el gesto que repites veinte veces al día. Dos segundos de diferencia por trámite, con veinte trámites diarios, son unos cuarenta segundos: en una jornada no se nota, pero a lo largo de un año de unos 250 días laborables se acercan a las tres horas.

Casi cualquier negocio de servicios tiene semanas que no se parecen en nada entre sí. Un salón en enero y el mismo salón la semana antes de Navidad son dos negocios. Un taller en verano y el mismo taller con la primera helada, también. Un colegio en la segunda semana de noviembre y el mismo colegio en el cambio de evaluación, todavía más.

Si pruebas un software en la semana tranquila, lo pruebas en condiciones en las que funciona casi cualquier sistema. La prueba te confirma entonces algo que nunca estuvo en discusión y calla sobre lo que después te va a costar dinero.

Contra esto ayuda menos esfuerzo del que uno supone:

• Sitúa la prueba a propósito en una semana cargada, no en vacaciones. Mejor fracasar en condiciones reales que aprobar en condiciones ideales.
• O pide una ampliación. La mayoría de proveedores amplían el periodo de prueba si lo pides y explicas el motivo. Ese correo cuesta dos minutos.
• O reconstruye el pico. Coge un sábado real del año pasado y mételo en una hora en el sistema de prueba. Después sabes cómo se ve un día lleno sin haber tenido que esperar a que llegue.

El último punto tiene un efecto secundario que conviene aprovechar: al hacerlo compruebas cuánto tarda la propia introducción de datos. No es mal ejercicio, porque ese trabajo exacto lo vas a repetir cuando hagas el cambio de verdad.

Un sistema vacío es rápido, claro y ordenado. No tiene duplicados, ni clientela antigua sin número de teléfono, ni un servicio que dejó de ofrecerse hace dos años y sigue en la lista. Pero de eso está hecho precisamente el día a día.

Por eso la medida más eficaz en cualquier periodo de prueba es meter datos reales, al menos una parte. Doscientos registros de clientes y tres meses de historial de citas bastan para responder a las preguntas que con cinco registros de prueba quedan invisibles: ¿qué aspecto tiene la búsqueda cuando cuatro personas se apellidan parecido? ¿Qué pasa con un registro sin dirección de correo cuando el sistema quiere enviar una confirmación? ¿Se pueden fusionar dos duplicados sin perder el historial?

Aquí hay dos cosas importantes. La primera: un sistema de prueba también es un sistema en el que hay datos personales reales. El tratamiento necesita la misma base que en producción, y si el proveedor trata datos por cuenta tuya hace falta un contrato de encargo del tratamiento; en el marco europeo del RGPD es el artículo 28, y rige desde el primer registro de prueba, no a partir de la primera factura.

La segunda: exige ya durante la prueba que los datos de prueba se puedan borrar. Si decides no seguir con ese proveedor, querrás esos doscientos registros fuera del mundo. Un sistema que no sabe hacerlo por sí solo te ha dado la respuesta a una pregunta mucho mayor.

El motivo más frecuente de que un periodo de prueba pase sin resultado no es la falta de tiempo. Es que nadie ha fijado antes qué se iba a probar. Se dan vueltas, todo parece bastante correcto y el día catorce la pregunta sigue exactamente igual de abierta.

Un plan aprovechable cabe en media página y consiste en tres trámites reales que recorres de principio a fin: no catados, sino terminados. Para la mayoría de los negocios son estos:

1. El trámite estándar completo. De la consulta a la cita y de ahí al justificante cobrado, tal y como ocurre de verdad en tu negocio.
2. El caso excepcional. Anulación de última hora, cambio de fecha, devolución, pago parcial, corrección posterior de una factura. Los casos excepcionales son una parte pequeña de los trámites y la mayor parte de los disgustos.
3. La mirada atrás. ¿Qué pasó el mes pasado? ¿Quién no aparece desde hace un año? Si no encuentras un informe en dos minutos, no lo vas a mirar nunca.

A eso se suma un ejercicio obligatorio que no llega a diez minutos y que casi nadie hace: lanza una vez una exportación completa de datos y abre el archivo. No porque lo necesites, sino para ver qué contiene. Es el único momento en que esa comprobación no cuesta nada, y el único hallazgo del periodo de prueba que después decide sobre el camino de vuelta.

Los criterios de abandono parecen exagerados mientras no hacen falta. Pero protegen del efecto más fuerte de cualquier periodo de prueba: después de diez horas invertidas nadie quiere oír que el software no encaja. A esas alturas ya no se está probando un software, se está defendiendo una decisión.

Escribe por eso, antes del primer acceso, dos o tres frases que marquen el final. Deberían ser tan concretas que alguien de fuera pudiera comprobarlas. Por ejemplo: «Si no consigo crear una cita estándar en menos de treinta segundos». O: «Si la exportación no incluye el historial de citas». O: «Si a los dos días laborables no hay respuesta a mi consulta de soporte».

Frases así abaratan el abandono, y ese es todo su cometido. Además te ahorran la variante más incómoda: el contrato que nace porque el periodo de prueba ha vencido y nadie ha dicho nada. Comprueba por eso el primer día si tu acceso de prueba pasa automáticamente a una suscripción de pago y dónde se desactiva exactamente. Esa información va al principio del periodo de prueba, no al final.

Y si lo dejas: dile brevemente al proveedor dónde estuvo el problema. No es un favor que haces; es la única respuesta con la que un producto aprende de verdad.