Reducir las transferencias que frustran a los clientes

Un cliente de banca cuenta su problema por cuarta vez en cuarenta minutos. No está enfadado por el problema original —una tarjeta bloqueada, un cargo duplicado—; está enfadado porque cada persona que lo atiende empieza de cero, como si él fuera nuevo cada vez. Esa es la experiencia que casi ningún mapa de procesos de la empresa muestra, porque en el papel la transferencia es una flecha limpia entre dos cajas. En la vida real es una fractura.

La tesis de este artículo es simple y, creo, incómoda para muchos equipos de operaciones: las transferencias no frustran porque el cliente tenga que "cambiar de canal", sino porque cada transferencia borra el progreso que el cliente sentía haber hecho. El problema no se arregla con más empatía en el guion del agente. Se arregla rediseñando quién posee el problema, qué información viaja con el cliente y en qué punto una transferencia deja de ser necesaria y se convierte en un atajo cómodo para la organización.

¿Qué es exactamente una transferencia que frustra al cliente?

Una transferencia frustrante es cualquier momento en que el cliente tiene que volver a explicar, volver a autenticarse o volver a esperar porque la propiedad de su caso ha cambiado de manos sin que el contexto haya viajado con él. No toda transferencia es mala: derivar una reclamación técnica compleja a un especialista puede ser exactamente lo correcto. Lo que frustra no es el traspaso en sí, sino su coste invisible —tiempo, repetición, incertidumbre sobre si alguien realmente se hará cargo— comparado con el beneficio que el cliente percibe de él.

En el lenguaje del diseño de procesos, esto se llama un "punto de fricción de propiedad": el instante en que el hilo de responsabilidad se corta y nadie garantiza la continuidad. Cuantas más manos tiene un proceso, más probable es que exista uno de estos puntos, y casi siempre nace de una decisión de diseño organizativo, no de mala voluntad de quien atiende.

¿Por qué duele tanto más de lo que sugiere el diagrama de flujo?

Porque el cliente no experimenta el proceso como una secuencia de pasos: lo experimenta como una acumulación de esfuerzo hacia una meta, y cada transferencia amenaza esa sensación de avance. La hipótesis del gradiente de meta —documentada 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"— muestra que las personas aceleran su esfuerzo cuanto más cerca perciben estar de completar un objetivo. Una transferencia hace justo lo contrario: reinicia la percepción de distancia hasta la meta. El cliente sentía que estaba a media conversación de resolver su problema; de golpe, vuelve a estar en la casilla de salida.

A esto se suma la aversión a la pérdida que describieron Daniel Kahneman y Amos Tversky en su teoría de las perspectivas de 1979: el cliente ya ha invertido tiempo, ha entregado datos, ha construido una narrativa coherente con el primer agente. Esa inversión se siente como propiedad —como algo suyo—, y perderla en la transferencia se vive como una pérdida real, no como un simple retraso. Por eso "tengo que volver a explicarlo" indigna más de lo que su duración objetiva justificaría.

El estudio de 2010 de Matthew Dixon, Karen Freeman y Nicholas Toman, publicado en Harvard Business Review bajo el título "Stop Trying to Delight Your Customers", llegó a una conclusión que sigue siendo la más citada del sector de servicio al cliente: reducir el esfuerzo del cliente predice la lealtad mejor que intentar sorprenderlo positivamente. Las transferencias mal gestionadas son, casi por definición, esfuerzo añadido sin compensación emocional.

Cada transferencia cobra un impuesto invisible: el cliente lo paga con memoria, paciencia y confianza, mientras la organización lo contabiliza como coste cero porque no aparece en ningún estado de resultados.

¿Dónde nacen las transferencias que no deberían existir?

Casi nunca nacen en el punto de contacto. Nacen tres o cuatro capas más arriba, en decisiones de diseño organizativo que nadie revisita porque funcionaron razonablemente bien el día en que se tomaron. Las causas más comunes que encuentro al hacer descubrimiento de procesos son siempre las mismas:

