É segunda-feira de manhã, e você é o líder de conta de três clientes Shopify Plus que usam PushEngage. Você tem uma ligação com um cliente em uma hora e, antes que ela comece, precisa da taxa de cliques da semana passada para os envios de abandono de carrinho de cada site. Normalmente, isso significa três logins separados no painel PushEngage, três exportações separadas e três reinícios mentais separados antes de você ter dito uma palavra a alguém.
É assim que o gerenciamento de várias contas de clientes com um único assistente de IA funciona na prática. Com o servidor PushEngage MCP conectado ao Claude, Cursor ou outro assistente agentivo, esse ritual de segunda-feira se transforma em uma única conversa. Você pede a taxa de cliques da semana passada no primeiro site, recebe, pede novamente para o segundo, recebe, pede novamente para o terceiro, e você entra na ligação com os três números antes que seu café esfrie.
Gerenciar várias contas de clientes com um único assistente de IA parece simples até que seu portfólio misture duas situações diferentes: sites que você gerencia sob um login PushEngage e clientes que cada um mantém sua própria conta separada. Trate essas da mesma forma e você não conseguirá acessar os dados de metade dos seus clientes ou, pior, corre o risco de o token de um cliente tocar na conta de outro cliente. É assim que o PushEngage MCP para agências realmente funciona depois de passar da demonstração: dois mecanismos distintos, não um interruptor universal. Este post cobre ambos, quando usar cada um e como usá-los sem abrir um único painel manualmente.
Primeiros passos: conectando o PushEngage MCP ao seu assistente de IA
Se você ainda não configurou o servidor PushEngage MCP, a versão curta é um comando. Adicione npx -y @pushengage/mcp à configuração MCP do seu cliente — o claude_desktop_config.json do Claude Desktop, Claude Code ou o mcp.json do Cursor aceitam a mesma entrada — e reinicie o cliente. Peça ao seu assistente para "me conectar ao PushEngage", aprove o prompt do navegador que se abre e seu assistente armazena um token de acesso localmente; sua senha nunca toca no chat.
A partir daí, peça "mostre meus sites PushEngage" e "use o site [ID]" para escolher em qual o assistente atua. Tudo abaixo assume que essa configuração base já foi feita para pelo menos uma conta; para o guia completo, incluindo solução de problemas de um cliente que não conecta, consulte o guia de configuração do PushEngage MCP.
Gerenciar várias contas de clientes com um único assistente de IA significa resolver dois problemas diferentes
Agências que executam o PushEngage em um portfólio de clientes se deparam com uma das duas situações e precisam de correções diferentes.
Alternância de sites é o que você tem quando vários sites de clientes residem sob um único login PushEngage que você gerencia em nome dos clientes — uma configuração comum para agências que integram clientes diretamente em uma conta de propriedade da agência. Um login, um token, vários sites para direcionar o assistente.
Separação de contas é o que você tem quando cada cliente mantém e paga por sua própria conta PushEngage, e faz login independentemente. Aqui não há login compartilhado para alternar internamente — existem vários logins separados, cada um com seu próprio token, e o trabalho é evitar que eles se misturem.
Uma regra geral define qual se aplica: se você alternaria sites dentro de uma aba do painel PushEngage, você quer a alternância de sites. Se você precisaria fazer logout de um painel de cliente para fazer login em outro, você quer a separação de contas. Confundir os dois é o erro que vale a pena evitar: tratar contas de clientes separadas como se fossem sites sob um único login é exatamente o tipo de mistura entre contas que nunca deveria acontecer com dados de clientes.
| Alternância de sites | Separação de contas | |
| Quem detém o login | Você, em nome dos clientes | Cada cliente, independentemente |
| O que muda entre os clientes | O site selecionado | O registro completo do servidor MCP e o arquivo de token |
| Ferramentas envolvidas | pushengage_list_sites, pushengage_select_site | PE_MCP_CONFIG_PATH separado por nome de servidor |
| Modo de falha se você usar o incorreto | Você nunca acessa os dados de um cliente (se contas verdadeiramente separadas) | Sobrecarga desnecessária de reautenticação (se um único login compartilhado de verdade) |
A maioria das agências que gerenciam PushEngage para uma lista completa acaba usando ambos ao mesmo tempo: elas alternam entre sites PushEngage dentro do punhado de clientes que compartilham um login gerenciado pela agência, e registram contas separadas para os clientes que insistem em manter as suas. Nada no registro de múltiplas contas PushEngage impede que você também alterne sites dentro de qualquer uma delas assim que estiver logado.
Alternância de sites: puxando CTR de três sites de clientes em uma única conversa
Para o caso multi-site, duas ferramentas permitem que você alterne entre sites PushEngage sem sair da conversa: pushengage_list_sites e pushengage_select_site. Cada ferramenta com escopo de site (analytics, segmentos, configurações de campanha) atua sobre o site que estiver atualmente selecionado, e a seleção persiste entre reinicializações, então você a define uma vez por sessão e cada pergunta subsequente nessa conversa se aplica ao mesmo site.
De volta à segunda-feira de manhã. Com um login conectado, a consulta de CTR para três sites de clientes se parece com isto em uma única conversa:
- Pergunte “liste meus sites PushEngage.” O assistente retorna o nome e o ID de cada site.
- Peça para usar o ID do primeiro site, depois peça a taxa de cliques da semana passada. O assistente chama
pushengage_get_analytics_timeseriese retorna cliques, visualizações e CTR por dia. - Peça para alternar para o ID do segundo site. Faça a mesma pergunta. Repita para o terceiro.
- Peça um resumo comparando os três. O assistente já puxou todos os três conjuntos de dados na conversa e pode colocá-los lado a lado.
O que torna isso útil em vez de três exportações de painel não é apenas a velocidade. São os números que você está extraindo que são atribuíveis por site, não apenas aberturas e cliques brutos. pushengage_get_analytics_summary e pushengage_get_analytics_timeseries retornam cliques, visualizações e valor de meta ao lado da CTR, então o relatório que você apresenta na chamada com o cliente é lido como receita recuperada por site, não apenas contagens de engajamento que você teria que traduzir para o cliente sozinho.
Essa formulação importa porque a CTR sozinha conta apenas metade da história. Um estudo em todo o setor sobre segmentação e taxa de cliques descobriu que a CTR se move 2x ou mais dependendo de quão bem os envios de um cliente são segmentados, então o mesmo número de CTR pode significar resultados de receita muito diferentes em três clientes com diferentes níveis de maturidade de segmentação. Essa diferença vale a pena sinalizar na chamada, não apenas relatar.
Este é um trabalho somente leitura. Nada sobre alternar entre sites PushEngage desta forma envia, agenda ou edita uma campanha; pushengage_list_sites e pushengage_select_site apenas mudam quais dados existentes do site o restante da conversa lê.
Separação de contas: registrar o servidor MCP sob um nome por cliente
Para contas de clientes genuinamente separadas, a correção está na própria configuração do MCP, não em uma chamada de ferramenta. O servidor do PushEngage lê a localização do seu token de uma variável de ambiente, PE_MCP_CONFIG_PATH, que tem como padrão ~/.pushengage/mcp.json se você nunca a definir. Registre o servidor duas vezes, uma por cliente, cada um apontado para seu próprio arquivo, e os dois logins nunca compartilham um token:
{
"mcpServers": {
"pushengage-northwind": {
"command": "npx",
"args": ["-y", "@pushengage/mcp"],
"env": {
"PE_MCP_CONFIG_PATH": "/Users/you/.pushengage/mcp-northwind.json",
"PE_MCP_CLIENT_NAME": "Claude Desktop (Northwind)"
}
},
"pushengage-brightleaf": {
"command": "npx",
"args": ["-y", "@pushengage/mcp"],
"env": {
"PE_MCP_CONFIG_PATH": "/Users/you/.pushengage/mcp-brightleaf.json",
"PE_MCP_CLIENT_NAME": "Claude Desktop (Brightleaf)"
}
}
}
}(Northwind e Brightleaf são nomes de clientes ilustrativos.) PE_MCP_CONFIG_PATH deve ser um caminho absoluto — ele é usado exatamente como fornecido, sem expansão de ~, portanto, verifique o caminho antes de reiniciar seu cliente. PE_MCP_CLIENT_NAME é opcional e apenas altera o rótulo que seu assistente exibe na tela de autorização do próprio PushEngage; ele não afeta o isolamento, mas vale a pena definir para que você possa dizer qual cliente você autorizou quando a aba do navegador abrir.
Faça login em cada nome de servidor separadamente: “me conecte ao pushengage-northwind” e, em uma etapa posterior, “me conecte ao pushengage-brightleaf”. Cada um autoriza contra qualquer conta PushEngage que você escolher naquela sessão específica do navegador. Dois nomes de servidor, dois arquivos de configuração, dois tokens que nunca se tocam. Este é o padrão para executar várias contas PushEngage lado a lado, e ele escala além de dois: uma agência com uma dúzia de contas de clientes registra uma dúzia de entradas de servidor, cada uma com seu próprio PE_MCP_CONFIG_PATH, e nenhum deles jamais compartilha um arquivo. É também a parte que a maioria das guias concorrentes de "IA multicliente" pula com conversas vagas sobre isolamento em vez de uma configuração real para copiar.
Executando o mesmo prompt de criação de segmento em todas as contas de clientes
Uma vez que seus clientes são registrados como nomes de servidor separados, você pode reproduzir uma solicitação em todos eles sem nunca abrir um painel. Digamos que você queira um segmento de “visitantes de /pricing” ativo em cinco contas de clientes antes do final do dia. Peça ao seu assistente, por sua vez, para “criar um segmento para visitantes de /pricing” contra pushengage-northwind, depois pushengage-brightleaf, depois cada nome de servidor de cliente restante. Cada solicitação chama pushengage_create_segment contra o token de cada conta, e cada cliente acaba com o mesmo segmento de regra de URL, construído em sua própria base de assinantes.
O motivo pelo qual o mesmo prompt é transferido de forma limpa entre as contas de cinco clientes diferentes é que ele está invocando um modelo de segmentação integrado ao PushEngage, não algo que você está arquitetando do zero para cada cliente. pushengage_list_segments e pushengage_create_segment funcionam com regras de URL e critérios comportamentais que a plataforma já entende — recência, frequência, padrões de visita de página — as mesmas categorias que fazem a abordagem do guia de segmentação de e-commerce funcionar como um sistema em vez de uma lista única. É isso que permite que um prompt faça o trabalho real de segmentação cinco vezes em vez de cinco compilações manuais separadas. E como a segmentação é agora um requisito de entregabilidade em vez de um diferencial, reproduzi-la em todas as contas de clientes é mais próximo da higiene padrão da conta do que um atalho.
Manter o acesso de um ex-membro da equipe fora da conta de todos os outros clientes
A separação de contas se justifica no dia em que alguém sai de uma conta. Como o token de cada cliente vive em seu próprio arquivo de configuração, remover o acesso de uma pessoa a um cliente nunca afeta o restante de sua lista.
Duas maneiras de encerrar:
- Localmente: saia do registro do servidor apenas desse cliente — “sair do pushengage-northwind” chama
pushengage_auth_logout, que exclui o token desse único arquivo de configuração e deixa o arquivo de todos os outros clientes intocado. - No lado do servidor: se o membro da equipe que está saindo autorizou a sessão do navegador, revogue-a de dentro do PushEngage em Configurações → Segurança na conta específica desse cliente, o que invalida o token independentemente de onde ele esteja armazenado localmente.
Compare isso com o que acontece com um único login compartilhado entre clientes: revogar o acesso significa rotacionar um token compartilhado, o que quebra a conexão de todos os colegas de equipe com todos os clientes de uma vez. Manter cada cliente em seu próprio PE_MCP_CONFIG_PATH transforma um exercício de pânico em toda a equipe em uma correção de uma linha.
O que isso muda na forma como uma agência precifica e aloca pessoal para trabalho de push com vários clientes
Nada disso muda o que as notificações push fazem pelos números de retenção de um cliente. O servidor MCP do PushEngage não envia, agenda ou cria campanhas por conta própria; cada chamada pushengage_send_notification ou pushengage_send_ab_notification ainda é executada em um site por vez, com sua aprovação. O que muda é o tempo entre “o cliente quer saber seus números” e “o cliente tem seus números”, e o tempo é o único recurso que um gerente de contas não pode comprar mais no meio do mês.
Esse é o verdadeiro valor de gerenciar várias contas de clientes com um único assistente de IA: não uma nova capacidade, mas tempo recuperado. Isso importa na escala em que o PushEngage já opera — mais de 25.000 proprietários de negócios em mais de 150 países enviaram 15,2 bilhões de notificações pela plataforma nos últimos 30 dias apenas.
Uma agência que gerencia um punhado dessas contas não está pedindo a essa infraestrutura para fazer algo novo; está pedindo para alcançar o trabalho de relatórios e construção de público que ela já faz, sem um login de painel entre o assistente e a resposta. O gerente de contas que costumava passar as manhãs de segunda-feira exportando três CSVs agora gasta esse tempo com o que esses números dizem sobre a taxa de recompra de cada cliente. Essa é a parte do trabalho que nunca deveria ter sido sobre logins em primeiro lugar.
Seja qual for a necessidade do seu portfólio de troca de sites, separação de contas ou ambos, os mecanismos acima funcionam em todos os planos do PushEngage, com preço escalonado com base nos assinantes ativos em vez de por conta de cliente, então adicionar o quarto ou quinto cliente a essa configuração não significa renegociar o que você paga para alcançá-los. Essa é a forma real do MCP do PushEngage para agências: não um novo nível de conta de gerente adicionado no topo, mas os mesmos dois mecanismos (um login com vários sites ou vários logins que nunca se cruzam) aplicados a quantos clientes você estiver gerenciando neste trimestre.
