Reducir las transferencias que frustran a los clientes

Un cliente no odia hablar con varias personas. Odia tener que empezar de cero cada vez que lo hace. Ese es el matiz que la mayoría de los mapas de proceso pasa por alto: el problema no es el traspaso en sí, es la memoria que se pierde en el camino.

Llevo años sentado en salas de operaciones donde el argumento de siempre es "reducir los traspasos entre áreas". Es un objetivo razonable, pero incompleto. Se puede tener un proceso con seis traspasos que el cliente experimenta como fluido, y otro con dos que se siente como una pelea. La diferencia no está en la cantidad: está en si el contexto viaja con el cliente o si el cliente tiene que cargarlo él mismo, una y otra vez, como si nadie antes le hubiera prestado atención.

¿Por qué frustra un traspaso aunque cada agente resuelva bien su parte?

Frustra porque cada traspaso sin contexto obliga al cliente a hacer un trabajo que no le corresponde: reconstruir su propio caso para un desconocido. El agente puede ser amable, competente y rápido; si empieza preguntando "¿en qué le puedo ayudar?" a alguien que ya lo explicó tres veces, la calidad individual de esa interacción no compensa el desgaste acumulado. La frustración no vive en el momento del traspaso: vive en la repetición que el traspaso exige.

¿Qué es exactamente un traspaso, y por qué no todos pesan lo mismo?

Un traspaso ocurre cada vez que la responsabilidad sobre el caso de un cliente cambia de persona, equipo, canal o sistema. Eso puede ser tan visible como transferir una llamada, o tan invisible como que un ticket pase de un agente de chat a un back office que nunca habla con el cliente. No todos pesan igual porque no todos exigen lo mismo del cliente. Vale la pena separarlos en tres tipos:

• Traspaso informacional: el cliente tiene que repetir datos objetivos (número de póliza, pedido, motivo del reclamo). Es el más fácil de eliminar con buena arquitectura de datos.
• Traspaso contextual: el cliente tiene que reconstruir la narrativa completa (qué intentó, qué le dijeron antes, por qué está molesto). Este es el que de verdad erosiona la paciencia.
• Traspaso emocional: el cliente tiene que volver a persuadir a alguien de que su problema es legítimo, porque el nuevo interlocutor parte de cero y, sin querer, cuestiona lo que ya se había validado.

El error operativo típico es medir solo el primero —cuántos campos se transfieren en el CRM— y no darse cuenta de que el daño real ocurre en el segundo y el tercero.

¿Por qué repetir la historia duele más de lo que parece?

Duele porque activa dos mecanismos psicológicos que rara vez se nombran en la sala de operaciones. El primero es la carga cognitiva: reconstruir una narrativa completa —secuencia, emociones, expectativas incumplidas— exige un esfuerzo mental notablemente mayor que recitar un número de cuenta. El Nielsen Norman Group ha documentado extensamente cómo el exceso de carga cognitiva reduce la capacidad de las personas para procesar información con paciencia, y un cliente que repite su caso por tercera vez está, literalmente, gastando la reserva mental que le quedaba para tolerar la espera.

El segundo mecanismo es más sutil: el efecto de gradiente de meta (goal-gradient effect), descrito originalmente por Clark Hull y retomado en el contexto de fidelización por Ran Kivetz, Oleg Urminsky y Yuhuang Zheng en su estudio de 2006 publicado en el Journal of Marketing Research, "The Goal-Gradient Hypothesis Resurrected". El hallazgo central —que la motivación se acelera cuanto más cerca se percibe la meta— tiene una lectura incómoda para el diseño de procesos: cada vez que un traspaso obliga al cliente a repetir su historia, el cerebro interpreta que la meta se alejó, no que simplemente cambió de responsable. El cliente no siente que avanza hacia la resolución; siente que retrocede.

