Cómo vender cuando el usuario no es el comprador

• En situaciones donde el usuario usa el producto pero no es quien tiene la autoridad de pago, la clave es identificar quién tiene realmente la autoridad y la influencia
• La persona que toma decisiones y tiene la autoridad real no necesariamente es la compradora ni la primera usuaria
• En organizaciones pequeñas, ahorrar tiempo es importante, por lo que es muy probable que el desarrollador adopte la herramienta directamente y luego logre la compra convenciendo a sus superiores
• En organizaciones grandes, las restricciones de seguridad y proceso son fuertes, así que la autoridad de compra suele estar en el CTO o en la dirección, y se necesita un ciclo de ventas largo
• Quien tiene autoridad de compra no siempre coincide con quien controla el presupuesto, y el objetivo clave es la persona que percibe con mayor claridad el valor del producto y puede impulsarlo
• Una estrategia efectiva es ayudar a que el usuario convenza a la dirección proporcionándole datos concretos y materiales de persuasión, y apoyar ese proceso
• El éxito final consiste en diseñar un proceso que respalde al usuario para que pueda cumplir un rol de ventas internas

---

Introducción – punto de partida de la pregunta

• ¿Cómo deberíamos abordar la situación cuando el usuario real del producto y el cliente que toma la decisión de compra no son la misma persona?
• Se toma como contexto el caso típico de ventas de software B2B en el que un desarrollador prueba el producto y el CTO o el Director of Engineering toma la decisión final

La pregunta esencial sobre la autoridad

• La pregunta “¿quién tiene el poder de verdad?” es el punto más importante de todos
• No se trata simplemente de quién tiene la autorización para pagar con tarjeta o de quién prioriza probar el producto, sino de la influencia real y la motivación que determinan el flujo de compra

Escenarios según la estructura organizacional

En organizaciones pequeñas: estructura plana y decisiones rápidas

• A menudo el desarrollador descubre el producto y lidera su adopción
• La motivación principal del CTO es salir al mercado rápido e iterar, por lo que la propuesta de herramientas por parte del desarrollador tiene una influencia importante en la decisión
• Es común una expansión tipo Trojan-horse, donde el desarrollador prueba rápidamente una herramienta gratis y luego esta se convierte en una compra de pago

En organizaciones grandes: seguridad y cumplimiento como restricciones principales

• Existen restricciones distintas al tiempo, como la seguridad, y las decisiones del liderazgo son importantes en todo el proceso
• No se permite que el usuario (desarrollador) instale o compre por su cuenta, y el ciclo de ventas es largo y complejo
• Los criterios para percibir valor/riesgo se enfocan más en la seguridad y el resultado final que en la UI/UX o la DX

La perspectiva de la influencia real y del valor

• Quien controla el presupuesto no siempre es quien tiene la autoridad real
• Lo importante es identificar quién tiene palanca y los incentivos de quién influyen más para que el proceso avance
• Hay que entender con realismo qué actor puede intercambiar efectivamente el valor equivalente al precio

Ejemplo concreto del flujo de adopción del producto

1. El usuario/desarrollador se registra en el producto
2. Usa la prueba gratuita en un entorno local
3. Experimenta directamente el valor real de la función (por ejemplo, comparación antes/después de un Pull Request, resaltado de problemas)
4. Percibe el valor → expectativa de mayor eficiencia laboral y automatización
5. El usuario convence al liderazgo de la necesidad
6. El liderazgo aprueba o rechaza tras pruebas internas y revisión de presupuesto
7. El liderazgo aprueba la compra final
8. Se completa la compra del producto y se expande más dentro de la organización

La pregunta sobre los incentivos de ambas partes

• Entender la motivación esencial del desarrollador para proponer la herramienta (comodidad en el trabajo, destacar su capacidad personal, lograr objetivos de la empresa, etc.)
• Entender la motivación de compra del liderazgo (aumentar la eficiencia del desarrollo, alcanzar más rápido los objetivos de la empresa, etc.)
• Si existen estas motivaciones clave, se propone la siguiente estrategia

Estrategia práctica de respuesta

1. Proporcionar herramientas de persuasión, como reportes precisos de comparación antes/después, para que el usuario pueda convencer al liderazgo
   • En este proceso, son importantes los resultados basados en datos cuantitativos, no los consejos abstractos
   • Cifras concretas, como “cuánto tiempo se redujo frente al método anterior”, son la clave de la persuasión
2. Entender mediante entrevistas con clientes (desarrolladores) cómo avanzan realmente las conversaciones de compra, y resolver de antemano los obstáculos del proceso de persuasión

• Es decir, más que persuadir directamente a quien tiene la autoridad de compra, hay que ofrecer todo el apoyo ambiental y los materiales concretos para que el usuario pueda desempeñar con éxito un rol de ventas internas
• En este proceso, el éxito del usuario se conecta directamente con el éxito del vendor (una estructura de ganancia para usuario-vendor-liderazgo-empresa)

