Medir la experiencia donde realmente ocurre.

Seamos honestos: la mayoría de las organizaciones no mide la experiencia de sus clientes. Mide el NPS y da por hecho que es lo mismo.

Así empezó todo para mí. Durante mucho tiempo, la experiencia llegaba a los stakeholders en dos números que siempre viajaban juntos: el NPS, "¿Qué tan probable es que nos recomiendes?", y a su lado una satisfacción general, "¿Qué tan satisfecho estás con nosotros?". Con ellos se celebraba o se buscaban culpables.

El problema es que ninguno de los dos habla de la experiencia. Uno mide una intención; el otro, una impresión general de la marca:

• Miden opinión declarada, no lo que el cliente vivió. Alguien puede recomendarte y decir que está satisfecho por tu tasa o tu marca, y al mismo tiempo odiar tu proceso.
• No dicen qué arreglar. Si bajan 8 puntos, no sabes si fue la app, la agencia, una comisión o la campaña de la competencia.
• El NPS esconde la distribución. Al restar detractores de promotores, dos realidades muy distintas pueden dar el mismo número.

Al final, eran dos números para toda la organización y ninguno para cada proceso. Si en un trimestre lanzas un nuevo onboarding, rediseñas la carga de documentos y cambias cómo se informa el estado de una solicitud, y la satisfacción sube 4 puntos, ¿cuál de los tres cambios lo logró? Nadie lo sabe. No hay granularidad.

Así que bajamos al nivel donde la experiencia realmente ocurre: el flujo. Empezamos a medir esfuerzo, tiempo, abandono y satisfacción en cada proceso. Ganamos detalle, pero creamos un problema nuevo: cuatro números que nadie relacionaba entre sí. En cada presentación a stakeholders llegaba la misma pregunta: "Entonces, ¿está bien o está mal?"

#Todo en un solo número

La respuesta que encontré fue juntarlas en un solo índice. No inventé ninguna métrica: todas existen hace años en UX y en analítica de producto. Lo que armé es una capa de síntesis encima, que llamé EXP Index: un número del 0 al 100 con una etiqueta al lado, algo como "74, Bueno". Me funciona porque cualquier stakeholder lo entiende sin que yo tenga que explicar qué es un CES, y quien quiera el detalle sigue teniendo las métricas debajo.

Lo mido al cerrar cada proyecto, para tener una línea base del flujo que entregamos, y después de forma continua, para ver si se mantiene o se va deteriorando.

Eso sí, no pretende medir negocio. Para eso ya están la conversión y la retención; el EXP Index va al lado de esas métricas, no en su lugar.

#Qué lo compone, y por qué no todo pesa igual

El esfuerzo pesa más que todo porque en procesos financieros la fricción es el principal enemigo. Un cliente que tuvo que pelear con un formulario no vuelve, aunque al final lo haya logrado.

El tiempo y el abandono suman la mitad del índice porque son las señales de comportamiento: no dependen de lo que el usuario opina, sino de lo que pasó. Dentro del tiempo, el end-to-end pesa un poco más que el tiempo activo porque, en procesos con aprobaciones, la espera suele ser lo que más se siente.

La satisfacción pesa menos porque en buena parte es consecuencia de lo demás. Si el proceso fue fácil, rápido y nadie lo abandonó, la satisfacción suele acompañar. Bajarle el peso es mi forma de no contar dos veces lo mismo, aunque no lo resuelve del todo (vuelvo a esto más abajo).

#Cómo se calcula

El cálculo tiene dos pasos: llevar los cinco componentes a la misma escala de 0 a 100, y luego aplicar los pesos.

#Paso 1: normalizar

Dos de las métricas se invierten, porque en ellas un número menor es mejor.

#Paso 2: ponderar

Un ejemplo con datos ficticios. Imagina un flujo de solicitud de préstamo en línea:

En lugar de cinco números que discutir, los stakeholders reciben uno: este flujo necesita atención. Y la tabla dice por dónde empezar a mirar: el esfuerzo es lo que más puntos resta, seguido de la espera end-to-end. Lo que no dice es por qué; para eso hay que ir a investigar.

