För att organisera kunder i ett CRM för WhatsApp, separera fyra uppgifter: vem personen är, vilka beställningar hen har gjort, vad som diskuteras och vad nästa åtgärd för teamet är. Inom e‑handel hjälper denna separation att undvika ett vanligt misstag: att behandla en kontaktetikett som om den sammanfattar alla kundens köp. Utgångspunkten är att definiera var varje uppgift kommer ifrån och hur man kontrollerar att den fortfarande är korrekt.
Vad behöver ett CRM för WhatsApp organisera?
CRM är hantering av kundrelationer. I en verksamhet som använder WhatsApp innebär det att koppla kontakter, kommersiell kontext och uppföljning. Konversationen är en del av den kontexten, men själva meddelandehistoriken bekräftar inte betalning, leverans eller annullering.
Tänk på en kund som handlat två gånger. Den första beställningen levererades; den andra väntar på betalning. Hon kan vara en återkommande köpare och samtidigt ha ett köp som är öppet. Om hela profilen får bara etiketten “pago” förlorar teamet skillnaden mellan beställningarna.
Därför, organisera relationen i lager. Den segmentering av kunder för kampanjer svarar vem som ska ingå i en målgrupp; inboxen för support samlar konversationer; butiken eller systemet som ansvarar för beställningen informerar om köpet status. Dessa funktioner behöver utbyta kontext, även när de finns i olika verktyg. En matris för att avgöra var varje uppgift hör hemma
Tabellen är en modell för arbetsorganisation, inte en lista över fält som finns i all programvara. Anpassa namnen till det system som används och behåll endast de uppgifter som behövs för verksamheten.
Lager
| Användbar information | Källa att fastställa | Nödvändig verifiering | Kund |
|---|---|---|---|
| Identifierare i butiken, namn och bekräftad kontakt | Butikens register eller ansvarigt CRM | Stämmer kontakten överens med personen och är den kopplad till rätt registrering? | Beställning |
| Identifierare, status och tidpunkt för uppdatering | Butik, ERP eller system definierat för det stadiet | Tillhör statusen den aktuella beställningen och är den uppdaterad? | Konversation |
| Orsak till kontakten, öppet ärende och nödvändig sammanfattning | Supporthistorik | Vilket ärende behöver fortfarande ett svar? | Nästa åtgärd |
| Ansvarig, åtgärd och intern tidsfrist | CRM, uppgiftshanteringsverktyg eller teamkontroll | Har någon tagit över kontinuiteten? | Kommunikationspreferenser |
| Registrerat samtycke, syfte och begäran om avbrott | Process där preferensen meddelades | Respekterar den planerade kommunikationen den senaste preferensen? | Välj en ansvarig källa för varje uppgift. Om ERP bekräftar fakturering och butiken visar en äldre status behöver teamet en regel för att kontrollera konflikten. Ett nyimporterat data är inte nödvändigtvis det mest aktuella: importen kan föra med sig ett gammalt fotografi av databasen. |
I
integrationer med e‑handelsplattformar kontrollera vilka händelser och fält som är tillgängliga. “Integrerar med butiken” säger inte i sig vilka uppdateringar som kommer in, under vilka villkor eller hur de kopplas till kunden.Hur man börjar organisera basen
1. Identifiera kunder utan att slå ihop register baserat på antaganden
Använd kundens identifierare i butiken som referens när den finns tillgänglig. Standardisera sättet att registrera telefon och landskod enligt integrationskraven. Liknande namn är inget bevis på att två poster tillhör samma person.
Ett telefonnummer kan ha skrivits fel, delas av en familj eller ändrats. Vid tvekan skicka verifieringen till teamet innan du slår ihop historik eller använder numret för att skicka orderinformation. Standardisera kontaktformatet och bekräfta kopplingen är olika uppgifter.
2. Koppla varje köp till motsvarande order
Behåll en specifik referens för varje beställning, även när alla tillhör samma kund. En uppdatering bör ändra kontexten för det köpet. Betalning av en beställning stänger inte automatiskt en annan som fortfarande är öppen.
]
Denna försiktighet är särskilt viktig vid betalningspåminnelser via WhatsApp: innan en skuld meddelas måste operationen kontrollera vilken beställning som är öppen och om betalningen redan har bekräftats av den ansvariga källan.
3. Använd etiketter med betydelse och borttagningsregel
En etikett bör ha en definition som teamet kan förklara. ”Intresse för keramik” kan representera en kunduppgiven preferens; ”byte under granskning” beskriver en temporär situation som måste kopplas till rätt ärende eller beställning.
För varje operationell etikett, registrera vad som tillåter att den appliceras, vem som underhåller informationen och när den ska tas bort eller ses över. Undvik att använda en permanent kundetikett för att ersätta en tillfällig orderstatus. Om verktyget endast tillåter etiketter på kontakten, kontrollera beställningen vid källan innan du fattar ett beslut.
4. Registrera kontinuitet utanför handläggarens minne
När du avslutar ett steg, ange tydligt vad som återstår att lösa. En sammanfattning som ”kund frågade om leverans; logistik kontrollerar beställning B; återkoppling planerad inom angiven tidsram” är mer användbar än ”se senare”. Använd det verkliga inköpsidentifieraren i intern kontroll.
Ansvarig och tidsfrist kan ligga i CRM eller i annan teamkontroll. Betrakta endast detta steg som automatiserat efter att du bekräftat att verktyget faktiskt erbjuder funktionen och att processen har konfigurerats. Ett meddelandeinkorg är inte i sig en uppgiftshanterare.
Exempel: en kund, två beställningar och en fråga
Detta scenario är hypotetiskt och används för att testa dataorganisationen. En kund har fått beställning A levererad och beställning B väntar på betalning. Hon skriver och frågar om en retur avseende beställning A.
- Identifiering: teamet bekräftar vilket konto och vilket köp som hör till konversationen.
- Support: frågan kopplas till beställning A utan att ändra status för beställning B.
- Kontinuitet: den ansvarige för bytet och nästa åtgärd registreras.
- Kommunikation: innan någon påminnelse om beställning B skickas, kontrollerar teamet betalningen och tar hänsyn till sammanhanget i det öppna ärendet.
- Kampanj: som redaktionell rekommendation kan butiken skjuta upp ett erbjudande medan bytet hanteras, förutsatt att denna uteslutning kan tillämpas i den process som används.
Beslutet att skjuta upp en kampanj är en operativ rekommendation, inte en automatisk antagen exkludering av produkten. Exemplet visar varför köpstatus, supportärendets situation och kommersiellt intresse måste förbli åtskiljbara.
Importerad registrering motsvarar inte tillåtelse att skicka
Den WhatsApp Business Messages Policy kräver att personen har lämnat kontakten och godkänt vidare kommunikation. Den kräver också respekt för stoppbegäranden, gjorda både inom och utanför WhatsApp. Att importera en lista eller identifiera ett tidigare köp bevisar inte sådant samtycke i sig.
Som organisatorisk praxis, koppla till kontakten källan och syftet med samtycket, samt de senaste preferenserna. Om dessa register finns i ett annat system, definiera hur de kommer att konsulteras innan en målgrupp väljs. Avsaknaden av ett fält i programvaran tar inte bort behovet av att respektera kundens val.
På Business Platform kräver samma policy godkända mallar för att inleda konversationer och tillåter svar utan mall inom 24-timmars servicefönstret, öppnat och förnyat av användarens meddelanden. Att ha ett organiserat register ändrar inte dessa sändningsvillkor.
Var kommer WPP Marketing in i denna process?
WPP Marketing organiserar kunder, listor, etiketter och butikshändelser för att stödja kampanjer och support. Inkorgen gör det möjligt att granska konversationer och svara från panelen. Förslaget är att koppla kommunikationen till e-handelsdriften; opportunity-pipelines, kommersiella uppgifter och andra krav för ett komplett CRM måste utvärderas separat.
För egna system är Events API är en av integrationsmöjligheterna med kommersiella händelser. Den tillgängliga datasetten beror på den implementerade integrationen. Anta inte att varje fält i matrisen i den här artikeln har en färdig vy eller synkronisering.
Den initiala organiseringen av kontakter skiljer sig också från automatisk klassificering efter beteende. Villkor för historik och tillgänglighet för denna funktion bör kontrolleras på segmenteringssidan och i den använda planen innan du planerar driften.
Fem tester innan du använder databasen i kampanjer och automationer
Gör kontrollen i en testmiljö eller med auktoriserade testrposter, skicka inte meddelanden till verkliga kunder under valideringen.
- Två beställningar för en kund: ändra statusen för en av dem och kontrollera om den andra behåller sitt tillstånd.
- Kontakt med avvikelse: visa registreringar med liknande namn eller motstridiga telefonnummer och kontrollera hur teamet identifierar rätt post.
- Gammal uppdatering: kontrollera hur försenad information hanteras och vem som löser konflikten med aktuell status.
- Preferens ändrad: registrera ett avbrott i kommunikationen och kontrollera om nästa målgruppsval respekterar ändringen.
- Byte av ansvarig: be någon annan fortsätta ett ärende endast med den registrerade kontexten. Hen bör hitta beställningen och förstå nästa åtgärd.
Registrera det förväntade resultatet, det observerade och justeringen som krävs. Det finns ingen universell takt för organisering av databasen: det första målet är att kunna förklara, för varje kommunikation, vem som kommer att kontaktas, vilket faktum motiverar meddelandet och var detta faktum kontrollerades.
Konsulterade källor
Konsultation genomförd den 10 oktober 2026. Matrisen, scenariot och testerna är redaktionella förslag för organisation, inte resultat av ett experiment med kunder.
- WhatsApp Business — Meddelandepolicy: tillstånd, avbrott och villkor för meddelanden på Business Platform.
- WPP Marketing — kundsegmentering: omfattning av publikorganisation och skillnad i förhållande till ett fullständigt CRM.
- WPP Marketing — supportinkorg: historikuppslag och svar via panelen.
För att koppla butikens data till kommunikationen med dina kunder, bekanta dig med WPP Marketing-plattformen och utvärdera de funktioner som passar din verksamhet.