Customer Success y alineación con Producto

Este es el escenario que convierte una decisión de producto sencilla en una crisis de retención: una funcionalidad utilizada por el 4% de las cuentas, pero de la que dependen tres de los diez clientes más importantes. Producto decide retirarla. El coste de mantenimiento es desproporcionado respecto al uso, una capacidad más moderna tiene más sentido desde el punto de vista arquitectónico y el 96% de las cuentas no notará su ausencia. La decisión tiene sentido sobre el papel.

Entonces se envía el aviso de 30 días. CS se entera la misma semana que los clientes. Los clientes que dependen de la funcionalidad no son el 4% de usuarios ocasionales. Son quienes construyeron flujos de trabajo a su alrededor, capacitaron a sus equipos en ella y, en algunos casos, la integraron mediante API. Son también quienes tienen un ARR que representa un porcentaje significativo de su cartera de renovaciones. Escalan el problema. Customer Success (CS) gestiona llamadas sin lenguaje aprobado, sin playbook de migración y sin entender cuándo se tomó la decisión ni por qué. Este es un caso de manual para la gestión de clientes en riesgo. Las cuentas con mayor probabilidad de abandono tras una retirada son las mismas que debían estar en una lista de vigilancia antes de que saliera el aviso.

El abandono que sigue no es inevitable. Es el resultado de un fallo de proceso: CS se incorporó demasiado tarde.

Por Qué se Retiran las Funcionalidades, y por Qué Importa para la Comunicación

La razón por la que se retira una funcionalidad determina cómo debe CS enmarcar la conversación con los clientes. Equivocarse en la razón, o utilizar una explicación genérica, hace que la comunicación parezca corporativa y desconectada de la experiencia real del cliente. El marco de retirada de producto de Gartner utiliza las "6M" (mensaje, motivo, significado, mitigación, migración y método) precisamente porque cada razón de retirada exige un enfoque diferente en las seis dimensiones.

Deuda técnica: La funcionalidad cuesta más mantener de lo que justifica su uso. El enfoque honesto es: "Estamos redirigiendo los recursos de ingeniería para construir capacidades que sirvan a más clientes." Esto es defendible y los clientes que entienden la economía de los productos SaaS lo aceptarán, si se dice de forma directa.

Pivote estratégico: El producto se mueve en una dirección en la que la funcionalidad no encaja. Los clientes pueden percibir que el producto se aleja de sus necesidades. CS debe poder explicar la dirección estratégica en términos que importen al cliente: ¿qué significa el pivote para las capacidades que más utilizan? ¿Qué se está construyendo en su lugar?

Consolidación: Una nueva funcionalidad sustituye a dos antiguas, pero el reemplazo no es equivalente. Este es el escenario más peligroso para CS, porque "hemos construido algo mejor" a menudo no es cierto desde la perspectiva del cliente individual. Si la nueva funcionalidad no admite su caso de uso específico, la consolidación es una pérdida neta para ellos. Sea honesto al respecto.

Cumplimiento normativo o seguridad: La funcionalidad se ha convertido en un riesgo. Esta es la razón más fácil de comunicar porque es externa, no una preferencia de producto, sino un requisito. Los clientes comprenden el cumplimiento normativo. Puede que no les guste, pero aceptarán una explicación clara.

Cada una de estas razones requiere una primera línea diferente en la conversación con el cliente. El lenguaje genérico del tipo "siempre estamos mejorando" no sirve para ninguna de ellas. Sin embargo, el patrón que produce los peores resultados no es solo un mensaje equivocado. Es un proceso equivocado.

Datos Clave: Retirada de Funcionalidades y Riesgo de Retención

El 79% del abandono de clientes B2B SaaS vinculado a la descontinuación de funcionalidades es prevenible con la participación temprana de CS en el proceso de retirada, según la investigación de retención de clientes de Gainsight.

Las empresas que notifican a los clientes sobre la descontinuación de funcionalidades con más de 90 días de antelación registran tasas de abandono 3,2 veces menores entre las cuentas afectadas en comparación con las que dan 30 días de aviso, según los datos de referencia de ChurnZero.

Las cuentas en periodo de renovación en el momento de la retirada de una funcionalidad tienen una probabilidad de abandono 2,7 veces mayor que las cuentas que no están en renovación, a menos que reciban una conversación de migración proactiva de su CSM, según el análisis de retención de Totango.

