Identificar stakeholders clave en compras técnicas

Tipo de lección: Video

Concepto clave

Identificar stakeholders clave en compras técnicas significa mapear a todas las personas que influyen, deciden o se ven afectadas por la adquisición de tu producto SaaS. En ventas consultivas, no vendes a una empresa, vendes a un ecosistema humano con diferentes necesidades, autoridad y criterios de evaluacion.

Imagina que eres un arquitecto diseñando una casa. No solo hablas con el dueño (el tomador de decisiones final), sino tambien con los que viviran alli (usuarios), el ingeniero estructural (equipo tecnico), y el administrador de la propiedad (operaciones). Cada uno tiene preocupaciones distintas: estetica vs seguridad vs mantenimiento. En ventas SaaS, los stakeholders son similares: desde el CIO que prioriza ROI hasta el ingeniero que necesita APIs documentadas.

Como funciona en la practica

El proceso de identificacion sigue estos pasos:

1. Investigacion previa: Usa LinkedIn y sitios corporativos para entender la estructura organizacional. Busca titulos como "Head of Engineering", "Product Manager", o "IT Director".
2. Preguntas de discovery: En la primera llamada, pregunta: "¿Quien mas en su equipo se veria impactado por esta solucion?" y "¿Como se toman las decisiones tecnologicas aqui?".
3. Mapeo de influencia: Crea una tabla mental o escrita con:
   • Nombre/rol
   • Nivel de autoridad (decisor, influenciador, usuario)
   • Dolor principal
   • Metrica que les importa
4. Validacion continua: Confirma tu mapa con cada nuevo contacto, ajustando segun nueva informacion.

Dato importante: En compras SaaS tecnicas, el 74% involucra a 3 o mas stakeholders segun Gartner. Ignorar a uno puede costarte el cierre.

Caso de estudio

Un Sales Engineer vendiendo una plataforma de monitoreo de aplicaciones a una fintech. Inicialmente, solo contactaba al CTO. Tras aplicar identificacion de stakeholders, descubrio:

Stakeholder	Rol	Dolor	Metrica clave
CTO	Decisor final	Escalabilidad	Uptime >99.9%
Lead Developer	Influenciador tecnico	Debugging lento	Tiempo medio de resolucion
DevOps Manager	Usuario principal	Alertas falsas	Ruido de alertas
CFO	Aprobador presupuesto	Costo total	ROI en 12 meses

El Sales Engineer adapto su demo: al CTO mostro dashboards de rendimiento, al Lead Developer integracion con GitHub, al DevOps Manager reglas de alerta inteligentes, y al CFO un calculador de ROI. Resultado: cierre en 45 dias vs los 90 promedio.

Errores comunes

• Enfocarse solo en el contacto inicial: Asumir que quien responde el correo es el unico que importa. Solucion: pregunta explicitamente "¿Quien mas deberia estar en esta conversacion?".
• Ignorar a los usuarios finales: Los ingenieros que usaran tu herramienta diariamente tienen influencia silenciosa. Solucion: incluye una sesion separada con ellos para entender sus workflows.
• Sobrestimar la autoridad formal: Un VP puede tener el titulo, pero un arquitecto senior puede vetar tecnicamente. Solucion: mapea influencia real, no solo jerarquia.
• No actualizar el mapa: Las organizaciones cambian, personas se van, roles evolucionan. Solucion: revisa tu mapa de stakeholders en cada interaccion.
• Tratar a todos igual: Enviar el mismo email tecnico al CFO que al ingeniero. Solucion: personaliza el mensaje segun el dolor y metrica de cada stakeholder.

Checklist de dominio

1. Identifico al menos 3 stakeholders distintos en cada oportunidad, mas alla del contacto inicial.
2. Documento para cada stakeholder: rol, dolor principal, metrica que valora, y nivel de influencia.
3. Adapto mi lenguaje y demostracion segun el stakeholder (tecnico vs negocios vs usuario).
4. Pregunto activamente en discovery: "¿Hay alguien cuyo visto bueno necesitamos para avanzar?".
5. Valido mi entendimiento de los stakeholders con preguntas como "¿Es correcto que a Maria le preocupa principalmente el tiempo de integracion?".
6. Identifico al "champion" interno que me ayudara a navegar la organizacion.
7. Actualizo mi mapa de stakeholders cuando aparecen nuevos contactos o cambian las circunstancias.

Mapeo de stakeholders para una oportunidad real

Selecciona una oportunidad de venta actual o pasada donde hayas estado involucrado. Si no tienes una, usa este escenario ficticio: Una startup de e-commerce con 50 empleados necesita una herramienta de CI/CD.

1. Investiga la estructura: Para tu oportunidad, busca en LinkedIn o supone roles comunes. Lista al menos 5 posibles stakeholders. Ejemplo: CTO, Lead Developer, DevOps Engineer, Product Manager, Head of Security.
2. Define influencia: Para cada stakeholder, clasificalo como:
   • Decisor (aprueba compra)
   • Influenciador (recomienda o veta)
   • Usuario (usa la herramienta)
   • Aprobador (da visto bueno presupuestario)
3. Identifica dolores: Escribe el principal dolor o necesidad de cada stakeholder. Ejemplo: DevOps Engineer - "Automatizar despliegues sin errores".
4. Propuesta de valor: Para 2 stakeholders clave, escribe una frase de valor personalizada. Ejemplo: Para Lead Developer: "Nuestra herramienta reduce el tiempo de integracion de 2 horas a 10 minutos".
5. Plan de contacto: Diseña un plan para involucrar a cada stakeholder. ¿Que tipo de contenido o demo le mostrarias primero?

Pistas

• Piensa en quien sufre el problema que resuelve tu producto, no solo en quien firma el cheque.
• Un stakeholder puede tener multiples roles (ej: usuario e influenciador).
• Considera stakeholders "ocultos" como equipos legales o de cumplimiento en industrias reguladas.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.