Como avaliar um software SaaS antes de contratar: critérios que vão além do preço

A proposta comercial costuma chegar com um número em destaque: tantos reais por usuário, por mês. É o dado mais fácil de comparar e, justamente por isso, o que mais engana. Quem pesquisa como escolher software SaaS logo descobre que o preço de tabela diz pouco sobre o que a empresa vai gastar, sobre o esforço de implantação e sobre o risco de ficar presa a uma ferramenta que não resolve o problema. A contratação de um sistema por assinatura é uma decisão de operação, de segurança e de dados, e merece o mesmo cuidado de uma compra de equipamento.

O roteiro a seguir não cita fornecedores. A ideia é oferecer critérios e perguntas que funcionam para qualquer categoria, de CRM a gestão de projetos, e ajudar a montar uma matriz de decisão que envolva as áreas que vão conviver com a ferramenta no dia a dia.

Comece pelo problema, e não pela vitrine

Demonstrações comerciais são desenhadas para impressionar. Antes de assistir a qualquer uma, vale escrever em uma página o problema que o software precisa resolver, quem vai usá-lo e como o trabalho é feito atualmente. Esse documento curto evita que a escolha seja guiada pelo recurso mais vistoso, e não pelo mais necessário.

Uma forma prática é separar os requisitos em três grupos:

• Obrigatórios: sem eles, a ferramenta não serve. Exemplo: emitir relatório no formato exigido pelo cliente ou integrar com o sistema financeiro.
• Desejáveis: agregam valor, mas admitem alternativa. Exemplo: aplicativo móvel com uso offline.
• Irrelevantes para o caso: funções que aparecem na apresentação, mas que ninguém vai usar. Registrá-las ajuda a não pagar por elas.

Os requisitos obrigatórios funcionam como filtro eliminatório. Um fornecedor que não atende a um deles sai da disputa, por mais atraente que seja o preço.

Os critérios que pesam além do preço

Aderência ao processo

A pergunta central é quanto a empresa terá de mudar a própria rotina para caber na ferramenta, e quanto a ferramenta pode ser configurada para caber na rotina. Mudar processos pode ser saudável, mas precisa ser uma decisão consciente. Peça ao fornecedor que demonstre o seu fluxo real, com os seus campos e as suas exceções, e não um roteiro genérico.

Integrações e API

Um SaaS isolado vira mais uma planilha de retrabalho. Verifique se há integração nativa com os sistemas que a empresa já usa, se existe API documentada e pública, quais são os limites de chamadas e se a integração está incluída no plano ou é cobrada à parte. Integrações feitas por terceiros também entram na conta, porque dependem de um fornecedor a mais.

Segurança e proteção de dados

No modelo SaaS, o cliente usa a aplicação, mas não controla a infraestrutura por trás dela. A definição de computação em nuvem publicada pelo NIST, o instituto de padrões dos Estados Unidos, deixa isso claro: nesse modelo, o consumidor não gerencia servidores, rede ou armazenamento, apenas configurações limitadas da aplicação. Por isso, a confiança precisa ser verificada por documentos.

Algumas perguntas úteis:

• O fornecedor tem certificação ISO/IEC 27001 ou relatório de auditoria independente, como o SOC 2? Qual o escopo e a validade?
• Onde os dados ficam armazenados e se há transferência para outros países?
• Há autenticação multifator e login único (SSO) no plano que será contratado, ou só nos planos mais caros?
• Como são registrados os acessos e por quanto tempo esses registros ficam disponíveis?
• Qual o procedimento e o prazo de aviso em caso de incidente de segurança?

Quando houver dados pessoais envolvidos, a Lei Geral de Proteção de Dados (Lei nº 13.709/2018) entra na conversa. Em regra, o fornecedor atua como operador e deve tratar os dados segundo as instruções do controlador, como prevê o artigo 39. O contrato precisa refletir isso, e o encarregado de dados da empresa deve participar da análise. Questionários padronizados de segurança, como os disponibilizados pela Cloud Security Alliance, ajudam a comparar fornecedores com as mesmas perguntas.

Disponibilidade e suporte

