Ett samtal på WhatsApp Business bör bli ett ärende när svaret kräver undersökning, beror på en annan avdelning eller är en uppgift som fortsätter efter chatten. För att den posten ska vara användbar måste den visa problemet, vad som redan har provats, vem som kommer att fortsätta och nästa steg. Att spara meddelanden utan att organisera denna information lämnar ärendet i historiken.
Denna guide föreslår en rutin för supportteam som tar emot rapporter via WhatsApp och behöver följa upp lösningen. Fomuläret, exemplen och testerna nedan är arbetsmodeller att anpassa till verksamheten; de representerar inte verkliga fall eller uppmätta resultat.
När öppna ett ärende och när fortsätta i konversationen
Ärendet, även kallat ticket, representerar en uppföljningsbar förfrågan. En och samma konversation kan innehålla en enkel fråga och ett problem som kräver analys. Separera ämnen innan du bestämmer vad som ska registreras.
| Situation | Föreslaget skick | Kriterium för beslut |
|---|---|---|
| Kund frågar om supportens öppettider | Svara i konversationen | Det finns aktuell och tillräcklig information för att lösa frågan. |
| En funktion fortsätter att falla efter den initiala vägledningen | Öppna tekniskt ärende | Det krävs undersökning av beteendet och uppföljning av en åtgärd. |
| Kund begär ett kommersiellt villkor | Skicka vidare till försäljning | Nästa steg är ett försäljningsbeslut, inte en supportundersökning. |
| Kund frågar igen om ett redan registrerat problem | Hitta och fortsätt det befintliga fallet | Begäran är densamma; ett nytt meddelande betyder inte ett nytt problem. |
Denna uppdelning är en operationell regel. Förutsätt inte att systemet upptäcker dubbletter eller slår ihop poster automatiskt. Om verktyget inte gör den kontrollen måste någon i teamet göra det.
Förbered ett formulär som gör det möjligt att fortsätta arbetet
Innan du vidarebefordrar ärendet, kontrollera att någon annan skulle förstå ärendet utan att be kunden berätta allt igen. Använd de fält som finns i systemet eller en auktoriserad intern post. Strukturen nedan är ett processförslag, inte en lista över obligatoriska fält i Whatsplaid.
- Ärendereferens: verklig postidentifierare och koppling till konversationen.
- Observerat problem: vad som hände, i vilket steg och sedan när.
- Förväntat resultat: vad kunden försökte uppnå.
- Påverkan: vilka aktiviteter hindrades och vem påverkades.
- Användbar bevisning: felmeddelande, ungefärlig tidpunkt och relevant bild, när det behövs.
- Tidigare försök: instruktioner som redan följts och deras resultat.
- Aktuell pendens: den saknade uppgiften, beslutet eller åtgärden.
- Fortsättning: intern ansvarig, nästa steg och avtalad tidpunkt för en uppdatering.
Be bara om det som fattas för att undersöka. Råd kunden att dölja tredjepartsinformation i bilder och att inte skicka lösenord eller åtkomstkoder. En ofullständig rapport bör identifieras som ofullständig; AI eller agenten ska inte fylla luckan med en hypotes som presenteras som ett faktum.
Exempel på sammanfattning som hjälper teamet
Överväg detta fiktiva scenario: en person kan logga in i ett system men kan inte ladda ner en rapport. “Kund med systemproblem” säger inget om den blockerade uppgiften. En mer användbar sammanfattning skulle vara:
Kunden loggar in på kontot, men nedladdningen av rapporten slutförs inte. Anger att felet började i morse. Har försökt igen enligt anvisningen, utan förändring. Den bifogade skärmbilden visar ett felmeddelande, ännu inte analyserat av det tekniska teamet. Det återstår att bekräfta vilken rapport som begärdes. Nästa åtgärd: samla den informationen och undersöka nedladdningen.
Observera att sammanfattningen skiljer mellan rapport, försök och väntande bekräftelse. Den tillskriver inte felet webbläsaren eller servern utan bevis. Teamet bör jämföra sammanfattningen med historiken innan det fattar ett beslut.
Prioritera efter påverkan och brådska
Atlassians dokumentation använder påverkan och brådska för att definiera prioritet i incidenthantering. Tillämpa samma resonemang på ditt teams process: vad är hotat och hur mycket tid finns det att agera? Den konceptuella referensen finns i källorna längst ner; det innebär inte en integration med Whatsplaid.
I exempelrapporten kan ett fel som hindrar en omedelbar uppgift förtjäna mer uppmärksamhet än en fråga utan operativ blockering. Prioritet beror på den bekräftade kontexten, inte bara på ordet “urgent” i meddelandet.
Bestäm vem som granskar den initiala klassificeringen, hur teamet hanterar omfattande otillgänglighet och vem som tar över när den vanliga ansvarige inte är tillgänglig. Separera uppdateringstid från lösningstid: det går att ge en återkoppling om läget utan att lova en lösning vars orsak ännu är okänd.
Håll ansvaret tydligt under utredningen
När ärendet överförs till en annan avdelning, bestäm vem som kommer att undersöka och vem som fortsätter att kommunicera med kunden. Dessa roller kan ligga hos olika personer, men åtagandet att återkoppla måste fortsätta vara synligt.
En inkorg med historik och mänsklig inblandning hjälper teamet att fortsätta konversationen. Ärendet organiserar den kvarvarande öppna frågan. För att organisera arbetet för flera personer i kanalen behandlar guiden för multiservice med AI och mänskligt team reglerna för överlämning mellan handläggare.
Om skapande eller vidarebefordran misslyckas
Meddela inte att ett ärende har öppnats innan du har bekräftat registreringen. Om operationen använder en extern integration, kontrollera även att destinationen mottagit fallet. Ett försök att skicka bevisar inte mottagande. Använd teamets beredskapsrutin, bevara kontexten och förklara för kunden vad nästa kontakt blir, utan att hitta på ett ärendenummer.
Om kunden återkommer innan lösning
Konsultera det befintliga ärendet, registrera den nya informationen och värdera om påverkan ändrats. Undvik att upprepa råd som redan prövats. Om det nya meddelandet gäller ett annat problem, registrera sambandet mellan ärendena och avgör om de behöver separata uppföljningar.
Vad som kan automatiseras i Whatsplaid
Whatsplaid-dokumentationen beskriver skapandet av interna ärenden under kundkontakten, med sammanfattning, kategori, prioritet och kontext för samtalet. Teamet kan också följa historiken, pausa AI:n och svara via panelen. Flödeskonfigurationen bör kontrolleras före aktivering.
Det gör inte varje regel som föreslås i denna guide till en automatiserad funktion. Ärendeansvarig, granskning av prioritet, tidsövervakning, hantering av dubbletter och avslutningskriterier måste definieras av företaget och verifieras i det valda verktyget. Anta inte automatisk fördelning mellan tekniker, tidsvarningar eller integration med ett specifikt system utan bekräftelse.
Separera även lagren: konversationen i WhatsApp Business-appen, utskick av meddelanden via WhatsApp Business Platform och ärendet som hålls i supportprogramvaran är skilda delar av driften. En automatisering via integration beror på vilka åtgärder och bekräftelser som är tillgängliga i varje system.
Avsluta ärendet med bevis och återkoppling till kunden
Definiera i förväg vad som krävs för att stänga varje typ av ärende. I exempelrapporten måste en tillämpad korrigering följas av en verifiering av nedladdningen i den påverkade kontexten. Att registrera en teknisk åtgärd och att bekräfta att problemet är löst är skilda steg.
Registrera vidtagen åtgärd, resultatet av verifieringen och eventuella kvarstående begränsningar. Om kunden inte svarar, följ en uttrycklig uppföljningsregel; registrera inte en bekräftelse som inte har skett. Återaktiveringen av AI:n bör också kontrolleras i den konfigurerade flödet.
När du skickar svar via WhatsApp Business Platform, observera 24-timmars supportfönstret, som öppnas eller förnyas av användarens meddelande. Utanför detta kräver policyn godkända mallar. Ett öppet ärende förlänger inte detta fönster. Respektera också önskemål om att avbryta meddelanden och säkerställ en tydlig väg till mänsklig support.
Testa processen innan du skalar upp verksamheten
Använd fiktiva fall för att verifiera hela flödet, inklusive fel. Tester nedan är ett förslag på validering; de har inte körts i ett verkligt konto.
- Enkel fråga: bekräfta att den kan lösas utan att skapa ett onödigt ärende.
- Ofullständig rapport: kontrollera om den saknade uppgiften efterfrågas eller registreras som väntande, utan att hitta på något.
- Skapande misslyckades: kontrollera att svaret undviker att bekräfta en icke-existerande post och aktiverar en reservplan.
- Återkoppling om samma problem: kontrollera att teamet hittar det tidigare fallet innan ett nytt öppnas.
- Mänsklig inblandning: bekräfta åtkomst till historik och att AI pausas under handläggares insats.
- Avslut: kontrollera bevis på lösning, tillåten kommunikation och automatiseringens beteende efter avslut.
I piloten, granska ärenden utan nästa steg, ofullständiga poster, återkopplingar utan lösning och klassificeringar som korrigerats av teamet. Mät per typ av förfrågan och registrera hur varje indikator beräknades. Dessa är uppföljningsförslag; de förutsätter inga färdiga rapporter i produkten eller universella prestationsmål.
Konsulterade källor
Konsultation genomförd den 30 september 2026. Kanalregler och verktygsfunktioner kan ändras; kontrollera den gällande dokumentationen när du konfigurerar verksamheten.
- WhatsApp Business meddelandepolicy: supportfönster, mallar och eskaleringsvägar.
- Atlassian: påverkan, brådska och prioritet: konceptuell referens för att organisera triage.
För att utvärdera skapande av ärenden med kontext från ditt företags konversationer, känn till Whatsplaid-ärenden för support på WhatsApp Business och se hur funktionen passar in i din supportprocess.