El Patrón de Desalineación

El patrón que produce los peores resultados de retención es constante entre empresas. También es una de las señales de alerta en 8 señales de advertencia de desalineación CS-Producto: cuando CS recibe una copia del correo al cliente al mismo tiempo que los clientes lo reciben, la relación ya está rota a nivel de proceso.

Producto toma la decisión de retirada en una reunión de roadmap, sin participación de CS
Legal u operaciones de producto redacta el aviso de descontinuación
CS recibe copia del correo cuando se envía a los clientes (simultáneamente, no antes)
Los CSMs reciben escalaciones de clientes sin lenguaje aprobado ni contexto de producto
Las cuentas en riesgo no se identifican hasta las conversaciones de renovación, lo que es entre 30 y 90 días demasiado tarde
Los CSMs individuales negocian extensiones informales o soluciones provisionales que sientan precedentes que nadie tenía intención de crear

El proceso correcto invierte esto por completo: CS participa antes de que se finalice la decisión de retirada, las cuentas en riesgo se identifican antes de que salga cualquier comunicación externa, y los CSMs reciben un briefing con lenguaje aprobado antes de que se produzca la primera conversación con el cliente.

Paso 1: Identificar Quién Depende de la Funcionalidad

Este es el paso que debe ocurrir antes de fijar el calendario de retirada, no después.

La distinción que importa es uso frente a dependencia. Un cliente que usó una funcionalidad una vez en el último año es un usuario. Un cliente que construyó un flujo de trabajo a su alrededor, la utiliza en un proceso repetible o la ha integrado mediante API depende de ella. Estos son perfiles de riesgo completamente diferentes.

Los datos de uso indican quién la ha utilizado. El análisis de producto puede mostrar qué cuentas han usado la funcionalidad en los últimos 90 días, la frecuencia de uso y si el uso ha aumentado o disminuido. Esto es necesario pero no suficiente.

Los datos de dependencia indican quién no puede prescindir de ella. CS conoce cosas que los datos de producto no muestran: qué clientes mencionaron esta funcionalidad en QBRs, quiénes han preguntado sobre ella en tickets de soporte, quiénes han capacitado a sus equipos en ella. Esta es la inteligencia que CS aporta a la conversación de retirada y que Producto no tiene a partir de métricas de uso.

El proceso de aportación de CS antes de la retirada debería ser: Producto comparte el candidato a retirada con el liderazgo de CS. Los líderes de CS tienen entre 5 y 7 días hábiles para revisar los registros de clientes, las notas de QBR y el historial de soporte, y devolver una lista de cuentas clasificadas por riesgo. Nivel 1 (alta dependencia, alto ARR) requiere contacto personal proactivo de su CSM antes de que salga cualquier correo. Nivel 2 (dependencia moderada) recibe el correo de descontinuación con un seguimiento del CSM en las 48 horas siguientes. Nivel 3 (dependencia baja o nula) recibe el correo estándar de descontinuación. Realizar una revisión conjunta de cuentas en riesgo con Ventas antes de que salgan las comunicaciones de retirada ayuda a identificar qué cuentas de Nivel 1 también tienen conversaciones de expansión abiertas que deben protegerse por separado.

Esta clasificación solo funciona si CS tiene acceso a los datos correctos. La puntuación de impacto en el cliente formaliza este proceso mediante la construcción de un marco repetible para cuantificar qué cuentas están más expuestas a cualquier cambio de producto, no solo a las retiradas.

Qué significa "dependencia" en la práctica:

La funcionalidad está referenciada en los criterios de éxito documentados
La mencionaron en un QBR o revisión de salud en los últimos 12 meses
Tienen una integración API que usa la funcionalidad
Han enviado un ticket de soporte sobre ella en los últimos 90 días
La puntuación de salud en CS tiene alguna correlación con el uso de esta funcionalidad

Paso 2: Fijar el Calendario de Retirada

¿Cuánto aviso es suficiente? La respuesta honesta es: depende del grado de dependencia de las cuentas afectadas y de la facilidad de la migración. La investigación de Gartner sobre prevención del abandono concluye que el 60% de los compradores de software que cancelan contratos lo hacen a causa de una decisión de compra que lamentaron posteriormente, y las migraciones forzadas de funcionalidades sin aviso suficiente son un desencadenante clásico de ese arrepentimiento.

