El dashboard de soporte dice 98% de tickets resueltos dentro del SLA. El dashboard de producto dice que la feature X tiene 64% de adopción. Las métricas se ven sanas. Después una revisión trimestral revela que los customer effort scores están cayendo, el NPS está derivando hacia abajo y el equipo de soporte está silenciosamente manejando las mismas cinco preguntas cientos de veces al mes. Ambos dashboards eran técnicamente correctos. A ambos les faltaba la foto.

Mayuri Dekate lo llama friction debt: el coste acumulado de fricción recurrente del usuario que se resuelve a nivel ticket pero nunca se arregla a nivel producto. Como la deuda técnica, no rompe nada individualmente. Como la deuda técnica, compone silenciosamente hasta que limita todo.

Cuando la resolución parece éxito

Resolución y mejora no son lo mismo. Un ticket de soporte se cierra cuando el problema inmediato del usuario se resuelve. La causa subyacente del problema normalmente permanece. El siguiente usuario choca contra la misma fricción, abre un ticket similar, recibe una resolución similar. El sistema se siente como funcionando porque cada ticket tiene respuesta. El producto está acumulando deuda en silencio.

La resolución no es lo mismo que la mejora. Cuando confundes las dos, empiezas a acumular lo que llamo friction debt.

Qué ve soporte que producto a menudo se pierde

Los equipos de soporte se sientan sobre la fuente más concentrada de datos de fricción de producto en la empresa. Cada ticket es una señal pequeña: esta cosa confundía, esta cosa no funcionaba como esperaba, esta cosa le costó al usuario más de lo que debía. Las señales se quedan en la herramienta de soporte porque el equipo de producto está ocupado mirando métricas de adopción y uso de features.

El gap es estructural. Las analíticas de producto miden comportamiento (¿el usuario clickó?). Los tickets de soporte capturan comprensión (¿el usuario entendió en qué clickar?). Los dos responden preguntas distintas, y la mayoría de equipos de producto optimizan por la primera ignorando la segunda.

Por qué los dashboards te dan falsa confianza

Métricas comunes que ocultan friction debt:

  • % de adopción de feature. Cuenta quién usó la feature. No cuenta quién intentó y falló.
  • DAU/WAU. Cuenta usuarios activos. No cuenta usuarios que se volvieron activos a pesar de la fricción (y que churnarán más rápido).
  • Tiempo en página. Cuenta engagement. No distingue engagement de confusión.
  • Tasa de resolución de tickets. Cuenta tickets cerrados. No cuenta el mismo problema apareciendo 200 veces.
  • NPS promediado trimestralmente. Suaviza los patrones de fricción visibles en los verbatims de detractores.

Ninguna de estas métricas está mal. Son insuficientes. Sin señal complementaria de patrones de soporte, crean una historia de salud que la experiencia vivida del usuario contradice.

El gap de fricción, ilustrado

Imagina que un producto lanza una feature nueva. Analíticas del día 1:

  • Adopción de feature: 42% en la semana 1 (genial)
  • Duración media de sesión: arriba 8% (genial)
  • Métrica de activación: alcanza objetivo (genial)

Mientras tanto, en soporte:

  • 67 tickets en la semana 1 con variaciones de "activé la feature pero no pasó nada"
  • Resolución: respuesta de 4 minutos explicando el paso adicional que nadie sabía
  • Tasa de cierre de tickets: 100%

Los dashboards dicen éxito. Soporte está manejando confusión diaria. El producto técnicamente funciona pero está enseñando silenciosamente a los usuarios que este equipo envía cosas que necesitan explicación. Dos trimestres después, esto es la friction debt que explica por qué el NPS cayó y por qué el siguiente lanzamiento aterriza más plano.

La fricción silenciosa es más peligrosa que el fallo ruidoso

Una feature que crashea genera una avalancha de tickets, atención de liderazgo y un arreglo rápido. Una feature que confunde genera un goteo lento de tickets, ninguno de los cuales parece urgente individualmente, y un decaimiento a largo plazo en la confianza. El crash se arregla en una semana. La confusión se acumula durante meses.

Por eso la fricción silenciosa es la peligrosa. No dispara los sistemas que arreglan cosas. Dispara los sistemas que cierran tickets uno por uno para siempre.

Cómo reducir realmente la friction debt

1. Hacer de soporte un input del roadmap, no una función separada

Una vez al mes, el lead de soporte presenta los top 10 patrones recurrentes de tickets al equipo de producto. No métricas agregadas. Patrones específicos: "23 tickets este mes sobre confusión en el paso 4 del onboarding". Cada patrón entra a consideración del roadmap con el mismo peso que una petición de feature de ventas.

2. Definir y trackear friction debt explícitamente

Añade una lista de friction debt al roadmap, paralela al backlog de features. Cada ítem nombra un patrón recurrente, el volumen de tickets que genera y el arreglo propuesto a nivel producto. Trátalo como deuda técnica: asigna capacidad trimestral a pagarla.

3. Dejar de celebrar solo métricas de resolución

Las métricas del equipo de soporte deberían incluir "reducción en patrones recurrentes de tickets" junto a "tiempo de resolución". Un equipo de soporte que resuelve el mismo problema 100 veces está haciendo trabajo heroico en un sistema que les está fallando. Mide el éxito por problemas que dejaron de recurrir, no solo por tickets cerrados.

4. Usar transcripciones de soporte en las revisiones de producto

Una vez al trimestre, el equipo de producto lee 30 transcripciones de soporte en grupo. No métricas sobre transcripciones. Transcripciones reales. Detecta el lenguaje que usan los usuarios, los puntos donde aparece confusión, los momentos donde se rinden. Esta sola práctica cambia más decisiones de roadmap que cualquier dashboard de analíticas.

5. Auditar lanzamientos a 30 y 90 días por señal de fricción

La métrica de lanzamiento no debería ser solo "¿alcanzó la adopción el X%?". Debería ser "¿alcanzó la adopción el X% sin generar volumen Y de tickets de confusión?". Un lanzamiento que adopta bien pero crea un patrón crónico de soporte no fue un éxito limpio.

Para llevar

Los tickets resueltos no significan un producto sano. Significan un equipo de soporte competente sosteniendo la línea contra la fricción de producto acumulándose. La friction debt debajo de la superficie es la que ralentiza el siguiente año de crecimiento. El arreglo es estructural: hacer de los patrones de soporte un input del roadmap, trackear friction debt explícitamente, medir problemas recurrentes junto a velocidad de resolución, leer transcripciones en equipo y auditar lanzamientos por patrones de confusión. Las métricas que parecen sanas dejan de ser tu foto completa. El producto que emerge es el que los usuarios disfrutan usar, no el que los dashboards dicen que está bien.