Herramientas y stack tecnológico del ingeniero de ventas

Son las 9:52. La demo comienza en ocho minutos. El SE tiene la pestaña uno del navegador abierta en el CRM, buscando las notas de la llamada anterior. La pestaña dos es el sandbox de la demo, que muestra los datos inicializados de la semana pasada y un registro de prueba a medias de otro representante. La pestaña tres es el Loom de ayer, que el SE quería volver a ver para recordar la objeción que el AE había marcado. La pestaña cuatro es un mensaje directo de Slack con el AE: "¿Seguimos posicionando esto como sustitución competitiva o eso cambió?" Además, hay un ordenador portátil aparte con el entorno real del producto.

Cinco superficies. Un comprador. Cuatro minutos.

El stack no está roto. El SE dará una demo aceptable. Pero cada lunes por la mañana ese caos le cuesta al equipo algunos puntos porcentuales de conversión de demo que nadie está midiendo.

El objetivo de un stack tecnológico del SE no es tener las últimas herramientas. Es comprimir el tiempo de preparación, aflorar las señales del comprador y permitir que un solo SE cubra dos o tres veces el volumen de operaciones sin agotarse. Un stack ordenado lo hace posible. Un stack desordenado penaliza silenciosamente cada demo.

Por qué el stack determina la calidad de la demo

La mayoría de los fallos de demo no ocurren durante la llamada. Ocurren en los 30 minutos anteriores, cuando el SE está reconstruyendo el contexto desde cuatro herramientas, o en la semana posterior, cuando un POC supera su fecha de decisión porque nadie lo estaba siguiendo.

Dónde los SEs pierden operaciones realmente:

• El comprador menciona en la llamada de descubrimiento un flujo de trabajo que el AE olvidó registrar. El SE presenta la ruta equivocada y el comprador concluye que el producto no encaja.
• Un POC comienza sin criterios de éxito escritos. Seis semanas después, el comprador dice "no vimos suficiente valor," y el SE no tiene ningún documento firmado para rebatirlo.
• La misma objeción técnica aparece en tres demos ese mes. Tres SEs la gestionan de tres maneras distintas. Ninguno le comenta nada al otro.
• Un SE hereda una operación a mitad del ciclo. Las notas del SE anterior están en su Notion personal. Los entornos de demostración no están etiquetados. El nuevo SE básicamente empieza desde cero.

Cada uno de estos es un problema de stack disfrazado de problema de habilidades. Mejores herramientas, integradas en el flujo de trabajo real de demos y POCs, resuelven más de estos problemas que otra ronda de coaching al SE.

El stack debe seguir el flujo de trabajo, no al revés. Los equipos de RevOps a veces empiezan con "¿en qué debemos estandarizar?" y terminan comprando una plataforma que el equipo de SE nunca abrirá. Empiece por cómo se construye una demo, cómo avanza un POC desde el inicio hasta la decisión y cómo el SE traspasa al CS. Las herramientas se derivan de eso.

Las seis capas del stack del SE

Estas son las seis capas que un SE necesita cubrir. La mayoría de los equipos tienen algo en cada capa; la pregunta es si las capas están conectadas.

Capa 1: CRM para el contexto de la operación

Esta es la primera parada del SE antes de cada demo. Debe responder a una pregunta en menos de 60 segundos: ¿qué sabe ya este comprador y qué nos dijo que le importa?

Lo que el SE necesita ver:

• Etapa actual de la operación y fecha de cierre
• Mapa de stakeholders (quién está en la llamada, quién no, quién decide realmente)
• Notas de llamadas anteriores del AE (transcripciones del descubrimiento, no resúmenes)
• Contexto competitivo (quién más está en la operación, qué se dijo sobre ellos)
• Cualquier contacto previo con el producto (prueba gratuita, asistencia a webinars, tickets de soporte si es una renovación)

Opciones de vendor: Salesforce es el predeterminado para equipos enterprise con un administrador y un modelo de objetos funcional. HubSpot es el predeterminado para equipos de mercado medio que quieren una configuración más rápida y una interfaz más limpia. Rework CRM es una opción más ligera para equipos liderados por SE que quieren seguimiento unificado de operaciones y actividades sin el coste administrativo de Salesforce: 12 USD por usuario y mes, con la vista de contexto de operaciones que los SEs realmente utilizan. El CRM correcto es el que sus SEs abrirán antes de cada demo.

El modo de fallo aquí es siempre el mismo: el CRM existe, pero el SE no confía en los datos, así que contacta al AE por Slack. Si detecta ese patrón, la solución no es un nuevo CRM. Es una conversación con el AE sobre la disciplina de registrar las notas del descubrimiento el mismo día de la llamada.

Capa 2: Gestión del entorno de demostración

Aquí es donde la mayoría de los stacks pierden más demos. El SE comparte su pantalla, el comprador ve datos inicializados de otro sector y el golpe a la credibilidad es inmediato.

Cómo se ve una buena gestión:

• Entornos de demostración dedicados por segmento ICP, no un sandbox compartido que todos sobreescriben
• Datos inicializados que coincidan con el sector del comprador (cuentas de muestra, valores de operaciones, convenciones de nomenclatura)
• Actualización semanal para que las integraciones no fallen y los registros de prueba antiguos no aparezcan en pantalla
• Etiquetado para que el SE acceda al entorno correcto en 30 segundos, no en 10 minutos de "espera, ¿cuál tenía los datos de manufactura?"

Algunos productos incluyen herramientas de demo integradas. Para todo lo demás, el equipo de SE construye las suyas propias. Habitualmente, una hoja de cálculo con los entornos de demostración, la persona, el sector, la fecha de última actualización y la URL de inicio de sesión. No es elegante, pero es la diferencia entre una demo que funciona y una que no.

Capa 3: Seguimiento del POC

Una vez que una operación entra en fase de POC, el modo de fallo cambia. La pregunta pasa a ser: ¿seguimos trabajando en esto o se ha detenido?

Un tracker dedicado para el POC (documento en Notion, tablero en Linear, Dashboard de RevOps) sustituye al hilo de Slack de "¿creo que seguimos en POC?" Cada POC activo debe tener un único registro con:

• Criterios de éxito (¿qué tiene que ver el comprador para decir que sí?)
• Responsable técnico de cada parte
• Responsable de negocio en el lado del comprador
• Fecha de decisión acordada por el comprador
• Estado semanal: verde, amarillo, rojo, con una nota sobre lo que cambió
• Bloqueos abiertos y quién los está resolviendo

Opciones de vendor: Asana, Linear, Monday, ClickUp, Notion o una solución personalizada de RevOps funcionan. La plataforma importa menos que la disciplina de actualizarla semanalmente. Los POCs sin tracker tardan aproximadamente un 40% más que los POCs con uno. La mayor parte de ese tiempo extra se pierde en el estado en que ninguna de las dos partes sabe quién debe dar el siguiente paso.

Capa 4: Inteligencia conversacional

Gong, Chorus, Clari Copilot, Avoma, Fathom. Elija uno. La razón por la que todo equipo de SE necesita esta capa no es para vigilar a los AEs. Es para que los SEs puedan hacer auto-coaching.

El patrón en los equipos de SE de alto rendimiento: cada SE revisa dos de sus propias demos por semana. Buscan los momentos en que el comprador hizo una pregunta y recibió una respuesta ligeramente incorrecta, la objeción que no tuvo una respuesta clara, el punto técnico que provocó silencio en lugar de asentimiento. Ahí es donde los SEs realmente mejoran.

Caso de uso secundario: analizar las llamadas de inicio del POC en busca de objeciones que el AE pasó por alto. El comprador dijo algo de pasada en el minuto 38 que nadie marcó. La inteligencia conversacional lo identifica, el SE hace el seguimiento y el POC sigue vivo.

Capa 5: Herramientas de demo asíncrona

Las demos en directo son costosas. Cada minuto en una llamada en vivo debe ganárselo un comprador que ya se ha cualificado a sí mismo.

Las herramientas de demo asíncrona resuelven problemas en la parte inicial y final del funnel:

• Loom para los seguimientos. En lugar de un correo de seguimiento de 400 palabras, grabe un recorrido de 90 segundos sobre la funcionalidad que el comprador preguntó.
• Storylane, Reprise, Navattic, Walnut para tours interactivos del producto. Envíelos antes de las demos en vivo para que el comprador pueda explorar por su cuenta. Los SEs que hacen esto bien informan de un 20 a un 30% menos de demos en vivo desperdiciadas.
• Vidyard o Wistia para bibliotecas de demo asíncrona alojadas que el AE puede usar en las primeras llamadas.

La disciplina consiste en adaptar la herramienta asíncrona a la etapa del comprador. No envíe un tour de 12 minutos a alguien que simplemente tiene curiosidad, y no envíe un Loom de 90 segundos a un comprador que necesita presentar el producto ante un comité.

Capa 6: Roleplay con IA y preparación

La capa más nueva, la que avanza más rápido. Casos de uso que se han consolidado:

• Roleplay de objeciones. Proporcione a una herramienta de IA el sector del comprador, su rol y las objeciones conocidas. Pruebe la respuesta del SE antes de la llamada real.
• Guion gráfico de la demo a partir del descubrimiento. Introduzca la transcripción del descubrimiento y pida a la IA que mapee qué momentos debe destacar la demo. Ahorra entre 30 y 40 minutos de preparación por llamada.
• Síntesis de múltiples llamadas. Cuando una operación ha tenido cuatro conversaciones, la IA puede extraer el hilo conductor de "¿qué le importa realmente al comprador?"

El error es tratar la IA como un sustituto del criterio del SE. Es un compañero de entrenamiento, no un redactor de guiones. Si el SE lee la salida de la IA palabra por palabra durante la llamada, el comprador lo nota.

Rúbrica de evaluación del stack

Cuando RevOps o un líder de SE elige herramientas para una capa, evalúe cada opción en cuatro ejes:

Puntúe cada herramienta del 1 al 5 en cada eje. Cualquier puntuación por debajo de 3 en un solo eje es una señal de alerta. Incluso una herramienta con alta puntuación general pero con un 1 en coaching degradará silenciosamente su equipo en el plazo de un año.

El otro filtro: ¿sus SEs abrirían esta herramienta por iniciativa propia un martes por la mañana? Si la respuesta honesta es no, la adopción fracasará independientemente de lo que diga el contrato.

Lista de verificación para la actualización del entorno de demostración

Ejecútela semanalmente. Lleva 30 minutos y evita al menos una demo al mes con el error "los datos en pantalla son incorrectos."

• Actualidad de los datos: el último registro inicializado tiene fecha de los últimos 7 días
• Estado de las integraciones: cada herramienta conectada (CRM, calendario, facturación) responde
• Alineación con la persona: los datos de muestra coinciden con el segmento ICP al que está asignado el entorno
• Revisión de enlaces rotos: haga clic en cada elemento de navegación, cada widget del Dashboard, cada formulario
• Limpieza de registros de prueba: elimine cualquier registro creado por un SE durante ensayos
• Comprobación de inicio de sesión: las credenciales siguen funcionando, la autenticación multifactor no está bloqueada, el usuario de demo tiene los permisos correctos

Si su equipo tiene más de tres SEs, rote el responsable de la actualización mensualmente. Un responsable único siempre falla cuando esa persona está de vacaciones.

Plantilla del tracker de POC

Cada POC activo tiene un único registro. Los mismos campos, siempre:

• Nombre de cuenta e ID de operación (vinculados al CRM)
• Criterios de éxito: tres a cinco resultados específicos que el comprador acordó antes del inicio
• Responsables técnico y de negocio en el lado del comprador (nombre, cargo, correo)
• Fecha de decisión acordada por el comprador por escrito
• Estado semanal: verde, amarillo, rojo, con una frase explicando el color
• Bloqueos abiertos con responsable y fecha estimada de resolución
• Resultado al cierre: ganado, perdido, sin decisión, con una breve justificación

El resultado "sin decisión" es el que la mayoría de los equipos infravaloró. Los POCs que no llegan a ningún lado no son pérdidas en la columna del AE, pero sí son pérdidas en el calendario del SE. Registrarlos aflorará el problema de cualificación aguas arriba.

Secuencia de preparación de la demo

Un SE con experiencia debería poder preparar una demo estándar en 20 minutos:

