WhatsApp Business API és omnichannel ügyfélszolgálat

A hang és az SMS után a harmadik csatorna, amelyet az ügyfélszolgálati rendszereinkbe beépítettünk, a WhatsApp. Ez a bejegyzés arról szól, hogyan működik a WhatsApp Business Platform Cloud API-ja fejlesztői szemmel, hol vannak a buktatók, és hogyan illesztettük be egy olyan rendszerbe, ahol az ügyfél egyetlen felületen látja a hívásokat, SMS-eket és WhatsApp-üzeneteket.

Cloud API: mit kapunk és mit nem

A Cloud API egy HTTP-alapú interfész: üzenetet POST-kéréssel küldünk, a beérkező üzeneteket és állapotváltozásokat webhookon kapjuk. Nincs saját szervert igénylő kliens, nincs telefon, amelyen a WhatsApp fut. Ez nagy előrelépés a korábbi, on-premise megoldásokhoz képest.

Amit viszont el kell fogadni:

• a telefonszám a WhatsApp Business fiókhoz kötődik, és a fiók ellenőrzése (üzleti adatok, megjelenített név) napokat vehet igénybe,
• a platform szabályai szigorúak: kéretlen üzenetet nem lehet küldeni, és a felhasználói jelentések rontják a szám minőségi besorolását, ami küldési korlátot eredményez,
• az API verziózott és rendszeresen változik, ezért a verziót explicit módon rögzítjük, és a frissítést tudatosan ütemezzük.

Sablonok és a 24 órás ablak

A WhatsApp két üzenettípust különböztet meg, és ez az egész integráció legfontosabb fogalma.

Session üzenet. Ha a felhasználó ír nekünk, 24 órán belül bármilyen szabad szöveggel válaszolhatunk. Ez az ablak minden beérkező üzenettel újraindul.

Sablonüzenet. Az ablakon kívül, vagy ha mi kezdeményezünk, csak előre jóváhagyott sablont küldhetünk. A sablon szövege tartalmazhat változókat (név, időpont, rendelésszám), de a szerkezetét a platform hagyja jóvá, kategória szerint (tranzakciós, marketing, hitelesítés).

A gyakorlatban ez azt jelenti, hogy a rendszernek nyilván kell tartania, mikor volt az utolsó beérkező üzenet minden beszélgetésben, és a küldés előtt el kell dönteni, hogy szabad szöveg mehet-e vagy sablon kell. Mi ezt a küldő rétegben oldjuk meg: az alkalmazás “üzenetet küld”, a réteg pedig eldönti, hogy az ablakon belül van-e, és ha nem, a megfelelő sablonra képezi le, vagy visszautasítja a küldést egy értelmes hibával.

A sablonok jóváhagyása külön munkafolyamat. Az elutasítás okát nem mindig indokolják részletesen, ezért érdemes a sablonokat egyszerűnek, egyértelműnek tartani, és a marketingjellegű szövegeket külön kategóriába rakni.

Webhookok és megbízhatóság

A beérkező üzenetek, a kézbesítési és olvasási állapotok mind ugyanazon a webhook-végponton érkeznek. Néhány szabály, amit itt betartunk:

• a webhook aláírását (HMAC) minden kérésnél ellenőrizzük, a hitelesítetlen kérést eldobjuk,
• a végpont azonnal 200-zal válaszol, a feldolgozás sorba kerül; ha a feldolgozás lassú, a platform újraküld, és duplikátumok keletkeznek,
• az üzenetazonosító alapján idempotens a feldolgozás, mert az újraküldés így is előfordul,
• az állapotfrissítések (elküldve, kézbesítve, olvasva) sorrendje nem garantált, ezért az állapotot csak “előre” léptetjük.

A webhook-végpont a rendszer legkritikusabb belépési pontja: ha kiesik, az ügyfelek üzenetei elvesznek vagy késnek. Ezért külön monitorozzuk, és a beérkező nyers eseményeket a feldolgozás előtt is naplózzuk.

Egy beérkező, három csatorna

Az ügyfélszolgálat szempontjából a WhatsApp nem különálló rendszer, hanem egy újabb csatorna ugyanahhoz az ügyfélhez. A cél egy közös beérkező (unified inbox), ahol egy ügyfél idővonalán egymás után látszik a hívás, az SMS és a WhatsApp-üzenet.

Ehhez egy csatornafüggetlen eseménymodellt használunk: minden interakció egy conversation-höz tartozik, amelyet az ügyfél azonosítója (jellemzően a telefonszám) köt össze. Az esemény típusa (bejövő hívás, kimenő SMS, WhatsApp-üzenet) csak egy attribútum. Az ügyintéző felülete így egyetlen listát mutat, és a válasz csatornáját a rendszer javasolja: ha az ügyfél WhatsAppon írt és az ablak nyitva van, ott válaszolunk; ha lejárt, SMS-t vagy sablont ajánl.

Ez az architektúra teszi lehetővé a chatbot-folyamatokat is. Az automatikus válaszok (nyitvatartás, időpontfoglalás, állapotlekérdezés) egy egyszerű állapotgépként futnak a beszélgetésen, és amikor a bot nem tud tovább lépni, átadja a beszélgetést egy ügyintézőnek, a teljes előzménnyel együtt. A bot ugyanazon az eseménymodellen dolgozik, mint az ember, így a váltás nem jár adatvesztéssel.

GDPR és adatkezelés

A WhatsApp-integráció személyes adatot dolgoz fel: telefonszámot, nevet, üzenettartalmat. Amit ezért minden bevezetésnél tisztázunk az ügyféllel:

• az adatkezelés jogalapja (jellemzően szerződés teljesítése vagy hozzájárulás), és hogy a felhasználó hogyan iratkozhat le,
• a megőrzési idő: az üzeneteket nem tároljuk örökké, a törlés automatikus és naplózott,
• az adatfeldolgozási szerződés a platform üzemeltetőjével, és az, hogy a tartalom a platform szerverein is átmegy,
• a tárolt adatok az EU-n belüli szerveren maradnak, titkosítva, hozzáférés-naplózással.

A technikai megoldás egyszerű; a szabályozási rész az, ami időt igényel, és ezt érdemes a projekt elején kezelni, nem az indulás előtti héten.

Az omnichannel ügyfélszolgálat építése során lett egyre világosabb számunkra, hogy a következő lépés nem egy újabb csatorna, hanem az automatizálás mélyítése. Erről a következő hónapokban valószínűleg többet fogunk írni.