A esto se suma lo que Matthew Dixon, Karen Freeman y Nicholas Toman documentaron en su artículo de julio-agosto de 2010 en Harvard Business Review, "Stop Trying to Delight Your Customers", basado en investigación del Corporate Executive Board: el esfuerzo que un cliente percibe al resolver un problema predice su lealtad futura mejor que su nivel de satisfacción con una interacción puntual. Verse forzado a repetir información ante interlocutores distintos es, según ese trabajo, una de las fuentes de esfuerzo percibido más determinantes —y más evitables— del servicio.

Un traspaso bien diseñado transporta la memoria del cliente. Uno mal diseñado le devuelve la carga de demostrarla.

¿Cómo se mapea un traspaso para encontrar dónde se rompe?

Se mapea siguiendo el recorrido de la información, no solo el recorrido del cliente. La mayoría de los customer journey maps muestran las etapas que el cliente atraviesa, pero no muestran qué le pasa a su contexto por debajo, en el momento exacto en que cambia de manos. Ese es el punto ciego que hay que iluminar con un ejercicio de rediseño de procesos apoyado en la lógica del service blueprint, la técnica que Lynn Shostack introdujo en 1984 en su artículo de Harvard Business Review, "Designing Services That Deliver", y que sigue siendo la herramienta más honesta para conectar el frontstage que ve el cliente con el backstage que lo produce.

El proceso, en la práctica, tiene un orden:

1. Levanta cada traspaso real, no el que dice el manual. Escucha grabaciones, lee hilos de tickets y pregunta a los agentes dónde "se pierde" la información en la práctica. El proceso documentado casi nunca coincide con el que ocurre.
2. Clasifica cada traspaso según el tipo de carga que impone —informacional, contextual o emocional— usando la distinción anterior. Esto revela cuáles son cosméticos y cuáles son estructurales.
3. Mide el tiempo de "reconstrucción del contexto" en cada punto de traspaso: cuánto tarda el nuevo responsable en entender el caso, y cuánto de eso lo hace el cliente en voz alta.
4. Identifica qué sistema, o falta de sistema, obliga a repetir la historia. Casi siempre es un problema de integración de datos, no de mala voluntad del agente.
5. Prioriza por impacto emocional, no por volumen. Un traspaso de bajo volumen pero alta carga emocional —una reclamación, una cancelación— pesa más en la percepción de marca que diez traspasos rutinarios sin fricción.

Este ejercicio se apoya bien en un diagnóstico más amplio de madurez operativa; la evaluación de madurez de CX ayuda a ubicar en qué building blocks —gobierno de datos, diseño de procesos, cultura de servicio— está el origen real del problema antes de rediseñar nada.

¿Qué distingue un traspaso invisible de uno que rompe la experiencia?

La diferencia no está en si el cliente lo nota, sino en si el cliente tiene que trabajar para que no lo note. Un traspaso bien diseñado tiene estas características:

• El contexto llega antes que la pregunta. El nuevo interlocutor ya sabe qué pasó, no necesita que el cliente lo resuma.
• Hay un responsable único visible para el cliente, aunque detrás operen varios equipos. El cliente no necesita saber cuántas manos tocó su caso.
• La narrativa emocional se conserva, no solo los datos. Si el cliente estaba molesto, el siguiente agente lo sabe y no empieza con un tono neutro que se sienta como indiferencia.
• El cliente percibe progreso, no reinicio. Cada contacto lo acerca a la resolución en lugar de devolverlo al punto de partida.
• El traspaso ocurre antes de que el cliente lo pida, no como reacción a su enojo por tener que insistir.

Cuando falta alguno de estos elementos, el traspaso deja de ser un mecanismo operativo y se convierte en una prueba que el cliente tiene que aprobar para seguir siendo atendido.

¿Cómo se rediseña el proceso sin eliminar la especialización?

Aquí está la trampa habitual: los equipos de operaciones intentan resolver la frustración eliminando traspasos, es decir, fusionando roles o creando "superagentes" que lo hacen todo. Funciona en organizaciones pequeñas y colapsa en las grandes, porque la especialización existe por buenas razones —complejidad técnica, cumplimiento normativo, volumen. El rediseño correcto no elimina la especialización: elimina la amnesia entre especialistas.

