← Todos los insights
ai-sdrRevOpspipelinecrm-hygiene

El fracaso de los AI SDR es un problema de la capa operativa, no del envío

Los proveedores de AI SDR autónomos han recibido críticas públicas por ARR inflado y abandono de clientes. Los agentes envían bien. Lo que falla es la capa operativa que tienen debajo, y eso es un problema de RevOps.

Por qué el fracaso de los AI SDR empieza debajo del botón de enviar

Durante el último año, los proveedores de AI SDR autónomos han recibido críticas públicas por ARR inflado y abandono de clientes. No voy a juzgar aquí a ningún proveedor en concreto, en parte porque no puedo ver sus cuentas. Lo que sí puedo comentar es el patrón, porque vemos lo mismo desde el lado del comprador.

Los agentes envían. Envían mucho, rápido y con una redacción decente. Enviar nunca fue lo difícil. El fracaso de los AI SDR ocurre en la capa operativa: las definiciones de pipeline, los bucles de retroalimentación del CRM y la lógica de descalificación que le dicen a un agente qué es un buen resultado. Sin ellos, el agente optimiza lo único que puede ver, que es la actividad.

Por eso la idea de este artículo es nombrar esas tres partes, dar un ejemplo de cómo falla cada una y explicar qué haría yo al respecto. Es un enfoque estratégico, no un tutorial. La implementación es la parte en la que conviene tener a alguien trabajando con usted desde dentro.

¿Qué es la capa operativa que hay bajo un AI SDR?

La capa operativa es el conjunto de reglas y datos creados por personas que deciden qué es un lead, qué es una reunión y qué es un callejón sin salida. La llamaré la capa base. Un agente SDR se apoya sobre ella.

Tiene tres partes:

  1. Definiciones de pipeline: qué cuenta como una reunión calificada, una oportunidad o un cambio de etapa.
  2. El bucle de retroalimentación del CRM: cómo regresan los resultados para que el agente aprenda qué funcionó.
  3. Lógica de descalificación: las reglas sobre a quién nunca se contacta, o a quién se retira tras la primera señal.

Un SDR humano se las arregla con una capa base débil porque una persona absorbe lo que falta en las reuniones diarias, en las revisiones de oportunidades, en el pasillo. Un agente no tiene pasillo.

Definiciones de pipeline: el agente cumple la cifra que usted le dio

Supongamos que un equipo de SaaS B2B le pide a su agente que agende reuniones. Nadie ha dejado por escrito qué es una reunión. ¿Cuenta una llamada de 15 minutos con un becario? ¿Cuenta dos veces una reunión reprogramada tras una ausencia?

El agente agenda 120 reuniones en un mes. El panel se ve estupendo. Los AE las atienden, y un tercio son con personas sin autoridad presupuestaria y sin un problema activo. El proveedor reporta éxito porque la métrica del contrato eran las reuniones. El comprador cancela dos trimestres después porque el pipeline no se movió.

Mi impresión es que así empieza buena parte del fracaso de los AI SDR, y así arrancan algunas de las historias públicas de cifras infladas. Nadie tiene que estar mintiendo. La cifra se definió en la capa equivocada.

La solución es aburrida. Escriba la definición, guárdela en el CRM como un campo con valores controlados y mida al agente por la etapa posterior, no por la reserva. En HubSpot eso es una propiedad con opciones definidas, no una nota de texto libre.

El bucle de retroalimentación del CRM: sin resultados, no hay aprendizaje

Un agente solo puede mejorar si los resultados le llegan de vuelta. La mayoría de los CRM, para bien o para mal, están llenos de etapas obsoletas y campos a medio completar. Los compradores con los que hablamos describen SDR que cometen errores manuales al actualizar las relaciones cuenta-contacto en Salesforce. Si las personas se equivocan en eso, un agente que lee los mismos registros aprende del ruido.

Un ejemplo. Un agente escribe a un contacto que dejó la cuenta hace seis meses, porque la relación nunca se actualizó. El correo rebota o recibe una respuesta vaga. Nada se escribe de vuelta en el registro. La semana siguiente el agente lo intenta de nuevo. Ese bucle es el fracaso de los AI SDR en miniatura: actividad con total seguridad, cero aprendizaje.

