“Site completo” parece uma descrição simples até o cliente pedir mais páginas, textos, fotografias e atendimento contínuo. Um pacote bem construído transforma uma promessa ampla em uma entrega compreensível. Ele mostra o que será feito, o que depende do cliente e quais solicitações exigirão uma nova combinação. Para o freelancer, essa definição também ajuda a calcular capacidade e evitar que cada projeto se torne um serviço completamente diferente.
Comece pelo uso do site e pelo cliente que vai atendê-lo
Antes de escolher quantidade de páginas, defina o trabalho que o site precisa cumprir. Um prestador de serviços pode precisar apresentar sua atuação e receber pedidos de orçamento. Um criador de conteúdo pode querer reunir materiais e encaminhar visitantes para produtos que já vende em outra plataforma.
Esses objetivos levam a entregas diferentes. A página que direciona para uma plataforma externa não inclui, por si só, checkout, área de membros ou processamento de pagamentos. O pacote deve dizer onde termina sua responsabilidade e qual serviço executa as etapas seguintes.
Imagine um pacote hipotético para um profissional autônomo: apresentação, serviços, perguntas frequentes e contato. A proposta pode reunir essas seções em uma página ou distribuí-las em páginas separadas. O importante é mostrar a estrutura prevista e explicar por que ela atende ao objetivo aprovado.
Descreva um cenário de uso na própria proposta. Para um serviço local, o visitante precisa reconhecer se a empresa atende sua região e então solicitar orçamento. Para um criador, pode ser importante distinguir produtos disponíveis e seguir para a plataforma que realiza a compra. A estrutura deve apoiar esse caminho. Essa descrição ajuda a resolver discussões posteriores sobre elementos que parecem interessantes, mas não contribuem para a finalidade contratada.
Defina também o responsável pelo atendimento. Um formulário bem feito não resolve a ausência de alguém para consultar os registros. Se o pacote inclui apenas a estrutura de captação, deixe claro como o cliente verificará as solicitações e quais tarefas continuam com sua equipe.
Descreva as entregas como itens verificáveis
Troque expressões vagas por atividades que possam ser conferidas. “Visual profissional” depende de interpretação. “Aplicação de logotipo, paleta aprovada e imagens fornecidas em cinco páginas” define melhor o trabalho, sem impedir uma conversa sobre qualidade.
- Estrutura: páginas ou seções incluídas, com seus assuntos.
- Conteúdo: quem fornece informações e quem escreve ou revisa os textos.
- Imagens: quantidade prevista, origem e responsabilidade pelas licenças.
- Contato: formulário e campos combinados, com teste de recebimento.
- Validação: testes em celular e computador, links e navegação.
- Entrega: orientação de uso e documento com responsabilidades.
Se o formulário faz parte do pacote, descreva o comportamento esperado e o destino das informações. O tutorial de formulários do W3C recomenda solicitar apenas o necessário e identificar os campos adequadamente. Isso ajuda a discutir uma entrega utilizável, em vez de apenas colocar caixas de texto na página.
Inclua os conteúdos institucionais ou avisos que o cliente deverá fornecer. Não prometa assessoria jurídica ou conformidade integral apenas porque um modelo de texto foi incluído no projeto.
Para conteúdo, escolha uma unidade que permita estimar esforço. “Redação de textos” pode significar entrevistar o cliente e escrever do zero ou apenas adaptar material pronto. Liste páginas, assunto de cada uma, profundidade esperada e fonte das informações. Se houver muitas versões de um serviço, confirme se elas serão páginas independentes ou variações de uma mesma seção.
Faça o mesmo com imagens: seleção em banco licenciado, adaptação de fotografias enviadas e produção fotográfica são atividades diferentes. Informe quem verifica a autorização de uso e como uma troca depois da aprovação será tratada. Um pacote compreensível não precisa descrever cada clique, mas deve esclarecer os pontos que mudam tempo, custo ou responsabilidade.
Estabeleça revisões, dependências e critérios de aceite
Uma rodada de revisão precisa de significado. Você pode defini-la como uma lista consolidada de ajustes enviada por uma pessoa responsável. O número de rodadas e o prazo para recebê-las devem ser combinados conforme a complexidade do projeto.
Também vale separar correção de mudança de escopo. Ajustar um telefone digitado incorretamente é diferente de acrescentar uma área de cursos. Alterar uma frase dentro da página aprovada é diferente de trocar o público do site e reescrever todas as páginas.
Crie um pequeno roteiro de aceite: páginas previstas presentes, conteúdo aprovado, links funcionais, formulário testado e treinamento realizado. Registre pendências conhecidas. Esse roteiro deve estar disponível desde a proposta, para que o cliente saiba como a entrega será avaliada.
O cronograma depende de materiais e respostas. Em vez de prometer uma data descolada dessas dependências, registre o prazo de produção e como atrasos no envio de conteúdo afetam a programação. Reserve tempo para a última conferência depois dos ajustes.
Uma rodada pode começar quando o cliente recebe uma versão identificada e terminar quando o responsável envia uma lista consolidada. Novos comentários posteriores podem entrar na rodada seguinte, conforme o acordo. Isso permite trabalhar com uma referência estável. Evite solicitar aprovações por várias mensagens soltas sem indicar a qual versão cada uma se refere.
Monte também um procedimento para pedido adicional: descrever a mudança, estimar impacto e aguardar decisão antes de executar. Se o cliente pede um novo idioma, por exemplo, avalie tradução, navegação, revisão e manutenção. Não trate essa solicitação como simples duplicação de páginas. A comparação com o escopo aprovado deve ser objetiva, sem transformar toda correção legítima em cobrança extra.
Separe criação, plataforma e trabalho recorrente
Explique quais pagamentos são únicos e quais continuam depois da publicação. O desenvolvimento inicial pode ser cobrado como projeto. Domínio, plataforma e serviços contratados podem ter cobrança própria. Manutenção é outro serviço, se houver contratação.
Se a solução escolhida for a Orbite, por exemplo, o chatbot para visitantes ou a geração de artigos podem fazer sentido em determinados projetos. A apresentação oficial da Orbite ajuda a conhecer os recursos. Defina no pacote se você apenas configura a solução ou também revisa conteúdos e acompanha seu uso.
Uma assinatura de ferramenta não descreve as horas de trabalho do freelancer. Da mesma forma, uma mensalidade de manutenção precisa dizer quais tarefas cobre. Evite juntar tudo em um valor único sem explicar o que acontecerá quando o cliente quiser encerrar apenas uma parte do serviço.
Mostre o custo inicial e as despesas recorrentes em grupos distintos. Se o cliente contratar diretamente a plataforma, indique onde consultar as condições e quem manterá a conta. Se algum serviço for intermediado por você, explique o que acontece no encerramento da relação. Uma solução conveniente durante o projeto pode gerar dependência desnecessária quando contas e cobranças ficam misturadas.
No uso de IA, detalhe a atividade humana que acompanha o recurso. Definir pautas, conferir informações e ajustar respostas do chatbot são entregas diferentes de disponibilizar a ferramenta. Na Orbite, agendamentos ficam registrados no banco de dados; não acrescente ao pacote sincronização externa ou notificações sem comprovação específica.
Ofereça poucas opções com diferenças que façam sentido
Você pode trabalhar com uma oferta principal e complementos. Por exemplo, um site institucional delimitado, com contratação separada de novas páginas, preparação de conteúdo ou manutenção. Isso costuma ser mais fácil de explicar do que três pacotes quase iguais com nomes sofisticados.
Teste o pacote em um projeto demonstrativo. Meça quanto tempo cada entrega consome e identifique o que depende de terceiros. Se um item é difícil de prever, faça uma etapa de diagnóstico antes de fixar o escopo.
Ao final, leia a proposta como se fosse o cliente. Ele consegue entender o que vai receber, o que precisa fornecer, como serão aprovadas as etapas e quanto continuará pagando? Se essas respostas estiverem claras, o pacote já cumpre uma função importante: permitir uma decisão informada e uma execução organizada.
A tabela exemplifica como separar uma entrega institucional de complementos. Ela não é uma tabela de preços nem um pacote obrigatório. Ajuste as fronteiras ao projeto, mantendo cuidados essenciais de uso e segurança mesmo na opção mais simples. Recursos adicionais devem resolver necessidades identificadas, não apenas tornar uma versão básica artificialmente insuficiente.
| Item | Definição no pacote | Possível adicional |
|---|---|---|
| Páginas | Estrutura e assuntos aprovados | Nova seção ou novo idioma |
| Textos | Adaptação ou redação delimitada | Entrevistas e conteúdo extra |
| Contato | Campos e destino verificados | Fluxo adicional investigado |
| Revisões | Rodadas e aprovador definidos | Mudança de objetivo |
| Entrega | Orientação de tarefas essenciais | Treinamento ampliado |
| Recorrência | Tarefas mensais contratadas | Volume acima do combinado |
Depois de testar o pacote, revise os itens que sempre geram dúvida. Se todos perguntam quem escreve os textos, a explicação precisa aparecer com mais destaque. Se uma tarefa costuma extrapolar a estimativa, torne o pré-requisito explícito ou avalie contratar uma etapa de diagnóstico. O pacote deve refletir o trabalho real, e não uma lista que você não consegue sustentar.
Antes de enviar, confira se é possível dizer com clareza quando o projeto termina. Conteúdo aprovado, fluxo testado e orientação entregue formam um encerramento mais verificável que uma sensação geral de que o site está pronto.
