Connecting process maps to journey maps

Un mapa de journey precioso, lleno de emojis y curvas emocionales, no explica por qué el cliente lleva veintitrés minutos esperando una validación de KYC. Para eso hace falta el otro mapa: el que nadie cuelga en la pared del comité de dirección, el que muestra colas, aprobaciones, sistemas legados y personas que reenvían un correo a las 17:40 porque el turno cambia a las 18:00. Ese es el mapa de procesos, y sin él, el mapa de journey es una novela bonita sin explicación causal.

La tesis es simple y la defiendo desde hace años en proyectos de rediseño operativo: un journey map sin su proceso operativo debajo es un diagnóstico sin tratamiento. Muestra el síntoma —frustración, abandono, una caída de nueve puntos en satisfacción tras el paso 4— pero no toca la causa, que casi siempre vive en un traspaso entre departamentos, una regla de negocio obsoleta o un sistema que no habla con otro. Conectar ambos mapas no es un ejercicio de diseño; es la única forma de que un rediseño de experiencia sobreviva el primer trimestre después del lanzamiento.

¿Qué diferencia hay entre un mapa de procesos y un mapa de journey?

El mapa de journey documenta la experiencia desde la perspectiva del cliente: lo que siente, lo que espera, lo que hace en cada etapa, con qué emoción sale de cada touchpoint. El mapa de procesos documenta cómo la organización produce esa experiencia por dentro: los pasos, las decisiones, los sistemas, los responsables y los tiempos de ciclo. El primero responde "¿qué vive el cliente?"; el segundo responde "¿qué tiene que pasar internamente para que eso ocurra?".

La distinción no es cosmética. Un journey map bien hecho puede señalar que la apertura de cuenta se siente lenta y ansiógena. Solo un mapa de proceso —con sus carriles por departamento, sus tiempos de espera entre pasos y sus puntos de decisión— puede mostrar que el 60% de ese tiempo ocurre en una cola de validación manual que nadie ha tocado desde que se automatizó el resto del flujo. El journey map te dice dónde duele. El mapa de proceso te dice por qué duele y quién tiene que actuar para que deje de doler.

El concepto que las une, y que muchos equipos de CX ignoran, es el service blueprint. Lynn Shostack lo introdujo en 1984 en su artículo "Designing Services That Deliver", publicado en Harvard Business Review, precisamente para resolver este problema: superponer la línea de visibilidad del cliente sobre las acciones de front-office, back-office y sistemas de soporte. Cuatro décadas después, sigue siendo la herramienta más subestimada del diseño de experiencia.

¿Por qué las empresas mapean el journey pero no el proceso?

Porque el journey map es más fácil de vender internamente. Tiene caras, emociones, una curva que sube y baja: es narrativa, y la narrativa convence a un comité en cuarenta minutos. El mapa de proceso, en cambio, expone quién es responsable de qué demora, qué sistema está fuera de soporte y qué política nadie se ha atrevido a cuestionar. Es políticamente incómodo. Y ahí está el problema real: los equipos de experiencia dibujan la emoción del cliente, pero delegan la explicación operativa a "otro equipo" que nunca llega a la misma sala.

He visto el patrón repetirse en banca, en salud y en retail: el equipo de CX presenta el journey, identifica el "momento de dolor" en la etapa de reclamos, propone un rediseño de comunicación... y seis meses después el NPS no mueve una décima, porque el proceso de resolución interno sigue teniendo siete traspasos y una aprobación manual que nadie mapeó. El síntoma se maquilló; la causa siguió intacta.

La firma de consultoría Bain & Company, en su estudio de 2005 Closing the Delivery Gap, encontró que el 80% de las empresas creía ofrecer una experiencia superior, mientras solo el 8% de sus clientes coincidía. Esa brecha no nace de una intención equivocada: nace de que quienes diseñan la promesa de experiencia rara vez auditan el proceso que tiene que cumplirla.

¿Qué se rompe cuando los dos mapas viven separados?

La lista de síntomas es previsible una vez que has visto suficientes operaciones por dentro:

