Gestión de programas de CX multifuncionales

Un programa de CX transversal no muere por falta de patrocinio ejecutivo. Muere porque nadie es dueño de la pérdida cuando algo sale mal, y todo el mundo reclama el mérito cuando algo sale bien. Esa asimetría —pura aversión a la pérdida en términos de Kahneman y Tversky— es la razón silenciosa por la que la mayoría de las iniciativas de experiencia de cliente se diluyen entre marketing, operaciones y tecnología antes de cumplir dos años.

La tesis es sencilla y algo incómoda: los programas de CX no fallan por falta de voluntad, fallan por diseño de gobernanza. Se gestionan como proyectos con fecha de cierre, cuando deberían gestionarse como un sistema operativo permanente con presupuesto propio, derechos de decisión explícitos y una cadencia de revisión que no dependa de la buena voluntad de nadie. Un programa de CX transversal es, por definición, una estructura que coordina decisiones y recursos de varias funciones —producto, operaciones, marketing, tecnología, atención al cliente— alrededor de journeys que ninguna de ellas controla por completo. Y ahí está el problema de origen: se le pide a una estructura sin autoridad formal que produzca resultados que sí requieren autoridad formal.

¿Por qué fracasan los programas de CX transversales?

Fracasan porque se diseñan como coordinación voluntaria en lugar de como gobernanza con dientes. Cuando el "dueño" de la experiencia de cliente es un comité, un consejo consultivo o un patrocinador ejecutivo que aparece en el kickoff y desaparece en la ejecución, cada función interpreta la CX según su propio incentivo: marketing la lee como campaña, operaciones como eficiencia, tecnología como backlog. El resultado no es sabotaje deliberado. Es la consecuencia previsible de pedir alineación sin dar autoridad.

El dato que mejor ilustra esta brecha entre intención y ejecución sigue siendo el de Bain & Company, que en su estudio de 2005 Closing the Delivery Gap encontró que el 80% de las empresas creía que ofrecía una experiencia superior, mientras que solo el 8% de sus clientes estaba de acuerdo. Veinte años después, la brecha no ha cerrado porque el problema nunca fue de intención: fue de estructura. Nadie puede entregar lo que nadie tiene mandato de decidir.

¿Qué es exactamente un programa de CX transversal?

Un programa de CX transversal (cross-functional) es el conjunto de journeys, métricas, rituales de decisión y presupuesto que atraviesan varias funciones organizativas con el objetivo de mejorar la experiencia en momentos que ninguna función controla de punta a punta. Un journey de reclamación bancaria, por ejemplo, pasa por atención al cliente, cumplimiento, tecnología y a veces legal. Ninguna de esas áreas puede arreglarlo sola, y esa es precisamente la razón por la que el programa existe.

La confusión habitual es tratar esto como un ejercicio de mapeo. El service blueprint, la técnica que documenta procesos front-stage y back-stage detrás de un journey, es una herramienta necesaria pero no suficiente. Mapear sin gobernar produce diagramas hermosos que nadie actualiza a los seis meses porque no hay un mecanismo que obligue a las funciones a revisarlos, priorizarlos y financiarlos juntas.

¿Por qué la falta de patrocinio ejecutivo no es el verdadero problema?

Porque casi todos los programas de CX que he visto colapsar tenían un patrocinador ejecutivo con buenas intenciones y un discurso convincente en el town hall. Lo que no tenían era un mecanismo de decisión que sobreviviera a la ausencia de ese patrocinador en una reunión concreta de priorización de presupuesto.

Aquí opera la aversión a la pérdida de forma muy literal. Cuando un programa transversal pide a un director de operaciones que ceda presupuesto, personas o prioridad de sprint para financiar una mejora que beneficiará sobre todo a la métrica de otra función, esa cesión se percibe como pérdida cierta hoy a cambio de un beneficio incierto —y compartido— mañana. La investigación clásica de Kahneman y Tversky sobre la teoría prospectiva, publicada en 1979 en Econometrica, mostró que las personas valoran las pérdidas casi el doble que las ganancias equivalentes. Aplicado a la política interna: nadie regala su presupuesto para que otra área se lleve el crédito por la mejora del NPS.

Un patrocinador ejecutivo sin autoridad de reasignación de presupuesto no es gobernanza. Es un cargo honorífico con acceso a un dashboard.

La solución no es pedir más entusiasmo. Es diseñar la estructura para que las decisiones de recursos no dependan de la generosidad de nadie en un momento dado.

¿Cómo se diseña un modelo de gobernanza que sobreviva a la política departamental?

Un modelo de gobernanza de CX transversal funciona cuando define, por escrito, quién decide qué, con qué presupuesto y con qué frecuencia de revisión —antes de que surja el primer conflicto entre funciones, no durante él. Estos son los elementos que en la práctica marcan la diferencia entre un programa que sobrevive al segundo año y uno que se disuelve en la reorganización siguiente:

1. Definir el journey como unidad de gobierno, no la función. El comité que decide sobre el journey de onboarding debe tener representación de cada función que toca ese journey, con un solo responsable final de la métrica extremo a extremo —no un responsable por tramo.
2. Asignar presupuesto al journey, no a la iniciativa. Mientras el dinero viva en los silos funcionales, cada mejora transversal competirá contra las prioridades internas de esa función y perderá. Un presupuesto propio para el journey convierte la coordinación en decisión, no en súplica.
3. Establecer derechos de decisión explícitos (RACI real, no decorativo). Quién aprueba un cambio de proceso, quién lo veta, quién solo es consultado. Sin esto, cada desacuerdo escala al comité más alto disponible, que es la forma más lenta y más cara de resolver un problema operativo.
4. Fijar una cadencia de revisión que no dependa de crisis. Revisiones trimestrales de journey performance, con datos, no solo revisiones cuando un cliente se queja en redes sociales. La gobernanza reactiva enseña a la organización que la CX solo importa cuando hay incendio.
5. Vincular el bono o la evaluación de cada función líder a al menos una métrica compartida del journey. Este es el paso que casi nadie da y el que más cambia el comportamiento. Si el incentivo sigue siendo 100% funcional, la coordinación seguirá siendo cosmética.

Este enfoque de gobernanza es, en esencia, lo que desarrollamos con clientes bajo un modelo de estrategia de gobernanza de CX: no un comité más, sino una arquitectura de decisión con presupuesto y autoridad reales.

¿Qué rol debe tener la oficina de programa de CX (CX PMO)?

La oficina de programa de CX debe operar como un centro de coordinación con autoridad delegada, no como un equipo de reporting que produce dashboards que nadie usa para decidir. Su función principal no es "hacer CX" —eso lo hacen las líneas de negocio— sino garantizar que las decisiones que afectan a journeys compartidos se tomen con los datos correctos, en el foro correcto, con la persona correcta en la sala.

En la práctica, una oficina de programa de CX bien diseñada hace tres cosas que ninguna función aislada puede hacer por sí sola:

• Mantiene el inventario vivo de journeys críticos y sus métricas de salud, de forma que ninguna función pueda decir "no sabíamos que ese journey estaba roto".
• Arbitra la priorización entre journeys en competencia por el mismo presupuesto de mejora, aplicando un criterio consistente —impacto en retención, en coste de servicio, en riesgo regulatorio— en lugar de la urgencia de quien grite más fuerte esa semana.
• Convierte hallazgos de voz del cliente e investigación en iniciativas con dueño, plazo y presupuesto, cerrando el ciclo entre "sabemos que esto duele" y "esto ya se está arreglando".

Cuando este rol no existe, lo que suele pasar es que la función de tecnología termina decidiendo prioridades de CX por defecto, simplemente porque controla el backlog. No es mala fe: es vacío de gobernanza llenado por quien tiene el control operativo más cercano.

¿Cómo se evita el sludge de gobernanza que frena la ejecución?

Se evita distinguiendo, de forma deliberada, entre la fricción que protege una decisión importante y el sludge que solo protege el statu quo de alguien. Richard Thaler acuñó el término "sludge" para describir la fricción administrativa innecesaria que retrasa una acción deseable; Cass Sunstein lo desarrolló después como el reverso oscuro del nudge en su análisis de 2019 sobre fricciones administrativas, Sludge and Ordeals, publicado en el Duke Law Journal. En un programa de CX transversal, el sludge más habitual es el comité que existe para aprobar, no para decidir: la reunión mensual donde se presenta el mismo dashboard, nadie objeta, nadie aprueba nada concreto y la iniciativa vuelve a la cola.

Tres señales delatan sludge de gobernanza en un programa de CX:

• Las decisiones requieren la firma de más de tres personas que no estuvieron en la discusión original.
• El mismo caso de negocio se presenta más de dos veces en foros distintos antes de recibir presupuesto.
• Existe un comité de CX, pero las decisiones reales de recursos se toman fuera de él, en conversaciones bilaterales que el comité solo ratifica después.

La corrección no es eliminar toda fricción —cierta fricción protege contra decisiones impulsivas y mal fundamentadas—, sino reservarla para las decisiones que realmente la necesitan y eliminarla de las que no. Este es también el terreno donde la gestión del cambio se vuelve inseparable de la gobernanza: no basta con rediseñar el comité, hay que rediseñar los hábitos de decisión de las personas que se sientan en él.

¿Qué métricas usar para gestionar el programa como un P&L?

Se gestionan con métricas que combinan salud de la experiencia con impacto financiero, revisadas con la misma disciplina que un estado de resultados —no con un NPS trimestral aislado que nadie conecta a una decisión de inversión. El NPS, el CSAT y el CES son útiles como termómetro, pero son insuficientes como base de gobernanza porque no dicen qué journey priorizar ni cuánto vale arreglarlo.

Un programa maduro combina al menos estas tres capas de medición:

• Salud del journey: métricas de fricción y abandono en los pasos críticos, no solo satisfacción al final.
• Impacto en el negocio: retención, coste de servicio evitado, valor de vida del cliente asociado a ese journey.
• Salud de la gobernanza misma: tiempo medio desde que se identifica un problema hasta que recibe presupuesto, porcentaje de iniciativas de journey que se completan frente a las que se abandonan sin cierre.