Un marco útil de partida:

Nivel de dependencia	Dificultad de migración	Aviso mínimo
Bajo (uso ocasional, sin integración en flujo de trabajo)	Fácil (migración en un clic)	30 días
Moderado (uso regular, migración manual)	Moderada (requiere configuración)	60 días
Alto (crítico para el flujo de trabajo, integración API)	Difícil (requiere trabajo personalizado o solución alternativa)	90-120 días
Crítico (proceso de negocio central construido sobre ella)	Muy difícil o sin vía directa	120+ días, con calendario negociado para cuentas específicas

La tensión entre Producto y CS en cuanto al calendario es normal. Producto quiere moverse rápido: la deuda técnica tiene un coste, y cuanto más tiempo permanezca activa la funcionalidad descontinuada, más esfuerzo de ingeniería consume. CS quiere más tiempo porque las conversaciones de migración requieren tiempo, y forzar a una cuenta de alto ARR a una migración comprimida crea riesgo de abandono.

La aportación de CS en la conversación sobre el calendario no es un veto. Pero sí es una señal de riesgo necesaria. El formato correcto: "Aquí están las tres cuentas que consideramos con mayor riesgo de abandono por esta retirada, su ARR, sus fechas de renovación y nuestra evaluación de la dificultad de migración. En base a esto, recomendamos una ventana de 90 días en lugar de 30." Eso no es pedir más tiempo porque el cambio sea difícil. Es construir un caso de negocio con el ARR adjunto.

La distinción entre descontinuación y fecha de corte definitiva también importa. Un aviso de descontinuación dice: "Esta funcionalidad no estará disponible después de [fecha]." Una fecha de corte definitiva es la fecha de aplicación real. Para las cuentas de alta dependencia, considere si el aviso de descontinuación y la fecha de corte definitiva necesitan estar separados por más del periodo de aviso estándar. Algunas empresas ofrecen a las cuentas enterprise una extensión negociada, pero esto debe gestionarse con cuidado (véanse los anti-patrones más adelante).

Paso 3: Comunicación, Qué, Cuándo y Quién

Quién da la noticia:

Para las cuentas de Nivel 1 (alto ARR, alta dependencia), el CSM da la noticia en una conversación en directo: una llamada específica, no un correo. El CSM llama a la cuenta, explica la situación, y el correo de descontinuación sigue como confirmación escrita de lo hablado. El cliente no debe ver el correo antes de hablar con su CSM.

Para las cuentas de Nivel 2, el correo de descontinuación va primero, seguido de un contacto del CSM en las 48 horas siguientes. La tarea del CSM en ese seguimiento es entender el impacto e iniciar la conversación de migración.

Para las cuentas de Nivel 3, el correo de descontinuación es la comunicación principal. CS gestiona las preguntas entrantes conforme llegan.

Qué incluye el mensaje:

La funcionalidad que se retira, descrita con claridad (no solo su nombre interno)
La razón, en lenguaje sencillo (véanse las cuatro razones anteriores)
La fecha efectiva, incluyendo tanto la fecha del aviso de descontinuación como la fecha de corte definitiva
Qué la sustituye, si hay algo, con una descripción honesta de si el reemplazo es equivalente
Qué soporte de migración está disponible: documentación, sesiones específicas, soporte de ingeniería para migraciones de API
Con quién contactar para preguntas

Qué no incluye el mensaje:

Disculpas que impliquen que la decisión fue errónea ("Lamentamos los inconvenientes que esto pueda ocasionar" señala arrepentimiento por la decisión, no empatía hacia el cliente)
Plazos vagos ("en algún momento de los próximos meses" no da a los clientes nada con qué planificar; merecen una fecha específica)
Alternativas no solicitadas que el cliente no pidió ("¡También podría usar nuestra nueva herramienta de informes!" suena a intento de venta durante un anuncio negativo)
Optimismo corporativo en el encuadre ("¡Estamos entusiasmados por simplificar nuestra plataforma!" no cae bien cuando se pide a los clientes que cambien sus flujos de trabajo)

Plantillas de comunicación para tres escenarios:

Escenario A: Funcionalidad que se retira con reemplazo directo "[Nombre de la funcionalidad] se retirará el [fecha]. Hemos construido [reemplazo] para atender la misma necesidad, y creemos que es una base más sólida para [caso de uso principal]. [El reemplazo] gestiona [función específica] de [manera específica]. Hemos preparado documentación de migración y nuestro equipo está disponible para sesiones de migración específicas. Póngase en contacto con su CSM para programar una."

