Programar el contacto sin perder trazabilidad
Programar contacto en salud exige motivo, ventana, canal, consentimiento, responsable y cierre; si falta una pieza, la agenda pierde gobierno.
Contenido operativo para equipos administrativos de salud. No es consejo médico. Los agentes de Arbol no diagnostican, no prescriben ni orientan clínicamente — escalan a tu equipo. Revisado:
Programar contacto sin perder trazabilidad significa que cada llamada, mensaje o tarea queda conectada a una finalidad, una ventana, un responsable, un canal autorizado y un estado de cierre. Si el contacto se agenda como recordatorio suelto, la institución puede hablar mucho con la persona y aun así no saber por qué la buscó, qué respondió ni quién debe actuar después.
La trazabilidad se pierde antes del primer intento
Muchas instituciones creen que pierden trazabilidad cuando alguien olvida registrar una llamada. A veces ocurre ahí, pero la pérdida suele empezar antes: cuando se crea una tarea sin motivo, cuando la lista no trae fuente, cuando el canal no tiene regla, cuando la ventana no tiene vencimiento o cuando el estado de cierre no está definido. El intento final solo revela un diseño incompleto.
Programar contacto es más que poner una alarma. En salud, el contacto tiene contexto: una ruta de atención, una cita, una autorización, una señal de laboratorio, una cohorte preventiva, una barrera administrativa o una solicitud de la persona. Si ese contexto no viaja con la tarea, el equipo queda obligado a interpretar. Y cuando cada persona interpreta, la institución pierde consistencia.
La Resolución 2275 de 2023 muestra una dirección clara para el sistema: datos asistenciales, administrativos y financieros más estructurados alrededor de RIPS y FEV en salud. Pero la trazabilidad del contacto no aparece automáticamente por tener datos de prestación. RIPS puede confirmar que algo ocurrió; no necesariamente explica quién intentó evitar que se perdiera una cita, qué canal funcionó o qué barrera expresó la persona.
Por eso la programación de contacto necesita su propio modelo. Debe registrar intención antes de ejecución. Debe saber si la tarea busca confirmar, recuperar, orientar, actualizar, escalar o cerrar. Debe vincularse con la ruta o indicador que la justifica. Debe terminar con una respuesta utilizable. Sin esa estructura, el contacto queda como actividad, no como gestión.
Cada contacto programado necesita seis campos vivos
El primer campo es motivo. No basta “llamar”. El motivo debe nombrar la finalidad: confirmar cita, recuperar inasistencia, agendar primera consulta, actualizar dato, resolver barrera, entregar orientación institucional, escalar ausencia de cupo. El motivo protege al equipo porque evita improvisación. También protege a la persona porque explica por qué la institución aparece.
El segundo campo es fuente. ¿De dónde salió el caso? Agenda, historia clínica, RIPS, laboratorio, cohorte manual, solicitud de la persona, remisión, autorización, alerta de ruta. La fuente permite auditar. Si el contacto fue equivocado, la institución sabe qué señal ajustar. Si el contacto fue útil, sabe qué fuente replicar. Una tarea sin fuente no aprende.
El tercer campo es ventana. El contacto debe tener una fecha límite que venga del propósito. En la ruta materno-perinatal, la Resolución 3280 vuelve crítica la captación antes de la semana 10; en otras rutas, la ventana puede venir de control, resultado, autorización o agenda. Sin ventana, todo se programa “cuando se pueda”, que en operación suele significar tarde.
El cuarto campo es canal autorizado. La Ley 1581 obliga a que el tratamiento de datos personales tenga reglas de finalidad, libertad y acceso restringido. Traducido a programación, no todo canal sirve para todo motivo. Un recordatorio administrativo no expone la misma información que una conversación sobre una ruta sensible. El campo de canal debe decir qué se puede enviar, qué no y cuándo debe cambiar a contacto humano.
El quinto campo es responsable. Una tarea puede ejecutarse por una persona, un agente o una cola mixta, pero siempre debe tener dueño institucional. Si nadie responde por el caso, la automatización solo acelera el desorden. El responsable no es quien hizo el intento; es quien debe asegurar que el caso llegue a cierre o escalamiento.
El sexto campo es estado de cierre. Confirmada, reprogramada, no localizada, dato inválido, rechazó contacto, requiere humano, requiere revisión clínica, cerrada por atención realizada, cerrada por traslado, abierta por falta de cupo. Estos estados deben ser finitos y auditables. Si la nota final es texto libre sin clasificación, la institución podrá leer anécdotas, pero no gobernar.
La programación no debe borrar la finalidad clínica
Cuando una institución programa campañas de contacto, corre el riesgo de agrupar motivos distintos bajo una misma tarea. “Confirmaciones”, “pendientes”, “seguimiento” o “llamadas” pueden mezclar rutas preventivas, solicitudes administrativas, controles crónicos, primera consulta prenatal, recuperación de inasistencias y educación. Ese agrupamiento facilita ejecutar, pero dificulta gobernar.
La finalidad clínica o asistencial no debe perderse en la herramienta de agenda. Si una tarea busca captación prenatal, su lenguaje, ventana y escalamiento son distintos a una confirmación de cita general. Si busca recuperar un resultado crítico, no puede tener la misma insistencia ni el mismo cierre que una actualización de datos. Si busca continuidad de una ruta preventiva, no puede presentarse como campaña genérica.
El artículo sobre contacto con propósito clínico lo resume bien: contactar más no es mejor si la institución no puede explicar por qué. Programar contacto con trazabilidad convierte esa idea en campos y reglas. Cada tarea debe responder: qué derecho o proceso protege, qué dato usa, qué acción ofrece, qué límites tiene y qué evidencia deja.
Esta disciplina también evita que la institución confunda automatización con delegación total. Un agente puede ejecutar horarios, intentos, guiones y registro. No decide por sí mismo la finalidad de una ruta, no redefine consentimiento, no inventa estados de cierre y no promete atención fuera de la capacidad real. La trazabilidad no es un subproducto de la automatización; es una decisión de diseño.
Los reintentos son parte de la política, no un detalle técnico
Una programación seria define reintentos antes de activar la tarea. ¿Cuántas veces se intenta? ¿En qué horarios? ¿Se alterna canal? ¿Cuándo se deja de insistir? ¿Qué ocurre si la persona responde tarde? ¿Qué pasa si pide no ser contactada por ese canal? ¿Qué casos se escalan después del primer intento fallido? Sin esas reglas, cada operador termina creando su propio estándar.
El exceso de reintentos desgasta confianza. La ausencia de reintentos abandona casos importantes. La regla correcta depende de finalidad y sensibilidad. Confirmar una cita de baja complejidad no exige la misma insistencia que recuperar una primera atención prioritaria. Actualizar datos no exige el mismo tono que orientar una ruta. En todos los casos, la persona debe entender el motivo y tener una salida clara.
La Ley 1438 vuelve relevante este punto porque una mala política interna puede restringir acceso u oportunidad en la práctica. Si una institución decide cerrar automáticamente después de un intento en horario laboral, quizá está dejando por fuera a personas que solo pueden responder en otro momento. Si decide insistir sin límite, puede vulnerar confianza y privacidad. La gobernanza está en el equilibrio.
Los reintentos también deben medirse como proceso, no como culpa. Si cierto horario falla, el tablero debe mostrarlo. Si cierto canal genera datos inválidos, debe corregirse. Si muchas personas piden llamada humana, el guion o la ruta necesitan revisión. La trazabilidad convierte esos patrones en mejora; sin trazabilidad, el equipo solo siente cansancio.
Una buena cola de contacto se parece a una lista de decisiones
La cola ideal no dice únicamente “pendientes”. Dice qué decisión necesita cada caso. Hay casos listos para contacto automático porque tienen motivo, canal, ventana y guion. Hay casos que requieren validación de datos antes de contacto. Hay casos que deben ir al equipo humano porque la señal es sensible o contradictoria. Hay casos que no deberían contactarse hasta confirmar finalidad o permiso.
Esa clasificación evita dos errores opuestos. El primero es automatizar todo por eficiencia. El segundo es mandar todo al equipo humano por miedo. Entre ambos hay una operación híbrida: tareas simples y bien delimitadas se ejecutan de forma sistemática; excepciones se escalan con contexto; casos incompletos se limpian antes de tocar a la persona. Ese es el punto donde la tecnología ayuda sin borrar criterio.
En Colombia, este enfoque se alinea con gobernanza y con el trabajo de Arbol en Colombia: no se trata de agregar canales, sino de ordenar la relación entre institución y persona. La programación de contacto debe respetar finalidad, oportunidad y evidencia. Si no deja evidencia, no gobierna. Si no respeta finalidad, no cuida. Si no respeta oportunidad, llega tarde.
- 1Crea la tarea desde una señal
No programes desde una lista muda; registra fuente, fecha, motivo y ruta asociada.
- 2Asigna ventana y canal
Define cuándo vence el contacto y por qué canal puede hacerse según finalidad y autorización.
- 3Define resultado permitido
Antes del primer intento, decide si la tarea puede cerrar por cita, actualización, rechazo, no contacto o escalamiento.
- 4Registra cada intento como dato estructurado
Fecha, hora, canal, respuesta, causa y próxima acción deben quedar disponibles para auditoría y tablero.
Qué revisar antes de escalar el volumen
- ¿Cada tarea tiene motivo y fuente visibles?Sin ambos, no podrás explicar el contacto ni corregir errores.
- ¿La persona recibe una explicación proporcional al canal?Un canal menos privado exige menos detalle y más cuidado.
- ¿Los estados de cierre son pocos y obligatorios?Si el equipo puede cerrar con texto libre, el tablero perderá señal.
- ¿Los reintentos tienen límite y escalamiento?Insistir y abandonar son decisiones; ambas deben estar gobernadas.
- ¿Los casos sin dueño aparecen en una vista diaria?Una alerta sin responsable no mejora por estar automatizada.
La trazabilidad no debe sentirse como burocracia. Bien diseñada, reduce carga porque evita reconstruir historias. El equipo ya no pregunta “¿quién llamó?”, “¿qué dijo?”, “¿por qué se cerró?” o “¿qué sigue?”. La tarea lo dice. La institución puede revisar casos, detectar cuellos de botella y aprender qué reglas producen buen contacto.
El costo de no hacerlo aparece después. Una persona recibe varios contactos por el mismo motivo. Otra no recibe ninguno porque su dato estaba malo. Una cita se pierde porque nadie escaló falta de cupo. Una queja llega y nadie puede reconstruir el recorrido. Un indicador mensual baja y el comité no sabe si falló la agenda, el canal, el dato o el cierre. Todo eso es pérdida de trazabilidad, aunque el equipo haya trabajado mucho.
Programar contacto sin perder trazabilidad es una práctica de gobierno, no una pantalla. Requiere menos improvisación, menos listas genéricas y más definición previa. Cuando cada contacto nace con motivo y termina con estado, la institución deja de medir actividad y empieza a medir continuidad.
Fuentes
- Ley 1581 de 2012 — Función Pública
- Ley 1438 de 2011 — Función Pública
- Resolución 2275 de 2023 — Ministerio de Salud y Protección Social
- Resolución 3280 de 2018 — Ministerio de Salud y Protección Social