La brecha también aparece del lado de los AE. Un cliente nos contó que sus ejecutivos de cuenta se centran en el plazo de firma y el presupuesto, y no profundizan lo suficiente en los motivos de dolor. Los motivos de cierre ganado y cierre perdido quedan escasos, de modo que nada le dice al sistema qué dolores predijeron un negocio. No se puede entrenar la segmentación con datos que nadie registró.

Lo que yo haría es auditar la ruta de escritura de vuelta antes de comprar nada. ¿Qué resultados llegan al CRM, en qué campos, quién los introduce y en cuánto tiempo? Si la respuesta es "depende del representante", ya tiene su primer proyecto, y no es un proyecto de agentes.

Lógica de descalificación: las reglas sobre a quién no contactar

Es la parte que más veo omitida. Los equipos definen su ICP y olvidan las exclusiones: clientes actuales, oportunidades abiertas, competidores, regiones en las que el equipo no puede dar seguimiento, empresas demasiado pequeñas para pagar.

Un cliente nos dijo que la prospección en EMEA les resulta difícil y que la persona que la cubre no se siente cómoda al teléfono. Otro temía que los SDR no ejecutaran las tareas telefónicas incluidas en los flujos de las campañas. Si coloca un agente en ese escenario sin lógica de descalificación, disparará contra cuentas de EMEA que el equipo no puede trabajar y luego agendará llamadas de vuelta que nadie hará. El volumen sube, la conversión baja y todos culpan al agente.

Aquí las reglas prácticas son baratas: por cada criterio de ICP que escriba, escriba una exclusión al lado. Cinco inclusiones y ninguna exclusión significa que el agente trabaja con la mitad de las instrucciones, y esa mitad es una causa frecuente del fracaso de los AI SDR.

¿Cómo secuenciaría un despliegue para evitar el fracaso de los AI SDR?

Tres fases, y el orden es lo importante:

  1. Primero, las definiciones. Etapas del pipeline, criterios de reunión y exclusiones, escritos y codificados en el CRM. Dos o tres semanas en un proyecto ágil.
  2. Segundo, la retroalimentación. Campos de resultados, escrituras de vuelta obligatorias y una revisión semanal de que los motivos de cierre perdido sean reales.
  3. Tercero, el agente, en un segmento reducido, medido por oportunidades creadas y no por envíos.

La razón por la que lo hacemos así es que, más adelante, cuando alguien pregunte por qué el agente hizo algo, usted pueda rastrearlo hasta una regla escrita por una persona. Sin eso, no se puede depurar. Solo se puede apagar.

Por eso también es un problema de RevOps y no de herramientas. Si usted se dedica a RevOps, es un gestor de proyectos con una especialidad, y este es un proyecto: acordar definiciones, codificarlas, instrumentar los resultados. La elección del proveedor viene después, y un CRM como Salesforce o HubSpot puede contenerlo todo.

Lo que no sé sobre el fracaso de los AI SDR

No tengo una gran respuesta sobre si los agentes autónomos acabarán infiriendo estas reglas por sí solos. Quizá. Los proveedores lo aseguran y los modelos siguen mejorando. Mi experiencia es que incluso un buen fichaje nuevo necesita las definiciones, y un agente es un fichaje nuevo muy rápido y sin jefe.

Tampoco puedo auditar los ingresos de ningún proveedor, así que tome mi lectura como un patrón, no como un veredicto. Lo que sí puedo decir es que el fracaso de los AI SDR aparece dondequiera que falta la capa base, y eso se puede comprobar en una tarde.

Si está evaluando un agente ahora mismo, mi recomendación es que haga a su propio equipo tres preguntas antes de la demo: qué cuenta como una reunión, dónde se escriben de vuelta los resultados y a quién no se contacta nunca. Si esas respuestas tardan más de un minuto, empiece por ahí. Encontrará más sobre cómo abordamos este tipo de trabajo en nuestra biblioteca de artículos.

Noah Charak
Noah Charak
Managing Director

Founder of Checkpoint GTM. 15 years of Revenue and Business Operations across the Berlin start-up scene, with 65+ transformation projects delivered. CRM architecture and RevOps specialist, certified in Salesforce and HubSpot.

LinkedIn

Comparta este artículo