• Silos funcionales disfrazados de especialización. Se divide el trabajo por producto o por sistema interno, no por la intención del cliente, así que un problema que el cliente vive como "uno solo" cruza tres departamentos distintos.
• Sistemas que no se hablan entre sí. El agente B no ve lo que el agente A ya registró, así que la única forma de "transferir contexto" es que el cliente lo repita en voz alta.
• Incentivos mal calibrados. Si el tiempo medio de gestión (AHT) es la métrica que se premia, transferir un caso complicado mejora el número de quien lo pasa y empeora la experiencia de quien lo recibe.
• Escalado como reflejo, no como diseño. Sin criterios claros de cuándo escalar y a quién, cada agente decide por intuición, y la intuición varía de persona a persona.
• Autenticación repetida por defecto. Cada sistema exige verificar identidad de nuevo, aunque el cliente ya se autenticó dos minutos antes en el canal anterior.

Ninguna de estas causas se ve en un mapa de procesos dibujado desde el escritorio de un gerente. Se ven cuando alguien se sienta con los equipos de primera línea, escucha llamadas reales y traza el recorrido tal como ocurre, no como debería ocurrir según el manual.

¿Cómo se diagnostica una transferencia antes de intentar arreglarla?

El error más frecuente es rediseñar el proceso sin haberlo observado primero. La disciplina correcta —heredada del service blueprinting que popularizó Lynn Shostack en la década de 1980 y que sigue siendo la base metodológica del diseño de servicios moderno— separa lo que el cliente ve de lo que ocurre detrás del telón, y expone exactamente dónde cambia de manos la responsabilidad.

1. Reconstruye el recorrido real, no el oficial. Toma diez a veinte casos recientes de un mismo tipo de solicitud y traza cada paso que dieron realmente, con marcas de tiempo. La brecha entre el proceso documentado y el proceso vivido suele ser la primera sorpresa.
2. Marca cada punto donde cambia el propietario del caso. No solo el cambio de canal (teléfono a email), sino el cambio de persona o de sistema responsable, aunque el canal sea el mismo.
3. Clasifica cada transferencia como necesaria, evitable o mal ejecutada. Una transferencia necesaria y bien ejecutada no es el problema; el problema son las evitables y las mal ejecutadas.
4. Mide el coste real de cada una. Tiempo de espera generado, número de veces que el cliente repite información, y si existe abandono o reapertura del caso después de la transferencia.
5. Identifica quién gana y quién pierde con el statu quo. Casi siempre hay un departamento para el que la transferencia actual es cómoda, aunque sea costosa para el cliente y para la organización en conjunto.

Este ejercicio de descubrimiento —cuando se hace con rigor y no como un taller de un día— es lo que separa un rediseño superficial de uno que realmente elimina fricción. Suele apoyarse en el trabajo estructurado de mapeo que ofrecen las jornadas de cliente (CX journeys) cuando se conectan con el detalle operativo, no cuando se quedan en un dibujo bonito para un comité.

¿Cómo se reducen las transferencias sin fingir que no existen?

No todas las transferencias se pueden ni se deben eliminar. El objetivo operativo correcto es reducir las evitables y rediseñar las necesarias para que no cuesten memoria, tiempo ni confianza al cliente. Esto pasa por cuatro palancas concretas:

• Modelo de propietario único del caso. Una persona o equipo pequeño posee el problema de principio a fin, aunque consulte a especialistas por detrás. El cliente nunca necesita saber cuántas manos tocaron su caso; solo necesita saber a quién preguntarle.
• La regla del contexto que viaja, no del cliente que repite. Ningún agente debería preguntar algo que ya está en el sistema. Si la tecnología no lo permite hoy, la solución intermedia es un resumen obligatorio de treinta segundos que el agente saliente deja antes de transferir, no una nota genérica de "cliente molesto".
• Transferencia caliente, no fría. Cuando la transferencia es realmente necesaria, el agente que la origina debe permanecer en línea el tiempo suficiente para presentar al cliente y confirmar que el nuevo responsable tiene el contexto correcto, en vez de simplemente colgar y redirigir.
• Criterios de escalado explícitos, no intuitivos. Definir con precisión qué tipo de caso se escala, a qué nivel y con qué información mínima obligatoria reduce la variabilidad entre agentes y evita las transferencias en cadena que no llevan a ninguna parte. Esto es exactamente el terreno de una estrategia de escalado bien diseñada, y no un simple árbol de decisión colgado en la pared del contact center.

