Dejen de intentar coordinar una llamada conmigo
(matduggan.com)- Desde el momento en que uno solo quiere probar ligeramente un nuevo producto SaaS, empiezan a llegar correos de ventas, listas de correo y solicitudes repetidas de llamadas, consumiendo cada vez más tiempo del usuario
- El proceso de compra termina girando no alrededor de la una o dos funciones realmente necesarias, sino de demos prefijadas y explicaciones estilo “everything platform”, mientras el representante comercial y el ingeniero de ventas siguen sumando llamadas
- En la etapa de aprobación del pago, aumenta la presión para meter en la llamada a responsables de más alto nivel, y la aprobación interna normalmente toma al menos un mes; en una Fortune 500, incluso si todo sale bien, toma como mínimo 3 meses
- Después de la compra, el representante de ventas desaparece y al usuario real le quedan un soporte al cliente basado en LLM, SLA largos, límites no documentados y modos de fallo
- El ejecutivo de cuenta se enfoca más en vender funciones adicionales que en resolver problemas y, al final, cuando aparece una alternativa open source más rápida y gratuita, todo termina con no renovar el contrato y una despedida por correo
Contacto que llega después de la prueba
- Uno de los mayores obstáculos al probar un servicio o producto nuevo es el contacto persistente que sigue después
- Al principio empieza con un correo inofensivo de “avísanos si tienes alguna pregunta”, pero pronto aparece alguien con un cargo como “customer success fun-gineer” diciendo que quiere revisar la experiencia de la prueba
- Normalmente el usuario se registra para verificar solo una función específica
- Si esa función no existe, pierde el interés y se olvida del producto
- A menos que todavía lo esté evaluando, es difícil entender por qué lo están contactando
- Si uno se queda en la lista de correo, sigue recibiendo avisos de nuevas versiones y lanzamientos
- Aunque no haya interés, cada vez surge la duda de cancelar la suscripción porque quizá sí agregaron la función deseada
- Si no hay notas de versión accesibles, los correos de marketing terminan pareciendo la única forma de verificar si añadieron funciones
Cuando el proceso de compra se convierte en “hagamos una llamada”
- En el peor de los casos, el momento más problemático es cuando por fin ya se puede usar el servicio, porque desde ahí uno queda atado a una serie de llamadas
- En vez de terminar ingresando la tarjeta en el sitio web, hay que construir una relación con desconocidos en Microsoft Teams
- En un equipo comercial típico de SaaS aparecen dos roles
- El representante de ventas mete datos en el CRM y sigue empujando hasta cerrar la venta
- La persona con cargo de “sales engineer” o “customer success engineer” es de las pocas que realmente leyó la documentación, y explica el producto como si fuera una nueva “everything platform”
- El demo incluye funciones que el usuario no quiere
- El usuario llegó para revisar una o dos funciones, pero la plantilla fija del demo no es flexible
- El representante comercial intenta suavizar el ambiente con halagos ligeros, como decir que el usuario “es técnico”
- El demo del ingeniero de ventas falla en el peor momento, y después llega la explicación de que “normalmente sí funciona”
Seguridad, compliance y aprobaciones cada vez más largas
- En algún punto, cuando uno pregunta por compliance y seguridad, lo que llega es un paquete de certificaciones sin mucho sentido
- Los documentos de certificación se tratan más como algo que demuestra que pueden parecer haber hecho las cosas correctamente, que como evidencia real de que las hicieron
- Una vez terminados el demo y la construcción de relación, el equipo comercial intenta meter en la llamada al responsable superior de la toma de decisiones del usuario
- Como esos responsables no quieren escuchar pitches de ventas de varias empresas cada semana, el trabajo de ordenar la propuesta termina recayendo en el usuario
- Si el usuario realmente considera importante el producto, tiene que contactar directamente a las personas necesarias para la aprobación interna
- Este proceso toma al menos un mes
- En una empresa Fortune 500, incluso si todo avanza perfectamente, toma como mínimo 3 meses
- Lo que se iba a adoptar para ahorrar tiempo se convierte en un gran proyecto, y el usuario termina preguntándose si no habría sido mejor aplicar ingeniería inversa a la herramienta por su cuenta
Lo que queda después de comprar: límites y soporte al cliente
- Cuando termina la aprobación y cambia de manos el dinero, el representante de ventas desaparece y el usuario queda en manos de Customer Service, es decir, de un LLM
- La “limitless, cloud-based platform” empieza a mostrar muchos límites en el uso real
- Un día funciona bien
- Al día siguiente supera un umbral invisible y todo el flujo se rompe
- La documentación está organizada para destacar ventajas, así que cuesta encontrar advertencias o limitaciones
- El soporte al cliente basado en LLM repite los mismos enlaces a la documentación, y solo después permite enviar un correo a una persona real
- El SLA del correo de soporte es largo, algo como 72 business hours, y se justifica porque no se eligió el Super Enterprise Plan™
- La respuesta termina siendo algo como que se alcanzó un límite invisible y que hay que reconfigurar el workflow
- Cuanto más se usa, más crece la lista de modos de fallo no documentados
- Ejemplo: “si haces clic demasiado rápido en dos botones, el iFrame falla”
- Parece que el stack debe estar registrando el error, pero nadie se comunica para explicar la causa ni ayudar a corregirlo
Ejecutivo de cuenta, upselling, open source y despedida
- Un día se pone en contacto un nuevo ejecutivo de cuenta (account rep) y pide una llamada para hablar sobre cómo se está usando el producto y cómo podría ayudar
- Esa llamada se parece más a otro pitch de ventas que a una instancia para recoger feedback o resolver problemas
- La persona escucha la lista de problemas y dice que “lo revisará”, pero el verdadero objetivo termina siendo convencer al usuario de comprar más funciones
- Las funciones adicionales son cosas como SSO o acceso a API: cuestan casi nada al proveedor, pero hacen una gran diferencia para el usuario
- El usuario tiene que decidir si compra más del producto para obtener funciones básicas, o si lo elimina por completo y toma otro camino
- Al final, algún desarrollador open source crea una herramienta gratuita que hace lo mismo
- El nombre puede ser algo ridículo como CodeSquish, Dojo o GitCharm
- Uno se entera por un colega y, al revisarla, resulta que hace todo lo necesario, no cuesta nada y es 100 veces más rápida
- Aunque la mantenga una sola persona y su foro sea solo un servidor de Discord, sigue siendo muchísimo mejor que el producto comercial
- La despedida se retrasa por el contrato, pero al final se le dice a Finance que no renueve
- Cuando se ve que no habrá renovación, el equipo del proveedor de pronto muestra muchísimo interés e intenta convencer al usuario de que la herramienta open source en realidad es inferior
- El usuario responde “lo vamos a discutir internamente”, pero en realidad no lo discute, y al final se despide por correo y bloquea el dominio
1 comentarios
Opiniones de Hacker News
Los inversionistas también suelen ver esos procesos como una señal de madurez y una práctica de primer nivel.
El enfoque opuesto es divulgar la información con la mayor transparencia posible y sin bloquearla; hablar primero y con honestidad de las debilidades; cuando un cliente quiere hablar con una persona, conectarlo de inmediato con alguien que pueda resolver el problema; no hacer que un agente de IA llame a menos que el cliente lo pida, y aclarar de inmediato que es una IA; ofrecer opciones flexibles de suscripción por correo, como solo mensual/trimestral/anual/notas de lanzamiento; y, si el producto no encaja, sugerir alternativas útiles, como otros productos más adecuados.
Muchas empresas terminan en esta situación por la fijación de precios basada en valor. En vez de tener precios estándar, investigan a fondo al cliente, estiman el valor que obtendrá con el producto y fijan el precio en función de eso. En teoría maximiza los ingresos, pero es lento e invasivo.
Un usuario del plan gratuito que ni siquiera sabe programar lo más básico puede llevarse todo el tiempo de soporte técnico en cuanto se lo permites.
Revelar el uso de IA, ofrecer varias opciones de newsletter y decir con honestidad cuando algo no encaja son cosas razonables y, de hecho, funcionaron bien. Pero las primeras tres pueden arruinar el producto. Aunque tal vez yo sea cínico o haya manejado mal las cosas hasta ahora.
Eso aplica si la premisa es construir un unicornio con dinero de inversionistas; para el crecimiento lento pero constante de una empresa unipersonal con otros ingresos secundarios, este enfoque podría encajar.
La competencia sin regulación es una carrera hacia el fondo, donde ganan las tácticas más poco éticas, invasivas, al borde de la legalidad y manipuladoras.
No gana el mejor producto, sino el mejor marketing; no gana la orientación al cliente, sino la conversión mediante coerción; y el precio no lo determina el valor del producto o servicio, sino el monto máximo que la gente puede pagar.
Exigen demos aunque exista un plan gratuito o una prueba y buena documentación. Prefieren hacerme perder el tiempo a que alguien de su lado lo evalúe.
En realidad no tienen intención de cambiarse, pero te usan como referencia de precio/funcionalidades para lograr una renovación más barata con un competidor enterprise.
Tienes que llenar cuestionarios de seguridad interminables sin saber siquiera si podrás venderles. Como si a uno le encantara responder más de 100 preguntas un viernes a las 11 de la noche.
El proceso de compras tarda de 3 a 6 meses, y a menudo se meten uno o dos revendedores de software externos que solo se preocupan por su propio margen. Hay que decirle a CDW que no voy a bajar el precio 15% para que ustedes ganen dinero.
Incluso después de cerrar el contrato, el dinero llega 60 a 90 días después, pero el servicio ya debe prestarse y el flujo de caja se vuelve pesado. Hasta puede llamarte el ejecutivo del banco para preguntar por qué el margen y el límite de la tarjeta de crédito están al tope.
Por eso, a las grandes empresas definitivamente les voy a cobrar caro.
Ayuda muchísimo decir de antemano con claridad qué haces y qué no haces. Igual siguen pidiendo cosas como formularios de compras, pero al menos puedes negarte y establecer expectativas.
https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
Si se necesita algo un poco personalizado, o si una startup temprana está colaborando con un cliente piloto para refinar y demostrar el encaje producto-mercado, se vuelve más difícil. Si el cliente no es otra startup dentro del portafolio de un inversionista, sino una empresa real, y afecta a algo más que un equipo muy pequeño dentro de ella, aunque ya tengas la atención del CEO, tienes que prepararte para meses de reuniones interminables con stakeholders de varios departamentos.
Como startup temprana y ágil, sientes que en teoría deberías tener una enorme ventaja de innovación frente a una gran corporación lenta y pesada, porque ellos parecen incapaces de hacer cualquier cosa.
Pero si cometiste el error de necesitar la aprobación de esa gran corporación lenta y pesada que no parece capaz de hacer nada, entonces la mayoría de sus barreras de movimiento se vuelven tus barreras.
También he visto una variante peor de la misma historia: un ingeniero cuyo equipo ya operaba con éxito una buena solución open source intentó dar la alarma al enterarse de que a otro ingeniero le había caído una ofensiva de ventas enterprise de un producto basura, pero ya era demasiado tarde.
Alguien más arriba en el organigrama ya había apostado capital político y firmado, y en algunos casos gastar el dinero de la empresa en ese producto específico se convirtió en un indicador de desempeño personal. Así que todas las alternativas quedaron bloqueadas, todos esperaron meses a que se cerrara la venta, luego esperaron otro mes a que IT configurara SSO y la base de datos, y finalmente fueron obligados a migrar de una solución que funcionaba bien a una basura.
Al final el contrato no se renueva y quienes lo impulsaron salvan las apariencias, pero la mitad de las personas que tuvieron que cargar con eso se fueron a mejores empresas; una cuarta parte recibió un PIP o vio estancada su carrera porque el producto basura las obstaculizó; y la mayor parte del cuarto restante probablemente será despedida al año siguiente.
A las ventas enterprise simplemente hay que decirles NO. Lo único peor que tener que hacer ventas enterprise para vender tu producto es que, como empleado, te obliguen a usar una mala decisión de compra creada por las ventas enterprise de otra empresa.
Pero cuando encuentras una solución open source, por lo general es mejor y puede hacer todo lo que quieres. Con solo
docker compose upya puedes probarla fácilmente.Sin embargo, en la etapa de despliegue, compliance solo verifica la certificación SOC2 y bloquea con fuerza el avance, exigiendo una due diligence profunda del código porque, en teoría, cualquiera en el mundo puede modificarlo.
El gerente pregunta cómo puede ser tan bueno si es gratis y de código abierto, y a los equipos sobrecargados por lo general no les gusta tener que dar soporte a otro software impredecible más
Así que al final la elección es entre quemar dinero y nervios en un SaaS pésimo, ciclos de venta interminables e inútiles, y una dependencia de proveedor horrible y cara; o quemar un poco de dinero y nervios adoptando y operando open source internamente
Normalmente se elige open source. Sobre todo si el SaaS no ofrece un self-onboarding rápido y sencillo, un período de evaluación significativo, y precios predecibles y transparentes
Y si se adopta ampliamente, se apoya al autor o, si es software open source más complejo, se asigna presupuesto para un plan de soporte. Aunque en la práctica sea muy probable que casi nunca haga falta
“[…] Busqué CodeSquish en Google y hacía todo lo que necesitaba, costaba 0, y tenía un rendimiento 100 veces mejor. Y eso que lo mantenía un ermitaño que de vez en cuando salía de su granja en Vermont para hacer push de código a su repositorio git autoalojado.”
Ese pobre mantenedor ermitaño se entera un martes por la tarde de que tu empresa gana 100 millones de dólares al año con “CodeSquish” sin aportar nada. Mientras alimenta a las gallinas en su granja de Vermont, empieza a cuestionarse en silencio sus decisiones de vida; no, sus decisiones de licencia
La mayoría del open source o SaaS, aunque sea útil en una compañía Fortune 500, se parece más a una comodidad y es difícil asignarle valor. En el texto también se ve cómo el proveedor SaaS adorna las cosas para parecer más valioso ante una gran empresa, llama a la gente para venderles humo y usa precios basados en valor
Tampoco he visto muchos casos en los que una empresa opere un sistema open source y luego lo revenda. Normalmente quieren poseer toda la propiedad intelectual y terminan recreando su propia porquería, como en el texto
Lo que Amazon le hizo a Elastic fue posible porque Elastic había construido una marca. No se puede hacer eso con un proyecto cualquiera. Puedes usar cierto proyecto para operar infraestructura, pero atribuir valor a una biblioteca o proyecto específico es muy difícil
Amazon gana dinero porque es Amazon, no porque use el kernel de Linux. En cualquier caso, es un problema difícil de ordenar mentalmente
Primero, buena parte de esto quizá sea necesario para hacer ventas B2B y mantener en marcha la mitad de la industria del software. La empresa vendedora puede tener que contactar varias veces, asignar ingenieros de ventas y ayudar a alinear a todos los tomadores de decisiones. Si no, el asunto directamente no avanza. Los compradores están demasiado ocupados y venderle a una gran empresa es demasiado complejo, así que parte de esto es un mal necesario para que las operaciones B2B sigan avanzando
Segundo, sería bueno imaginar que las empresas realmente compraran mejor. Las grandes compañías gastan millones de dólares en software enterprise inflado, aunque una startup podría crear algo 10 veces mejor por una décima parte del costo. Si fuera más fácil venderles, todos podrían usar algo mejor sin esta locura
Coincido en que la experiencia del texto original desgasta el alma, pero si los clientes también se ayudaran un poco a sí mismos, les quedaría más dinero en el bolsillo y obtendrían mejor tecnología
Los productos enterprise simplemente son otra categoría, y eso es independiente del producto en sí
“Vi en LinkedIn que hablas español. Escuché que ‘¡Qué chévere!’ tiene una forma única y encantadora de aportar energía y brillo a una conversación. ¿Has tenido oportunidad de practicarlo últimamente?”
“Desarrollamos herramientas de automatización de compliance que se adapitates a regulaciones cambiantes, reduciendo costos indirectos mientras garantizamos programas de inversión seguros y eficientes.”
Ninguna persona vería en LinkedIn mi marca de español “competencia laboral limitada” y diría algo como la primera frase. Y el “adapitates” de la segunda no es una palabra real, sino una alucinación. https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
El problema no es la venta en sí; la mayoría de la gente acepta cierto grado de venta. Una vez recibí un correo frío no personalizado de una empresa de replicación de datos: era breve, iba al grano y, para ser spam, se sentía auténtico, así que de hecho me interesó el producto
Todas las empresas del planeta están experimentando con esta tecnología, y si no les damos una señal fuerte cuando la arruinan, estamos atando a nuestro yo futuro a esta basura
Los clientes que quieren esas funciones necesitan soporte o reportes SOC-2 cuesten lo que cuesten, y con eso subsidian a los clientes que no los necesitan. Si ayuda, puedes ver el paquete avanzado con SSO y SLA como el precio real del producto
Para empezar, en tecnología casi no existe una fijación de precios realmente basada en costos
En la práctica, eso significa que la empresa tiene que asumir el costo totalmente cargado de al menos 1 empleado adicional. Si se estima ese costo totalmente cargado como aproximadamente 2 veces el salario, y se divide entre la cantidad de clientes que exigen ese SLA, empieza a verse cuánto habría que cobrar
Si uno sabe que recién va a recibir respuesta tres días después, busca por su cuenta lo obvio y solo contacta a soporte cuando no puede encontrar la respuesta por otros medios. Pero un SLA más corto, sobre todo el soporte telefónico, hace que cierto tipo de clientes copie y pegue tal cual todos los mensajes de error que encuentra, aunque quizá ni siquiera provengan del producto, y espere que el equipo de soporte se los resuelva. Lo viví en carne propia.
Los subsidios cruzados pueden surgir por regulación o cuando una empresa intenta monopolizar un mercado.
El precio de un producto se determina más por cuánto se puede cobrar y por los costos variables que por el costo de desarrollo. Como señalaste, esto lleva a discriminación de precios y, desde afuera, puede parecer que un grupo subsidia a otro, pero en realidad quizá no sea así.
Me gustaría ver un modelo de costo marginal y toma de decisiones ideal. Decidir crear una función exclusiva para clientes grandes solo es rentable si esos clientes pagan por esa función. Otros clientes pueden terminar obteniéndola, pero eso no es un “subsidio”. Aunque no sé cuál sería una palabra mejor.
Si ofreces un enfoque directo y sin tonterías, una demo inmediata, un período de evaluación significativo y un onboarding sencillo, terminas perdiendo a clientes que esperan el jueguito de ventas habitual.
Fuente: yo uso el enfoque directo.
Entonces, ¿por qué hablar por teléfono con un ingeniero de ventas? Los correos simplemente se pueden borrar.
Si, como en la situación descrita, la persona técnica está bloqueando al responsable final de la decisión, es más una apuesta y falla con frecuencia.
Los únicos productos con los que quiero poner la tarjeta de crédito y empezar de inmediato son software de uso general, como AWS EC2 o servicios de registro de dominios.
A veces se cruzan los cables entre el modelo de precios y el de ventas, por ejemplo cuando se pone precio a un producto enterprise como si fuera software genérico. Suele ser una señal de que la empresa es inmadura.
El software de precio de dos o tres cifras no debería tener equipo de ventas. El software de cinco o seis cifras, o más, definitivamente necesita personas en el proceso de ventas y onboarding. Porque una gran parte de lo que pago es soporte.
El problema es que lo que normalmente queremos saber no es “¿puede cubrir este caso de uso?”, sino “¿qué tan bien cubre este caso de uso?”. Eso es difícil de evaluar sin tocar el software directamente.
No recibo pitches de ventas tan seguido, pero por otros motivos tengo una actitud similar. Quiero dejar todo por escrito, por si primero dicen que sí para meter el pie en la puerta y luego, en los detalles, resulta que no.