Operational excellence in service delivery

Un cliente no experimenta un organigrama. Experimenta el tiempo que tarda una aprobación, el número de veces que repite su historia y el silencio entre el paso 3 y el paso 4 de un proceso que nadie diseñó pensando en él. La experiencia que se siente en el mostrador, en la app o en el call center es, casi siempre, el residuo visible de una operación invisible.

Esa es la tesis que defiendo después de años levantando procesos con equipos que juraban tener "todo mapeado": la excelencia operativa no es una disciplina de eficiencia interna que corre en paralelo a la experiencia del cliente. Es su cimiento. Cuando la operación falla —un traspaso mal definido, una regla de negocio contradictoria, un sistema que no habla con otro— la experiencia no se degrada un poco. Se rompe exactamente en ese punto, y el cliente lo siente como un problema de servicio, aunque el origen esté tres departamentos más atrás.

¿Qué es la excelencia operativa en la prestación de servicios?

La excelencia operativa en servicios es la capacidad de una organización de ejecutar sus procesos internos con la consistencia, velocidad y calidad suficientes para que el cliente nunca perciba la complejidad que hay detrás. No es "hacer las cosas más rápido" a cualquier precio: es diseñar el back office con la misma intención con que se diseña el front stage, sabiendo que ambos son la misma experiencia vista desde dos ángulos.

Esto exige abandonar una separación artificial que persiste en muchas organizaciones: la CX como función de marca y comunicación, y las operaciones como función de costo y control. En la práctica, cada bottleneck operativo tiene un correlato emocional en el cliente: frustración, desconfianza, esfuerzo percibido. Y cada mejora operativa bien diseñada tiene un correlato en retención. Frederick Reichheld y W. Earl Sasser lo documentaron hace más de tres décadas en su artículo "Zero Defections: Quality Comes to Services", publicado en Harvard Business Review en septiembre-octubre de 1990: mejoras relativamente pequeñas en la tasa de retención de clientes generan incrementos desproporcionados en la rentabilidad, precisamente porque el costo de servir mal —reprocesos, escalamientos, compensaciones— es mucho mayor que el costo de servir bien la primera vez.

La excelencia operativa no reduce costos porque haga las cosas más baratas. Las reduce porque elimina la necesidad de arreglar lo que se hizo mal la primera vez.

¿Por qué el customer journey se rompe en el mapa de procesos, no en el touchpoint?

Cuando un equipo de CX diagnostica un journey roto, suele mirar el touchpoint: la pantalla confusa, el guion del agente, el tiempo de espera. Son síntomas reales, pero rara vez son la causa raíz. La causa suele vivir un nivel más abajo, en el diseño del proceso que alimenta ese touchpoint: quién aprueba qué, con qué información, en qué sistema, y qué pasa cuando falta un dato.

He visto journeys de apertura de cuenta bancaria rediseñados con un blueprint impecable en el front, mientras el proceso de verificación de documentos en el back office seguía dependiendo de un correo electrónico reenviado manualmente entre dos áreas que no comparten sistema. El cliente experimenta esa fricción como "el banco es lento". El banco lo experimenta como "un problema de operaciones que no es nuestro problema de CX". Ambos están describiendo el mismo hecho desde trincheras distintas, y mientras sigan sin hablarse, el journey seguirle roto por más talleres de co-creación que se hagan sobre el mapa visible.

Por eso el service design serio siempre trabaja en dos capas simultáneas: el front stage que el cliente ve, y el back stage que lo sostiene. Un blueprint de servicio que solo documenta la interacción visible es un mapa incompleto; documenta la mitad del sistema y omite exactamente la mitad donde suelen originarse los defectos.

¿Dónde se esconden los cuellos de botella que nadie ve?

Los bottlenecks operativos rara vez están donde el organigrama dice que deberían estar. Están en las costuras: los puntos donde un proceso cruza de un sistema a otro, de un equipo a otro, de un canal a otro. Tres patrones aparecen con una regularidad casi predecible en los procesos de servicio que auditamos:

• El traspaso ciego. Un caso pasa de un equipo a otro sin contexto: el segundo equipo repite preguntas que el cliente ya respondió, y el cliente concluye —correctamente— que nadie se está comunicando internamente.
• La excepción convertida en regla. Un proceso se diseñó para el caso estándar, pero el 30% de los casos reales son excepciones que ese diseño no contempla. Cada excepción termina resuelta manualmente por la persona más senior disponible, que se convierte en el cuello de botella humano de toda la operación.
• El dato que no viaja. La información existe en algún sistema de la empresa, pero no llega al punto donde se necesita, así que se le vuelve a pedir al cliente. Cada vez que un cliente repite un dato que la empresa ya tiene, la organización está cobrando —en esfuerzo del cliente— por su propia desorganización interna.

Ninguno de estos tres patrones aparece en un dashboard de satisfacción. Aparecen en un mapa de proceso levantado con las personas que realmente ejecutan el trabajo, no con las que lo diseñaron en una sala de reuniones hace tres años.

¿Cómo el "sludge" operativo erosiona la experiencia sin que nadie lo note?

Richard Thaler introdujo una distinción útil dentro de la economía del comportamiento: no toda fricción es igual. Existe la fricción que protege —una verificación de seguridad antes de una transferencia grande— y existe el sludge: fricción innecesaria, generalmente administrativa, que no protege a nadie y solo existe porque nunca se rediseñó el proceso que la produce. Un formulario que pide el mismo dato tres veces, una aprobación que necesita cuatro firmas para algo de bajo riesgo, un proceso de reembolso que exige visitar una sucursal para un trámite que podría resolverse en una app: eso es sludge operativo.

La razón por la que el sludge sobrevive tanto tiempo dentro de las organizaciones es puramente operativa, no maliciosa. Nadie diseña sludge a propósito. Se acumula porque cada nueva regla de control, cada nuevo sistema heredado, cada nueva política de compliance se agrega sobre el proceso existente sin que nadie vuelva a mirar el conjunto. El resultado es un proceso que en su origen tenía sentido y que, veinte capas después, es incomprensible incluso para quienes lo operan todos los días.

Desde el lado del cliente, el sludge se percibe como falta de respeto por su tiempo. Y aquí el sesgo de aversión a la pérdida —descrito por Daniel Kahneman y Amos Tversky— juega en contra de la empresa: el cliente no valora simétricamente el tiempo ganado con el tiempo perdido. Diez minutos ahorrados en un proceso rápido generan agradecimiento moderado; diez minutos perdidos en un proceso lento generan una queja desproporcionada. La operación ineficiente no solo cuesta tiempo: cuesta más reputación de la que su duración objetiva justificaría.

¿Cómo se diagnostica una operación antes de rediseñarla?

El error más común al abordar la excelencia operativa es empezar por la solución: automatizar, reorganizar equipos, comprar un nuevo sistema. La secuencia correcta empieza siempre por el descubrimiento —entender el proceso como realmente ocurre, no como el manual dice que ocurre—. La metodología que uso con los equipos de operaciones sigue una secuencia deliberada:

1. Levantar el proceso real, no el documentado. Se observa el trabajo en curso —shadowing de agentes, revisión de tickets reales, seguimiento de casos de punta a punta— porque el proceso escrito en el manual de calidad casi nunca coincide con el proceso que la gente ejecuta bajo presión.
2. Mapear el journey y el proceso en paralelo. Cada etapa del journey del cliente se cruza con el paso operativo que la sostiene, identificando qué sistema, qué rol y qué decisión hay detrás de cada momento visible.
3. Cuantificar la fricción, no solo describirla. Tiempo de ciclo, tasa de reprocesos, número de traspasos, volumen de excepciones. Sin números, cada bottleneck es una opinión; con números, es una prioridad objetiva.
4. Separar la fricción que protege de la que solo estorba. Antes de eliminar un paso, hay que entender por qué existe. Eliminar un control real por velocidad es tan peligroso como conservar un control inútil por costumbre.
5. Rediseñar desde el momento de verdad hacia atrás. En lugar de optimizar cada paso por separado, se rediseña el proceso completo empezando por el momento que más impacto emocional tiene para el cliente, y se ajusta todo lo anterior para sostenerlo.
6. Pilotar, medir, escalar. Ningún rediseño operativo se despliega a ciegas en toda la organización. Se prueba en un segmento acotado, se mide el efecto real sobre tiempo de ciclo y experiencia, y solo entonces se escala.