#El tiempo de espera también cuenta

Esta es la parte que más discusión genera. Al principio lo metía todo en el TCT: lo que el usuario tarda frente a la pantalla y también lo que espera mientras alguien aprueba, revisa o valida algo del otro lado. Pero mezclarlo confunde, porque en UX el tiempo de tarea es el tiempo activo, no la espera. Así que hoy lo separo en dos: el TCT, que es el tiempo que el cliente pasa haciendo la tarea, y el E2E, que es todo lo que pasa hasta que obtiene su resultado.

Siempre aparece alguien que dice que eso es operación, no diseño. Puede ser, pero al cliente le da igual. Si llenó el formulario en 8 minutos y la respuesta le llegó a los 5 días, para él el trámite duró 5 días. Medir solo los 8 minutos es quedarse con la parte en la que salimos bien para la foto.

Además tiene un efecto secundario que me gusta: deja claro que la experiencia no depende solo de quien diseña las pantallas, sino de toda la organización.

Separarlos también lo vuelve más accionable. Si el TCT está bien pero el E2E está mal, el problema no está en la pantalla: está en la operación, en una aprobación manual o en un back office saturado. Y eso cambia a quién hay que sentar en la mesa.

#Cómo medimos el tiempo

Los dos tiempos se miden igual: contra un ideal y un máximo que se definen para cada flujo. La diferencia es qué se cuenta. El TCT va en minutos y solo corre mientras el cliente está haciendo algo. El E2E va en horas o días y corre desde que envía la solicitud hasta que tiene una respuesta, aunque en el medio no haga nada.

Si no tienes datos históricos, así los defino yo:

1. Mapear el flujo completo, paso a paso.
2. Estimar un tiempo razonable por paso.
3. Definir el T ideal como la suma sin fricciones: lo que tarda un usuario competente, no el mínimo absoluto.
4. Definir el T máx entre 2 y 3 veces el T ideal: el punto donde la experiencia ya es claramente crítica.
5. Validarlo con las primeras sesiones con usuarios y ajustar.

En un crédito con varias etapas, los dos tiempos quedarían algo así (las cifras son ilustrativas):

#Qué significa cada resultado

El número solo sirve si dice qué hacer. Por eso cada rango trae una acción asociada:

Y se mide en tres momentos: al cerrar el proyecto (línea base), de forma continua (para detectar degradación) y en cada iteración (para comprobar que el cambio realmente mejoró algo).

#Lo que el índice no hace

Primero, un 68 no es una verdad. Es lo que sale de esta fórmula, con estos pesos y estos benchmarks. Me sirve para ver si un flujo mejora o empeora con el tiempo, pero no como nota absoluta, y tampoco para comparar una apertura de cuenta con un crédito hipotecario: cada flujo tiene sus propios tiempos de referencia.

Segundo, los pesos no salen de un modelo estadístico. Salen de lo que como organización queremos impulsar en la experiencia: hoy, sobre todo, reducir el esfuerzo del cliente. Son una apuesta, y mi plan es revisarlos cuando tenga entre 3 y 6 meses de mediciones reales, para ver si esa apuesta se refleja en los resultados.

Tercero, los componentes se pisan entre sí. La fricción alarga el tiempo, el tiempo hace que la gente abandone y todo eso baja la satisfacción. Bajarle el peso al CSAT ayuda, pero en parte sigo contando lo mismo más de una vez.

Y lo más importante: el índice no te dice qué arreglar. Lo que te da es la salud de un flujo en particular: si algo anda mal y en qué componente. El porqué está en la investigación y en las entrevistas con usuarios, y eso no lo va a reemplazar ningún número. Por eso lo pienso como una capa más, cada una con su propia pregunta:

#Pruebalo con tus datos

#Demo

Armé una calculadora abierta para que cualquier equipo pueda probar el índice con sus propios números:

Si la usas, me encantaría saber qué pesos te funcionan a ti y en qué tipo de procesos. También en qué casos el índice se queda corto.