Traspasos entre áreas: dónde se pierde el pedido
El pedido se pierde en el momento en que un área lo entrega a otra, porque el contexto se queda en la cabeza de quien entregó y quien recibe solo tiene el mensaje. El problema es de arquitectura, no de atención de las personas. La salida es un registro único que viaja con el pedido, campos obligatorios y una aceptación explícita de quien recibe.
¿Dónde se pierde un pedido entre dos áreas?
En la entrega, y casi nunca en el trabajo de cada área. Quien entrega conoce el contexto: qué pidió el cliente fuera del formulario, qué ya se acordó, qué está pendiente. Quien recibe ve lo que llegó. Esa diferencia es el traspaso, y es donde la información desaparece sin que nadie haya cometido un error.
La medicina lo estudió de cerca, porque equivocarse cuesta caro y los registros son buenos. El caso "Empty Handoff", publicado en 2012 por la AHRQ, la agencia federal estadounidense de investigación y calidad en salud, describe a un paciente que llegó a cirugía sin que el equipo supiera de su sensibilidad a la insulina. La enfermera pidió a un auxiliar que avisara, el aviso no se transmitió y el glucómetro no estaba acoplado, así que la lectura baja nunca llegó a la historia clínica. El comentario cita un análisis de 60 demandas por error quirúrgico ligadas a fallos de comunicación: el 43% implicaba un traspaso mal hecho.
Un hospital no es su empresa. El mecanismo se parece: la información depende de que alguien se acuerde de transmitirla, por un canal que no obliga a nadie a confirmar. Los autores del caso concluyen que confiar en las personas para cubrir el hueco es poco fiable, incluso con profesionales cuidadosos.
¿Qué cambia cuando el traspaso tiene estructura?
Los errores bajan de forma medible. Starmer y sus colegas probaron el programa I-PASS en nueve hospitales pediátricos, con 10.740 ingresos, en tres fases de seis meses: observación, formación con uso obligatorio y seguimiento. Los errores médicos pasaron de 24,5 a 18,8 por cada 100 ingresos, un 23% menos. Los eventos adversos evitables bajaron de 4,7 a 3,3 por cada 100, un 30% menos. El resultado se publicó en el New England Journal of Medicine en 2014.
I-PASS no es solo un guion. Reúne formación, un traspaso verbal en cinco partes (gravedad del caso, resumen, lista de acciones, conciencia de la situación con plan de contingencia y síntesis hecha por el receptor), herramientas digitales con la misma estructura, supervisión y una campaña interna. El diseño compara antes y después, sin grupo de control simultáneo, así que la cifra muestra una asociación, no una prueba aislada de causa.
Lo que importa para su operación es la última letra: quien recibe resume lo que entendió. El traspaso solo termina cuando el receptor confirma.
¿Basta un mensaje escrito como traspaso?
No, cuando es el único canal. Parke, Hobbs y Kanki, de la NASA, hicieron un experimento con 50 participantes en una tarea que imitaba traspasos de turno en entornos industriales. Reforzar el registro escrito con conversación presencial, vídeo o audio redujo de forma significativa los errores de la tarea, y el texto solo fue la modalidad menos preferida. El resumen del estudio no da las tasas de error.
Nuestra lectura para una empresa es esta: lo que reduce el error es la posibilidad de que el receptor pregunte y el emisor corrija. En un sistema, el equivalente es un paso de aceptación con respuesta, y no una notificación que el receptor marca como leída. Esa lectura es nuestra, no del estudio.
Un ejemplo práctico: la propuesta aprobada que se convierte en la póliza equivocada
El escenario siguiente es hipotético, sin cifras medidas. Una correduría de seguros tiene ventas por un lado y emisión de pólizas por otro. El corredor cierra una propuesta empresarial y, por teléfono, el cliente pide una cobertura adicional para una nave. El corredor escribe en el chat del equipo: "aprobado, puedes emitir". Emisión lee el mensaje, abre el formulario estándar y emite la póliza sin la cobertura adicional.
Nadie trabajó mal, y eso indica dónde está el problema: no es de atención, es de arquitectura. El corredor transmitió lo que le pareció central y emisión hizo exactamente lo que el mensaje pedía. El error aparece meses después, en un siniestro o en una renovación en la que el cliente cuestiona el precio. La información existía. Simplemente no viajó.
Un traspaso estructurado cambiaría tres cosas. La propuesta aprobada se movería como un solo registro, con el historial de lo acordado, y no como un mensaje suelto. Un campo obligatorio de "condiciones fuera del estándar" impediría que el pedido saliera vacío. Y emisión solo aceptaría el pedido tras devolver un resumen de lo que va a emitir, para que el corredor lo compruebe.
¿Cómo se diseña el traspaso en el sistema?
Con cuatro elementos, que son nuestra traducción de I-PASS a la operación de una empresa, no una receta de sus autores.
El primero es el registro único: el pedido pasa como el mismo objeto de un área a otra, con su historial. Cuando cada etapa abre un registro nuevo y copia datos a mano, el traspaso se vuelve reescritura y el contexto se queda atrás. El segundo son los campos obligatorios, elegidos con la pregunta "qué necesita saber el receptor y no puede deducir": plazo y prioridad, lo acordado fuera del formulario, lo que falta y lo que puede salir mal.
El tercero es la aceptación del receptor. Quien recibe confirma lo que entendió, y el sistema solo mueve el pedido a la etapa siguiente después de eso. El cuarto es la comprobación posterior. El comentario publicado por la AHRQ recomienda verificar, tras el traspaso, que expectativas, situación y documentación coinciden, porque la mayoría de los errores de traspaso no causa daño en el momento y puede quedar oculta mucho tiempo. En un sistema, esto se vuelve una comprobación sencilla: ¿lo que se emitió corresponde a lo que se aprobó?
Otro artículo del blog trata un vecino de este problema. Excepciones de proceso: el camino sin registro habla de lo que hace el equipo cuando el sistema no cubre un caso, y el traspaso informal por mensaje es uno de esos caminos.
El caso SuperVida muestra el registro único aplicado a toda la operación: contratos, beneficiarios, vendedores y socios pasaron a gestionarse en un solo lugar cuando la red de tarjetas de beneficios salió de Airtable hacia un ERP a medida, entregado en 2023.
Preguntas frecuentes
Mi equipo está acostumbrado a pasar los pedidos por mensaje. ¿Aceptará un formulario?
Depende de lo que le cueste a quien entrega. Si un campo obligatorio se rellena en segundos y evita la pregunta de vuelta, los equipos tienden a adoptarlo. Empiece por un solo tipo de pedido, el que más retrabajo genera, y deje el mensaje como complemento, no como canal.
¿Será complicada la integración con lo que ya uso?
No siempre exige integrarlo todo. El punto crítico es un traspaso, entre dos áreas, y el registro puede vivir en el sistema que ya existe o en un módulo nuevo, siempre que los datos de la etapa anterior lleguen con él. Mapear qué dato cruza la frontera es el primer paso, antes de elegir cualquier herramienta.
No sé si esto tiene retorno financiero. ¿Cómo lo mido?
Mida antes de cambiar nada: cuántos pedidos vuelven al área anterior, cuánto tiempo esperan una aclaración y cuántos errores llegan al cliente. Los estudios citados son de salud y de la NASA, así que no sirven como meta para su operación. Lo que vale es su propia línea de base.
El siguiente paso
Si hoy los pedidos cambian de área por mensaje y nadie confirma lo que entendió, el Diagnóstico de Arquitectura Operacional, una conversación de 30 minutos, es una invitación a mapear dónde ocurren esos traspasos y qué debe llevar cada uno: hable con Yowpi.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico