El martes en que un ayuntamiento decidió cerrar su piloto de avisos digitales para citas sanitarias, la conversación empezó con una pregunta engañosamente simple: «¿Ha funcionado?». En la pantalla había una cifra atractiva: menos ausencias que el trimestre anterior. El proveedor propuso renovar el contrato; el equipo de innovación quería extenderlo a todos los centros. Sin embargo, una administrativa señaló que algunas personas habían dejado de llamar porque el nuevo mensaje solo llegaba a un teléfono que compartían con otra persona. Un mediador añadió que varias familias nunca habían recibido la invitación al piloto. La cifra no era falsa, pero no respondía por sí sola a la pregunta importante: si el servicio había mejorado sin crear una puerta más estrecha para quienes ya encontraban obstáculos.
Un piloto no termina cuando se agota el presupuesto, cuando la demostración sale bien o cuando se publica una presentación de resultados. Termina bien cuando quienes tienen que decidir pueden explicar qué se probó, a quién afectó, qué aprendieron, qué daño apareció y por qué la siguiente decisión —ampliar, corregir, pausar o abandonar— está justificada. Ese criterio parece exigente porque obliga a renunciar a la comodidad de una métrica única. Pero es precisamente lo que distingue una prueba que produce conocimiento de una pequeña implantación disfrazada de experimento.
La primera tarea es recuperar la promesa concreta del piloto. «Digitalizar citas» es demasiado amplio para evaluarlo. En cambio, «comprobar si un aviso por mensaje, acompañado por una alternativa telefónica, reduce ausencias sin excluir a personas con acceso inestable» permite observar algo real. Una promesa concreta incluye el problema que se quería atender, la población a la que se ofreció la prueba, el periodo, la alternativa disponible y el límite de lo que no se pretendía demostrar. Sin esta reconstrucción, el cierre suele premiar cualquier resultado que parezca positivo, aunque no tenga relación con la necesidad que justificó el piloto.
Separar uso, resultado y justicia#
La actividad de una herramienta no equivale a su beneficio. Que muchas personas abran un mensaje no demuestra que comprendan una cita; que un formulario se complete rápido no demuestra que el trámite sea accesible; que el coste por interacción baje no demuestra que la atención haya mejorado. Un cierre responsable separa, como mínimo, tres planos: uso, resultado y distribución. El uso pregunta qué ocurrió en la herramienta. El resultado pregunta si cambió la situación que motivó la prueba. La distribución pregunta quién recibió el beneficio, quién soportó una nueva carga y quién quedó fuera de la observación.
La actividad de una herramienta no equivale a su beneficio. Que muchas personas abran un mensaje no demuestra que comprendan una cita; que un formulario se complete rápido no demuestra que el trámite sea accesible; que el coste por interacción baje no demuestra que la atención haya mejorado.
En el piloto de avisos, el uso podría mostrar cuántos mensajes se entregaron y cuántas personas confirmaron. El resultado requeriría comparar ausencias, cancelaciones y reprogramaciones con un periodo equivalente, atendiendo a cambios de horario, personal o demanda. La distribución exigiría mirar si la mejora alcanzó de manera similar a quien tiene un teléfono propio, a quien cambia de número, a quien necesita una lectura fácil o a quien prefiere atención en otro idioma. No hace falta convertir cada diferencia en una acusación. Hace falta evitar que una media tranquila oculte un perjuicio concentrado.
También conviene registrar los efectos que el equipo no esperaba. Tal vez las llamadas disminuyeron porque el mensaje resolvía dudas sencillas. Tal vez aumentaron porque el enlace llevaba a una página confusa. Tal vez el personal empezó a copiar datos a mano entre dos sistemas y el supuesto ahorro se trasladó a una cola invisible. Un piloto tiene permiso para descubrir sorpresas; lo que no tiene permiso es para ignorarlas porque no encajan en la historia de éxito prevista. Una hoja de incidencias sencilla, revisada cada semana con personal de atención, suele aportar más verdad que una tabla diseñada al final para defender una decisión ya tomada.
Diseñar el cierre antes del desenlace#
La decisión de cierre debería escribirse antes de conocer el resultado final. No como una condena rígida, sino como un conjunto de condiciones visibles. Por ejemplo: ampliar solo si la reducción de ausencias se mantiene durante dos ciclos, si ninguna vía alternativa pierde capacidad, si los problemas de accesibilidad tienen una respuesta verificable y si existe una persona responsable de atender errores. Corregir y repetir si hay una mejora limitada pero los fallos son reparables. Pausar si faltan datos esenciales o si la presión del calendario impide una prueba justa. Abandonar si la herramienta produce un daño que no puede compensarse sin cambiar su lógica.
Estas condiciones evitan un vicio frecuente: ajustar la definición de éxito después de ver el resultado. Si la única meta anunciada era reducir ausencias y se logra una reducción pequeña, puede ser tentador declararse satisfecho. Pero si esa reducción coincide con más citas perdidas por personas que no recibieron el aviso, el cierre debe admitir la tensión. Decidir no ampliar todavía no es un fracaso del equipo; es una forma de impedir que una evidencia incompleta se convierta en una obligación para toda la población.
Un buen criterio de cierre además nombra qué evidencia no basta. Una encuesta voluntaria con respuestas muy favorables puede ser útil, pero no representa automáticamente a quien abandonó el proceso. El entusiasmo de una demostración puede revelar que la interfaz es clara para quien ya conoce el servicio, pero no que funcione bajo presión, con conectividad irregular o con una persona que no puede resolver una incidencia por sí misma. Cuando una prueba declara sus zonas ciegas, ofrece una base más sólida para la siguiente ronda.
Dar voz a quienes hicieron funcionar el piloto#
Los datos de sistema rara vez cuentan todo lo que pasó. La recepcionista que explica el mensaje, el profesional que corrige una cita duplicada y la persona usuaria que no pudo abrir un enlace ven partes del piloto que un cuadro de mando no registra. Por eso el cierre necesita una conversación estructurada, no una ronda ceremonial de felicitaciones. Puede incluir entrevistas breves, una sesión con personal de primera línea y un canal accesible para las personas participantes. Cada observación debe quedar asociada a una pregunta práctica: ¿muestra un error puntual, una barrera repetida, una necesidad de explicación o un límite de la propia herramienta?
Escuchar no significa recoger nombres y detalles innecesarios. El equipo puede trabajar con relatos anonimizados y con patrones agregados. Si una persona cuenta que tuvo que pedir a su hijo que leyera un mensaje sanitario, lo importante para el cierre no es almacenar su identidad, sino reconocer que la autonomía quedó condicionada por el diseño del aviso. Esta distinción protege la privacidad y, a la vez, convierte una experiencia concreta en una mejora posible: redacción más clara, canal alternativo, confirmación humana o permiso para elegir el modo de contacto.
La participación también corrige una asimetría: quienes diseñan suelen poder interpretar una pantalla y pedir ayuda interna; quienes reciben el servicio no siempre. Preguntar «¿qué habría hecho si esto fallaba?» revela si hay una salida real. Una vía de ayuda que solo funciona en horario laboral, exige una cuenta adicional o pide repetir toda la información no es una alternativa suficiente. El piloto debe cerrar con una lista de obstáculos y con la respuesta adoptada para cada uno, aunque esa respuesta sea reconocer que todavía no existe una solución segura.
Conservar un rastro que permita discrepar#
Un cierre responsable produce un expediente breve y comprensible. Debe contener la hipótesis inicial, las condiciones de participación, las métricas usadas, sus límites, las incidencias, los cambios introducidos durante la prueba, las voces consultadas y la decisión final. No se trata de publicar datos sensibles ni de crear una burocracia interminable. Se trata de impedir que, seis meses después, alguien solo encuentre un titular que diga «piloto exitoso» sin saber qué significó esa palabra.
El expediente debe distinguir lo observado de lo interpretado. «Las ausencias bajaron un ocho por ciento en dos centros» es una observación condicionada por un periodo y una fuente. «El aviso digital mejora el acceso» es una interpretación que exige más apoyo. Esta separación permite que un equipo posterior cuestione una conclusión sin tener que reconstruir todo desde cero. También protege a quienes participaron: si aparece un daño, existe una forma de saber qué decisión lo produjo y quién puede revisarla.
La rendición de cuentas incluye decidir qué se borra. Un piloto puede acumular números de teléfono, registros de navegación, notas de soporte o respuestas de encuesta que ya no son necesarias para la evaluación. Cerrar significa aplicar el plazo prometido, limitar accesos y documentar qué evidencia agregada se conservará. No es coherente hablar de aprendizaje y retener indefinidamente datos personales por si acaso resultan útiles en otra idea futura.
Elegir el siguiente paso, no celebrar el último#
En el caso del ayuntamiento, el cierre más honesto quizá no sea extender de inmediato el aviso a toda la ciudad. Puede ser una segunda prueba más pequeña, con mensajes revisados, opciones de contacto elegidas por la persona y una comparación explícita con la atención telefónica. La decisión debe incluir fecha, alcance, responsable y señal de parada. Si no puede explicar quién detendrá la ampliación ante un problema, la organización todavía no está preparada para ampliar.
La pregunta final no es «¿podemos poner esto en producción?», sino «¿qué decisión podemos defender ante quien recibió el servicio y ante quien tendrá que corregirlo?». Un piloto digital ha cumplido su función cuando deja una respuesta proporcional a la evidencia: ampliar con salvaguardas, mejorar con un plan concreto, pausar para entender un riesgo o abandonar una solución que no merece crecer. Ese final no es menos ambicioso que una implantación rápida. Es más útil porque convierte una prueba limitada en una capacidad pública para aprender sin convertir a las personas en el coste oculto de la innovación.
