Modelo de madurez del cliente

Un modelo de madurez del cliente es un mapa por etapas de qué tan profundamente una cuenta usa tu producto — típicamente crawl, walk, run — que un equipo de CS usa para definir la siguiente acción correcta de cada cliente y para temporizar la expansión. No es un health score (el health te dice el riesgo ahora mismo; la madurez te dice qué tan lejos ha llegado la cuenta hacia el valor total) y no es lo mismo que el customer journey (el journey es la secuencia de momentos del ciclo de vida; la madurez es la profundidad de adopción dentro de ellos). El modelo existe para responder una pregunta sobre cada cuenta del book: ¿cuál es la única cosa de mayor impacto que este cliente debería hacer a continuación?

El framework crawl / walk / run

Define cada etapa por comportamiento observable del producto y un outcome que el cliente ha alcanzado — no por cuánto tiempo lleva siendo cliente. El tiempo es un proxy débil; una cuenta de seis meses atascada en una feature es menos madura que una cuenta de seis semanas que usa el workflow central a diario.

• Crawl — onboardeada y en vivo. El cliente completó el setup, el admin principal hace login y al menos un workflow central corre con éxito. La amplitud de adopción es una o dos features; el uso es superficial y manejado por el admin. El trabajo de CS aquí es el time-to-first-value: lleva la cuenta a su primer outcome real, no a la amplitud de features.
• Walk — adoptada en un equipo. El workflow central es habitual para un equipo o caso de uso. El uso activo semanal es constante, una segunda feature está en juego y el cliente puede describir el valor con sus propias palabras. El trabajo de CS es profundizar y documentar el outcome para que sobreviva a un cambio de champion, y luego encontrar el siguiente equipo.
• Run — embebida y en expansión. Múltiples equipos o casos de uso dependen del producto, el uso es diario entre roles y la cuenta lo trata como infraestructura. El trabajo de CS pasa de la adopción a la expansión y la advocacy: nuevos seats, nuevos módulos, renovación multianual, referencias.

Calibrando las puertas de etapa

Las etapas genéricas son relleno. Calibra cada puerta con dos o tres umbrales medibles que puedas sacar del product analytics (Pendo, Amplitude) o de tu plataforma de CS (Gainsight, Vitally, Planhat). Un ejemplo trabajado para una herramienta de colaboración:

Elige los umbrales de tus propios datos: toma tu cohorte de mejor retención y mayor NRR, mira qué amplitud y profundidad alcanzaron antes de expandir, y fija la puerta de Run justo debajo de eso. Las puertas son específicas del producto — copiar los números de otra empresa anula el propósito.

Usar la madurez para impulsar la expansión

La madurez es una regla de ruteo para plays, no un dashboard de vanidad. Mapea cada etapa al único play que mueve la cuenta hacia adelante:

• Las cuentas Crawl reciben un play de adopción, nunca un upsell. Vender seats a una cuenta que no alcanzó el first value es cómo manufacturas churn — compran más de algo que aún no usan, y luego fallan ambas renovaciones. Guard: la motion de expansión está deshabilitada para cualquier cuenta debajo de la puerta de Walk.
• Las cuentas Walk reciben un play de profundizar y aterrizar un segundo equipo. Aquí se crea el pipeline de expansión, no se cierra — una cuenta Walk que suma un segundo equipo se está graduando sola a Run.
• Las cuentas Run reciben el play de expansión. La dependencia multi-equipo más una profundidad mayor a 50% es la señal de expansión más fuerte que tienes; correlaciona con el NRR mucho mejor que la antigüedad o el valor del contrato. Temporiza la conversación de upsell al momento en que una cuenta cruza la puerta de Run, no al calendario de renovación.

El beneficio compuesto: la madurez le da a RevOps un pipeline de expansión pronosticable. El conteo de cuentas en la puerta de Walk este trimestre es un indicador adelantado de cuentas elegibles para expansión el próximo trimestre.

Errores comunes

• Confundir madurez con health. Una cuenta en etapa Run puede estar no saludable (el champion se acaba de ir) y una cuenta Crawl puede estar perfectamente saludable (en curso, solo temprana). Guard: trackea ambos, y nunca dejes que una etapa de madurez alta suprima una alerta de riesgo de churn.
• Etapas basadas en tiempo. “90 días = Walk” no es un modelo de madurez; es un calendario. Guard: cada puerta se define por un umbral de producto o un outcome, nunca solo por tiempo transcurrido.
• Puertas sin democión. Las cuentas retroceden — un reorg mata al champion, el uso cae. Guard: recomputa la etapa con la misma cadencia que el health (semanal es típico) para que una cuenta que cae debajo del umbral de profundidad de Walk regrese y vuelva a entrar al play de adopción.
• Hacer upsell a cuentas Crawl. Cubierto arriba; es el error más caro que el modelo está diseñado para prevenir.

Cuándo el framework se rompe

Tres etapas son demasiado gruesas para productos con una superficie de adopción larga (una plataforma con veinte módulos necesita sub-etapas dentro de Run) y demasiado finas para productos transaccionales o de una sola feature donde “en vivo” es el único estado significativo. Calibra el número de etapas a tu superficie de adopción, no a la convención crawl/walk/run. Para pricing basado en uso, la madurez y el revenue se mueven juntos automáticamente, así que el play de expansión es menos sobre una motion de ventas y más sobre quitar fricción del uso más profundo.

Relacionados

• NRR vs GRR — las métricas de retención que la madurez busca mover
• Gainsight — plataforma de CS para scorear y etapar cuentas
• Vitally — plataforma de CS manejada por uso del producto
• Pendo — product analytics para calibrar las puertas de etapa