Det är måndag morgon, och du är kontochef för tre Shopify Plus-klienter som alla kör push via PushEngage. Du har ett klientmöte om en timme, och innan det börjar behöver du förra veckans klickfrekvens för varje webbplats skickade varukorgsövergivningsmeddelanden. Normalt innebär det tre separata PushEngage-instrumentpanelsinloggningar, tre separata exporter och tre separata mentala omställningar innan du har sagt ett ord till någon.
Det här är vad som menas med att hantera flera klientkonton med en AI-assistent i praktiken. Med PushEngage MCP-servern ansluten till Claude, Cursor eller en annan agentassistent, förvandlas den där måndagsmorgonritualen till en enda konversation. Du frågar efter förra veckans CTR på den första webbplatsen, får den, frågar igen för den andra, får den, frågar igen för den tredje, och du går in i mötet med alla tre siffrorna innan ditt kaffe har kallnat.
Att hantera flera klientkonton med en AI-assistent låter enkelt tills din lista blandar två olika situationer: webbplatser du hanterar under en PushEngage-inloggning, och klienter som var och en har sitt eget separata konto. Behandla dem på samma sätt och du kan antingen inte komma åt hälften av dina klienters data, eller värre, du riskerar att en klients token vidrör en annan klients konto. Det här är vad PushEngage MCP för byråer faktiskt ser ut när du väl har passerat demon: två distinkta mekanismer, inte en universell växling. Det här inlägget täcker båda, när du ska använda vilken, och hur du använder dem utan att öppna en enda instrumentpanel manuellt.
Komma igång: ansluta PushEngage MCP till din AI-assistent
Om du inte redan har konfigurerat PushEngage MCP-servern, är den korta versionen ett kommando. Lägg till npx -y @pushengage/mcp i din klients MCP-konfiguration — Claude Desktops claude_desktop_config.json, Claude Code eller Cursors mcp.json accepterar alla samma post — och starta om klienten. Be din assistent att ”logga in mig på PushEngage”, godkänn webbläsarprompten som öppnas, och din assistent lagrar en åtkomsttoken lokalt; ditt lösenord vidrör aldrig chatten.
Därifrån, fråga ”visa mina PushEngage-webbplatser” och ”använd webbplats [ID]” för att välja vilken assistenten agerar på. Allt nedan förutsätter att denna grundläggande konfiguration redan är gjord för minst ett konto; för hela genomgången, inklusive felsökning av en klient som inte ansluter, se PushEngage MCP-installationsguiden.
Att hantera flera klientkonton med en AI-assistent innebär att lösa två olika problem
Byråer som kör PushEngage över en klientlista stöter på en av två situationer, och de behöver olika lösningar.
Webbplatsväxling är vad du har när flera klientwebbplatser finns under en PushEngage-inloggning som du hanterar å klienternas vägnar — en vanlig konfiguration för byråer som onboardar klienter direkt till ett byråägt konto. En inloggning, en token, flera webbplatser att rikta assistenten mot.
Kontoavskiljning är vad du har när varje klient har och betalar för sitt eget PushEngage-konto och loggar in självständigt. Här finns ingen delad inloggning att växla mellan – det finns flera separata inloggningar, var och en med sin egen token, och uppgiften är att förhindra att de någonsin blandas.
En tumregel avgör vilken som gäller: om du för närvarande skulle växla webbplatser inom en PushEngage-instrumentpanel, vill du ha webbplatsväxling. Om du för närvarande skulle behöva logga ut från en klients instrumentpanel för att logga in på en annan, vill du ha kontoavskiljning. Att förväxla de två är misstaget värt att undvika: att behandla separata klientkonton som om de vore webbplatser under en enda inloggning är precis den typen av kors-konto-blandning som aldrig borde hända med klientdata.
| Webbplatsväxling | Kontoavskiljning | |
| Vem hanterar inloggningen | Du, på klienternas vägnar | Varje klient, självständigt |
| Vad som ändras mellan klienter | Den valda webbplatsen | Hela MCP-serverregistreringen och tokenfilen |
| Verktyg som används | pushengage_list_sites, pushengage_select_site | Separat PE_MCP_CONFIG_PATH per servernamn |
| Felläge om du använder fel | Du når aldrig en klients data (om verkligen separata konton) | Onödig omautentiserings-overhead (om verkligen en delad inloggning) |
De flesta byråer som använder PushEngage för en hel lista slutar med att använda båda samtidigt: de växlar mellan PushEngage-webbplatser inom de få klienter som delar en enda av byrån hanterad inloggning, och registrerar separata konton för de klienter som insisterar på att ha sina egna. Ingenting med att registrera flera PushEngage-konton hindrar dig från att också växla webbplatser inom något av dem när du väl är inloggad.
Webbplatsväxling: hämta CTR över tre klientwebbplatser i en konversation
För fallet med flera webbplatser låter två verktyg dig växla mellan PushEngage-webbplatser utan att lämna konversationen: pushengage_list_sites och pushengage_select_site. Varje webbplats-specifikt verktyg (analys, segment, kampanjinställningar) agerar på den webbplats som för närvarande är vald, och valet kvarstår över omstarter, så du ställer in det en gång per session och varje uppföljande fråga i den konversationen gäller samma webbplats.
Tillbaka till måndag morgon. Med en inloggning ansluten ser CTR-hämtningen för tre klientwebbplatser ut så här i en enda konversation:
- Fråga "lista mina PushEngage-webbplatser." Assistenten returnerar varje webbplats namn och ID.
- Be att få använda den första webbplatsens ID, fråga sedan efter förra veckans klickfrekvens. Assistenten anropar
pushengage_get_analytics_timeseriesoch returnerar klick, visningar och CTR per dag. - Be att få växla till den andra webbplatsens ID. Fråga samma fråga. Upprepa för den tredje.
- Be om en sammanfattning som jämför de tre. Assistenten har redan hämtat alla tre datamängderna under konversationen och kan ställa dem sida vid sida.
Det som gör detta värt att göra istället för tre dashboard-exporter är inte bara hastigheten. Det är att siffrorna du hämtar kan hänföras per webbplats, inte bara råa öppningar och klick. pushengage_get_analytics_summary och pushengage_get_analytics_timeseries returnerar klick, visningar och målvärde tillsammans med CTR, så rapporten du går in i kundmötet med läses som återvunnen intäkt per webbplats, inte bara engagemangssiffror som du själv skulle behöva översätta för kunden.
Den här inramningen spelar roll eftersom CTR ensamt berättar bara halva historien. En branschövergripande studie om segmentering och klickfrekvens fann att CTR rör sig 2 gånger eller mer beroende på hur tätt en kunds utskick är segmenterade, så samma CTR-siffra kan innebära mycket olika intäktsresultat över tre kunder med olika segmenteringsmognad. Den skillnaden är värd att flagga för i samtalet, inte bara rapportera.
Detta är skrivskyddat arbete. Ingenting med att växla mellan PushEngage-webbplatser på detta sätt skickar, schemalägger eller redigerar en kampanj; pushengage_list_sites och pushengage_select_site ändrar bara vilken webbplats befintliga data resten av konversationen läser.
Kontoseparation: registrera MCP-servern under ett namn per klient
För genuint separata klientkonton finns lösningen i själva MCP-konfigurationen, inte i ett verktygsanrop. PushEngages server läser sin tokenplats från en miljövariabel, PE_MCP_CONFIG_PATH, som standard är ~/.pushengage/mcp.json om du aldrig ställer in den. Registrera servern två gånger, en gång per klient, var och en pekande på sin egen fil, och de två inloggningarna delar aldrig en 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 och Brightleaf är illustrativa klientnamn.) PE_MCP_CONFIG_PATH måste vara en absolut sökväg – den används exakt som den anges, utan ~-expansion, så dubbelkolla sökvägen innan du startar om din klient. PE_MCP_CLIENT_NAME är valfri och ändrar bara etiketten som din assistent visar på PushEngages egen auktoriseringsskärm; den påverkar inte isoleringen, men det är värt att ställa in den så att du kan se vilken klient du auktoriserade när fliken i webbläsaren öppnas.
Logga in på varje servernamn separat: "logga in mig på pushengage-northwind", sedan, i ett senare steg, "logga in mig på pushengage-brightleaf". Varje auktoriserar mot det PushEngage-konto du väljer i den specifika webbläsarsessionen. Två servernamn, två konfigurationsfiler, två tokens som aldrig rör vid varandra. Detta är mönstret för att köra flera PushEngage-konton sida vid sida, och det skalar förbi två: en byrå med ett dussin klientkonton registrerar ett dussin serverposter, var och en med sin egen PE_MCP_CONFIG_PATH, och ingen av dem delar någonsin en fil. Det är också den del som de flesta konkurrerande "multi-client AI"-guider hoppar över med vagt prat om isolering istället för en faktisk konfiguration att kopiera.
Kör samma prompt för att skapa segment över alla klientkonton
När dina klienter är registrerade som separata servernamn kan du spela upp en begäran över alla av dem utan att någonsin öppna en instrumentpanel. Säg att du vill ha ett segment för "besökare av /pricing" live på fem klientkonton före slutet av dagen. Be din assistent att i sin tur "skapa ett segment för besökare av /pricing" mot pushengage-northwind, sedan pushengage-brightleaf, sedan varje återstående klientservernamn. Varje begäran anropar pushengage_create_segment mot det kontots egna token, och varje klient får samma URL-regel-segment, byggt på deras egen prenumerantbas.
Anledningen till att samma prompt överförs rent över fem olika klientkonton är att den anropar en segmenteringsmodell som PushEngage levererar inbyggd, inte något du skapar från grunden per klient. pushengage_list_segments och pushengage_create_segment arbetar med URL-regler och beteendekriterier som plattformen redan förstår – aktualitet, frekvens, sidbesöksmönster – samma kategorier som gör e-handelsguiden för segmenterings metod fungera som ett system snarare än en engångslista. Det är det som gör att en prompt kan göra verkligt segmenteringsarbete fem gånger om istället för fem separata manuella byggen. Och eftersom segmentering nu är ett leveranskrav snarare än en trevlig finess, är att spela upp det över varje klientkonto närmare standardkontohygien än en genväg.
Att hålla en tidigare teammedlems åtkomst borta från varje annat klients konto
Kontoseparation tjänar sitt syfte den dagen någon lämnar ett konto. Eftersom varje klients token finns i sin egen konfigurationsfil, påverkar borttagning av en persons åtkomst till en klient aldrig resten av din personal.
Två sätt att avsluta det:
- Lokalt: logga ut från bara den klientens serverregistrering – "logga ut mig från pushengage-northwind" anropar
pushengage_auth_logout, som raderar token från den enda konfigurationsfilen och lämnar varje annan klients fil orörd. - Server-sida: om den avgående teammedlemmen själv godkände webbläsarsessionen, återkalla den inifrån PushEngage under Inställningar → Säkerhet på den specifika klients konto, vilket ogiltigförklarar token oavsett var den lagras lokalt.
Jämför det med vad som händer med en enda delad inloggning över klienter: att återkalla åtkomst innebär att rotera en delad token, vilket bryter varje lagkamrats anslutning till varje klient samtidigt. Att hålla varje klient på sin egen PE_MCP_CONFIG_PATH förvandlar en personalomfattande brandövning till en enradig lösning.
Vad detta förändrar för hur en byrå prissätter och bemannar push-arbete för flera klienter
Inget av detta ändrar vad push-notiser gör för en kunds bibehållningssiffror. PushEngages MCP-server skickar, schemalägger eller bygger inte kampanjer på egen hand; varje anrop till pushengage_send_notification eller pushengage_send_ab_notification körs fortfarande mot en webbplats i taget, och du godkänner det. Det som ändras är tiden mellan ”kunden vill veta sina siffror” och ”kunden har sina siffror”, och tid är den enda resurs som en kontohanterare inte kan köpa mer av mitt i månaden.
Det är det verkliga värdet av att hantera flera klientkonton med en AI-assistent: inte en ny funktion, utan tid tillbaka. Det spelar roll i den skala som PushEngage redan körs på — 25 000+ företagare i över 150 länder skickade 15,2 miljarder notiser genom plattformen bara under de senaste 30 dagarna.
En byrå som hanterar en handfull av dessa konton ber inte denna infrastruktur att göra något nytt; den ber om att nå rapporterings- och publikbyggnadsarbetet som den redan gör, utan en dashboard-inloggning som står mellan assistenten och svaret. Kontohanteraren som brukade spendera måndagsmorgnar på att exportera tre CSV-filer spenderar nu den tiden på vad dessa siffror säger om varje kunds återköpsfrekvens. Det är den delen av jobbet som aldrig var tänkt att handla om inloggningar från första början.
Oavsett om din lista behöver webbplatsbyte, kontoseparation eller båda, körs mekanismerna ovan på alla PushEngage-planer, prissatta för att skala med aktiva prenumeranter snarare än per klientkonto, så att lägga till den fjärde eller femte kunden i denna konfiguration innebär inte att omförhandla vad du betalar för att nå dem. Det är den faktiska formen av PushEngage MCP för byråer: inte en ny chefskonto-nivå pålagd ovanpå, utan samma två mekanismer (en inloggning med flera webbplatser, eller flera inloggningar som aldrig korsas) tillämpade på hur många kunder du hanterar detta kvartal.