Leia o acordo de nível de serviço com atenção. Um compromisso de disponibilidade só tem valor se vier acompanhado de consequência, como créditos na fatura quando a meta não é cumprida. Verifique também o horário de atendimento, o idioma, os canais disponíveis e o tempo de resposta por gravidade do chamado. Uma ferramenta crítica com suporte apenas por e-mail em outro fuso horário é um risco operacional.

Portabilidade e saída

Toda contratação deveria começar com a pergunta sobre como ela termina. Em que formato os dados podem ser exportados? A exportação inclui anexos, históricos e relacionamentos entre registros, ou só tabelas soltas? Por quanto tempo os dados ficam acessíveis depois do cancelamento e como é comprovada a exclusão? Ferramentas que dificultam a saída aumentam o custo de qualquer troca futura e enfraquecem a posição da empresa na renovação.

Custo ao longo do contrato

O preço mensal é o começo. Entram na conta a implantação, a migração de dados, o treinamento, os módulos adicionais, o número mínimo de licenças, as regras de reajuste e o que acontece quando a equipe cresce ou diminui. Compare cenários de três anos, e não apenas o primeiro mês.

Saúde e trajetória do fornecedor

Pergunte há quanto tempo o produto existe, quantos clientes de porte semelhante ele atende e como é publicado o roteiro de evolução. Peça referências de clientes do mesmo setor e converse com eles sem a presença do vendedor.

Como montar a matriz de decisão

A matriz transforma impressões em números comparáveis. O passo a passo é simples:

1. Liste os critérios que importam para o caso, agrupados por tema.
2. Atribua um peso a cada critério, de modo que a soma dê 100. Aderência ao processo e segurança costumam pesar mais do que interface ou recursos extras.
3. Defina uma escala de notas, por exemplo de 1 a 5, com descrição do que significa cada nota. Sem essa descrição, cada avaliador usa uma régua diferente.
4. Peça que cada área avalie os critérios em que tem competência. Quem usa avalia a rotina; quem cuida da tecnologia avalia integração e segurança; o financeiro avalia custo.
5. Multiplique nota por peso, some e compare, lembrando que requisitos obrigatórios não atendidos eliminam a opção antes de qualquer cálculo.

O resultado não substitui o julgamento, mas deixa claro por que uma opção venceu e registra a decisão para quem vier depois.

O que perguntar e testar no período de avaliação

A maioria dos fornecedores oferece período de teste ou prova de conceito. Ele só é útil se for planejado. Monte um roteiro com três a cinco tarefas reais, escolha usuários de verdade, e não apenas o time de tecnologia, e use dados representativos, anonimizados quando houver informação pessoal.

Durante o teste, registre respostas para perguntas como estas:

• Quanto tempo um usuário novo leva para concluir a tarefa principal sem ajuda?
• A integração com o sistema existente funcionou com dados reais ou só na demonstração?
• O suporte respondeu dentro do prazo prometido quando foi acionado?
• Os relatórios trazem o que a gestão precisa, ou será preciso exportar para planilha?
• A exportação completa dos dados funciona e pode ser reimportada em outro lugar?
• As permissões por perfil permitem restringir o que cada pessoa vê e altera?

Anote também o que irritou os usuários. Pequenos atritos no teste costumam se transformar em resistência na implantação.

Quem precisa estar na mesa

Contratações conduzidas por uma única área tendem a falhar em algum ponto cego. Um grupo enxuto de avaliação costuma incluir:

• um representante dos usuários finais, que conhece a rotina;
• alguém de tecnologia, para integração, segurança e gestão de acessos;
• o encarregado de dados ou o jurídico, para o contrato e a LGPD;
• o financeiro, para o custo ao longo do tempo;
• um patrocinador com autoridade para decidir e para cobrar a adoção.

Erros que se repetem

Alguns tropeços aparecem com frequência em contratações de software por assinatura. O primeiro é assinar contrato anual para ganhar desconto antes de validar a ferramenta com os usuários. O segundo é ignorar a cláusula de reajuste e o custo de licenças adicionais. O terceiro é deixar a exportação de dados para ser testada só no dia da saída. O quarto é não definir um responsável interno pela ferramenta depois da compra, o que leva a configurações abandonadas e a licenças pagas sem uso.

Evitar esses erros não exige grande estrutura. Exige método, registro das decisões e a disposição de fazer as perguntas difíceis antes da assinatura, quando o poder de negociação ainda está do lado de quem compra.