Pedir orçamento dizendo “quero um sistema para minha empresa” é a receita para propostas incomparáveis: um fornecedor cobra o triplo, outro entrega pela metade, e ninguém sabe quem está certo. O briefing é o documento que reduz esse risco. Escrevê-lo leva algumas horas e evita meses de retrabalho.
O que é o briefing e por que importa
O briefing é um resumo organizado do que você precisa. Ele serve para:
- Alinhar você e a sua equipe sobre o que querem.
- Permitir que fornecedores orcem o mesmo escopo.
- Definir limites, evitando que o projeto cresça sem controle.
- Ser a base do contrato e dos critérios de aceite.
Não precisa ser bonito nem técnico. Precisa ser claro.
O que colocar no briefing, parte por parte
1. O problema e o objetivo
Comece pelo motivo. Responda:
- Qual problema o sistema resolve? (“Perdemos pedidos porque o estoque é controlado em três planilhas.”)
- Qual é o resultado esperado? (“Reduzir erros de estoque e o tempo de fechamento do dia.”)
- Como saberemos que deu certo? Escolha um ou dois números simples.
Sem objetivo medível, qualquer entrega parece suficiente ou insuficiente.
2. Quem usa o sistema
Liste os tipos de usuário e o que cada um faz:
- Dono ou gerente: vê relatórios, aprova descontos.
- Atendente: cadastra pedidos e clientes.
- Estoquista: dá entrada e saída de produtos.
- Cliente final: acessa pelo site ou aplicativo, se for o caso.
Para cada um, defina permissões: o que pode ver, criar, editar e apagar. Isso é importante para segurança e para orçamento. Para ter ideia de como definir o público, veja público-alvo e persona de um app.
3. Como o processo funciona hoje
Descreva o fluxo atual em passos curtos, com exemplos reais:
- O cliente pede pelo WhatsApp.
- A atendente anota numa planilha.
- O estoquista separa e confere.
- O financeiro emite a nota.
Anexe prints, planilhas atuais, modelos de documentos e fotos de formulários. Material real vale mais que descrição genérica.
4. O que o sistema precisa fazer
Liste as funções em ordem de importância, usando três grupos:
- Essencial: sem isso o sistema não serve.
- Importante: deve entrar, mas pode ser em uma segunda etapa.
- Desejável: só se sobrar orçamento e tempo.
Essa separação é a base de um MVP. Se precisar, leia o que é MVP de app. Para cada função, escreva uma frase no formato “o usuário X consegue fazer Y para obter Z”. Exemplo: “A atendente consegue cadastrar um pedido com itens e forma de pagamento para o estoque ser baixado automaticamente.”
5. Regras do negócio
São as regras que o sistema precisa respeitar:
- Descontos acima de um limite exigem aprovação.
- Pedidos só são liberados após pagamento confirmado.
- Cada cliente tem uma tabela de preços.
- Produtos têm validade e lote.
Se alguma regra muda por exceção, anote a exceção. É nelas que os sistemas costumam falhar.
6. Integrações
Descreva com o que o sistema precisa conversar:
- Nota fiscal. Veja emitir nota fiscal em sistema.
- Pagamentos, como Pix e cartão. Veja Pix no site e no app.
- Maquininha e PDV.
- WhatsApp, e-mail, marketplaces, transportadoras.
- Planilhas e sistemas que você já usa.
Pergunte ao fornecedor como ele faz cada integração e quais custos recorrentes elas geram.
7. Requisitos de segurança e dados
Descreva:
- Que dados pessoais o sistema vai guardar (clientes, funcionários, saúde, financeiros).
- Quem pode acessar cada tipo de dado.
- Se existe obrigação de guardar registros por algum tempo.
- Como será o backup e a recuperação.
- Como o sistema atenderá a LGPD. Veja LGPD para pequenas empresas.
8. Prazo, orçamento e responsabilidades
Seja transparente:
- Prazo desejado e se existe uma data-limite real (um evento, uma temporada).
- Faixa de orçamento que você considera viável. Dizer o teto ajuda o fornecedor a propor o que cabe.
- Quem na sua empresa tira dúvidas e aprova entregas.
- Como será o pós-entrega: suporte, manutenção e evolução. Veja quanto custa manter um sistema.
Perguntas para fazer aos fornecedores
- Já fizeram algo parecido? Posso falar com um cliente?
- Quem exatamente vai trabalhar no meu projeto?
- Como serão as entregas por etapa e a validação?
- De quem é o código e onde ele fica guardado?
- Qual a garantia contra defeitos?
- Como é cobrado o que mudar no meio do caminho?
Mais pontos de cuidado em como contratar desenvolvedor ou agência de apps.
Modelo de estrutura em uma página
Se preferir um molde, organize o briefing nesta ordem: resumo do negócio em três linhas, problema a resolver, objetivo e como medir, usuários e permissões, processo atual, funções essenciais, importantes e desejáveis, regras de negócio, integrações, dados e segurança, prazo e orçamento, e perguntas para o fornecedor. Cada seção pode ter poucas linhas. O importante é que, ao ler, alguém de fora do seu negócio entenda o que você quer.
Erros que estragam o briefing
- Descrever a solução em vez do problema, o que limita o fornecedor a fazer exatamente o que você imaginou, mesmo que exista um jeito melhor.
- Querer tudo na primeira versão. Priorize.
- Omitir restrições, como orçamento e prazo.
- Esquecer quem vai usar, e não ouvir a equipe que lida com o processo no dia a dia.
- Não guardar a versão assinada do documento junto ao contrato.
Como usar o briefing
Escreva em um documento de poucas páginas, envie para dois ou três fornecedores e compare as respostas: um bom fornecedor faz perguntas e aponta riscos. Se todos entenderem o mesmo, você tem um briefing bom. Se cada um entender algo diferente, falta clareza, e é melhor descobrir isso antes de assinar contrato.
Ao receber as propostas, compare não só o preço, mas o que cada uma inclui, o que deixa de fora e como trata mudanças. Uma proposta barata que não cobre testes, treinamento ou suporte costuma sair cara depois.