Escenario B: Funcionalidad que se retira sin reemplazo directo "[Nombre de la funcionalidad] se retirará el [fecha]. Esta funcionalidad no está siendo sustituida por un equivalente único. [Explicación honesta del motivo.] Según cómo lo utiliza su equipo, creemos que [solución alternativa o enfoque alternativo] puede atender su necesidad principal. Su CSM se pondrá en contacto esta semana para entender su situación específica y asegurarse de que tiene un camino a seguir."

Escenario C: Funcionalidad que se retira por cumplimiento normativo o seguridad "[Nombre de la funcionalidad] se retirará el [fecha]. Esta decisión es requerida por [normativa/requisito de seguridad] y afecta a todos los clientes. Entendemos que esto requiere ajustes por su parte. [Vía de migración]. Su CSM se pondrá en contacto para ayudarle a gestionar la transición."

Paso 4: La Conversación de Migración

Cuando existe una funcionalidad de reemplazo: No asuma que el reemplazo es mejor para cada cliente. Dígalo explícitamente: "La nueva capacidad gestiona [X] de forma diferente. Para la mayoría de los clientes es una mejora, pero quiero entender su flujo de trabajo específico antes de hablar de migración." Este enfoque es más honesto y produce mejores resultados de migración porque se identifican las brechas antes de que el cliente las descubra. El playbook de estrategia de adopción de funcionalidades se aplica aquí. Migrar clientes a una funcionalidad de reemplazo requiere el mismo enfoque estructurado de adopción que lanzar una nueva, no solo una notificación puntual.

Cuando no existe reemplazo directo: CS puede ofrecer tres cosas: documentación de soluciones alternativas, soporte de configuración personalizada y visibilidad del roadmap sobre lo que se está construyendo y que podría atender la necesidad subyacente en el futuro. Lo que CS no puede ofrecer es la promesa de que el reemplazo llegará pronto, a menos que esté confirmado de forma veraz en el nivel apropiado.

Cuando un cliente dice que la vía de migración no funciona para su caso de uso: Esta es una conversación de Producto, no solo de CS. La tarea del CSM en ese momento es capturar la brecha específica y escalarla a Producto: "Nuestro cliente en [empresa] tiene una dependencia en [capacidad específica] que el reemplazo no cubre. Esto es lo que necesitan. ¿Podemos tener una llamada de 30 minutos con el PM para discutirlo?" Si el resultado es una adaptación del producto, un calendario negociado o una solución provisional documentada es una decisión de Producto. Pero el CSM es quien lo pone frente a las personas adecuadas.

Paso 5: Gestión del Riesgo de Retención

La zona roja: Cuentas que dependen de la funcionalidad retirada y que están en periodo de renovación. Estas cuentas necesitan recibir noticias de su CSM antes de que salga el aviso de descontinuación, y el CSM necesita un plan de retención para cada una antes de que se produzca cualquier comunicación externa. La formación del cliente es una palanca clave en ese plan. Las guías de migración que abordan los puntos de confusión más comunes reducen significativamente las escalaciones de soporte durante una ventana de transición.

El plan de retención no tiene que ser complejo. Necesita responder a: cuál es la vía de migración de la cuenta, cuál es el calendario, quién en el lado de CS es responsable de llevarlo a término, y cuál es la escalación si el cliente señala que está considerando la retirada como razón para no renovar.

Lo que el liderazgo de CS presenta a Producto antes de cualquier retirada que afecte a las cuentas de mayor ARR:

Antes de finalizar una retirada, el liderazgo de CS debe presentar a Producto: una lista ordenada de las 10 cuentas más afectadas por ARR, sus fechas de renovación, su nivel de dependencia y la dificultad estimada de migración. Esto no es una solicitud de veto. Es un briefing de riesgo empresarial. La información modifica el cálculo de riesgo del equipo de Producto sobre el calendario de retirada y si ciertas cuentas necesitan un tratamiento personalizado.

Extensiones negociadas: Ofrecer a una cuenta específica de alto ARR más tiempo del que tiene la ventana de aviso estándar puede ser la decisión correcta. Pero debe gestionarse con cuidado. Una extensión informal sienta un precedente que todas las demás cuentas afectadas descubrirán eventualmente. Si se amplía para una cuenta, decida a nivel directivo si la extensión está disponible para todas las cuentas de Nivel 1 o solo para esta, y documente esa decisión.