Conclusión y resumen

• La mejor estrategia es ayudar a que el usuario cumpla con éxito el rol de ventas internas del producto
• Hay que enfocarse en proporcionar evidencia cuantitativa y materiales concretos de valor necesarios para convencer al liderazgo
• Antes que nada, se debe analizar en detalle la estructura de toma de decisiones según el tamaño de la organización y sus restricciones
• En última instancia, se enfatiza que si el usuario tiene éxito, tanto el vendor como la empresa también triunfan al mismo tiempo

[GN⁺]

Comentarios de Hacker News

• Me harta cuando quiero descargar algo y me piden mis datos de contacto, y poco después los vendedores empiezan a llamarme o escribirme por correo sin parar; aunque los rechace con cortesía, me ignoran y siguen insistiendo con reuniones. Yo no tengo autoridad de compra, pero sí puedo difundir mi descontento dentro del equipo, así que al final la imagen del producto empeora. Cuando un ingeniero me pide una recomendación, obviamente termino mencionando esto. Casos así: Veeam, AWS y Keyence.

  • Como IT Manager, me pasa esto casi cada semana. Como no logran respuesta de mi parte, a veces intentan rodearme enviando correos al azar a mis colegas u otras personas de la empresa; cuando hacen eso, termino bloqueando rápidamente todo el dominio. Y ojalá dejaran de obligarte a ver un demo solo para recibir una cotización. Si ya investigué el producto y, si hacía falta, hasta probé un trial, lo razonable es darme primero el precio en vez de una presentación de ventas o un demo.

  • Auth0 y Okta también tienen ese mismo problema. Yo sí tenía la autoridad de compra y hasta el presupuesto, pero me contactaron tanto que simplemente me dejaron de gustar.

  • Me encanta el concepto de "poder de la queja". Incluso si algo se ofrece gratis, si el equipo de ventas o marketing se pone demasiado intenso, la percepción de la empresa puede empeorar. Hay que contactar al cliente como el cliente quiere, no solo de la forma que a uno le conviene, o el efecto termina siendo el contrario. Pero esto es difícil desde el punto de vista del diseño de incentivos.

  • He vivido experiencias extremas con algunos equipos de marketing SaaS que mandaban correos cada 5 a 15 minutos. A veces puede ser una acción aislada de un empleado, pero también parece que en algunos casos la gerencia o el propio CEO configuran al máximo las herramientas de email marketing.

  • También habría que incluir a los productos de Microsoft. Para registrarte tienes que crear una "cuenta profesional", y para eso no aceptan cuentas de gmail, entre otras barreras de entrada. Incluso si quieres usar un trial de 30 días para evaluar el producto, a veces ni siquiera puedes acceder por problemas con la cuenta. Si ya el trial es así de complicado, ni me imagino el proceso real de adopción. No me dan ganas de usar AI-based CRM, ERP, Dataverse ni nada por el estilo.

• Este fenómeno surge del problema principal-agente. La dirección de la empresa controla el presupuesto, pero quienes realmente usan el producto o la herramienta son los desarrolladores y el personal operativo. Desde la perspectiva de un fundador, suelen aconsejarte ganarte al usuario para que convenza al liderazgo, y la clave es que, como no puedes hablar con la persona que realmente tiene la tarjeta de crédito, debes apoyar al máximo al usuario para que pueda persuadir al liderazgo. Es decir, hacer que el usuario o desarrollador termine cumpliendo en la práctica una función de ventas. Pero aunque este enfoque puede servir para modelos premium y similares, me pregunto cómo superar esto en industrias como los sistemas hospitalarios y los EHR (historias clínicas electrónicas), donde la decisión de compra la toma unilateralmente la administración y el usuario real ni siquiera tiene oportunidad de probar el producto.

  • En la práctica también se ve mucho la situación inversa. Un vendedor pulido apunta a quien controla el presupuesto, bloquea la comunicación con los usuarios reales y cierra el contrato primero. Cuando los usuarios se quejan y señalan los problemas, el dinero ya fue pagado.

  • Para aplicar el consejo de "darle al usuario la mejor oportunidad de convencer al liderazgo, y hacerlo lucir bien solo con poder informar este tipo de elección al liderazgo", nosotros también llegamos a crear una "CEO Page" aparte: https://www.rsync.net/products/ceopage.html

• Como complemento sobre ventas enterprise: a veces ni la propia persona que toma decisiones entiende bien las dinámicas reales de poder dentro de la empresa. También hay que fijarse en si esa persona pertenece a un centro de costos o a un área que genera ingresos, si está impulsando una tecnología nueva o un producto ya estandarizado, y quién podría percibir este producto como una amenaza para su riesgo o su poder. Esa información debe reflejarse en la estrategia para decidir a quién venderle, a quién evitar y cuándo acercarse de forma pequeña o a gran escala.