• Minutos 0-4, análisis del CRM. Acceda al registro de la operación. Lea las dos notas de llamada más recientes del AE. Tome nota del mapa de stakeholders y el contexto competitivo.
• Minutos 4-8, selección del entorno. Elija el entorno de demostración etiquetado para el ICP del comprador. Confirme que los datos inicializados están actualizados. Abra el producto en vivo en una ventana separada.
• Minutos 8-14, revisión del guion. Recupere la transcripción del descubrimiento. Mapee dos o tres momentos de la demo a los puntos de dolor declarados por el comprador.
• Minutos 14-18, sincronización con el AE. Dos minutos por Slack o llamada: "Esta es la ruta que voy a seguir. ¿Algo cambió? ¿Algún punto delicado?"
• Minutos 18-20, limpieza final de pestañas. Cierre todo excepto el entorno de demostración, el CRM y la ventana de la llamada. Active el modo "no molestar" en Slack. Pruebe el compartir pantalla.

Si preparar una demo suele llevar más de 30 minutos, el cuello de botella casi siempre está en la Capa 1 o la Capa 2. Resuelva eso antes de añadir más herramientas.

Errores comunes

• Sin higiene del entorno de demostración. Datos obsoletos, integraciones rotas, registros de prueba a medias visibles durante el compartir pantalla. El comprador lo nota aunque no lo diga.
• Sin tracker de POC. "Lo gestionaremos por correo" se convierte en un POC abierto de seis semanas que nadie recuerda. La operación se pospone un trimestre.
• Ignorar la inteligencia conversacional para el auto-coaching. Los SEs revisan las llamadas de su AE pero nunca las suyas propias. La misma objeción destruye tres demos antes de que alguien lo note.
• Proliferación de herramientas sin sistema de registro. El SE senior sabe dónde está todo. El nuevo SE que hereda la operación no encuentra nada. La incorporación se alarga de dos semanas a dos meses.
• Comprar herramientas que el SE no pidió. RevOps estandariza en una plataforma que el equipo nunca abrirá realmente. La licencia queda sin usar, el presupuesto se cuestiona el año siguiente y toda la conversación sobre el stack vuelve a empezar.

El hilo conductor entre los cinco: el stack solo funciona cuando el flujo de trabajo del SE impulsa las herramientas, no al revés.

Cómo medir si el stack está funcionando

Cinco cifras, seguidas trimestre a trimestre:

• Tiempo de preparación de la demo por llamada. Objetivo: menos de 30 minutos para una operación estándar. Por encima de 45 minutos es un problema de stack, no de habilidades.
• Tasa de cierre en POC. Objetivo: 60% o superior en POCs cualificados. Por debajo de eso, revise primero la disciplina con los criterios de éxito.
• Tasa de cierre ante objeciones técnicas. Haga un seguimiento de qué objeciones destruyen operaciones y cuáles el equipo ha aprendido a gestionar. La lista debería reducirse trimestre a trimestre.
• Conversión de demo a POC. De las demos que realiza el SE, ¿cuántas avanzan a POC? Un número plano o decreciente indica que las demos aterrizan en el lugar equivocado, habitualmente por un problema en la Capa 1 (contexto) o la Capa 3 (cualificación).
• Tiempo hasta la decisión en el POC. Desde el inicio hasta un sí o un no, en días. La mediana debería ser de 30 días o menos para mercado medio, de 45 a 60 para enterprise. Por encima de eso, los POCs se están desviando.

El stack funciona cuando estas cifras mejoran. No funciona cuando todos tienen acceso a la última herramienta pero nadie puede responder a la pregunta "¿la inversión en herramientas de este trimestre hizo al equipo mejor?"

Construya el flujo de trabajo, no lo compre

El stack del SE no es una lista de vendors. Es un flujo de trabajo con herramientas integradas en él. Elija la herramienta más ligera que cubra cada capa. Ejecute la lista de verificación de actualización semanalmente. Haga seguimiento de las cinco cifras trimestralmente. Sustituya la herramienta cuando la cifra deje de mejorar.

La mayoría de los equipos sobreinvierten en las Capas 4 y 6 antes de haber resuelto las Capas 1 y 2. El orden importa. Sanee la base y la conversión de demo mejorará por sí sola. Si lo omite, ninguna cantidad de inteligencia conversacional salvará la demo en la que el comprador vio los datos inicializados de la semana pasada en su pantalla.

Más información

• Diseño de la demo a partir del dolor del comprador
• Un día en la vida de un ingeniero de ventas
• Métricas del ingeniero de ventas que importan
• La IA en el flujo de trabajo del ingeniero de ventas