Este es, en esencia, el trabajo de customer experience hecho desde la trinchera operativa: no se trata de imaginar una experiencia ideal y esperar que la operación se ajuste sola, sino de rediseñar la operación con la experiencia como criterio explícito de decisión, no como una consecuencia accidental.

¿Qué papel juega la excelencia operativa en la recuperación del servicio?

Ningún proceso es perfecto para siempre. Los sistemas fallan, los picos de demanda desbordan la capacidad planeada, los proveedores externos incumplen. La pregunta relevante no es si la operación fallará alguna vez, sino qué tan bien está diseñada la organización para recuperarse cuando eso ocurra.

Aquí entra el peak-end rule que Daniel Kahneman describió en su trabajo sobre la psicología del juicio y la memoria: las personas no recuerdan una experiencia como un promedio de todos sus momentos, sino, sobre todo, por su punto más intenso y por cómo termina. Esto tiene una implicación operativa muy concreta: una falla en el proceso no destruye automáticamente la relación con el cliente si la recuperación —el "end"— está bien diseñada. Un proceso de compensación rápido, claro y sin fricción adicional puede convertir un incidente en una prueba de que la empresa responde bien bajo presión, que es, paradójicamente, una de las señales de confianza más fuertes que existen.

Por eso una estrategia de escalamiento bien diseñada no es un parche de atención al cliente: es una pieza central de la arquitectura operativa. Define quién decide, con qué autoridad y en qué tiempo, cuando el proceso estándar no resuelve el caso. Las organizaciones que tratan la recuperación de servicio como un proceso de segunda categoría —resuelto ad hoc por quien esté disponible— pierden sistemáticamente la oportunidad de convertir sus peores momentos en los más memorables por las razones correctas.

¿Cómo se sostiene la excelencia operativa en el tiempo?

Rediseñar un proceso una vez es relativamente fácil. Sostener la disciplina operativa después de que el proyecto termina y el consultor se fue es lo difícil, y es donde la mayoría de las iniciativas de transformación se erosionan silenciosamente en seis o doce meses. Tres condiciones separan a las organizaciones que sostienen la mejora de las que la pierden:

• Propiedad clara del proceso, no solo del resultado. Alguien concreto debe responder por el tiempo de ciclo y la tasa de reprocesos de cada proceso crítico, no solo por el NPS que ese proceso afecta.
• Medición operativa conectada a la medición de experiencia. Si el dashboard de operaciones y el dashboard de CX viven en sistemas distintos que nadie cruza, la organización perderá la capacidad de ver la relación causal entre ambos justo cuando más la necesita.
• Gobernanza que revisa el proceso, no solo lo ejecuta. Un proceso necesita un ritual periódico de revisión —trimestral, no anual— donde se pregunte explícitamente si sigue teniendo sentido, o si ya acumuló sludge que nadie limpió.

Una estrategia de gobernanza de CX sólida incluye precisamente este mecanismo: un espacio institucional donde operaciones y experiencia se sientan a mirar los mismos datos, en lugar de descubrir el problema por caminos separados y culparse mutuamente cuando el cliente se queja. Herramientas como una evaluación de madurez de CX ayudan a poner esa conversación sobre una base objetiva, mostrando en qué building blocks operativos la organización todavía improvisa y en cuáles ya tiene procesos maduros y medibles.

La operación es la experiencia que nadie diseñó a propósito

La distancia entre una empresa que promete una gran experiencia y una que la entrega casi nunca se explica por la calidad de su estrategia de marca. Se explica por si alguien, en algún momento, se sentó a mirar el proceso completo —del primer clic a la última firma— y decidió diseñarlo con la misma intención que se diseña una campaña. Las organizaciones que ganan en experiencia no tienen procesos más simples por casualidad. Los simplificaron a propósito, sabiendo exactamente qué fricción protegía algo real y cuál solo sobrevivía por inercia.

Ese es el trabajo que sostiene todo lo demás en customer experience: sin una operación diseñada con intención, cualquier promesa de marca es una expectativa que el back office se encargará de romper. Si quieres empezar a ver dónde se está rompiendo la tuya, el primer paso no es rediseñar el journey visible: es conversar con quienes entienden dónde vive realmente el proceso, antes de que el cliente tenga que descubrirlo por ti.