• Una táctica que Slack y Postman usan mucho es algo como: "El 96% de su equipo ya usa nuestro producto. ¿No tiene más sentido comprarlo ahora?"

  • Y ahí te responden: "Si todos ya lo usan, ¿para qué comprarlo?". Esa pregunta muestra el nivel de desconexión entre comprador y usuario, sobre todo en entornos de pymes.

  • Por la misma razón también se ofrece software gratis a los estudiantes.

  • Esto también pasa mucho con equipos pequeños dentro de grandes empresas. Si hay un equipo de seguridad, puede ver como un problema que el uso esté repartido entre múltiples workspaces de Slack, así que funciona un argumento como: "En vez de que 400 personas usen 12 workspaces, mejor adminístrenlo con una sola cuenta oficial".

  • Una ventaja oculta del open source comercial o de modelos similares es que, mientras más crece la adopción individual, más crece también la adopción a nivel empresa.

• La empresa que fundé antes también se enfrentó a este problema. Tuvimos que venderle a equipos de desarrollo que no tenían poder real de compra. En empresas pequeñas, o en casos excepcionales donde sí había alguien con autoridad, cerrar contratos era fácil, pero en la mayoría de los casos había ciclos de venta largos y había que convencer a quienes tomaban las decisiones de arriba mediante ahorros de costos. Al final, este proceso tomaba mucho tiempo y la tasa de éxito era baja, y fue una de las principales razones del fracaso de la empresa. Me alegra que se hable más abiertamente de esto. Muchas pequeñas empresas lo viven, pero sorprendentemente no hay tanta orientación formal sobre el tema.

• Este modelo funciona bien cuando el usuario puede usar directamente el producto y además pertenece a la misma organización. Pero me pregunto cómo abordarlo cuando el usuario no está directamente relacionado con quien toma decisiones o cuando es difícil demostrar la justificación de compra, por ejemplo con algo como un llavero de entrada sin llave para autos. Para el conductor el beneficio es grande, pero desde la perspectiva del CTO de Ford, incluso la propuesta de reunión puede parecer innecesaria. ¿Qué consejo habría para salir al mercado después de desarrollar un producto en una situación así?

  • En esos casos, una estrategia bottom-up resulta atractiva. En vez de apuntar a la sede central de Ford, puede ser efectivo empezar con concesionarios de autos usados, talleres mecánicos o tiendas de accesorios. Tomando como ejemplo los sistemas de encendido remoto: los usuarios los necesitaban, pero a los fabricantes de autos no les interesaban mucho, así que al principio el mercado se formó por venta cruzada en tiendas de audio, y luego los fabricantes terminaron adoptándolos como opción. Yo también viví algo parecido con un dispositivo antirrobo: empezar en pequeño, construir base de clientes y luego acercarse gradualmente a empresas grandes puede ser muy efectivo.

  • Otra opción es destacar que la competencia ya está adoptando el llavero y así activar el FOMO (miedo a quedarse fuera).

• En enterprise no basta con venderle solo al CTO. Si es una empresa realmente central como AWS o Azure, quizá baste con convencer al CTO y a los ingenieros principales para impulsar un cambio en toda la organización, pero en la mayoría de los casos el software lo decide un gerente de línea, un director o el jefe de un área. Incluso cada departamento puede adoptar software distinto, así que hay que segmentar bien el objetivo.

• Los marketplaces B2B2C son especialmente interesantes. En un modelo donde no se le cobra al usuario "B2B" sino que se toma una comisión por transacción, se aprovecha a esos usuarios como una fuerza de ventas distribuida. Hay que ayudarlos a atraer clientes B2C a través de sus propias instancias. Desde el punto de vista del equipo fundador, a veces eso implica desarrollar muchas más cosas y puede sentirse caótico, pero tiene la ventaja de que la barrera de entrada inicial es baja y, cada vez que una cuenta transmite bien el valor al cliente final, los ingresos crecen de forma natural.

• En nuestra empresa también nos sentimos identificados con esto. Creamos una API de business intelligence relacionada con entity resolution, y como involucra a ingeniería, producto y data science, la separación entre comprador y usuario se vuelve compleja. Los ingenieros entienden intuitivamente lo difícil que es hacer matching de datos complejos de una empresa, pero los ejecutivos solo ven que el proyecto se retrasó. Por eso últimamente resulta más convincente acercarse con algo como: "Su equipo está dedicando meses enteros al matching de datos". Una empresa intentó construirlo internamente durante 10 años y todavía no funciona bien. Claro, también sentimos que la estrategia cambia según la empresa y la situación.

  • Me da curiosidad cómo están comunicando ese valor técnico a los usuarios. Quisiera preguntar si empiezan la conversación enviando primero correos en frío a ingenieros y luego expanden desde ahí.

• Otro modelo posible es algo como TikTok: tomar solo un porcentaje por cada transacción en la que intermedias.