Agências
Um funil, vinte clientes, vinte reputações mantidas separadas
Uma agência de três pessoas que faz marketing para vinte empresas locais tem o mesmo problema vinte vezes, e a mesma solução vinte vezes — só que a lista, a identidade de envio, o domínio e o registo de consentimento de cada cliente têm de permanecer inteiramente seus. O trabalho interessante está nesse "só que".
Um projeto por cliente, e a fronteira é tarefa da base de dados
Tudo aqui é delimitado a um tenant e a um projeto em conjunto — contactos, funis, criativos, campanhas, identidades de envio, relatórios. Essa delimitação é imposta pela segurança ao nível de linha na base de dados, não por uma cláusula que alguém tem de se lembrar de acrescentar a uma consulta. Um projeto esquecido não vê nada, em vez de ver as linhas do primeiro projeto.
O que significa que a lista de um cliente não pode vazar por engano para a campanha de outro, e que um relatório é sobre um cliente porque estruturalmente não pode ser sobre dois.
Cada cliente envia como ele próprio
Uma identidade de envio pertence a um projeto: o domínio deles, as chaves DKIM deles, a caixa de correio ou a conta do fornecedor deles, o limite de taxa deles. A campanha infeliz de um cliente não pode danificar a entregabilidade de outro, porque nunca partilharam nada que pudesse ser danificado.
Também resolve uma conversa desconfortável cedo. O cliente é dono do seu envio, da sua lista e do seu registo de consentimento. Quando sai — e alguns sairão —, sai com tudo isso, e tu não construíste uma situação de refém que terias de explicar.
- 1ContactosPor projeto. Imposta na base de dados, não por uma consulta que tens de te lembrar de fazer.
- 2EnvioO domínio deles, o DKIM deles, a caixa de correio ou fornecedor deles, o limite de taxa deles.
- 3ConsentimentoO registo deles. Viaja com eles, provas incluídas, se saírem.
- 4RelatóriosPor projeto, por construção. Não há forma de agregar acidentalmente dois clientes.
- iO que tu manténsAs definições dos funis e a tua forma de trabalhar. Isso é o teu produto, e é a parte que vale a pena reutilizar.
Sem reputação partilhadaSem lista partilhada
Reutilização sem copiar e colar
Constrói o funil uma vez. Implementa-o tantas vezes quantos os teus clientes.
Um funil é um grafo, e um grafo é JSON com um esquema publicado. O que significa que aquilo que estás a reutilizar é um documento, não uma captura de ecrã de um ecrã que tens de reconstruir à mão em cada conta.
Os teus funis da casa
Boas-vindas, carrinho abandonado, ausência, intervalo, recuperação. Escritos uma vez por quem for melhor nisso, guardados no teu próprio repositório, e criados num projeto de cliente com uma chamada de API.
Verificados da mesma forma em todo o lado
O validador corre sobre o teu funil em cada projeto onde ele chega. Um grafo que entraria em ciclo sem uma espera, ou que enviaria sem assunto, é recusado aí tal como seria aqui.
Simulado antes de correr
Faz um ensaio com um contacto real da lista desse cliente a atravessar o funil e lê o que lhe seria enviado. Faz isso uma vez por implementação e a conversa do "saiu mal" deixa de acontecer.
Melhorado num só lugar
Quando aprendes algo — o segundo lembrete funciona melhor às dez da manhã —, alteras a tua definição e implementas-a. Os clientes que já usam a versão antiga terminam na versão antiga; ninguém em curso é perturbado.
Criativos também
Um criativo é um documento com variáveis de substituição. O mesmo e-mail de boas-vindas, renderizado com a marca, as cores e o logótipo de cada cliente — recolhidos do site dele na primeira execução.
Ou deixa um agente fazê-lo
Aponta um assistente para o servidor MCP, com âmbito num único projeto, e deixa-o redigir e verificar o funil desse cliente. Tudo o que chega a uma pessoa real continua a precisar de uma confirmação explícita e mantém-se dentro da quota.
Onze clientes, onze remetentes, um só lugar onde olhar.
O problema do relatório mensal
A maior parte da dor de uma agência com relatórios não é produzir números. É produzir números que sobrevivam a uma pergunta de seguimento do cliente, e produzi-los sem três horas de capturas de ecrã no primeiro dia do mês.
Duas coisas ajudam aqui. Os relatórios são rotas de API, por isso o pacote mensal pode ser montado por um script e exportado como PDF, em vez de por uma pessoa e uma folha de cálculo. E os números são honestos quanto aos bots: os dados brutos e os filtrados estão ambos disponíveis, identificados, para que, quando um cliente pergunte por que a taxa de abertura caiu depois da mudança, possas explicá-lo numa frase em vez de o defender em quatro.
Os mesmos blocos chegam à dash-b — desempenho de campanhas, abandono no funil, crescimento da lista, entregabilidade por domínio — para que um cliente que queira um painel em tempo real possa ter um, na conta dele, com as credenciais dele e sem nenhuma chave tua na página.
- 1Para cada projetoUm token, um âmbito de projeto, o mesmo script.
- 2PullDesempenho de campanhas, abandono no funil, crescimento da lista, entregabilidade por domínio.
- 3RenderizarO documento criativo dele como página de relatório, depois para PDF.
- 4EnviarOu deixa no painel dele. Aquele que o cliente realmente lê.
- iO que mudouTrês horas de capturas de ecrã tornaram-se uma tarefa agendada, porque os relatórios sempre foram rotas.
Brutos e filtrados, ambos identificados
A conversa sobre consentimento, feita cedo
Toda a agência já conheceu o cliente que chega com uma folha de cálculo de quatro mil endereços e uma resposta vaga sobre a origem deles. Aqui isso não é uma discussão que tenhas de ganhar; é um campo.
A importação entra, no máximo, como interesse legítimo, nunca como consentimento, e a mistura de bases legais é mostrada antes de qualquer campanha sair. Se uma lista não puder ser usada para envios, isso é dito no momento da importação e não no momento de uma reclamação. Isso transforma um julgamento desconfortável numa leitura partilhada do mesmo ecrã — o que é uma posição muito melhor para ti quando o cliente insistir.
Vale a pena dizer em voz alta ao cliente: a reputação em risco por uma má lista é a dele, no domínio dele, porque cada projeto envia como si próprio. Esse é um argumento mais forte do que qualquer regulamentação, e é o que costuma convencer.