# Como estruturar um acordo white-label que funcione para ambas as partes

Source: https://baqueiro.es/pt/la-sala-de-maquinas/como-estruturar-acordo-white-label-pt/
Published: 2025-05-28T07:33:00+00:00
Updated: 2025-05-28T07:33:00+00:00
Author: Baqueiro Desarrollo Web
Language: pt-PT
Usage: Attribution required: quoting allowed with a visible link back

---

A maioria dos acordos white-label entre agências e parceiros técnicos começa da mesma forma: com boa vontade e sem qualquer documento.

Alguém conhece alguém. Surge um projeto. Parece haver sintonia. E começa-se a trabalhar com a ideia de que “depois definimos os pormenores”.

Muitas vezes, o primeiro projeto corre bem, porque os problemas não têm tempo de aparecer. O complicado chega com o segundo, ou com o terceiro, ou no dia em que algo corre mal e ninguém sabe ao certo quem é responsável por quê.

Um acordo bem estruturado não é burocracia: é o que separa uma relação que cresce de uma que se deteriora à primeira complicação. Se ainda estás a avaliar o modelo, antes pode interessar-te ler [o que é o desenvolvimento white-label e como protege a margem da tua agência](https://baqueiro.es/pt/la-sala-de-maquinas/o-que-e-desenvolvimento-white-label-margem-agencia/).

## Primeiro: definir exatamente o que se acorda

Parece óbvio, mas não é. “Trabalhamos juntos em projetos técnicos” pode significar coisas muito diferentes consoante quem o interpreta.

Um acordo white-label útil define com precisão, desde o início, pelo menos estes 3 elementos.

**Que tipo de projetos entram no acordo.** Tudo o que a agência precise a nível técnico? Só desenvolvimento à medida? Também manutenção? Projetos de qualquer dimensão ou só a partir de certo âmbito? E convém deixar escrito também o que fica de fora: saber de antemão [quando é preciso dizer “isto não fazemos”](https://baqueiro.es/pt/la-sala-de-maquinas/quando-subcontratar-e-quando-dizer-nao/) evita compromissos impossíveis.

**Quem faz o quê em cada projeto.** A agência gere a relação com o cliente e define os requisitos. O parceiro técnico executa o desenvolvimento e entrega o trabalho. Mas há zonas cinzentas: quem fala com o cliente quando surgem dúvidas técnicas? Quem decide se uma alteração de âmbito é viável? Quem controla os prazos? São perguntas que precisam de resposta antes de surgirem, não com o cliente à espera.

**Como se gere a comunicação.** Por que canal? Com que tempos de resposta? Como se documentam as decisões dentro de cada projeto? Muitas relações que funcionam no primeiro projeto falham no quarto porque ninguém definiu como circula a informação.

## O modelo económico: 3 opções e as suas implicações

A parte económica é onde surgem mais mal-entendidos se não estiver bem definida. Há 3 modelos habituais, cada um com as suas vantagens e desvantagens.

**Margem sobre o custo.** O parceiro técnico orçamenta um preço à agência e a agência repercute-o no cliente com a margem que considerar adequada. É o modelo mais limpo para a agência: controla totalmente a sua margem e não tem de partilhar o que cobra ao cliente final.

O risco é a agência apertar o preço do parceiro para competir. Um parceiro com margens muito apertadas acaba por dar prioridade a outros clientes nos picos de trabalho, e isso nota-se nos prazos.

**Comissão por projeto.** O parceiro técnico fatura diretamente ao cliente final e paga à agência uma comissão acordada por cada projeto que chega através dela. É menos habitual no white-label puro, mas funciona quando a agência atua mais como intermediária do que como gestora do projeto.

O problema é a confidencialidade: se o parceiro fatura ao cliente, o cliente sabe que ele existe. Nem sempre é um inconveniente, mas é preciso ter isso em conta.

**Valor fixo por capacidade reservada.** A agência paga um valor mensal fixo ao parceiro técnico em troca de ter garantida uma determinada capacidade de trabalho. Não projeto a projeto, mas como estrutura estável.

É o modelo que dá mais estabilidade a ambas as partes quando a relação está madura e o volume de trabalho é previsível. Ainda assim, o acordo deve esclarecer o que acontece às horas não utilizadas num mês (se se perdem, se acumulam ou se compensam) e como se fatura o que ultrapassar a capacidade reservada.

Não há um modelo melhor em abstrato, mas sim um mais adequado a cada momento da relação. O que importa em todos é que o parceiro funcione como [um parceiro técnico e não como um simples fornecedor de horas](https://baqueiro.es/pt/la-sala-de-maquinas/parceiro-tecnico-vs-fornecedor-horas/).

Seja qual for o modelo, deixa por escrito as condições de pagamento: em que prazo a agência paga ao parceiro e se esse pagamento depende ou não de o cliente final ter pago antes. Em Espanha, a lei contra os atrasos de pagamento fixa um máximo de 60 dias entre empresas.

## Propriedade intelectual: o ponto mais ignorado e o que mais problemas causa

Quando um projeto termina e o cliente tem o seu site a funcionar, de quem é o código?

A resposta parece óbvia: de quem o pagou. Mas, sem um acordo explícito, a resposta legal não é tão clara. Em Espanha, a cessão dos direitos de exploração sobre um programa tem de ser formalizada por escrito e, se o contrato não a detalhar, é interpretada de forma restritiva, limitada ao indispensável para a encomenda.

No white-label há ainda uma cadeia: o parceiro desenvolve, a agência entrega e o cliente utiliza. Para garantir os direitos ao cliente, a agência tem primeiro de os ter, por isso o acordo deve prever que o parceiro cede à agência (ou diretamente ao cliente final) os direitos de exploração sobre o código desenvolvido especificamente para cada projeto. O parceiro pode manter os direitos sobre componentes genéricos e reutilizáveis que fazem parte da sua forma de trabalhar, desde que isso não limite a capacidade do cliente de manter e evoluir o que recebeu.

O importante é que esteja escrito. Que não dependa do que cada parte se lembra de uma conversa de há 6 meses. Para a parte técnica, revê as [cláusulas técnicas que o teu contrato de desenvolvimento deveria incluir](https://baqueiro.es/pt/seguridad-y-juridico/clausulas-tecnicas-contrato-desenvolvimento/).

O mesmo acontece com a confidencialidade. O parceiro tem acesso ao negócio, aos sistemas e aos dados do cliente final, e isso exige um compromisso explícito que proteja a agência e o cliente. Não por desconfiança, mas por profissionalismo.

Se o parceiro vai tratar dados pessoais (uma base de clientes, as encomendas de uma loja, os formulários de contacto), a confidencialidade genérica não chega. O RGPD exige um contrato de subcontratação do tratamento que defina que dados são tratados, com que finalidade e com que medidas de segurança. Na prática, o parceiro atua normalmente como subcontratante ulterior da agência, que precisa da autorização do cliente para recorrer a ele, e tudo isso também tem de ficar por escrito.

E há uma cláusula quase obrigatória no white-label: a de não angariação. O parceiro compromete-se a não oferecer os seus serviços diretamente aos clientes da agência durante a colaboração e durante um período razoável depois. Sem ela, a agência partilha a sua carteira sem qualquer proteção.

## O que acontece quando algo corre mal

Um acordo que não define o que acontece quando as coisas não correm como esperado é um acordo incompleto.

Os problemas mais habituais nas colaborações white-label são 3: prazos que não se cumprem, trabalho entregue que não está à altura e alterações de âmbito que ninguém geriu bem e cujo custo tem de ser absorvido algures.

Para cada um destes cenários, e para outro que ninguém quer imaginar no início, o acordo deveria ter uma resposta clara antes de acontecerem.

**Prazos.** Que mecanismo existe quando um prazo vai falhar? Com quanta antecedência se avisa? Se o atraso afetar a entrega, quem dá a cara perante o cliente final e como se reparte o custo? Um parceiro que avisa com tempo é um parceiro com quem se pode trabalhar. Um que avisa na véspera é um problema estrutural.

**Qualidade.** Qual é o processo de revisão antes de entregar ao cliente? Quem valida que o trabalho cumpre os requisitos acordados? Durante quanto tempo ficam cobertas sem custo as correções posteriores à entrega? Um processo mínimo de controlo de qualidade evita muitas conversas difíceis.

**Alterações de âmbito.** Em quase todos os projetos, o cliente acaba por pedir algo que não estava no briefing inicial. A questão não é se vai acontecer, mas como se gere quando acontecer. Quem o avalia? Como se orçamenta? Quem comunica ao cliente o impacto no prazo e no custo? Um protocolo acordado poupa mais discussões do que parece.

**Fim da colaboração.** Ninguém começa uma relação a pensar em como termina, mas convém prevê-lo: prazo de pré-aviso, entrega de acessos, código e documentação dos projetos em curso, e quem mantém o que já está em produção. Se chegar o momento, ninguém deve ficar pendurado, muito menos o cliente final.

## O momento certo para assinar

A conversa sobre o acordo deve acontecer antes do primeiro projeto, não durante.

Quando há um projeto em cima da mesa e o cliente à espera de resposta, ninguém tem tempo nem energia para negociar os pormenores de uma colaboração a longo prazo. Decide-se o mínimo para começar, não o que mais convém para que a relação dure.

O momento ideal é quando há interesse mútuo, mas ainda não há urgência. Uma reunião de 2 horas para rever como trabalharia cada parte, o que espera da outra, quais são os limites e quais as expectativas. Essa clareza nota-se em todos os projetos que vêm depois.

Os melhores acordos white-label não são os mais longos, mas sim os que foram pensados com calma por 2 partes que querem trabalhar juntas durante muito tempo.

O documento é a consequência dessa conversa. Não o contrário.

Na Baqueiro, trabalhamos com agências ao abrigo de acordos white-label definidos desde o primeiro projeto. Se quiseres ver como poderia funcionar uma colaboração com a tua agência, [começamos com uma conversa sem compromisso](https://baqueiro.es/pt/contacto/).