Esta tercera capa es la que casi ningún programa mide, y es la que mejor predice si el programa seguirá existiendo en dos años. Para equipos que necesitan construir el caso de negocio ante finanzas, una calculadora de ROI de CX ayuda a traducir mejoras de journey en cifras que un comité de asignación de capital pueda comparar con cualquier otra inversión de la casa.

¿Cómo se gestiona el cambio cuando cada función habla un idioma distinto?

Se gestiona traduciendo la misma decisión a los términos que cada función ya usa para priorizar, en lugar de pedirle a todas que adopten un vocabulario de CX que perciben como ajeno. Operaciones piensa en coste por transacción. Tecnología piensa en capacidad de sprint. Marketing piensa en conversión y marca. Ninguna de estas funciones va a abandonar su marco mental porque un programa de CX lo pida; el trabajo de quien lidera el programa es demostrar cómo la misma mejora de journey resuelve el problema de cada una en su propio idioma.

Aquí el sesgo de afecto —la tendencia descrita por Kahneman a juzgar una opción por cómo nos hace sentir antes que por un análisis frío— explica por qué las presentaciones que abren con datos agregados de NPS generan menos compromiso que las que abren con la grabación de un cliente real describiendo la fricción exacta que ese equipo puede resolver. La emoción de escuchar a un cliente real activa el compromiso; los datos lo sostienen después. Por eso los programas que integran evidencia directa de voz del cliente en cada revisión de journey logran una adopción más rápida que los que solo circulan reportes trimestrales.

Sobre este terreno, tres prácticas de cambio marcan la diferencia:

1. Nombrar campeones de journey dentro de cada función, con tiempo protegido explícitamente asignado —no como tarea adicional sobre su carga actual.
2. Celebrar y comunicar las victorias tempranas del programa en el lenguaje de cada función afectada, no en un boletín genérico de "logros de CX".
3. Revisar la carga de coordinación real de los equipos involucrados; la investigación de Rob Cross, Reb Rebele y Adam Grant publicada en enero de 2016 en Harvard Business Review bajo el título Collaborative Overload mostró que una proporción creciente del tiempo de los empleados se consume en actividades colaborativas, y que ese tiempo tiende a concentrarse en un pequeño grupo de personas sobrecargadas —exactamente el perfil de quien suele terminar siendo "campeón de journey" sin descarga de otras responsabilidades.

¿Qué hacer cuando el programa pierde tracción a mitad de camino?

Cuando un programa de CX transversal pierde tracción en el mes seis u ocho, casi siempre es porque el efecto de gradiente de meta —la tendencia a acelerar el esfuerzo cerca de una meta visible y a relajarlo cuando la meta parece lejana o difusa— trabaja en contra del programa en lugar de a favor. Los hitos trimestrales genéricos ("mejorar la experiencia de onboarding") no generan ese impulso; los hitos específicos y visibles sí ("reducir de cinco a dos los pasos de verificación antes del 30 de noviembre").

La corrección práctica es dividir cada iniciativa del roadmap en hitos que un equipo pueda ver acercarse, no en fases abstractas. Un roadmap de implementación de CX bien construido no es una lista de proyectos con fecha de fin: es una secuencia de hitos visibles que mantiene el gradiente de meta trabajando a favor del equipo, semana tras semana, en lugar de depender de un gran relanzamiento anual que nadie recuerda en marzo.

Antes de rediseñar cualquier estructura de gobernanza, conviene diagnosticar en qué nivel de madurez está realmente el programa: muchos comités de CX se rediseñan sin haber confirmado primero si el problema es de estructura, de datos o de cultura. Una evaluación de madurez de CX evita el error común de aplicar una solución de gobernanza avanzada a una organización que todavía no tiene los datos básicos para sostenerla.

Lo que se sostiene después de que se apaga el entusiasmo inicial

Todo programa de CX transversal arranca con energía prestada: un patrocinador entusiasta, un kickoff bien producido, una promesa de que esta vez será distinto. Esa energía dura, en el mejor de los casos, dos trimestres. Lo que sobrevive después no es el entusiasmo. Es la estructura que se diseñó mientras el entusiasmo todavía estaba disponible para financiarla.

La pregunta que vale la pena hacerse no es si la organización cree en la experiencia de cliente —casi todas dicen que sí—, sino si alguien, concretamente, pierde algo cuando el journey no mejora. Si la respuesta es "nadie en particular", el programa ya tiene fecha de caducidad, aunque el dashboard siga verde un poco más de tiempo. Diseñar esa pérdida compartida, con presupuesto, autoridad y cadencia reales, es el trabajo silencioso que separa a los programas de CX que se recuerdan de los que solo se archivan.

Si está evaluando cómo estructurar o rescatar un programa de CX que cruza varias funciones en su organización, el punto de partida honesto es revisar la estrategia de experiencia de cliente con la misma exigencia con la que revisaría cualquier otra línea de inversión del negocio.