Pedido para parar de tentar agendar uma ligação comigo
(matduggan.com)- Desde o momento em que se tenta experimentar rapidamente um novo produto SaaS, começam a chegar emails de vendas, listas de email e pedidos repetidos de ligação, consumindo continuamente o tempo do usuário
- O fluxo de compra acaba sendo puxado não pelas uma ou duas funções realmente necessárias, mas por um demo padronizado e por explicações no estilo “everything platform”, enquanto o vendedor e o engenheiro de vendas aumentam o número de chamadas
- Na etapa de aprovação de pagamento, cresce a pressão para envolver na ligação um decisor mais sênior, e a aprovação interna normalmente leva pelo menos um mês; em empresas Fortune 500, leva no mínimo 3 meses mesmo quando tudo corre bem
- Depois da compra, o vendedor desaparece e o que sobra para o usuário real é suporte ao cliente baseado em LLM, SLAs longos, limitações não documentadas e modos de falha
- O account rep se concentra mais em vender recursos extras do que em resolver problemas e, no fim, quando surge uma alternativa open source mais rápida e gratuita, tudo termina com o cancelamento da renovação e uma despedida por email
Contato que vem atrás do teste
- Ao testar um novo serviço ou produto, uma das maiores barreiras é o contato persistente que vem depois
- No começo, tudo parece um email inofensivo dizendo “me avise se tiver dúvidas”, mas logo alguém com cargo tipo “customer success fun-gineer” entra em contato para verificar a experiência com o trial
- Em geral, o usuário se cadastra para verificar uma única função específica
- Se ela não existir, perde o interesse e esquece
- A menos que ainda esteja em fase ativa de avaliação, é difícil entender por que estão entrando em contato
- Se continuar na mailing list, passa a receber sem parar avisos de novas releases e lançamentos
- Mesmo sem interesse, sempre fica a dúvida se a função desejada talvez tenha sido adicionada, então cancelar a inscrição vira uma decisão recorrente
- Se não houver release notes acessíveis, os emails de marketing acabam parecendo o único caminho para confirmar se houve alguma função nova
Quando o fluxo de compra vira “vamos marcar uma call”
- No pior caso, isso acontece justamente quando já é possível usar o serviço, e daí em diante a pessoa fica presa a uma sequência de calls
- Em vez de simplesmente digitar o número do cartão de crédito no site e terminar o processo, é preciso criar relacionamento com desconhecidos no Microsoft Teams
- Em uma equipe típica de vendas SaaS, aparecem dois papéis
- O vendedor fica alimentando o CRM e pressionando até fechar a venda
- A pessoa com título como “sales engineer” ou “customer success engineer” é uma das poucas que realmente leu a documentação e apresenta o produto como uma nova “everything platform”
- O demo inclui recursos que o usuário não quer
- A pessoa veio para verificar só uma ou duas funções, mas o template do demo não é flexível
- O vendedor tenta suavizar o clima com um elogio leve, dizendo que o usuário parece ser técnico
- O demo do sales engineer quebra nos piores momentos, seguido da explicação de que “normalmente funciona bem”
Segurança, compliance e aprovações cada vez mais longas
- Em algum momento, ao perguntar sobre compliance e segurança, o que chega é um pacote de certificações sem sentido prático
- A documentação de certificação é tratada menos como prova de que os itens foram realmente cumpridos e mais como algo que mostra que é possível parecer que foram cumpridos de forma convincente
- Depois que o demo e a construção de relacionamento acabam, a equipe de vendas tenta colocar o decisor acima do usuário na ligação
- Como esse decisor não quer ouvir pitches de vendas de várias empresas toda semana, a tarefa de resumir a proposta acaba caindo sobre o usuário
- Se o usuário realmente considerar o produto importante, precisa contatar diretamente as pessoas necessárias para a aprovação interna
- Esse processo leva no mínimo um mês
- Em uma empresa Fortune 500, leva pelo menos 3 meses mesmo quando tudo sai perfeitamente
- A adoção de um produto que supostamente economizaria tempo vira um grande projeto, e o usuário passa a se perguntar se não teria sido melhor fazer engenharia reversa da ferramenta por conta própria
Limitações e suporte ao cliente depois da compra
- Quando a aprovação termina e o dinheiro muda de mãos, o vendedor desaparece e o usuário é entregue ao Customer Service, ou seja, ao LLM
- A “limitless, cloud-based platform” revela várias limitações no uso real
- Em um dia, tudo funciona normalmente
- No dia seguinte, algum limite invisível é ultrapassado e o fluxo inteiro desmorona
- A documentação é organizada para destacar os pontos positivos, então é difícil encontrar alertas ou limitações
- O suporte por LLM repete os mesmos links da documentação e só depois disso permite enviar email para uma pessoa real
- O SLA do email de suporte é longo, algo como 72 business hours, tratado como consequência de não ter sido escolhido o Super Enterprise Plan™
- A resposta termina dizendo que algum limite invisível foi atingido e que é preciso reestruturar o workflow
- Quanto mais se usa o produto, maior fica a lista de modos de falha não documentados
- Exemplo: “se você apertar dois botões rápido demais, o iFrame dá erro”
- Parece que a stack deve estar registrando o erro, mas ninguém entra em contato para explicar a causa nem ajudar a corrigir
Account rep, upsell, open source e despedida
- Um dia, um novo account rep entra em contato pedindo uma call para discutir como o produto está sendo usado e como poderia ajudar
- Essa call se parece mais com outro pitch de vendas do que com coleta de feedback ou resolução de problemas
- A pessoa ouve a lista de problemas e diz que “vai verificar”, mas o objetivo real logo se revela: convencer a comprar recursos extras
- Esses recursos extras incluem coisas como SSO ou acesso à API, itens que quase não custam nada ao fornecedor, mas fazem enorme diferença para o usuário
- O usuário então precisa decidir se compra mais do produto para conseguir funções básicas ou se remove tudo e segue por outro caminho
- No fim, algum desenvolvedor open source cria uma ferramenta gratuita que faz a mesma coisa
- O nome pode ser algo ridículo como CodeSquish, Dojo ou GitCharm
- A descoberta vem por meio de um colega e, ao olhar melhor, ela faz tudo o que era necessário, não custa nada e é 100 vezes mais rápida
- Mesmo sendo mantida por uma única pessoa e tendo apenas um servidor no Discord como fórum, ainda assim é muito melhor do que o produto comercial
- Por causa do contrato, a despedida é adiada, mas no fim o usuário avisa o Finance para não renovar
- Quando a interrupção da renovação aparece, a equipe do fornecedor de repente demonstra grande interesse e tenta convencer de que a ferramenta open source é na verdade inferior
- O usuário diz que “vai discutir internamente”, mas na prática não discute nada; no final, comunica a despedida por email e bloqueia o domínio
1 comentários
Comentários do Hacker News
Investidores também costumam ver esses processos como sinal de maturidade e prática de alto nível.
A abordagem oposta é divulgar as informações com o máximo de transparência possível e sem bloqueios, falar honestamente primeiro sobre os pontos fracos, conectar o cliente diretamente a alguém que possa resolver o problema quando ele quiser falar com uma pessoa, não deixar um atendente de IA ligar a menos que o cliente peça, e deixar claro imediatamente que é uma IA, oferecer opções flexíveis de assinatura de e-mail, como mensal/trimestral/anual/apenas notas de release, e, se o produto não for adequado, sugerir alternativas úteis, como outro produto mais apropriado.
Por causa da precificação baseada em valor, muitas empresas acabam nessa situação. Em vez de ter um preço padrão, investigam o cliente em detalhe, estimam o valor que ele obterá com o produto e definem o preço de acordo; em teoria isso maximiza a receita, mas é lento e invasivo.
Usuários do plano gratuito, sem saber nem programação muito básica, podem tomar todo o tempo do suporte técnico assim que você permite.
Divulgar o uso de IA, oferecer várias opções de newsletter e ser honesto quando não houver encaixe são coisas razoáveis e que, na prática, funcionaram bem. Mas as três primeiras podem destruir o produto. Talvez eu só seja cínico, ou talvez tenha lidado mal com isso até agora.
Isso vale se a premissa for criar um unicórnio com dinheiro de investidores; para o crescimento lento, mas constante, de uma empresa de uma pessoa só com outra renda complementar, essa abordagem pode fazer sentido.
Concorrência sem regulação é uma corrida para o fundo do poço, em que vencem as táticas mais antiéticas, invasivas, na fronteira da ilegalidade e manipulativas.
Não vence o melhor produto, vence o melhor marketing; não vence a experiência amigável ao cliente, vence a taxa de conversão por coerção; e o preço não é o valor do produto e do serviço, mas o máximo que as pessoas conseguem pagar.
Mesmo com plano gratuito ou trial e uma documentação decente, elas exigem uma demonstração. Preferem desperdiçar meu tempo a fazer alguém do próprio lado avaliar.
Usam você como referência de comparação de preço/funcionalidades para conseguir renovar mais barato o contrato com um concorrente enterprise, mesmo sem nenhuma intenção real de trocar.
Você precisa preencher questionários de segurança intermináveis sem nem saber se conseguirá vender. Como se alguém gostasse de responder mais de 100 perguntas às 23h de uma sexta-feira.
O processo de compras leva de 3 a 6 meses, e muitas vezes entram no meio um ou dois revendedores terceirizados de software que só se importam com a própria margem. É preciso dizer à CDW que você não vai reduzir o preço em 15% só para eles ganharem dinheiro.
Mesmo depois do contrato fechado, o dinheiro só entra 60 a 90 dias depois, mas o serviço já precisa ser prestado, e o fluxo de caixa fica apertado. Às vezes o gerente do banco liga perguntando por que a margem e o limite do cartão de crédito estão estourados.
Por isso, para grandes empresas, vou sempre cobrar caro.
Ajuda muito deixar claro de antemão o que fazemos e o que não fazemos. Ainda pedem coisas como formulários de procurement, mas pelo menos podemos recusar e alinhar expectativas.
https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
Se for preciso um pouco de customização, ou se uma startup em estágio inicial está colaborando com um cliente-piloto para refinar e provar o product-market fit, fica mais difícil. Se o cliente não é outra startup do portfólio de um investidor, mas uma empresa de verdade, e você afeta mais do que uma equipe minúscula lá dentro, mesmo já tendo o ouvido do CEO, precisa se preparar para meses de reuniões intermináveis com stakeholders de vários departamentos.
Do ponto de vista de uma startup inicial ágil, você sente na pele que, em teoria, deveria ter uma vantagem enorme de inovação sobre uma grande empresa lenta e pesada, porque elas parecem incapazes de fazer qualquer coisa.
Mas, se você cometeu o erro de precisar da aprovação justamente dessa grande empresa lenta e pesada que não consegue fazer nada, então a maior parte das barreiras de movimentação dela vira sua barreira também.
Já vi uma variação ainda pior da mesma história. Um engenheiro que já operava com sucesso uma boa solução open source na equipe ouviu de outro engenheiro que uma ofensiva de vendas enterprise de um produto horrível tinha caído sobre ele e tentou soar o alarme, mas já era tarde.
Alguém mais acima no organograma já tinha apostado capital político e assinado; em alguns casos, gastar dinheiro da empresa naquele produto específico tinha virado métrica de desempenho individual. Então todas as alternativas foram bloqueadas, todo mundo esperou meses pelo fechamento da venda, depois esperou mais um mês para o TI configurar SSO e banco de dados, e foi forçado a migrar de uma solução que funcionava bem para uma porcaria.
No fim, o contrato não é renovado e quem empurrou a decisão consegue salvar as aparências, mas metade das pessoas que tiveram que carregar aquilo já foi para empresas melhores, um quarto recebeu PIP ou teve a carreira estagnada por ser atrapalhado pelo produto ruim, e a maior parte do quarto restante provavelmente será demitida no ano seguinte.
É preciso simplesmente dizer NÃO a vendas enterprise. A única coisa pior do que ter que fazer vendas enterprise para vender seu próprio produto é, como funcionário, ser obrigado a usar uma decisão ruim de compra criada por outra venda enterprise.
Só que, quando você encontra uma solução open source, ela em geral é melhor e permite fazer tudo o que você quer. Com apenas
docker compose up, já dá até para testar de forma simples.Mas, na etapa de implantação, compliance só verifica se há certificação SOC2 e bloqueia com força, exigindo uma due diligence profunda do código só porque, em tese, qualquer pessoa no mundo pode alterá-lo.
O gerente pergunta como algo gratuito e open source pode ser tão bom, e uma equipe sobrecarregada geralmente não gosta de ter que dar suporte a mais um software imprevisível
Então, no fim, a escolha passa a ser entre queimar dinheiro e paciência com um SaaS ruim, ciclos de venda intermináveis e inúteis, e um aprisionamento a fornecedor horrível e caro; ou usar e operar open source internamente, queimando um pouco de dinheiro e paciência
Normalmente escolhem open source. Especialmente se o SaaS não oferece auto-onboarding rápido e fácil, um período de avaliação significativo e preços previsíveis e transparentes
E, se a adoção for ampla, passam a apoiar o autor ou, no caso de um software open source mais complexo, reservam orçamento para um plano de suporte. Fazem isso mesmo que, na prática, seja bem provável que quase nunca precisem
“[…] procurei CodeSquish no Google e ele fazia tudo de que eu precisava, custava 0 e tinha desempenho 100 vezes melhor. Mesmo sendo mantido por um eremita que sai de vez em quando de sua fazenda em Vermont para fazer push de código no próprio repositório git self-hosted.”
Esse pobre mantenedor eremita descobre, numa terça-feira à tarde, que a sua empresa ganha US$ 100 milhões por ano com “CodeSquish” sem contribuir com nada. Enquanto alimenta as galinhas na fazenda em Vermont, ele começa a questionar em silêncio suas escolhas de vida — ou melhor, suas escolhas de licença
A maior parte dos open source ou SaaS, mesmo sendo útil em empresas Fortune 500, fica mais perto de uma conveniência, então é difícil atribuir valor. No texto, também dá para ver o fornecedor de SaaS se enfeitando para parecer mais valioso para grandes empresas, ligando para pessoas e empurrando bobagem usando precificação baseada em valor
Também não vi muitos casos em que uma empresa opera um sistema open source e depois o revende. Normalmente querem possuir toda a propriedade intelectual e, como no texto, acabam recriando a própria porcaria deles
O que a Amazon fez com a Elastic foi possível porque a Elastic tinha construído uma marca. Não dá para fazer isso com um projeto aleatório. Um projeto pode ser usado para operar infraestrutura, mas é muito difícil atribuir valor a uma biblioteca ou projeto específico
A Amazon ganha dinheiro porque é a Amazon, não porque usa o kernel Linux. De qualquer forma, é uma questão difícil de organizar mentalmente
Primeiro, muito disso talvez seja necessário para vender B2B e manter metade da indústria de software funcionando. A empresa vendedora pode precisar entrar em contato várias vezes, envolver engenheiros de vendas e ajudar a alinhar todos os tomadores de decisão. Caso contrário, nada anda. Os compradores estão ocupados demais e vender para grandes empresas é complexo demais, então parte disso é um mal necessário para manter as transações B2B em movimento
Segundo, seria bom imaginar empresas comprando melhor de verdade. Grandes empresas gastam milhões de dólares em software enterprise inchado, mesmo quando uma startup poderia construir algo 10 vezes melhor por um décimo do custo. Se fosse mais fácil vender para elas, todo mundo poderia usar tecnologia melhor sem essa loucura
Concordo que a experiência do texto original corrói a alma, mas os clientes também poderiam se ajudar um pouco: sobraria mais dinheiro no bolso e eles teriam tecnologia melhor
Produto enterprise é simplesmente outra categoria, e isso é separado do produto em si
“Vi no LinkedIn que você fala espanhol. Ouvi dizer que a forma como ‘¡Qué chévere!’ traz energia e brilho a uma conversa é singularmente encantadora. Teve alguma oportunidade de praticar recentemente?”
“Desenvolvemos ferramentas de automação de compliance que se adapitates às regulamentações em mudança, reduzindo overhead enquanto garantem programas de investimento seguros e eficientes.”
Nenhuma pessoa veria no LinkedIn meu marcador de espanhol como “competência profissional limitada” e diria algo como a primeira frase. E “adapitates”, na segunda, não é uma palavra real, é uma alucinação. https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
Vendas em si não é o problema, e a maioria das pessoas aceita algum nível de abordagem comercial. Já recebi um cold email não personalizado de uma empresa de replicação de dados; era curto, direto e, para um spam, soava sincero, então acabei ficando realmente interessado no produto
Todas as empresas do planeta estão experimentando essa tecnologia, e se não dermos um sinal forte quando elas errarem, estaremos prendendo nossos futuros eus a esse lixo
Os clientes que querem esses recursos precisam deles, seja qual for o custo — suporte, relatório SOC-2 etc. — e essa estrutura subsidia os clientes que não precisam. Se ajudar, dá para encarar o pacote premium com SSO e SLA como o preço real do produto
Para começo de conversa, quase não existe precificação realmente baseada em custo na área de tecnologia
Na prática, isso significa que a empresa precisa arcar com o custo total de pelo menos 1 funcionário adicional. Esse custo total fica mais ou menos em 2 vezes o salário; divida isso pelo número de clientes que exigem esse SLA e você começa a ver quanto precisa cobrar
Se sei que só vou receber uma resposta três dias depois, eu mesmo pesquiso o que é óbvio e só entro em contato com o suporte quando não consigo encontrar a resposta de outra forma. Mas SLAs mais curtos, especialmente suporte por telefone, fazem certos tipos de cliente simplesmente copiar e colar qualquer mensagem de erro que encontram e esperar que a equipe de suporte resolva, mesmo que o erro talvez nem tenha vindo do produto. Já passei por isso
Subsídios cruzados podem surgir por causa de regulação ou quando uma empresa tenta monopolizar um mercado
O preço do produto é determinado mais por quanto é possível cobrar e pelos custos variáveis do que pelo custo de desenvolvimento. Como você apontou, isso leva à discriminação de preços e, por fora, pode parecer que um grupo está subsidiando outro, mas na prática talvez não seja o caso
Eu gostaria de ver um modelo de custo marginal e de tomada de decisão ideal. Decidir criar um recurso exclusivo para clientes de alto valor só é lucrativo quando esses clientes pagam por esse recurso. Outros clientes podem acabar recebendo o recurso, mas isso não é “subsídio”. Só não sei qual seria uma palavra melhor
Se você oferece uma abordagem direta, sem enrolação, demo imediata, um período de avaliação significativo, onboarding fácil etc., acaba perdendo clientes que esperam o teatrinho de vendas de sempre
Fonte: eu uso a abordagem direta
Então por que falar por telefone com um engenheiro de vendas? E-mail é só apagar
Se, como na situação descrita, a pessoa técnica está bloqueando o decisor final, vira mais uma aposta e frequentemente falha
Os produtos em que quero colocar o cartão de crédito e começar na hora são apenas softwares de uso geral, como AWS EC2 ou serviços de registro de domínio
Às vezes as linhas se confundem no modelo de preço/vendas, como quando um produto enterprise é precificado como software de uso geral. Normalmente isso é sinal de que a empresa é imatura
Software na faixa de dois ou três dígitos não deveria ter equipe de vendas. Software de cinco a seis dígitos ou mais precisa obrigatoriamente de pessoas no processo de vendas e onboarding, porque uma grande parte do que estou pagando é suporte
O problema é que, normalmente, o que queremos saber não é “vocês conseguem atender a este caso de uso?”, mas “quão bem vocês atendem a este caso de uso?”. É difícil avaliar sem mexer no software diretamente
Não recebo pitch de vendas com tanta frequência, mas tenho uma postura parecida por outros motivos. Quero deixar tudo por escrito, para o caso de alguém dizer sim só para colocar o pé na porta e depois dizer não nos detalhes das condições