Het is maandagochtend en jij bent de accountleider van drie Shopify Plus-klanten die allemaal via PushEngage draaien. Je hebt over een uur een klantgesprek en voordat het begint, heb je de doorklikratio van vorige week nodig voor de verzendingen van de winkelwagenverlatingen van elke site. Normaal gesproken betekent dit drie afzonderlijke PushEngage-dashboardlogins, drie afzonderlijke exports en drie afzonderlijke mentale resets voordat je iets tegen iemand hebt gezegd.
Dit is hoe het beheren van meerdere klantaccounts met één AI-assistent er in de praktijk uitziet. Met de PushEngage MCP-server verbonden met Claude, Cursor of een andere agent-assistent, verandert dat maandagochtendritueel in één gesprek. Je vraagt naar de CTR van vorige week op de eerste site, krijgt deze, vraagt opnieuw voor de tweede, krijgt deze, vraagt opnieuw voor de derde, en je loopt het gesprek in met alle drie de cijfers voordat je koffie koud is.
Het beheren van meerdere klantaccounts met één AI-assistent klinkt eenvoudig totdat je rooster twee verschillende situaties combineert: sites die je beheert onder één PushEngage-login en klanten die elk hun eigen aparte account hebben. Behandel je die op dezelfde manier, dan kun je de gegevens van de helft van je klanten niet bereiken, of erger nog, je loopt het risico dat de token van de ene klant de account van de andere klant raakt. Dit is hoe PushEngage MCP voor agentschappen er werkelijk uitziet als je voorbij de demo bent: twee afzonderlijke mechanismen, geen universele schakelaar. Dit bericht behandelt beide, wanneer je welke moet gebruiken en hoe je ze kunt gebruiken zonder met de hand een enkel dashboard te openen.
Aan de slag: PushEngage MCP verbinden met je AI-assistent
Als je de PushEngage MCP-server nog niet hebt ingesteld, is de korte versie één commando. Voeg npx -y @pushengage/mcp toe aan de MCP-configuratie van je klant — Claude Desktop’s claude_desktop_config.json, Claude Code of Cursor’s mcp.json accepteren allemaal dezelfde invoer — en start de client opnieuw. Vraag je assistent om "log me in bij PushEngage", keur de geopende browsermelding goed en je assistent slaat lokaal een toegangstoken op; je wachtwoord raakt nooit de chat.
Vraag vanaf daar "toon mijn PushEngage-sites" en "gebruik site [ID]" om te kiezen op welke site de assistent werkt. Alles hieronder gaat ervan uit dat deze basisinstelling al is gedaan voor ten minste één account; voor de volledige walkthrough, inclusief het oplossen van problemen met een klant die geen verbinding wil maken, zie de PushEngage MCP-installatiegids.
Het beheren van meerdere klantaccounts met één AI-assistent betekent het oplossen van twee verschillende problemen
Agentschappen die PushEngage gebruiken voor een klantenlijst komen een van de twee situaties tegen en hebben verschillende oplossingen nodig.
Site-wisseling is wat je hebt wanneer verschillende klantensites onder één PushEngage-login leven die je namens de klanten beheert — een veelvoorkomende opstelling voor agentschappen die klanten rechtstreeks in een door het agentschap beheerd account onboarden. Eén login, één token, meerdere sites om de assistent op te richten.
Account separation is wat je hebt wanneer elke klant zijn eigen PushEngage-account heeft en betaalt, en onafhankelijk inlogt. Hier is geen gedeelde login om tussen te wisselen - er zijn verschillende afzonderlijke logins, elk met zijn eigen token, en de taak is om te voorkomen dat ze ooit vermengd raken.
Een vuistregel bepaalt welke van toepassing is: als je momenteel sites zou wisselen binnen één PushEngage-dashboardtab, wil je site-wisseling. Als je momenteel zou moeten uitloggen bij het dashboard van de ene klant om in te loggen bij dat van een andere, wil je account-scheiding. Het verwarren van de twee is de fout die de moeite waard is om te vermijden: het behandelen van afzonderlijke klantaccounts alsof het sites waren onder één login is precies het soort cross-account vermenging dat nooit mag gebeuren met klantgegevens.
| Site-wisseling | Account-scheiding | |
| Wie beheert de login | Jij, namens de klanten | Elke klant, onafhankelijk |
| Wat verandert er tussen klanten | De geselecteerde site | De volledige MCP-serverregistratie en tokenbestand |
| Betrokken tools | pushengage_list_sites, pushengage_select_site | Aparte PE_MCP_CONFIG_PATH per servernaam |
| Foutmodus als je de verkeerde gebruikt | Je bereikt nooit de gegevens van een klant (als het echt aparte accounts zijn) | Onnodige herauthenticatie overhead (als het echt één gedeelde login is) |
De meeste bureaus die PushEngage gebruiken voor een volledige klantenlijst, gebruiken uiteindelijk beide tegelijk: ze wisselen tussen PushEngage-sites binnen de handvol klanten die één door het bureau beheerde login delen, en registreren aparte accounts voor de klanten die erop staan hun eigen accounts te beheren. Niets aan het registreren van meerdere PushEngage-accounts weerhoudt je ervan om ook sites binnen een van die accounts te wisselen zodra je bent ingelogd.
Site-wisseling: CTR ophalen van drie klantensites in één gesprek
Voor het multi-site geval laten twee tools je wisselen tussen PushEngage-sites zonder het gesprek te verlaten: pushengage_list_sites en pushengage_select_site. Elke site-specifieke tool (analytics, segmenten, campagne-instellingen) werkt op de momenteel geselecteerde site, en de selectie blijft behouden na herstarts, dus je stelt deze één keer per sessie in en elke volgende vraag in dat gesprek is van toepassing op dezelfde site.
Terug naar maandagochtend. Met één verbonden login ziet de CTR-pull voor drie klantensites er als volgt uit in één gesprek:
- Vraag "list my PushEngage sites." De assistent retourneert de naam en ID van elke site.
- Vraag om de ID van de eerste site te gebruiken, vraag dan naar de click-through rate van vorige week. De assistent roept
pushengage_get_analytics_timeseriesaan en retourneert klikken, weergaven en CTR per dag. - Vraag om over te schakelen naar de ID van de tweede site. Stel dezelfde vraag. Herhaal voor de derde.
- Vraag om een samenvatting waarin de drie worden vergeleken. De assistent heeft alle drie de datasets al in het gesprek opgehaald en kan ze naast elkaar zetten.
Wat deze actie de moeite waard maakt in plaats van drie dashboard-exports, is niet alleen de snelheid. Het is dat de cijfers die je ophaalt per site toewijsbaar zijn, niet alleen ruwe opens en clicks. pushengage_get_analytics_summary en pushengage_get_analytics_timeseries retourneren clicks, views en doelwaarde naast CTR, zodat het rapport dat je meeneemt naar het klantgesprek wordt gelezen als herstelde inkomsten per site, niet alleen als engagementaantallen die je zelf voor de klant zou moeten vertalen.
Die formulering is belangrijk omdat CTR alleen maar de helft van het verhaal vertelt. Een branchewijde studie naar segmentatie en click-through rate toonde aan dat CTR 2x of meer beweegt, afhankelijk van hoe nauw de verzendingen van een klant zijn gesegmenteerd, dus hetzelfde CTR-getal kan heel verschillende inkomstenresultaten betekenen bij drie klanten met verschillende segmentatiematuriteit. Dat verschil is het waard om te benadrukken tijdens het gesprek, niet alleen om te rapporteren.
Dit is alleen-lezen werk. Niets van het wisselen tussen PushEngage-sites op deze manier stuurt, plant of bewerkt een campagne; pushengage_list_sites en pushengage_select_site veranderen alleen welke bestaande gegevens van de site de rest van het gesprek leest.
Accountscheiding: het registreren van de MCP-server onder een naam per klant
Voor werkelijk gescheiden klantaccounts bevindt de oplossing zich in de MCP-configuratie zelf, niet in een tool-aanroep. De server van PushEngage leest de locatie van zijn token uit een omgevingsvariabele, PE_MCP_CONFIG_PATH, die standaard op ~/.pushengage/mcp.json staat als je deze nooit instelt. Registreer de server twee keer, eenmaal per klant, elk gericht op zijn eigen bestand, en de twee logins delen nooit een 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 en Brightleaf zijn illustratieve klantnamen.) PE_MCP_CONFIG_PATH moet een absoluut pad zijn — het wordt precies gebruikt zoals gegeven, zonder ~-expansie, dus controleer het pad dubbel voordat je je client opnieuw start. PE_MCP_CLIENT_NAME is optioneel en verandert alleen het label dat je assistent toont op het autorisatiescherm van PushEngage zelf; het heeft geen invloed op de isolatie, maar het is de moeite waard om in te stellen, zodat je kunt zien welke klant je hebt geautoriseerd wanneer het browsertabblad wordt geopend.
Log afzonderlijk in op elke servernaam: "log me in op pushengage-northwind", en vervolgens, in een latere stap, "log me in op pushengage-brightleaf." Elk autoriseert tegen welke PushEngage-account je ook kiest in die specifieke browsersessie. Twee servernamen, twee configuratiebestanden, twee tokens die elkaar nooit raken. Dit is het patroon voor het naast elkaar draaien van meerdere PushEngage-accounts, en het schaalt voorbij twee: een bureau met een dozijn klantaccounts registreert een dozijn serververmeldingen, elk met zijn eigen PE_MCP_CONFIG_PATH, en geen van hen deelt ooit een bestand. Het is ook het onderdeel dat de meeste concurrerende "multi-client AI"-gidsen overslaan met vage praatjes over isolatie in plaats van een daadwerkelijke configuratie om te kopiëren.
Het uitvoeren van dezelfde prompt voor het maken van segmenten op elk klantaccount
Zodra uw klanten zijn geregistreerd als afzonderlijke servernamen, kunt u één verzoek opnieuw afspelen op al deze servers zonder ooit een dashboard te openen. Stel dat u een segment 'bezoekers van /pricing' live wilt hebben op vijf klantaccounts vóór het einde van de dag. Vraag uw assistent om op zijn beurt een 'segment te maken voor bezoekers van /pricing' tegen pushengage-northwind, dan pushengage-brightleaf, dan elke resterende klantservernaam. Elk verzoek roept pushengage_create_segment aan tegen de eigen token van dat account, en elke klant krijgt hetzelfde URL-regelsegment, gebouwd op hun eigen abonneebestand.
De reden dat dezelfde prompt schoon over vijf verschillende klantaccounts wordt overgezet, is dat deze een ingebouwd segmentatiemodel van PushEngage aanroept, niet iets dat u per klant vanaf nul bouwt. pushengage_list_segments en pushengage_create_segment werken met URL-regels en gedragscriteria die het platform al begrijpt — recentheid, frequentie, pagina-bezoekpatronen — dezelfde categorieën die de aanpak van de gids voor e-commerce segmentatie als een systeem laten werken in plaats van een eenmalige lijst. Dat is wat één prompt vijf keer echt segmentatiewerk laat doen in plaats van vijf afzonderlijke handmatige builds. En omdat segmentatie nu een vereiste is voor leverbaarheid in plaats van een leuke extra, is het opnieuw afspelen ervan op elk klantaccount dichter bij standaard accounthygiëne dan een snelkoppeling.
De toegang van een voormalig teamlid uit elk ander klantaccount houden
Accountseparatie verdient zijn waarde op de dag dat iemand een account verlaat. Omdat de token van elke klant in zijn eigen configuratiebestand leeft, raakt het verwijderen van de toegang van één persoon tot één klant de rest van uw team nooit aan.
Twee manieren om het af te sluiten:
- Lokaal: log uit van alleen de serverregistratie van die klant — 'log me uit van pushengage-northwind' roept
pushengage_auth_logoutaan, wat de token uit dat ene configuratiebestand verwijdert en de bestanden van alle andere klanten onaangetast laat. - Server-side: als het vertrekkende teamlid de browsersessie zelf heeft geautoriseerd, trek deze dan in vanuit PushEngage onder Instellingen → Beveiliging op het account van die specifieke klant, wat de token ongeldig maakt, ongeacht waar deze lokaal is opgeslagen.
Vergelijk dat eens met wat er gebeurt met één gedeelde login voor meerdere klanten: het intrekken van toegang betekent het roteren van één gedeelde token, wat de verbinding van elk teamlid met elke klant tegelijkertijd verbreekt. Elke klant op zijn eigen PE_MCP_CONFIG_PATH houden, verandert een teambrede brandweeroefening in een oplossing van één regel.
Wat dit verandert voor hoe een bureau prijzen bepaalt en personeel inzet voor pushwerk voor meerdere klanten
Niets hiervan verandert wat pushmeldingen doen voor de retentietallen van een klant. De MCP-server van PushEngage verzendt, plant of bouwt geen campagnes op eigen houtje; elke pushengage_send_notification- of pushengage_send_ab_notification-aanroep wordt nog steeds tegen één site tegelijk uitgevoerd, met uw goedkeuring. Wat verandert, is de tijd tussen "de klant wil zijn cijfers weten" en "de klant heeft zijn cijfers", en tijd is de enige bron die een accountmanager niet meer kan kopen halverwege de maand.
Dat is de werkelijke waarde van het beheren van meerdere klantaccounts met één AI-assistent: geen nieuwe functionaliteit, maar tijd terug. Het is belangrijk op de schaal waarop PushEngage al draait — 25.000+ bedrijfseigenaren in 150+ landen hebben alleen al in de afgelopen 30 dagen 15,2 miljard meldingen via het platform verzonden.
Een bureau dat een handvol van die accounts beheert, vraagt deze infrastructuur niet om iets nieuws te doen; het vraagt om toegang te krijgen tot de rapportage- en publieksopbouw die het al doet, zonder dat een dashboardlogin tussen de assistent en het antwoord staat. De accountmanager die vroeger op maandagochtend drie CSV's exporteerde, besteedt die tijd nu aan wat die cijfers zeggen over de herhaalaankoopratio van elke klant. Dat is het deel van het werk dat nooit bedoeld was om over logins te gaan.
Of uw lijst nu site-overschakeling, accountseparatie of beide vereist, de bovenstaande mechanismen werken op elk PushEngage-abonnement, geprijsd om mee te schalen met actieve abonnees in plaats van per klantaccount, dus het toevoegen van de vierde of vijfde klant aan deze opstelling betekent niet dat u opnieuw moet onderhandelen over wat u betaalt om ze te bereiken. Dat is de werkelijke vorm van PushEngage MCP voor bureaus: geen nieuwe manager-accountlaag die er bovenop is geplakt, maar dezelfde twee mechanismen (één login met verschillende sites, of verschillende logins die nooit kruisen) toegepast op hoeveel klanten u dit kwartaal beheert.