Retroalimentar los resultados de retención a Producto: Tras completar la retirada, realice un seguimiento de lo que ocurrió con las cuentas afectadas. ¿Cuántas migraron con éxito? ¿Cuántas abandonaron? ¿Cuántas requirieron excepciones o negociaciones? Esos datos pertenecen a una retrospectiva con Producto, y deben informar el proceso para la próxima retirada, incluido cuánto aviso es apropiado y con qué antelación debe incorporarse CS. La investigación de HBR sobre retención de clientes sostiene que el coste de perder a los clientes adecuados es casi siempre mayor de lo que aparece en las métricas de abandono, lo que convierte los datos de retención post-retirada en uno de los insumos más infrautilizados en la planificación de producto.

Anti-Patrones

Ocultar la retirada en las notas de lanzamiento y esperar que nadie lo note. Algunos clientes no lo notarán durante meses. Pero los clientes que dependen de ella lo notarán de inmediato, y se sentirán sorprendidos porque no recibieron aviso previo. Los que no lo notaron estarán bien. Los que lo notaron y no fueron informados son su riesgo de abandono.

Ofrecer una solución provisional personalizada que CS tendrá que soportar indefinidamente. En la conversación de migración, la tentación es resolver el problema inmediato del cliente con una solución que solo funciona para su caso específico. Esa solución se convierte entonces en una obligación de soporte indefinida. Cualquier solución provisional que CS ofrezca en una migración de retirada debe ser revisada por Producto en cuanto a su escalabilidad. Si requiere esfuerzo continuo de CS para mantenerse, no es una solución provisional, sino una adaptación permanente que nadie acordó.

Dar a los clientes enterprise extensiones informales de plazo que sientan precedente. "Lo mantendremos activo para usted hasta el final de su año de contrato," dicho informalmente por un CSM en una llamada de retención, crea una obligación que Producto no ha aceptado, que ingeniería tiene que mantener y que otros clientes acabarán escuchando y solicitando para ellos mismos. Las extensiones deben pasar por el liderazgo de CS y obtener el visto bueno explícito de Producto.

Enmarcar la retirada como "noticias emocionantes" en el correo de comunicación. Los clientes a los que se pide que cambien sus flujos de trabajo no están entusiasmados. Lenguaje como "estamos encantados de avanzar nuestra plataforma retirando [funcionalidad]" señala una desconexión entre cómo ve el proveedor el cambio y cómo lo vive el cliente. Sea directo. La noticia es lo que es.

El Checklist Conjunto CS-Producto para la Retirada

Antes de que se finalice la decisión de retirada:

CS ha revisado los datos de uso y ha devuelto una evaluación de riesgo de dependencia para las cuentas afectadas
Las cuentas en periodo de renovación han sido identificadas y marcadas
El liderazgo de CS ha presentado a Producto las cuentas de mayor ARR en riesgo
El calendario de retirada se ha fijado con la aportación de CS sobre la dificultad de migración

Antes de que salga la comunicación externa:

Las cuentas de Nivel 1 han sido contactadas por su CSM en una conversación en directo
Las plantillas de comunicación aprobadas están listas y revisadas por Producto y Legal
El briefing de CSMs se ha completado: cada CSM conoce la razón de la retirada, la vía de migración y el lenguaje aprobado
La vía de escalación está definida para las cuentas que rechacen la vía de migración

Durante la ventana de migración:

Seguimiento semanal entre CS y Producto sobre el progreso de migración de las cuentas de Nivel 1
Las brechas de producto identificadas en las conversaciones de migración han sido escaladas a Producto
Las solicitudes de extensión de cuentas enterprise han sido revisadas por el liderazgo de CS y han recibido el visto bueno explícito de Producto

Tras completar la retirada:

Los resultados de retención de todas las cuentas afectadas han sido documentados
Se ha realizado una retrospectiva con CS y Producto para capturar qué funcionó y qué no
Las mejoras de proceso para futuras retiradas se han acordado y documentado

