Multi-inquilino para redes de serviços: uma instalação, N marcas

A maioria dos CRMs vende «multi-empresa» como upgrade. Você paga mais e aparece um menu suspenso no canto. Por baixo dos panos continua tudo na mesma tabela, com uma coluna companyId que ninguém impõe na camada de serviço. Funciona até duas coisas acontecerem ao mesmo tempo: um sócio pede sua marca, e uma auditoria pede para você provar isolamento.

O que «multi-inquilino» significa de verdade

São três camadas, e um CRM multi-inquilino real impõe as três.

1. Camada de dados

Cada linha carrega companyId. Cada consulta filtra por ele. Cada relação respeita-o. Isso é o mínimo - mas o ponto onde a regra é imposta importa: precisa ser na fronteira do serviço, não da interface. Esconder via CSS não é isolamento.

Na prática isso significa:

• Chaves estrangeiras que cascateiam dentro de um único inquilino
• Índices que sempre começam com (companyId, ...)
• Manipuladores de API que resolvem companyId da sessão e nunca confiam na URL

2. Camada de e-mail

A esquecida. Se dois inquilinos compartilham servidor de e-mail, compartilham reputação de envio. Uma queixa de spam do Inquilino A degrada a entregabilidade do Inquilino B. Por isso, um setup multi-inquilino de verdade dá a cada inquilino:

• Seu próprio domínio (ex.: @marca-a.com)
• Sua própria chave DKIM
• Sua própria configuração SPF e DMARC
• Opcionalmente, seu próprio cronograma de aquecimento

3. Camada de IA

A mais nova, muitas vezes ignorada. Se dois inquilinos compartilham janela de contexto do modelo, compartilham risco de vazamento. Uma integração de IA multi-inquilino de verdade:

• Roteia prompts por companyId sem estado compartilhado
• Usa chaves de API do próprio inquilino (cobrança fica do lado dele)
• Marca cada geração com o inquilino para auditoria
• Nunca constrói índice de embeddings entre inquilinos sem consentimento explícito

Onde isso importa

Três casos concretos:

Holdings de agências

Uma agência-mãe com três sub-marcas precisa de:

• Três pipelines de vendas separados (clientes diferentes, posicionamento diferente)
• Um diretório único de equipe (consultores transitam entre marcas)
• Três domínios de e-mail, cada um com sua própria reputação de envio
• Relatórios consolidados entre marcas para o holding

A maioria dos CRMs força a escolher: contas separadas (e perde a consolidação) ou conta compartilhada (e perde isolamento). Multi-inquilino de verdade dá os dois.

Consultorias multi-prática

Uma consultoria com práticas de engenharia, ambiental e jurídica não quer sobreposição de contatos. A engenharia qualifica por alinhamento técnico; a jurídica por exposição regulatória. Mesma firma, filtros diferentes.

Inquilino por prática com equipe compartilhada entrega isso.

Redes de franquia

Franquia em que cada unidade roda seu pipeline mas reporta para a corporação. Cada franqueada é dona dos seus contatos (soberania de dados). A corporação vê métricas consolidadas (governança). Marcas diferentes, manuais compartilhados.

O custo de fazer errado

Adicionar multi-inquilino depois é a segunda migração mais difícil em software, atrás só de troca de tipo de banco. Toda tabela compartilhada vira uma cilada. Todo domínio de e-mail compartilhado vira risco de entregabilidade. Todo contexto de IA compartilhado vira risco de privacidade.

A correção é começar multi-inquilino desde o dia zero - mesmo com um único inquilino.