Co-diseño de servicios: por qué el cliente debe sostener el lápiz

En la mayoría de los talleres de mapeo de journeys que he facilitado, el cliente no está en la sala. Está representado por un post-it, una cita de una encuesta de hace ocho meses o la opinión del gerente de sucursal que "los conoce bien". El blueprint que sale de esa sala es elegante, está bien diseñado y describe, con precisión notable, cómo la organización cree que vive su cliente. Rara vez describe cómo vive realmente.

Esa brecha no se cierra con más investigación de mercado ni con paneles de validación al final del proceso. Se cierra invitando al cliente a diseñar, no solo a opinar. El co-diseño de servicios consiste en sentar a clientes reales junto a las personas que operan el servicio —agentes, procesos, sistemas— en el mismo taller, con las mismas herramientas, desde el primer boceto del journey hasta la última decisión sobre el blueprint. No es una ronda de feedback disfrazada de innovación. Es un cambio de quién sostiene el lápiz.

¿Qué es exactamente el co-diseño de servicios?

El co-diseño de servicios es un método en el que clientes, empleados de primera línea y equipos de diseño construyen juntos el journey map y el blueprint de un servicio, en sesiones estructuradas, en lugar de que un equipo interno diseñe primero y valide después. La diferencia no es cosmética: cambia quién define el problema, no solo quién opina sobre la solución propuesta.

Esta distinción importa porque la mayoría de los programas de gestión de feedback de clientes operan río abajo del diseño: preguntan qué tan bien funcionó algo que ya se decidió sin el cliente. El co-diseño opera río arriba. El cliente participa cuando el journey todavía es maleable, cuando cambiar una etapa completa cuesta una tarde de trabajo con post-its y no una migración de sistemas de seis meses.

¿Por qué fallan los blueprints diseñados sin el cliente en la sala?

Fallan porque confunden la lógica interna del proceso con la lógica mental del cliente, y esa confusión no se detecta hasta que el servicio ya está en producción. Un equipo de operaciones diseña un flujo de reclamaciones pensando en minimizar pasos internos; el cliente, mientras tanto, no está contando pasos: está evaluando si alguien lo está escuchando. Son dos mapas distintos del mismo momento, y solo uno de ellos importa para la satisfacción final.

He visto blueprints técnicamente impecables —cada touchpoint documentado, cada SLA definido— que colapsaban en el primer piloto porque el equipo de diseño asumió un job-to-be-done que el cliente nunca tuvo. En banca, por ejemplo, un equipo puede diseñar la apertura de cuenta asumiendo que el cliente prioriza la velocidad, cuando en realidad prioriza la sensación de control sobre sus datos. Sin el cliente en la sala, esa asunción nunca se cuestiona; se documenta como si fuera un hecho.

El resultado es lo que en journeys co-creados llamamos el "blueprint huérfano": un documento correcto en su arquitectura interna pero desconectado de la experiencia real, que la organización defiende con datos operativos mientras el cliente sigue quejándose de lo mismo.

¿Qué explica la economía del comportamiento sobre por qué la co-creación funciona mejor que la validación?

La respuesta corta: cuando alguien participa en construir algo, lo valora más de lo que valoraría el mismo objeto entregado terminado. Este fenómeno tiene nombre y evidencia empírica. En su estudio de 2012 "The IKEA Effect: When Labor Leads to Love", publicado en el Journal of Consumer Psychology, los investigadores Michael Norton (Harvard Business School), Daniel Mochon (entonces en Tulane University) y Dan Ariely (Duke University) demostraron que las personas asignan un valor sustancialmente mayor a objetos que ensamblaron ellas mismas —desde muebles de IKEA hasta figuras de origami— frente a versiones idénticas ya montadas.

Aplicado a servicios, el efecto IKEA no es un truco de marketing: es una explicación estructural de por qué los clientes que co-diseñan un journey lo defienden, lo recomiendan y toleran mejor sus fricciones residuales. No lo hacen porque el servicio co-creado sea objetivamente superior en cada detalle. Lo hacen porque una parte del esfuerzo y la identidad del cliente quedó incorporada en el diseño, y el efecto de dotación (endowment effect) hace que renunciar a algo en lo que uno invirtió esfuerzo se sienta como una pérdida, no como una simple sustitución de opciones.