La pregunta de quién es responsable de los cambios orientados al cliente y de las notas de lanzamiento está directamente vinculada a este checklist. La claridad en la propiedad de los entregables de comunicación es lo que hace que cada paso se ejecute a tiempo en lugar de quedar atrapado en el espacio entre CS y Producto. Y para las cuentas donde la retirada expone un patrón más amplio de necesidades no atendidas, el proceso de cierre del ciclo de retroalimentación es donde esas ideas van para producir una mejora permanente en cómo se toman las decisiones de producto.

El Playbook de Retirada en 5 Pasos

El Playbook de Retirada en 5 Pasos nombra las cinco fases de un proceso conjunto CS-Producto para la retirada de funcionalidades. Los pasos se ejecutan en secuencia, y omitir cualquiera de ellos es la fuente más común de abandono prevenible por retirada.

Paso 1: Identificación de dependencias. Antes de fijar el calendario de retirada, CS revisa los datos de uso y los registros de clientes para distinguir usuarios de dependientes. Devuelve una lista de cuentas clasificada por riesgo: Nivel 1 (alta dependencia, alto ARR), Nivel 2 (dependencia moderada), Nivel 3 (dependencia baja o nula). Este paso debe ocurrir antes de planificar cualquier comunicación externa.

Paso 2: Fijación del calendario. CS y Producto acuerdan la ventana de aviso usando la matriz dependencia-migración (30 días para migraciones fáciles de baja dependencia; 90-120 días para cuentas de alta dependencia con integración API; 120+ días con calendarios negociados para dependencias críticas de flujo de trabajo). La aportación de CS no es un veto. Es una señal de riesgo con el ARR adjunto.

Paso 3: Diseño de la comunicación. Tres plantillas distintas para tres escenarios (existe reemplazo, no existe reemplazo, retirada por cumplimiento normativo). Las cuentas de Nivel 1 reciben una llamada en directo del CSM antes de que salga cualquier correo. Las cuentas de Nivel 2 reciben el correo seguido del contacto del CSM en 48 horas. Las cuentas de Nivel 3 reciben el correo estándar. Las plantillas son revisadas por Producto y Legal antes de que cualquier cliente las vea.

Paso 4: Conversaciones de migración. Soporte de migración cuenta por cuenta, con una vía de escalación clara cuando la vía de migración no cubre el caso de uso específico del cliente. Cualquier solución provisional ofrecida debe ser revisada por Producto en cuanto a su escalabilidad antes de convertirse en una obligación de soporte permanente.

Paso 5: Seguimiento de retención y retrospectiva. Tras la retirada: documente cuántas cuentas afectadas migraron con éxito, cuántas abandonaron o cuántas requirieron excepciones negociadas. Realice una retrospectiva con CS y Producto. Retroalimente los resultados en el proceso para la próxima retirada.

Análisis de Rework: El fallo de proceso más constante en la retirada de funcionalidades no es la plantilla de comunicación ni la duración del aviso. Es el Paso 1. Las empresas que omiten el paso de identificación de dependencias tratan a todas las cuentas afectadas de la misma manera, lo que significa que las cuentas de alto ARR con integración API reciben el mismo correo de 30 días que los usuarios ocasionales. Los datos sobre esto son claros: las empresas que notifican a los clientes con más de 90 días de antelación registran tasas de abandono 3,2 veces menores entre las cuentas afectadas en comparación con las que dan 30 días de aviso (datos de referencia de ChurnZero). Pero la duración del aviso es solo parte del resultado. Las cuentas que reciben una llamada en directo proactiva de su CSM antes de que llegue el correo tienen resultados de retención significativamente mejores que las que reciben el correo primero, independientemente de la duración del aviso. El Paso 1 es el que indica qué cuentas necesitan la llamada. Sin él, todas las cuentas reciben el correo.

Preguntas Frecuentes

¿Qué es el Playbook de Retirada en 5 Pasos?

El Playbook de Retirada en 5 Pasos es un proceso conjunto CS-Producto para retirar funcionalidades sin perder las cuentas que dependen de ellas. Los cinco pasos son: identificación de dependencias (antes de fijar el calendario), fijación del calendario (con la aportación de CS sobre la dificultad de migración), diseño de la comunicación (tres plantillas, clasificadas por dependencia de la cuenta), conversaciones de migración (con una vía de escalación clara para las brechas) y seguimiento de retención con una retrospectiva post-retirada. Las organizaciones que utilizan un proceso formal de retirada con corresponsabilidad CS-Producto reportan resultados de retención un 44% mejores entre las cuentas afectadas en comparación con las que utilizan comunicación improvisada, según los datos de experiencia del cliente de TSIA.

