Por qué la retención de clientes se estanca cuando la responsabilidad está repartida entre equipos, y qué cambia cuando hay un único punto de titularidad.
En la retención se comparten las aportaciones; el resultado tiene un responsable. La mayoría de las organizaciones solo se organizan para la primera mitad.
En resumen: muchos equipos contribuyen a la retención, pero el resultado necesita un responsable. Sin él, los objetivos departamentales tiran en contra del número común, las concesiones se descubren en lugar de decidirse, y la retención o va a la deriva o se atasca. Las empresas ya aceptan este modelo para el producto, donde un product manager responde del resultado sin gestionar a todos los equipos que lo moldean. La retención rara vez recibe el equivalente.
En la primera parte de esta serie, «Los fallos de retención empiezan por dentro», se argumentaba que los fallos de retención suelen empezar dentro de la organización, en lo bien que se comunica consigo misma antes de que nada llegue al cliente. Esta parte trata de la razón más habitual por la que no lo hace: la retención se trata como responsabilidad de todos, lo que en la práctica la deja sin dueño.
Imagina una reunión de dirección durante la revisión trimestral, en la que la retención ha caído cinco puntos según la definición que todas las partes aprobaron el año anterior. Cada una tiene una diapositiva y una teoría preparadas. Las campañas de marketing cumplieron sus objetivos, así que la caída tiene que venir de otro sitio. Producto hizo su parte y el engagement se mantuvo. Finanzas menciona la estacionalidad y el entorno económico. Cada explicación viene con su propio dashboard, y cada una puede ser parcialmente cierta. La reunión termina con acciones para todos: marketing probará una campaña de recuperación, producto revisará el embudo de onboarding, finanzas modelará los efectos estacionales y económicos. Cada acción responde a su propia explicación y se juzgará en el dashboard de su propio equipo. Llega el siguiente trimestre, cada equipo puede demostrar que su acción funcionó y… la retención sigue a la baja.
En la retención se comparten las aportaciones; el resultado tiene un responsable
El argumento a favor de la responsabilidad compartida es real. Producto decide si el cliente encuentra valor, soporte decide qué pasa cuando algo falla o alguien se queja, y marketing, CRM y facturación intervienen en el momento en que el cliente decide si se queda. Dicho esto, tratar a un solo equipo como «el equipo de retención» es en sí mismo un error.
Así que el problema parece estar en el resultado. Las aportaciones pueden compartirse indefinidamente (y a veces se comparten). Un resultado que es de todos puede ser reclamado por cualquiera y rechazado por todos, normalmente en el momento en que importa (para bien o para mal).
Esto significa también que, en la práctica, la retención rara vez queda del todo sin reclamar. La reclama la función que más cerca queda de ella en ese modelo de negocio concreto: CRM o marketing en las empresas lideradas por marketing, producto en las lideradas por producto, customer success en B2B. Los demás se desentienden, y nadie comprueba si quien la reclama llega a lo que realmente mueve el número. Normalmente no. CRM no fija los precios ni diseña el onboarding; producto no gestiona soporte ni facturación. La reclamación cubre una parte de las aportaciones y nada del resto.
Esa reclamación, además, se aplica de forma selectiva. Un buen trimestre tiene muchos padres: la campaña, el lanzamiento y el nuevo proceso de soporte se llevan el mérito. Un mal trimestre es del mercado, o de otro equipo. El mérito fluye hacia dentro y la culpa fluye hacia fuera. La explicación de cada equipo es plausible a nivel local. Sin un responsable, sin embargo, nadie está obligado a reconciliar las discrepancias.
Sin arbitraje, la retención va a la deriva o se atasca
Cuando los objetivos de los equipos no chocan, el resultado es la deriva. Hay una reunión, todos coinciden en que la retención necesita atención, no se asigna a nadie en concreto, y un mes después la misma reunión redescubre que sigue necesitando atención. Una iniciativa arranca con un impulsor y sin responsable, y dura exactamente lo que dure la atención de esa persona. El tema se discute en sucesivas revisiones trimestrales, formulado de forma ligeramente distinta cada vez, porque quien lo plantea no tiene obligación de seguir sosteniéndolo el trimestre siguiente. Cuando algo sí funciona, nadie sabe decir exactamente qué decisión lo hizo funcionar, así que se puede desear que vuelva a pasar, pero no replicarlo a demanda.
Cuando los objetivos de los equipos sí chocan, el resultado es la fricción. Marketing quiere más contacto, producto quiere menos ruido en el onboarding, finanzas quiere recuperación, riesgo quiere menos aprobaciones. Cada equipo tira hacia su propio objetivo, y los choques los zanja quien escala más fuerte, o no se zanjan. El objetivo común primero se cuestiona y después se abandona en silencio.
Los dos casos se ven distintos y tienen la misma causa: nadie arbitra.
Tres números de retención son un síntoma, no la enfermedad
Otra versión de esa reunión es aquella en la que marketing, producto y finanzas traen cada uno un número de retención distinto, porque cada uno cuenta una actividad diferente: aperturas, inicios de sesión, pagos. Es el lugar más fácil para ver todo esto, y el más habitual para malinterpretarlo. El instinto es tratarlo como un problema de datos: acordar una definición, arreglar los dashboards y seguir. Pero eso pasa por alto lo que los tres números muestran realmente. Nadie definió la retención porque nadie es responsable de ella. Cada equipo construyó su dashboard sobre su propia respuesta, y se permitió que los tres discreparan indefinidamente porque nadie estaba obligado a reconciliarlos. Es difícil mejorar algo que la empresa no ha acordado que existe en una única forma.
Así que la opción obvia es cerrar la definición, que suele ser lo primero que hace un responsable de verdad, y conseguir que todos los equipos trabajen con ella en lugar de limitarse a conocerla. Una definición útil responde a tres preguntas. Primera, qué actividad cuenta: un inicio de sesión no es una transacción, y una apertura no es una relación. Segunda, en qué ventana, ajustada a la frecuencia con la que ese cliente vuelve de forma natural y no al mes natural. Tercera, si un cliente que solo vuelve cuando se le paga está retenido o alquilado (saberlo es clave al principio y también a largo plazo, porque evita mucho dinero de campaña mal gastado). Cómo medir con honestidad frente a la definición es un tema aparte.
Los objetivos departamentales deben sumar al número de retención, no restarle
Los objetivos departamentales deben existir; una empresa sin ellos no tiene forma de dirigir a sus equipos. La cuestión es si cada uno suma al número común o le resta. Nada de esto es nuevo. El equipo detrás de los programas de crecimiento de Reforge describió el patrón hace años: los equipos a los que se da una métrica por etapa del embudo acaban optimizando a costa de los demás. Lo que realmente falta en la mayoría de las empresas no es conciencia del problema, sino una forma de comprobarlo. La prueba es sencilla de formular y de poner en práctica, e incómoda de responder: ¿podría este equipo cumplir su objetivo mientras la retención cae?
Normalmente, sí:
Un objetivo de reactivación medido en regresos en siete días puede cumplirse con incentivos que traen de vuelta a los clientes durante una semana. Al día treinta la mayoría se ha ido otra vez, y la empresa los ha alquilado en lugar de retenerlos.
Un objetivo de captación por volumen o coste por cliente puede cumplirse comprando tráfico más barato y de menor intención, cuya retención del primer mes se convierte en el número de otro y, a menudo, en uno imposible de alcanzar.
Un objetivo de activación basado en completar el onboarding puede cumplirse haciendo que el onboarding sea fácil de terminar en lugar de valioso de terminar.
Un objetivo de soporte basado en el tiempo de gestión puede cumplirse cerrando tickets que no están resueltos. El cliente no se queja dos veces; se va.
Un objetivo de recuperación de pagos fallidos puede cumplirse con un dunning lo bastante agresivo como para recuperar los ingresos de este mes y provocar las cancelaciones del próximo.
Un objetivo de pérdidas por fraude puede cumplirse endureciendo los controles hasta que bastantes buenos clientes se rinden.
Ningún equipo hizo nada «mal» según su propia medida y sus propios objetivos. La solución no es hacer a cada equipo responsable de todo el resultado, lo que solo convierte el problema de atribución en un conflicto abierto. Es añadir una salvaguarda a cada objetivo local: la reactivación sigue contando, pero solo si el cliente sigue retenido según la definición compartida, digamos, al día sesenta. Los equipos funcionan con métricas rápidas y se les reconoce por la más lenta. Salvaguardas así no se diseñan solas, sin embargo, y ahí es donde vuelven la titularidad y la autoridad.
Los objetivos necesitan una jerarquía, y una jerarquía necesita a alguien que la haga cumplir
Los objetivos individuales y el objetivo común pueden y deben coexistir (porque a veces uno nos hace correr más rápido y el otro nos hace correr más lejos), y los individuales importan porque alimentan el común. Cuando ambos entran en conflicto, decide el orden de prioridad. En lo más alto de ese orden está el negocio, no la retención. A veces la retención debe perder: frente al cumplimiento normativo, frente al margen, o frente al juicio honesto de que un cliente concreto no merece la pena. Eso es absolutamente legítimo, siempre que dicha jerarquía esté establecida, comunicada y se haga cumplir. Una jerarquía que nadie hace cumplir no es más que una diapositiva de la presentación de estrategia del año pasado.
Lo que importa es si una concesión se decide o se descubre. La retención cede legítimamente cuando la dirección (el responsable, el equipo ejecutivo o el consejo, según lo que esté en juego) decide que debe hacerlo, con el coste entendido de antemano. Falla cuando la decisión se toma arriba y el coste se descubre abajo. Se recortan incentivos para proteger el margen, y el trimestre siguiente la caída de la retención se investiga como un problema de CRM. O la concesión nunca se decide, y cada departamento acaba tomando su propia versión a nivel local. Una concesión decidida arriba tiene que asumirse arriba.
La retención necesita lo que el producto ya tiene
Las empresas ya han resuelto una versión de este problema, en el producto. Un product manager responde del resultado de un producto sin gestionar a los ingenieros, diseñadores o analistas que lo construyen, y a nadie le parece extraño. Conviene tener presente que esta analogía tiene un límite que merece mencionarse: la palanca de un product manager proviene de fijar las prioridades de un equipo dedicado a ese producto. Un responsable de retención (tal como están las cosas en la mayoría de las organizaciones) no tiene ese equipo, así que la palanca tiene que venir de un mandato del equipo ejecutivo sobre tres cosas: la definición de retención, la jerarquía de objetivos y las salvaguardas dentro de las que trabaja cada equipo. La retención, que en un negocio de alta frecuencia está tan cerca de los ingresos como cualquier otra cosa, rara vez recibe ni el rol ni el mandato.
La idea equivocada de muchas empresas es creer que ya tienen a alguien que resuelve ese problema porque tienen un responsable de CRM o un responsable de lifecycle. Sin embargo, ese rol suele limitarse a los canales: los mensajes, la automatización, el calendario de envíos y promociones. Es responsable de lo que sale, no de si los clientes se quedan.
Otras empresas sí tienen un responsable de retención, y entonces depende de hasta dónde alcance el cargo. Si el rol tiene autoridad transversal real, buena parte de este artículo puede no aplicarse, y conviene decirlo claramente. Si es CRM con otro nombre, todavía limitado a los canales, el problema sigue igual bajo el barniz de un eufemismo que por sí solo no resuelve nada. Si tiene el encargo sobre el papel pero no la autoridad en la práctica (lo más habitual), es un fallo distinto, que se trata más abajo. La prueba es sencilla: ¿puede el rol cambiar algo fuera de su propio equipo?
El equivalente de un product manager para la retención hace algunas cosas concretas:
Mantiene la definición de cliente retenido y reconcilia los dashboards con ella.
Diseña y mantiene las salvaguardas de los objetivos de cada equipo: cuáles se aplican, con qué umbral y qué ocurre cuando dos de ellas tiran en sentidos opuestos. Esto es clave y es la mayor parte del trabajo, y es la manera de ordenar los objetivos departamentales frente al número común en lugar de dejar que lo erosionen.
Arbitra el contacto con el cliente. Las reglas de frecuencia de CRM gobiernan los canales de CRM; cuando producto envía desde su propia herramienta y facturación desde otra, alguien tiene que poner a todos los remitentes bajo una misma política de contacto. Cuando nadie lo hace, el cliente arbitra por ti, normalmente silenciándote.
Da a la comunicación interna un sitio donde aterrizar. La Parte 1 trataba de equipos que no se hablan; aquí los equipos hablan perfectamente bien, y lo que dicen circula sin converger a menos que alguien lo reciba, lo reconcilie y lo convierta en una decisión.
Explica, de forma periódica, por qué se ha movido el número. Cuando la causa queda fuera de las campañas de cualquier equipo, como un producto que pierde valor, el responsable no puede arreglarlo solo, pero es quien tiene la obligación de decirlo pronto y con evidencias.
Nada de esto requiere un departamento nuevo, y a menudo ni siquiera más plantilla; con más frecuencia significa dar a una persona ya existente el trabajo que el número ya implica. Tampoco significa que cada decisión tenga que pasar por esa persona. El responsable fija las reglas dentro de las cuales deciden los equipos, e interviene solo cuando esas reglas chocan.
El paralelismo tiene, con todo, un punto débil conocido. La queja más habitual de los product managers es la responsabilidad sin autoridad, y un responsable de retención corre el mismo riesgo: su nombre asociado al número, sin la posición necesaria para cambiar lo que lo mueve. De eso trata la Parte 3.
Cómo saber si la retención en tu empresa tiene realmente un responsable
Unas pocas preguntas lo responden más rápido que un organigrama:
¿Podrían tres de tus líderes dar el mismo número de retención, calculado de la misma manera, sin preparación previa?
Si la retención se movió este trimestre, ¿hay una persona cuyo trabajo sea explicar por qué, o la explicación llega en pedazos desde revisiones separadas?
¿Podría cada equipo cumplir sus objetivos mientras la retención cae?
Cuando dos equipos quieren contactar al mismo cliente el mismo día, ¿quién decide?
La última vez que se sacrificó retención a cambio de otra cosa, ¿quién tomó la decisión, y asumió alguien el coste?
Las respuestas incómodas no siempre tienen que ver con la titularidad. Tres dashboards sin reconciliar también pueden significar que los datos realmente no se pueden reconciliar: si ningún sistema mantiene una visión única del cliente, ni siquiera un responsable competente tiene nada contra lo que reconciliar, y eso es una limitación de herramientas. La forma más rápida de saberlo es encargar a una persona durante un mes que reconcilie. Si no puede porque los datos no se pueden unir, el factor limitante real es el stack. Si puede y nada cambia, es la titularidad.
El punto
La retención no es un departamento, y no se puede dirigir como si fuera uno compartido. Es un número, y un número necesita un nombre asociado, o la responsabilidad se disuelve en algo que parece consenso y no se comporta en absoluto como tal.
La contribución es de todos. El resultado tiene un solo responsable. El arbitraje es lo que mantiene ciertas ambas cosas. Nada de esto es una idea nueva, puesto que la mayoría de las empresas ya gestionan así sus productos. Si preguntar quién es responsable de la retención en la tuya da lugar a una discusión en vez de a un nombre, merece la pena hablarlo.
Preguntas frecuentes
¿No se supone que la retención es responsabilidad de todos?
Todos contribuyen a ella, que es distinto de que todos respondan de ella. Producto, soporte, marketing y CRM influyen en que los clientes se queden, pero el resultado sigue necesitando un responsable que lo defina, reconcilie las visiones de los equipos sobre él y responda de su evolución.
¿Qué cuenta como cliente retenido?
No existe una definición universal, y por eso mismo cada empresa necesita una que todos los equipos usen. Una definición útil especifica qué actividad cuenta, en qué ventana (ajustada al ciclo natural del cliente) y si los clientes que solo vuelven cuando se les incentiva cuentan como retenidos.
¿No es el responsable de CRM quien ya responde de la retención?
Normalmente no. El rol suele limitarse a los canales: mensajes, automatización, calendario de envíos. Es responsable de lo que sale, no de si los clientes se quedan. Ser responsable de la retención significa responder del resultado en todos los equipos que lo moldean, igual que un product manager responde de un producto.
Tenemos un responsable de retención. ¿Esto sigue aplicándose?
Depende de hasta dónde alcance el rol. Con autoridad transversal real, el problema descrito aquí puede no existir. Si el rol es CRM con otro título, o tiene el encargo sin la autoridad, sí existe. La prueba es si el rol puede cambiar algo fuera de su propio equipo.
¿No bastaría con poner salvaguardas a los objetivos de cada equipo?
Las salvaguardas son el mecanismo principal, pero no se mantienen solas. Alguien tiene que sostener la definición en la que se apoyan, fijar los umbrales, detectar cuándo las salvaguardas de dos equipos se contradicen y ajustarlas a medida que el negocio cambia. Ese es el trabajo del responsable; sin él, las salvaguardas van a la deriva igual que la retención.
¿En qué se diferencia esto de la Parte 1?
La Parte 1 trata de equipos y sistemas que no se comunican, de modo que los errores llegan al cliente sin que nadie los vea. Esta parte está un nivel por encima: aunque los equipos se comuniquen bien, si nada converge en un único responsable del resultado, las piezas siguen coordinadas a nivel local y el número sigue a la deriva.