Ya escribí sobre esta mecánica aplicada a la creación conjunta de experiencias en un análisis anterior sobre el efecto IKEA y la co-creación, y la conclusión se mantiene aquí: el co-diseño no solo produce mejores servicios, produce clientes que se sienten coautores de esos servicios. Esa es una ventaja de adopción que ningún cuestionario de satisfacción posterior puede replicar.

Un journey validado por el cliente es un journey que el cliente tolera. Un journey co-diseñado con el cliente es un journey que el cliente defiende.

¿Cómo se estructura un taller de co-diseño de servicios?

La estructura importa más que la creatividad espontánea. Un taller de co-diseño sin secuencia clara degenera en una sesión de quejas o en un ejercicio dominado por quien habla más alto. Esta es la secuencia que uso, adaptable en duración pero no en orden:

1. Reclutar la mezcla correcta de participantes. No basta con "clientes leales". Se necesita al menos un cliente que abandonó recientemente, uno nuevo y uno de alto valor, junto con el empleado de primera línea que vive el proceso a diario —no solo su gerente.
2. Anclar la sesión en un momento real, no en el servicio completo. Elegir un momento de la verdad concreto —una reclamación, una activación, una cancelación— y no "toda la experiencia del cliente", que es demasiado amplio para diseñar en una sesión.
3. Hacer que el cliente narre su journey actual con sus propias palabras antes de que el equipo interno muestre cualquier proceso documentado. Si el equipo presenta primero su versión, el cliente ajustará su relato para no contradecirla; es anclaje puro.
4. Construir el journey map en conjunto, sobre la misma superficie física o digital, marcando emociones, fricciones y momentos de esfuerzo directamente sobre la línea de tiempo, con el cliente sosteniendo el marcador tanto como el facilitador.
5. Traducir el journey a un borrador de blueprint con el equipo operativo presente, para que cada decisión de rediseño se confronte de inmediato con su viabilidad de back-office, procesos y sistemas.
6. Priorizar los rediseños con los propios clientes, usando un criterio simple de esfuerzo de cambio versus impacto percibido, en lugar de dejar la priorización final solo en manos internas.
7. Cerrar con compromisos verificables: qué se prueba, con quién, en qué plazo —nunca "tomamos nota de sus comentarios".

El paso que más se salta, por presión de tiempo, es el tercero. Y es el que más cuesta recuperar después: si el cliente no narra primero, el taller entero se convierte en una validación disfrazada de co-diseño.

¿Qué diferencia hay entre el journey map y el blueprint en un proceso co-creado?

El journey map co-creado documenta la experiencia desde la perspectiva del cliente: sus etapas, sus emociones, sus momentos de fricción y satisfacción. El blueprint co-creado añade la capa invisible —procesos, sistemas, roles y evidencia física— que sostiene esa experiencia por detrás del escenario. Ambos deben construirse en la misma conversación, porque un journey emocionalmente preciso pero operativamente inviable no sobrevive el primer trimestre de presupuesto.

La secuencia correcta es diseñar primero lo visible con el cliente, y luego, sin que él se retire de la sala, conectar cada fricción identificada con la línea de front-stage, back-stage y procesos de soporte del diseño de servicios. Cuando el equipo operativo escucha en tiempo real por qué un proceso interno genera una emoción negativa específica, deja de defender el proceso por inercia y empieza a rediseñarlo por evidencia. Es la diferencia entre un blueprint que documenta el statu quo y uno que lo cuestiona con el cliente presente para confirmar si la alternativa realmente resuelve algo.

El marco del Double Diamond, desarrollado por el Design Council del Reino Unido, describe esta misma lógica en cuatro fases —descubrir, definir, desarrollar, entregar— alternando divergencia y convergencia. La diferencia práctica del co-diseño de servicios es que el cliente no entra solo en la fase de "descubrir": permanece en la sala durante "desarrollar", que es donde normalmente se le excluye por comodidad operativa.

¿Qué errores arruinan un taller de co-creación?