• El "momento de la verdad" queda sin dueño operativo. El journey map señala la etapa crítica, pero nadie traduce esa señal a un paso de proceso concreto con un responsable, un SLA y un sistema.
• Se rediseña el touchpoint visible y se ignora el cuello de botella invisible. Se cambia el copy del correo de confirmación mientras la aprobación manual detrás sigue tardando cuatro días.
• Las métricas de journey y las métricas operativas no se hablan. El CSAT cae en la etapa 3, pero nadie cruza ese dato con el tiempo de ciclo o la tasa de retrabajo de ese mismo paso interno.
• Cada rediseño de experiencia se convierte en un proyecto de comunicación, no de operación. Se maquilla la fachada porque tocar el proceso implica negociar con otro departamento, y nadie quiere abrir esa conversación.
• La deuda operativa se acumula sin visibilidad. Los parches manuales que "resuelven" un journey roto —una excepción, un favor, una hoja de Excel paralela— nunca aparecen en ningún mapa, hasta que colapsan bajo volumen.

El resultado es un ciclo de rediseños superficiales que mejoran la percepción durante un trimestre y luego regresan al punto de partida, porque el proceso que produce la experiencia nunca cambió.

¿Cómo se conectan un mapa de procesos y un mapa de journey en la práctica?

La conexión no es una capa de diseño adicional; es una secuencia de trabajo. Así la ejecuto en proyectos de rediseño operativo:

1. Mapea el journey primero, con evidencia real. Usa voz del cliente, no supuestos del equipo interno: entrevistas, transcripciones de soporte, encuestas de estrategia de voz del cliente. Identifica las etapas, los touchpoints y, sobre todo, dónde cae la emoción de forma abrupta.
2. Haz el descubrimiento del proceso subyacente para cada etapa crítica. No documentes el proceso "como debería ser" según el manual: siéntate con quien ejecuta la tarea cada día y documenta el proceso real, con sus atajos, excepciones y parches.
3. Superpón ambos mapas usando la línea de visibilidad. Arriba, lo que el cliente ve y siente. Abajo, en carriles paralelos, las acciones de front-office, back-office y los sistemas que las sostienen. Este es exactamente el formato de service blueprint que popularizó Shostack.
4. Marca cada traspaso entre carriles. Cada vez que una tarea cruza de un equipo a otro, de un sistema a otro o de un canal a otro, hay una probabilidad de fricción, demora o pérdida de información. Cuantifica el tiempo de espera en cada traspaso, no solo el tiempo de ejecución.
5. Cruza el dato emocional con el dato operativo. Coloca el EXIS o la métrica de satisfacción de cada touchpoint junto al tiempo de ciclo, la tasa de error y el volumen de esa misma etapa. Donde ambos datos son malos a la vez, ahí está tu prioridad número uno.
6. Rediseña el proceso, no solo el mensaje. Si el problema es una aprobación manual innecesaria, elimínala o automatízala antes de rediseñar cualquier comunicación alrededor de ella. El mensaje bonito sobre un proceso roto solo retrasa la queja.
7. Vuelve a medir en los dos planos. Un rediseño exitoso mueve la métrica de experiencia y la métrica operativa a la vez. Si solo mueve una, algo del diagnóstico original estaba incompleto.

Esta secuencia es, en esencia, lo mismo que describimos en detalle en nuestro trabajo sobre rediseño de procesos: no se trata de mapear por mapear, sino de convertir el mapa en la base de decisiones operativas concretas.

¿Qué papel juega el diseño conductual en esta conexión?

Aquí está el ángulo que la mayoría de los equipos operativos pasa por alto: no toda fricción de proceso es un error de diseño; parte de ella es sludge, el término que Richard Thaler y Cass Sunstein popularizaron en su libro Nudge (2008) para describir la fricción innecesaria que una organización impone —a veces deliberadamente— para retrasar una acción del cliente o protegerse de un riesgo interno. Un formulario que exige subir el mismo documento tres veces, una llamada obligatoria para cancelar un servicio que se activó con un clic: eso no es un journey mal diseñado, es sludge operativo camuflado de "proceso de control".

La distinción cambia la conversación con los equipos de operaciones. No basta con preguntar "¿dónde se frustra el cliente?"; hay que preguntar "¿esta fricción protege algo real —fraude, cumplimiento regulatorio— o solo protege la comodidad interna de no rediseñar un paso incómodo?". Cuando el mapa de proceso expone que un paso existe solo por inercia, el argumento para eliminarlo se vuelve mucho más fácil de defender ante finanzas o riesgo.

