Revisão: Fabio Ebner, especialista certificado em ClickUp e monday.com e instrutor certificado SENAC · atualizado em 18 de agosto de 2026
A demo não é o teste. É a apresentação. Quem escolhe o cenário, os dados e a ordem das telas é o fornecedor, e ele conhece o caminho feliz. Avaliar de verdade é inverter esse roteiro: escrever de 5 a 8 casos reais do seu negócio antes da primeira reunião, exigir que a ferramenta rode um processo do começo ao fim com as pessoas que vão usar, fazer as perguntas que a apresentação não cobre — saída de dados, autonomia de configuração, estouro de limite, retenção de clientes do seu porte — e somar o custo total em vez do preço da licença. O tamanho do ponto cego é mensurável. A ISO/IEC 25010:2023, norma internacional de qualidade de produto de software, define nove características de qualidade. Uma demo bem conduzida demonstra bem uma delas: adequação funcional. As outras oito você só descobre na operação, quando já assinou. O trabalho do comprador é antecipar o máximo possível dessas oito antes da assinatura.
Por que toda plataforma parece boa numa demo?
Porque a demo faz exatamente o que foi feita para fazer. Ela existe para mostrar o produto no melhor cenário possível, e isso é legítimo. O problema não é o vendedor. É usar a apresentação como evidência.
Três coisas garantem o resultado bonito.
Os dados são limpos. A base de demonstração tem 40 registros, todos preenchidos, sem duplicidade, sem cliente cadastrado três vezes com grafias diferentes, sem campo obrigatório vazio desde 2019. A sua base não é assim.
O cenário foi escolhido. O fluxo apresentado é o que a ferramenta faz melhor. Se o seu processo tem uma etapa de aprovação dupla com alçada por valor, ela pode aparecer no fim, resumida, ou não aparecer.
Ninguém da equipe real está operando. Quem clica é quem usa o sistema todo dia há dois anos. Ele não hesita, não erra o caminho, não abre o menu errado. A velocidade que você vê na tela não é a velocidade que a sua equipe terá.
Some a isso o efeito da ordem. Você vê três demos em duas semanas e compara lembranças, não fatos. A última costuma parecer melhor porque está mais fresca. Sem um roteiro seu, a comparação vira preferência estética.
O que preparar antes de marcar a primeira reunião?
Antes de qualquer contato com fornecedor, escreva os casos que a ferramenta precisa aguentar. Entre 5 e 8 é suficiente. Menos que isso não cobre o negócio, mais que isso ninguém executa.
Um caso real tem quatro elementos: um gatilho, os dados de verdade, as pessoas envolvidas com nome e papel, e o resultado esperado. Não escreva “gestão de projetos”. Escreva: “Chega um pedido de proposta de um cliente do setor X, com sete itens de escopo; o comercial monta a proposta, o técnico valida prazo, o financeiro confere margem, o diretor aprova acima de determinado valor, e o cliente recebe o documento; hoje isso leva quatro dias e passa por três planilhas”.
Inclua de propósito pelo menos dois casos incômodos:
- O caso feio. O processo que tem exceção, retrabalho ou cliente que muda de ideia no meio. Toda ferramenta lida bem com o fluxo linear. A diferença aparece na exceção.
- O caso de volume. O relatório do fechamento com o número real de registros, não com 40 linhas.
Leve também uma amostra da sua base — anonimizada se necessário — e peça para importar. A qualidade da importação diz mais sobre a vida futura do que qualquer tela.
Por fim, defina antes o que é aprovação. Escreva os critérios e os pesos antes de ver qualquer produto. Critério definido depois da demo tende a se ajustar ao que você acabou de ver.
O que testar de verdade — e com quem?
O teste que vale é um processo real rodado do começo ao fim, pelas pessoas que vão operar, sem o vendedor conduzindo o mouse. Ele pode estar na sala. Só não pode dirigir.
A pergunta que orienta o teste não é “a ferramenta faz?”. Quase tudo faz. É “quanto custa fazer, quem consegue fazer e o que quebra quando muda?”.
| O que testar | Como testar | Sinal de alerta |
|---|---|---|
| Importação da sua base | Subir uma amostra real, com sujeira | Precisa de serviço do fornecedor para toda carga |
| Um processo ponta a ponta | Quem opera executa, sem ajuda | Só funciona com o vendedor no comando |
| Mudança de campo ou etapa | Alguém da sua equipe altera na hora | Depende de chamado ou de horas de consultoria |
| Permissões e visibilidade | Criar um perfil restrito e testar por dentro | Tudo ou nada, sem granularidade |
| Volume real | Abrir a visão com todos os registros | Lentidão que “melhora com filtro” |
| Exportação completa | Exportar tudo e abrir o arquivo | Exporta só listas, sem anexos, histórico ou comentários |
| Integração com um sistema seu | Testar o fluxo real, não o catálogo de conectores | “Tem API” como resposta final |
| Uso por quem não gosta de sistema | Pedir a duas pessoas céticas para operar | Treinamento longo para tarefa simples |
Anote o tempo. Quantos cliques, quantos minutos, quantas dúvidas. Comparar tempo medido é muito mais honesto que comparar impressões.
Quais perguntas o vendedor não espera?
As perguntas de funcionalidade são esperadas e ensaiadas. As que revelam mais são administrativas e chatas. Faça por escrito e peça resposta por escrito.
“Se eu sair em 18 meses, como exporto tudo — incluindo anexos, histórico de alterações e comentários — e em que formato?” Exportar a lista de registros é fácil. O valor acumulado está no que veio junto: quem mudou o quê, quando, e o arquivo anexado na conversa.
“Quem, na minha equipe, consegue criar um campo ou mudar uma etapa sem abrir chamado?” A resposta separa ferramenta configurável por você de ferramenta configurável pelo fornecedor. As duas existem e as duas são legítimas. Só têm custos de vida muito diferentes.
“O que acontece exatamente quando eu ultrapasso o limite do plano — de usuários, de registros, de automações, de armazenamento?” Bloqueia? Degrada? Cobra automaticamente? Sobe de faixa? Peça o número do limite e a regra, não a tranquilização.
“Quantos clientes do meu porte e do meu setor você tem ativos há mais de dois anos? Posso falar com dois deles?” Note que a pergunta não é sobre número de clientes. É sobre permanência. E peça referências que você escolhe, não só as três da lista pronta.
“Quem faz a implantação: você, um parceiro ou eu?” Configurar é deixar a ferramenta pronta. Implantar é deixar a empresa usando. Muita frustração nasce de contratar o primeiro achando que comprou o segundo.
“O que costuma dar errado nos primeiros meses com clientes parecidos comigo?” Fornecedor experiente responde com casos. A ausência de resposta também é informação.
Quanto custa de verdade?
A licença costuma ser a parte visível e menor. A norma federal brasileira que rege contratações de tecnologia na administração usa o conceito de custo total de propriedade — a Instrução Normativa SGD/ME nº 94/2022 exige, no estudo técnico preliminar, “análise comparativa de custos” com “cálculo dos custos totais de propriedade (Total Cost Ownership – TCO)”. A lógica serve para empresa privada igual.
| Componente | O que entra | Onde costuma escapar |
|---|---|---|
| Licença | Preço por usuário ou por faixa, anual | Reajuste, moeda, faixa que muda ao crescer |
| Módulos e add-ons | Recursos vendidos à parte | O recurso que você viu na demo pode estar em outro plano |
| Implantação | Configuração, migração, desenho de processo | Cotada por escopo, cobrada por hora |
| Integração | Conexão com ERP, financeiro, e-mail, planilhas | Manutenção quando um dos lados muda |
| Treinamento | Turmas iniciais e reciclagem | Rotatividade — quem treina o próximo? |
| Tempo da sua equipe | Horas de quem participa da implantação e testa | Nunca entra na planilha e é frequentemente o maior item |
| Operação contínua | Ajustes, novos fluxos, suporte interno | Vira função informal de alguém |
| Saída | Extração, conversão, reentrada em outro sistema | Só aparece quando você decide sair |
Projete em três anos, não em um. E some o tempo da sua equipe em horas, mesmo que estimado. Sem esse item, a comparação entre uma ferramenta que você configura e uma que depende do fornecedor fica distorcida.
Como reconhecer sinais de aprisionamento?
Aprisionamento não é má-fé. É consequência de arquitetura e de contrato. E, sim, algum grau de dependência é inevitável: qualquer sistema que guarda o seu processo cria vínculo. O que se controla é o custo de romper esse vínculo.
| Sinal | Como se apresenta | Pergunta que confirma |
|---|---|---|
| Exportação limitada | “Exportamos os dados, claro” | Anexos e histórico saem juntos? Em que formato? |
| Customização só pelo fornecedor | “A gente configura para você, é mais rápido” | Quanto custa a próxima mudança, daqui a seis meses? |
| Preço por módulo | Plano base barato, essencial no módulo | Quais dos meus 5 a 8 casos exigem módulo pago? |
| Contrato longo sem saída | Desconto atrelado a prazo | Qual a cláusula de rescisão e o custo dela? |
| Conhecimento em uma pessoa | Um “dono do sistema” na sua empresa | Se essa pessoa sair amanhã, quem mexe? |
| Dados sem cópia sua | Tudo vive só no fornecedor | Consigo uma cópia periódica automática? |
O sinal mais subestimado é o penúltimo: a concentração interna. Não depende do fornecedor, depende de você — e é o mais fácil de corrigir, com documentação e uma segunda pessoa treinada desde o começo.
Por que o piloto pago diz mais que o trial gratuito?
O trial gratuito é útil e vale usar. Ele responde perguntas de superfície: a interface faz sentido, os campos existem, a navegação é tolerável. O que ele não faz é criar compromisso dos dois lados.
No trial, ninguém é responsável pelo resultado. Você testa nas brechas da semana, com dados falsos, e o fornecedor não tem obrigação de te acompanhar. No piloto pago, existe escopo, existe prazo, existe alguém do outro lado com nome, e existem critérios de aceite escritos. É a diferença entre experimentar e ensaiar.
A prática tem respaldo formal:
“Desde que previsto no edital, na fase a que se refere o inciso IV do caput deste artigo, o órgão ou entidade licitante poderá, em relação ao licitante provisoriamente vencedor, realizar análise e avaliação da conformidade da proposta, mediante homologação de amostras, exame de conformidade e prova de conceito, entre outros testes de interesse da Administração, de modo a comprovar sua aderência às especificações definidas no termo de referência ou no projeto básico.”
— Lei nº 14.133/2021, art. 17, §3º
Se a administração pública, que precisa justificar cada gasto, tem previsão legal para testar antes de contratar, a empresa privada não tem por que decidir com base numa apresentação.
Um piloto útil tem quatro elementos: escopo escrito, dados reais, as pessoas que vão operar, e critérios de aceite definidos antes. Defina também o que conta como reprovação. Piloto sem critério de reprovação sempre “dá certo”.
Como envolver a equipe sem transformar a avaliação em votação?
Sim, a equipe precisa participar. Sistema rejeitado por quem opera não sobrevive, por melhor que seja. Mas participação não é sufrágio, e essa confusão trava avaliações.
Separe os papéis desde o início. Quem decide é uma pessoa, com nome, e todos sabem quem é. Quem testa é quem vai operar, e o papel dessas pessoas é executar os casos e relatar fatos. Quem opina é o resto — opinião é bem-vinda como entrada, não como voto.
Peça relatos estruturados, não notas. “Consegui concluir o caso 3 em 11 minutos, travei na etapa de aprovação porque não achei o botão” é informação. “Achei a cor feia” não é.
Cuidado com dois vieses previsíveis. O primeiro é a preferência pelo parecido: quem usa planilha há dez anos tende a aprovar o que se parece com planilha. O segundo é a resistência ao registro: ferramenta que expõe o andamento do trabalho gera desconforto legítimo, e esse desconforto às vezes se disfarça de crítica técnica. Nomear os dois em voz alta, antes do teste, reduz o ruído.
Resumo
| Pergunta | Resposta curta |
|---|---|
| A demo serve para quê? | Conhecer o produto. Não para decidir. |
| Quantos casos preparar? | De 5 a 8, com dados e nomes reais, escritos antes do primeiro contato. |
| Qual é o teste que vale? | Um processo ponta a ponta, operado por quem vai usar, sem o vendedor no mouse. |
| Qual pergunta revela mais? | Como exporto tudo, com anexos e histórico, se eu sair. |
| O que somar no custo? | Licença, módulos, implantação, integração, treinamento, tempo da equipe, operação e saída — em três anos. |
| Como medir aprisionamento? | Pelo custo de sair, não pela intenção do fornecedor. |
| Trial ou piloto? | Trial para superfície; piloto pago, com escopo e critério de aceite, para decidir. |
| Como envolver a equipe? | Quem testa relata fatos; quem decide é uma pessoa. Não é votação. |
| Existe escolha garantida? | Não. Existe processo que reduz surpresa e deixa a saída barata. |
Se você vai ver demos nas próximas semanas, chegue com o roteiro pronto
Nenhum método elimina o risco de escolher errado. O que ele muda é a assimetria: você para de comparar impressões e passa a comparar evidências que você mesmo produziu, com os seus dados e a sua gente. Antes da próxima reunião marcada, faça o mínimo: escreva os seus 5 a 8 casos, defina os critérios de aprovação, e leve uma amostra da sua base. Isso já inverte o roteiro.
A Audatia acompanha empresas nesse tipo de avaliação — montando os casos de teste, conduzindo pilotos e revisando cláusulas de saída — e, como parceira ClickUp e monday.com, aplica a mesma disciplina inclusive quando a plataforma avaliada não é uma delas.