La elección de las incentivos internos importa tanto como el diseño del proceso. Si se sigue premiando el tiempo medio de gestión por encima de la resolución en el primer contacto, cualquier rediseño de transferencias durará hasta la primera revisión de objetivos trimestrales.

¿Qué papel juega la primera línea en todo esto?

La primera línea no es la causa del problema; es quien absorbe el coste de un diseño que nadie más ve. Un agente que transfiere un caso sin contexto suficiente no lo hace por pereza: lo hace porque el sistema no le da otra opción, porque no tiene autoridad para resolverlo él mismo, o porque las métricas que lo evalúan lo empujan a soltarlo rápido. Rediseñar transferencias sin involucrar a quien las ejecuta a diario es un error de discovery clásico: se optimiza sobre supuestos, no sobre la realidad operativa.

Integrar a los equipos de primera línea en el rediseño —no solo como fuente de datos, sino como coautores de la solución— es lo que convierte un proyecto de reingeniería en un cambio que sobrevive seis meses después de la presentación al comité ejecutivo. Este principio, y cómo aplicarlo en la práctica, se desarrolla con más detalle en el análisis sobre integración del personal de primera línea en el diseño de experiencia.

¿Cómo se sabe si el rediseño realmente funcionó?

Medir bien esto exige mirar más allá del NPS o el CSAT genéricos, que capturan la satisfacción general pero rara vez aíslan el efecto específico de una transferencia. Las métricas operativas que sí lo aíslan son:

• Tasa de repetición de información, capturada directamente en encuestas post-contacto o en escucha de llamadas: cuántas veces el cliente tuvo que volver a explicar su caso.
• Número de manos por caso, contado desde el sistema, no estimado: cuántos agentes o departamentos distintos tocaron una misma solicitud antes de cerrarla.
• Resolución en el primer contacto, que sube de forma directa cuando se reducen las transferencias evitables.
• Tiempo total del cliente, no solo el tiempo de cada agente: la suma de espera, repetición y traspaso que el cliente vive de punta a punta.

La recogida sistemática de estas señales depende de una gestión estructurada de la voz del cliente, capturada en el momento correcto del recorrido y no meses después en una encuesta anual que nadie recuerda con precisión. Y para justificar la inversión en rediseño de procesos frente a un comité financiero, conviene traducir esas mejoras operativas en impacto de negocio con una herramienta como la calculadora de ROI de CX, que ayuda a cuantificar cuánto vale realmente eliminar una transferencia innecesaria.

¿Qué pasa cuando el problema es cultural, no técnico?

A veces la tecnología ya permite compartir contexto perfectamente, y las transferencias siguen doliendo porque cada departamento sigue actuando como si el cliente perteneciera solo a su tramo del proceso. Ahí el problema ya no es de mapeo, sino de cómo se define el éxito internamente. Mientras un área mida su desempeño por cuántos casos "resuelve" —es decir, cuántos casos saca de su bandeja, sin importar si el cliente quedó realmente atendido—, seguirá existiendo un incentivo silencioso para transferir en vez de resolver. Corregir esto exige un trabajo de gestión del cambio que alinee objetivos entre departamentos alrededor del recorrido del cliente, no alrededor de la estructura del organigrama. Sin ese realineamiento, cualquier rediseño de proceso es cosmético: se ve mejor en el diagrama, pero el cliente sigue repitiendo su historia por teléfono.

El proceso perfecto en el papel y el cliente exhausto en la línea

Ningún comité de operaciones se reúne para diseñar una mala experiencia. Las transferencias que frustran al cliente son casi siempre el subproducto de decisiones razonables tomadas en aislamiento: especializar equipos, proteger presupuestos, medir lo que es fácil de medir. El coste de esas decisiones no aparece en ningún informe interno porque quien lo paga es el cliente, en tiempo, en memoria y en la sensación de que nadie, en realidad, se hizo cargo de su problema.

Arreglarlo no requiere más tecnología ni más buena voluntad en el guion de atención. Requiere trazar el recorrido tal como ocurre, nombrar sin miedo cada punto donde el hilo se corta, y decidir con disciplina quién posee el problema del cliente de principio a fin. Ese es el trabajo silencioso que separa a las organizaciones que hablan de experiencia de las que realmente la construyen, un traspaso a la vez.