24 órás ablak: WhatsApp Business API egy omnichannel ügyfélszolgálatban

Ha egy ügyfél WhatsAppon ír egy cégnek, a cég 24 órán át bármilyen szabad szöveggel válaszolhat. Utána csak előre jóváhagyott sablon mehet ki. Ez a szabály határozza meg a WhatsApp Business Platform Cloud API-jára épülő integrációk szinte minden részletét. A hang és az SMS után a WhatsApp a harmadik csatorna, amelyet beépítettünk az ügyfélszolgálati rendszereinkbe. Az alábbiakban leírjuk, hogyan működik az API 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, az SMS-eket és a WhatsApp-üzeneteket.

Amit a Cloud API ad

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

Cserébe el kell fogadni néhány dolgot:

• a telefonszám a WhatsApp Business fiókhoz kötődik, a fiók ellenőrzése (üzleti adatok, megjelenített név) pedig napokig tarthat,
• a platform szabályai szigorúak: kéretlen üzenet nem küldhető, a felhasználói jelentések rontják a szám minőségi besorolását, és ez küldési korláthoz vezet,
• az API verziózott és rendszeresen változik, ezért a verziót explicit rögzítjük, a frissítést pedig tudatosan ütemezzük.

Session és sablon

A WhatsApp két üzenettípust különböztet meg. 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. 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 tartalmazhat változókat (név, időpont, rendelésszám), a szerkezetét viszont a platform hagyja jóvá, kategóriánként (tranzakciós, marketing, hitelesítés).

A rendszernek ezért minden beszélgetésben nyilván kell tartania az utolsó beérkező üzenet idejét, és küldés előtt el kell döntenie, hogy mehet-e szabad szöveg, vagy sablon kell. Mi ezt a küldő rétegben oldjuk meg. Az alkalmazás “üzenetet küld”, a réteg pedig megnézi, hogy az ablakon belül van-e. Ha nincs, a megfelelő sablonra képezi le az üzenetet, vagy értelmes hibával visszautasítja a küldést.

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

A legkritikusabb végpont

A beérkező üzenetek, a kézbesítési és az olvasási állapotok mind ugyanarra a webhook-végpontra érkeznek. Itt néhány szabályt tartunk:

• 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; lassú feldolgozásnál a platform újraküld, és duplikátumok keletkeznek,
• a feldolgozás az üzenetazonosító alapján idempotens, mert ú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.

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

Egy beérkező, három csatorna

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

Ehhez 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ő így egyetlen listát lát, a válasz csatornáját pedig a rendszer javasolja. Ha az ügyfél WhatsAppon írt és az ablak nyitva van, ott válaszolunk. Ha lejárt, a rendszer SMS-t vagy sablont ajánl.

Ugyanez az architektúra teszi lehetővé a chatbot-folyamatokat. Az automatikus válaszok (nyitvatartás, időpontfoglalás, állapotlekérdezés) egyszerű állapotgépként futnak a beszélgetésen. Ha a bot elakad, a teljes előzménnyel együtt átadja a beszélgetést egy ügyintézőnek. A bot ugyanazon az eseménymodellen dolgozik, mint az ember, így a váltásnál nem vész el adat.

GDPR

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

• az adatkezelés jogalapját (jellemzően szerződés teljesítése vagy hozzájárulás), és azt, hogyan iratkozhat le a felhasználó,
• a megőrzési időt: az üzeneteket nem tároljuk örökké, a törlés automatikus és naplózott,
• az adatfeldolgozási szerződést a platform üzemeltetőjével, és azt, hogy a tartalom a platform szerverein is átmegy,
• hogy a tárolt adatok 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 viszi el az időt, ezért a projekt elején kell foglalkozni vele. Az indulás előtti héten már késő.

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