1. Diseña el "paquete de contexto" que viaja con el caso, no solo los campos de datos: motivo, tono emocional detectado, promesas ya hechas, canales ya usados. Esto se define junto con el resto de la arquitectura del recorrido del cliente, no como un parche aislado en el CRM.
2. Define un dueño del caso end-to-end, aunque no resuelva todo personalmente. Esa persona es el punto de anclaje que el cliente reconoce, incluso cuando el trabajo real ocurre en otro equipo.
3. Elimina la pregunta "¿me puede repetir su problema?" del guion y reemplázala por una confirmación: "Veo que usted reportó X ayer y le dijeron Y, ¿es así?". El cambio de una pregunta abierta a una confirmación cambia por completo la carga cognitiva que recae sobre el cliente.
4. Fija un límite de traspasos aceptable por tipo de caso y trata cualquier exceso como una alerta operativa, no como una anécdota. Si un reclamo típico pasa por más de dos manos, hay un problema de diseño, no de personas.
5. Cierra el ciclo con el agente que originó el caso, siempre que sea posible, para que el cliente sienta que alguien acompañó todo el recorrido, aunque otros hayan ejecutado partes técnicas.

Este tipo de rediseño rara vez se resuelve solo con tecnología. Requiere revisar el diseño de servicio de punta a punta —desde el guion del primer contacto hasta la política interna de escalamiento— porque los traspasos frustrantes casi siempre son síntoma de un proceso que se diseñó para la eficiencia interna, no para la continuidad narrativa del cliente.

¿Qué hacer cuando el traspaso es inevitable?

Hay casos —fraude, reclamos legales, incidentes críticos— donde el traspaso a un especialista es necesario y no se puede diseñar fuera del proceso. Ahí el objetivo cambia: no se trata de evitarlo, sino de anunciarlo bien y de proteger la peak-end rule que Daniel Kahneman describió en su trabajo sobre juicio y memoria, según la cual las personas recuerdan una experiencia sobre todo por su punto más intenso y por cómo termina, no por su duración total. Si el traspaso hacia el especialista se comunica con transparencia —"voy a transferirle a alguien que resuelve esto directamente, y ya le pasé todo el historial"— el cliente lo vive como avance. Si se comunica como un abandono —"eso no lo maneja este equipo"— el cliente lo vive como pérdida, incluso si el resultado final es idéntico. Este es también el terreno de una buena estrategia de escalamiento: definir de antemano qué casos requieren traspaso, quién lo anuncia, y cómo se cierra el círculo con el cliente al final, en lugar de improvisarlo cada vez que ocurre.

Las organizaciones que tratan sus canales como piezas sueltas —un CRM aquí, un chatbot allá, un centro de llamadas subcontratado más allá— multiplican estos traspasos sin darse cuenta. Vale la pena revisar cómo se diseñan los recorridos omnicanal que realmente se sienten fluidos, porque la continuidad entre canales es, en el fondo, el mismo problema que la continuidad entre personas: información que debe viajar sin que el cliente la cargue.

Lo que el mapa de proceso no debería seguir ocultando

La mayoría de los diagramas de proceso muestran cajas y flechas entre departamentos. Muy pocos muestran lo que el cliente tiene que hacer para que esas flechas funcionen. Ese es el ejercicio pendiente en casi toda operación que promete "experiencia sin fricción" mientras sigue midiendo su eficiencia interna en silos.

Reducir traspasos frustrantes no es un proyecto de tecnología ni un eslogan de cultura de servicio. Es un ejercicio de diseño de procesos con una pregunta incómoda en el centro: ¿qué parte del trabajo de recordar, explicar y demostrar le estamos delegando al cliente porque a nosotros nos resultó más barato organizarnos así? Las empresas que responden esa pregunta con honestidad no eliminan la complejidad operativa —siguen teniendo especialistas, sistemas separados, equipos distintos—. Lo que eliminan es la obligación de que el cliente sea quien mantiene viva la memoria de su propio caso. Esa es la diferencia entre un proceso eficiente y una experiencia que se siente cuidada.