Du genomför tisdagens kundåterhållningsgranskning för en Shopify Plus-butik som säljer för 40 miljoner dollar årligen, och någon ställer en enkel fråga om konfigurationen av din chattwidget för WhatsApp Messenger på webbplatsen: visas WhatsApp faktiskt som ett alternativ på kassasidan den här veckan. Ingen i rummet vet med säkerhet. Widgeten konfigurerades för åtta månader sedan av en entreprenör som sedan dess har slutat, och personen som hanterar supportärenden idag är inte den som ställde in kanalinställningarna.
Det här är det gap som aldrig syns i en lanseringschecklista: en widgetkonfiguration som var korrekt från dag ett och som tyst har glidit sedan dess. En kanal stängs av under en omdesign och slås aldrig på igen. Öppettider ställs in en gång och uppdateras aldrig när supporttäckningen ändras. En targetingregel begränsar widgeten till startsidan och ingen märker att den aldrig nådde kassan. Inget av detta ger ett felmeddelande. Det visar sig som en kund som aldrig ser widgeten, eller som skickar meddelanden till en kanal som ingen övervakar.
PushEngage MCP-servern ger dig ett snabbare sätt att kontrollera: fråga din AI-assistent. Det här inlägget täcker tre återkommande frågor som är värda att ställa, vad assistenten kan och inte kan berätta för dig, och hur du ansluter den.
Vad AI-assistenten faktiskt kan berätta om din widget (och vad den inte kan)
PushEngage MCP inkluderar ett verktyg för chattwidgetar: pushengage_list_chat_widgets. Det är ett läsverktyg. Fråga om en widget och den returnerar status, vilka kanaler som är aktiva, vilka enheter den visas på, om en begränsning baserad på öppettider är inställd och hur den är riktad.
Den skickar inte ett WhatsApp- eller Messenger-meddelande, och den skapar eller redigerar inte en widget. Inget verktyg i PushEngage MCP bygger eller ändrar en; assistenten rapporterar vad som är konfigurerat, och en person gör fortfarande ändringen i instrumentpanelen. Den gränsen är det som gör detta säkert att ge till en AI-assistent: den kan upptäcka ett problem med konfigurationen av din chattwidget för WhatsApp Messenger på webbplatsen, men den kan inte förvärra problemet genom att röra vid en aktiv kanal.
I praktiken innebär det att de tre frågorna nedan alla har samma form: du frågar vad som är konfigurerat, du får ett svar på vanligt språk tillbaka, och du bestämmer vad du ska göra med det. Det gäller för alla PushEngage chattwidgetfrågor i det här inlägget: assistenten rapporterar, en person agerar.
Bekräfta vilka kanaler — WhatsApp, Messenger och andra — som faktiskt är aktiva
Fråga: "Vilka kanaler är aktiverade för min chattwidget, och på vilka enheter?"
Detta är viktigt eftersom en PushEngage-chattwidget visar WhatsApp, Messenger och andra kanaler från en enda widget och en enda kampanjbyggare – inte som separata inbäddningar som du skulle installera en i taget på det sätt som de flesta fristående chattwidgetverktyg fungerar. Det är poängen med att kontrollera kanalstatus i en enda fråga istället för en inställningsflik per kanal: en marknadsföringssida som lovar ”chatta med oss på WhatsApp” är bara sann om WhatsApp faktiskt är aktiverat för den widgeten just nu, på de enheter som shoppare faktiskt använder.
Om din FAQ-sida, kassanstext eller annonslandningssida talar om för en shoppare att WhatsApp är ett alternativ och det inte är live för tillfället, är det inte en UX-detalj. Det är en shoppare som följt dina instruktioner in i en återvändsgränd. Kör den här kontrollen före någon kampanj som nämner en specifik kanal.
Bekräfta att öppettiderna styr widgeten på det sätt du tror
Fråga: ”Vilka är begränsningarna för öppettider på min chattwidget?”
Begränsningar för öppettider ställs in en gång, under installationen, och glöms sedan bort. Supporttäckningen är inte statisk – ett team lägger till en ny tidszon, utökar öppettiderna kring en lansering eller minskar helgtäckningen – och widgetens begränsning flyttas inte med den om inte någon kommer ihåg att uppdatera den. Missmatchningen går åt båda håll: en widget som visas som ”öppen” utanför faktisk täckning skickar en shoppare in i tystnad, och en widget som är mer begränsad än verklig täckning döljer en kanal som faktiskt är bemannad och redo att svara.
Att kontrollera chattwidgetens öppettider mot ditt faktiska supportschema kräver en fråga istället för att korsreferera två inställningsskärmar. Om ditt team har utspridd täckning, kombinera detta med en titt på hur agentplanering för chatt fungerar. Widgetens begränsning och agentplaneringen bakom den bör stämma överens.
Fånga en widget som är osynlig exakt där det spelar roll – kassan, prissättning
Fråga: ”Var är min chattwidget riktad att visas, och är den undantagen från kassan eller prissättning?”
Riktlinjer för målinriktning är det tystaste felscenariot av de tre. En widget kan vara helt live – alla kanaler på, öppettider korrekta – och ändå begränsas av en sidnivåregel för att bara visas på startsidan eller i en bloggsektion, medan kassan och prissättningen, sidorna med mest köpintresse på webbplatsen, aldrig ser den alls.
Det är här granskningen slutar handla om engagemang och börjar handla om intäkter du kan namnge. PushEngages tillvägagångssätt för kanaltrapportering attribuerar intäkter per kanal, inte bara öppningar och klick. Det fungerar bara om kanalen faktiskt finns på sidan där shopparen var på väg att konvertera. En widget som är dold från kassan av en kvarvarande regel för sidinriktning av chattwidgeten är inte en underpresterande kanal; det är en kanal som ger noll attribuerbara konverteringar på den enda sidan som betydde mest. Om din inriktning är mer genomtänkt än ”visa överallt”, jämför den med ett sidnivåinriktning för chatt-tillvägagångssätt som är byggt för exakt den här typen av kontroll.
Kom igång: anslut en AI-assistent till ditt PushEngage-konto
Att köra någon av dessa kontroller börjar med att ansluta PushEngage MCP-servern till en assistent du redan använder. Lägg till en enda post som kör npx -y @pushengage/mcp i din kunds MCP-konfiguration — Claude Desktop, Claude Code och Cursor är de vanligaste fallen, även om alla MCP-kompatibla klienter fungerar på samma sätt. Ingen global installation och inget API-nyckel att klistra in: första gången du ber den att logga in dig, öppnar den en webbläsarflik, du godkänner och en token lagras lokalt. Därifrån, be den att lista dina webbplatser, tala om för den vilken du ska använda, och de tre frågorna ovan är redo att köras. För hela genomgången, se hela PushEngage MCP-installationsguiden.
Gör widgetkontrollen till en fem minuters vana, inte en kvartalsvis brandövning
Ingen av dessa tre kontroller kräver en instrumentpanelsgenomgång när PushEngage MCP-anslutningen väl finns: de är en fråga vardera, och ingen rör en live-inställning. Kör dem som du skulle köra någon annan återkommande retentionskontroll: på ett schema, inte bara efter att en kund klagar på att WhatsApp aldrig svarade eller en kassa-sidans widget som skulle vara live visade sig vara osynlig under ett kvartal.
En chattwidget som glider ur konfigurationen är en långsam läcka i samma tratt som alla andra retentionskanaler arbetar för att täta. Ingen märker det på samma sätt som de skulle märka en trasig sekvens för övergivna kundvagnar, eftersom inget ger fel. PushEngage kör denna widget för 25 000+ företagare i 150+ länder, många konfigurationer som tyst kan glida på samma sätt som din kan.
Att kontrollera din chattwidget på plats för WhatsApp Messenger-inställningar, chattwidgetens öppettider och chattwidgetens sidinriktning kräver tre frågor, inte en inställningsrevision, och det är värt att göra innan en shoppare hittar luckan åt dig. Om du väger chatt som en retentionskanal mer allmänt, PushEngages livechattwidget dirigerar redan shoppare till WhatsApp, Messenger och mer från en enda widget, och det täcks på PushEngages planer. Att ställa in WhatsApp på din webbplats för första gången är ett separat, tidigare steg som det här inlägget antar att du redan har tagit.