¿Cuánto aviso deben recibir los clientes antes de que se retire una funcionalidad?

La duración del aviso debe corresponderse con el nivel de dependencia y la dificultad de migración. El mínimo es de 30 días para funcionalidades de baja dependencia con migraciones fáciles. Las cuentas de alta dependencia (con integraciones API o uso crítico para el flujo de trabajo) necesitan entre 90 y 120 días. Las cuentas con procesos de negocio críticos construidos alrededor de la funcionalidad pueden necesitar más de 120 días y un calendario negociado. Las empresas que notifican a los clientes con más de 90 días de antelación registran tasas de abandono 3,2 veces menores entre las cuentas afectadas en comparación con las que dan 30 días de aviso, según los datos de referencia de ChurnZero. La forma más fiable de fijar el calendario adecuado es completar el paso de identificación de dependencias antes de que se finalice el calendario.

¿Por qué la mayoría de los procesos de retirada de funcionalidades producen abandono de clientes?

La mayor parte del abandono por retirada es prevenible y resulta de un único fallo estructural: CS se incorpora al mismo tiempo que se notifica a los clientes, o después. Solo el 38% de los equipos de producto incorporan formalmente a CS antes de finalizar un calendario de retirada, según el estudio Estado de la Gestión de Producto de ProductBoard. Cuando CS se entera de la retirada la misma semana que los clientes, los CSMs no tienen lenguaje aprobado, ni playbook de migración, ni manera de identificar qué cuentas tienen mayor riesgo antes de que llegue la primera llamada de escalación. El Playbook de Retirada en 5 Pasos invierte esto: CS participa antes de que se finalice la decisión, las cuentas clasificadas por riesgo se identifican antes de que salga cualquier comunicación externa, y los CSMs reciben el briefing antes de que se produzca cualquier conversación con el cliente.

¿Cuál es la diferencia entre un usuario y un dependiente a efectos de retirada de funcionalidades?

Un usuario es cualquier cuenta que ha utilizado la funcionalidad en los últimos 90 días. Un dependiente es una cuenta que ha construido un flujo de trabajo a su alrededor, la utiliza en un proceso repetible o la ha integrado mediante API. Estos son perfiles de riesgo completamente diferentes para una retirada. El análisis de producto identifica a los usuarios; el conocimiento de CS identifica a los dependientes. Los indicadores de dependencia son: la funcionalidad aparece en los criterios de éxito documentados, la cuenta la mencionó en un QBR en los últimos 12 meses, hay una integración API que la usa, o hay un ticket de soporte sobre ella en los últimos 90 días. El paso de identificación de dependencias combina ambas fuentes de datos para producir la lista de cuentas clasificada por riesgo.

¿Cómo deben comunicar los CSMs la retirada de una funcionalidad a las cuentas de alto ARR?

Para las cuentas de Nivel 1 (alto ARR, alta dependencia), el CSM da la noticia en una conversación en directo antes de que salga el correo de descontinuación. El cliente no debe ver el correo antes de hablar con su CSM. La conversación cubre: qué se retira y cuándo, la razón en lenguaje sencillo, qué lo sustituye (si hay algo, con una evaluación honesta de si el reemplazo es equivalente) y qué soporte de migración está disponible. El correo de seguimiento sirve como confirmación escrita de lo hablado. Esta secuencia (llamada en directo primero, correo segundo) es lo que distingue una retirada gestionada de una notificación en crisis.

¿Qué debe hacer CS cuando un cliente dice que la vía de migración no funciona para su caso de uso?

Escalar a Producto de inmediato con datos concretos: la empresa, el ARR, la capacidad específica que el reemplazo no cubre y lo que el cliente necesita. No prometa una adaptación de producto ni un calendario. Esas son decisiones de Producto. La tarea del CSM es poner a las personas adecuadas en la conversación antes de que el cliente tome una decisión de renovación basada en un problema que CS no puede resolver solo. Cualquier solución provisional que CS ofrezca en una conversación de migración debe ser revisada por Producto en cuanto a su escalabilidad: si requiere esfuerzo continuo de CS para mantenerse, no es una solución provisional, sino una adaptación permanente que nadie acordó formalmente.

Más Información

Tara Minh

Senior Operations & Growth Strategist