Prueba piloto de 14 días antes de cambiar de sistema en tu clínica

Una prueba piloto bien hecha dura catorce días, se corre en un solo sillón y con pacientes nuevos, y se aprueba o se rechaza con números, no con opiniones. Los criterios que deciden son cuatro: minutos para agendar una cita, minutos del corte de caja, porcentaje de citas confirmadas y cantidad de dudas del equipo en la segunda semana. Si esos cuatro mejoran o al menos empatan, el cambio va; si empeoran, no importa qué tan bonito se vea el sistema.

La regla que sostiene todo el ejercicio: durante el piloto no se migra el histórico. Se prueba la operación del día a día, que es donde se gana o se pierde.

Por qué en un solo sillón y con pacientes nuevos

Porque el riesgo se acota. Si algo sale mal en el sillón piloto, la clínica sigue funcionando en los demás con el sistema de siempre. Y los pacientes nuevos no tienen historial que consultar, así que no necesitas haber migrado nada para atenderlos completo: se crean, se agendan, se atienden, se cobran y se facturan dentro del sistema nuevo, de principio a fin.

Ese recorrido completo es justo lo que una demostración comercial no te muestra. En la demo todo está precargado y todo sale bien. En una prueba piloto real aparecen las fricciones: el campo que no acepta un RFC de persona moral, el flujo que pide dos clics de más cada vez, la pantalla que la asistente no encuentra.

El calendario de 14 días

Días 1 y 2 · Configuración. Dar de alta la clínica, los consultorios y los horarios. Crear los usuarios reales del equipo, cada uno con su rol. Cargar la lista de tratamientos con precios y duraciones. No cargar pacientes.

Días 3 a 5 · Solo agenda. Todo paciente nuevo se agenda en el sistema nuevo. Los de siempre siguen igual. Al terminar el día 5, cronometra: cuánto tarda recepción en agendar una cita de principio a fin.

Días 6 a 8 · Expediente y consulta. Los pacientes nuevos del sillón piloto se atienden registrando la nota, el odontograma y el presupuesto en el sistema. Aquí es donde el doctor decide si le estorba o le ayuda.

Días 9 y 10 · Dinero. Cobros del sillón piloto dentro del sistema, con corte al final del turno y facturación de los que pidan comprobante. Es el módulo que más problemas revela.

Días 11 a 13 · Sin muletas. Nadie del equipo puede preguntarle al doctor cómo se hace algo: se busca en el centro de ayuda o se le pregunta al proveedor. Así mides el soporte y la curva de aprendizaje real.

Día 14 · Decisión. Reunión de treinta minutos con los cuatro números en la mesa y una pregunta a cada persona del equipo: qué te costó más trabajo.

Quién debe participar y con qué encargo

Una prueba piloto se hunde cuando participa todo el mundo o cuando participa una sola persona. El equipo correcto son tres roles con un encargo claro cada uno.

El coordinador. Normalmente el dueño o quien administra. Su trabajo no es usar el sistema, es anotar: qué se atoró, en qué paso, cuánto tardó. Diez minutos al final de cada día.

Quien agenda. La persona de recepción que más citas hace. Es la que va a detectar las fricciones que se repiten 150 veces al mes, que son las que de verdad importan.

Quien atiende en el sillón piloto. Un doctor, idealmente el que menos paciencia tiene con la tecnología. Si a esa persona el sistema le funciona, al resto le va a funcionar. Si eliges al más entusiasta, el resultado va a salir optimista y no se va a sostener después.

Deja fuera, a propósito, a quien no va a usar el sistema todos los días. Su opinión, aunque venga con buena intención, mete ruido en una decisión que debe tomarse con la operación real.

Los criterios de aprobación, con números

Escribe estos umbrales antes de empezar, no después. Un criterio que se define al final siempre se acomoda a lo que ya pasó.

Qué NO hacer durante la prueba piloto

No migrar el histórico. Es la decisión más importante. Mover años de expedientes para una prueba piloto significa pagar el costo alto de la migración antes de saber si el sistema te sirve. El histórico se migra cuando ya decidiste.

No poner a todo el equipo a la vez. Dos o tres personas bastan. Con ocho, nadie aprende y todos se estorban.

No probar en la semana más pesada del mes. Ni en quincena, ni en diciembre, ni el día que llega el especialista con seis casos.

No dejarlo sin dueño. Una persona coordina el ejercicio y anota lo que pasa. Si es tarea de todos, no es de nadie y al día 14 no hay datos.

Cómo se corre esto en DaleControl

El piloto en DaleControl es directo porque no requiere instalación en cada equipo: se crea la cuenta, se configuran consultorios y horarios en la agenda por sillón y por doctor y ya se puede agendar el mismo día. Los recordatorios por WhatsApp usan la API oficial, con un matiz que conviene saber desde el piloto: las plantillas las cobra Meta a la tarjeta de cada clínica, así que si quieres probar los recordatorios hay que dejar ese paso configurado antes del día 3.

Para la parte de dinero, la caja con cortes por turno permite cerrar solo el turno del sillón piloto sin mezclar los cobros del resto de la clínica, que es lo que hace posible comparar peras con peras. Y la importación de pacientes queda disponible para cuando ya hayas decidido, no antes. Los planes están publicados en la página de precios, así que puedes calcular el costo del cambio con números reales desde el primer día.

Después del día 14

Si la prueba piloto pasó, migra en este orden: primero pacientes activos de los últimos dos años, luego citas futuras, luego saldos pendientes. Lo demás puede esperar semanas sin que nadie lo note. Deja el sistema anterior en modo consulta durante un mes, sin capturar nada nuevo ahí, y fija una fecha de apagado para que nadie se quede a medio camino entre los dos.

Si no pasó, tienes algo valioso: sabes exactamente qué falló y en qué paso. Esa lista es la mejor guía para evaluar la siguiente opción, y te costó dos semanas en un solo sillón en lugar de un año en toda la clínica. Cuando quieras arrancar tu propio piloto, abre una cuenta y empieza por los días 1 y 2.