Casi todos los talleres de co-diseño que he visto fracasar comparten uno de estos errores, y ninguno tiene que ver con falta de presupuesto o de herramientas:

• Reclutar solo a clientes satisfechos. Un panel sin detractores produce un journey map cómodo y falso; los mejores insumos vienen de quien estuvo a punto de irse.
• Dejar que un ejecutivo senior facilite su propia sesión. La jerarquía silencia a los clientes y a los empleados de primera línea por igual; el facilitador debe ser neutral respecto al resultado.
• Mostrar el proceso interno antes de escuchar el relato del cliente. Ya mencionado, pero merece repetirse porque es el error más frecuente y el más silencioso.
• Confundir participación con consenso. Co-diseñar no significa que todos deban estar de acuerdo; significa que las tensiones entre lo que el cliente necesita y lo que la operación puede sostener queden explícitas, no disueltas artificialmente.
• No volver con resultados. Si el cliente que invirtió una tarde en el taller nunca sabe qué pasó con sus ideas, la próxima invitación a co-diseñar será rechazada, y con razón.

Este último punto conecta con un problema más amplio de gobierno interno: muchos programas de co-creación fallan no en el taller, sino después, cuando nadie en la organización tiene el mandato de convertir lo co-diseñado en un roadmap ejecutado. Ya he documentado esta brecha de propiedad en un análisis sobre programas de CX cross-funcionales, y la conclusión aplica directamente aquí: el co-diseño sin gobernanza de seguimiento es teatro participativo.

¿Cómo se mide si el co-diseño realmente funcionó?

Se mide comparando dos cosas que casi nunca se comparan en el mismo informe: la tasa de adopción del rediseño y la persistencia de esa adopción seis meses después, no solo la puntuación de satisfacción inmediata tras el lanzamiento. El co-diseño exitoso no siempre produce el mayor salto en NPS el primer mes; produce el rediseño que la organización deja de tener que defender internamente porque el cliente y el equipo operativo ya coinciden en por qué existe.

Un segundo indicador, menos citado pero más revelador, es la tasa de participantes del taller que aceptan volver a participar en el siguiente ciclo de co-diseño. Si el cliente que co-creó un journey no quiere repetir la experiencia, algo se rompió entre el taller y la implementación —probablemente el cierre de ciclo que mencionábamos arriba.

Para organizaciones que quieren instalar el co-diseño como práctica recurrente y no como evento aislado, tiene sentido evaluar primero dónde está la madurez de la organización frente a la voz del cliente, usando algo como una evaluación de madurez de CX antes de comprometer presupuesto a un programa de talleres. Diseñar en conjunto con el cliente exige una organización capaz de tolerar que el cliente cuestione decisiones ya tomadas; sin esa capacidad instalada, el taller produce ideas que nadie ejecuta.

El economista y profesor de marketing Venkat Ramaswamy, junto con C. K. Prahalad, planteó ya en el año 2000, en su artículo "Co-opting Customer Competence" publicado en Harvard Business Review, que la próxima fuente de ventaja competitiva no vendría de la eficiencia interna sino de la competencia acumulada de los propios clientes cuando se les invita a co-crear valor. Más de dos décadas después, esa tesis sigue subestimada en la mayoría de los programas de estrategia de voz del cliente, que todavía tratan al cliente como fuente de datos y no como fuente de diseño.

El cliente que diseña no es un riesgo, es una garantía

La resistencia habitual al co-diseño es interna, no del cliente: a los equipos les incomoda ceder control sobre decisiones que consideran técnicas. Pero el cliente que ayudó a construir el blueprint no exige perfección; exige coherencia con lo que él mismo ayudó a definir. Esa es una barra más baja y más sostenible que la que impone un cliente que descubre, ya en producción, un servicio diseñado sin su participación.

La organización que institucionaliza el co-diseño no lo hace por generosidad hacia el cliente. Lo hace porque ha entendido que el esfuerzo compartido en el diseño se convierte en tolerancia compartida en la operación, y esa tolerancia vale más, a largo plazo, que cualquier journey map perfecto dibujado a puerta cerrada. El próximo blueprint que su organización rediseñe merece, al menos, una silla vacía menos en la sala.