El otro principio que aplico sistemáticamente es el peak-end rule de Daniel Kahneman: las personas recuerdan una experiencia sobre todo por su punto más intenso y por cómo termina, no por el promedio de cada paso. Esto tiene una implicación operativa directa: si tienes recursos limitados para rediseñar procesos, prioriza el proceso que sostiene el pico emocional (positivo o negativo) y el proceso que sostiene el cierre del journey —la entrega final, la resolución del reclamo, la confirmación—, aunque no sean los pasos con más volumen de transacciones. El proceso más visitado no siempre es el proceso que más pesa en la memoria del cliente.

¿Cómo empezar sin paralizar la operación?

El error habitual es intentar mapear toda la organización antes de tocar nada, lo que garantiza que el proyecto muera en un archivo compartido. La alternativa operativa es más quirúrgica:

• Elige una sola etapa crítica del journey, la que ya tiene el peor dato de satisfacción o el mayor volumen de quejas, y mapea solo el proceso detrás de esa etapa.
• Trabaja con quien ejecuta la tarea, no solo con su gerente. El proceso documentado por un manual y el proceso real que corre en el día a día casi nunca coinciden; la brecha entre ambos suele ser precisamente donde vive la fricción.
• Cuantifica antes de rediseñar. Tiempo de ciclo, tasa de retrabajo, número de traspasos, volumen mensual. Sin esos números, cualquier propuesta de rediseño es una opinión con diagrama.
• Diseña la solución en los dos planos a la vez. Cada cambio de proceso debe tener su equivalente en el journey: si aceleras una aprobación interna, decide también qué le comunicas al cliente mientras espera, y cuándo.
• Institucionaliza la revisión conjunta. Un mapa de journey y un mapa de proceso que se actualizan por separado, en calendarios distintos, con dueños distintos, se desconectan de nuevo en menos de un año.

Esta última costumbre —revisar ambos mapas en la misma sesión, con el mismo dueño de negocio en la mesa— es la que separa a las organizaciones que sostienen la mejora de las que la reinician cada dieciocho meses. Y es, casi siempre, un problema de modelo operativo más que de voluntad: si nadie tiene el mandato de gobernar ambos mapas a la vez, cada rediseño vuelve a partir de cero.

En términos de herramienta, esta conexión es exactamente lo que plataformas como René Studio intentan resolver de forma nativa: en lugar de journey maps estáticos en una presentación y process maps sueltos en otro archivo, cada touchpoint del journey lleva su propio puntaje de impacto (EXIS) y se conecta con las etapas y pasos del proceso que lo sostiene, de modo que el equipo de operaciones y el equipo de experiencia miran el mismo dato, en el mismo lugar, en lugar de reconciliar dos verdades distintas cada trimestre.

¿Cómo se sabe si la conexión está funcionando?

La prueba no es visual, es de resultado. Si después de un rediseño el journey map muestra una etapa más fluida pero el tiempo de ciclo interno no bajó, algo se maquilló y no se resolvió. Si el tiempo de ciclo bajó pero la satisfacción del cliente no se movió, probablemente optimizaste un paso que no era el que pesaba en la memoria del cliente —volviendo al peak-end rule. La señal correcta es cuando ambos indicadores se mueven juntos, y cuando el equipo operativo puede explicar, sin traductor, por qué el cliente sintió lo que sintió.

Antes de lanzar cualquier programa de este tipo, vale la pena diagnosticar qué tan preparada está la organización para sostenerlo: una evaluación de madurez de CX suele revelar si el problema real es la falta de mapas o la falta de gobierno sobre lo que esos mapas dicen.

El mapa no es el objetivo

Un mapa de journey sin proceso es un cuadro emocional sin explicación. Un mapa de proceso sin journey es un diagrama eficiente que puede estar optimizando exactamente lo que menos importa al cliente. La disciplina que separa a los equipos que mejoran la experiencia de los que solo la documentan es la costumbre de mirar ambos mapas al mismo tiempo, con los mismos datos, en la misma sala, con alguien que tenga autoridad para cambiar el proceso y no solo el discurso. Ese, y no el diagrama en sí, es el verdadero entregable. Si tu organización todavía trata el rediseño de diseño de servicios como un ejercicio narrativo separado de la operación que lo sostiene, el próximo journey map que dibujes va a describir, con precisión, el mismo problema que el anterior.