Vlastní akce a webhooky v praxi, ověření zákazníka a rezervace termínu

Když má chatbot sáhnout do vašich systémů, lidé se bojí dvou věcí. Že něco udělá, o co ho nikdo nežádal. A že ukáže data někomu, komu nepatří. Obě ty obavy jsou oprávněné a obě jdou vyřešit. Tady jsou dvě ukázky, každá na jednu z nich.

Když má bot něco založit

Tato ukázka je z rezervací pomocí Cal.com. Zákazník se zeptá, jestli je volno ve čtvrtek. Bot se podívá do kalendáře a vypíše časy. Tohle je akce, která jen čte, takže odpoví okamžitě a nikdo nic nepotvrzuje.

Pak si zákazník vybere čas. Bot se zeptá na jméno, vyžádá si ověření e-mailu a ukáže shrnutí rezervace se dvěma tlačítky. A tady je ten rozdíl, kvůli kterému video vzniklo: dokud zákazník nestiskne Potvrdit, v kalendáři nevznikne nic. Kdyby místo toho stiskl Zrušit, neodejde žádné volání a rezervace nevznikne.

Rozdíl mezi čtením a zápisem není technická drobnost. Je to hranice, za kterou se bot sám nepustí.

Dva zápisy ze dvou stran

Zatímco se tohle děje v chatu, webhooky posílají ven události, na které si můžete napojit cokoli. Můžete použít například Make, který zapisuje řádky do Google Sheets, ale stejně tak to může být vaše CRM, nebo zpráva na Slack.

Jakmile rezervace vznikne, spadnou do tabulky dva řádky ze dvou různých systémů, které o sobě navzájem nevědí.

• Breezaro ví, co se stalo v konverzaci. Kterou akci bot zavolal, s jakými hodnotami, jestli uspěla a ke které konverzaci to patří.
• Rezervační systém ví, co je v kalendáři. Číslo rezervace, přesný začátek a účastníka tak, jak si ho zapsal.

Číslo rezervace u nás nenajdete, protože odpověď vašeho API v události neposíláme. Přijde z druhé strany. Dohromady tak máte doklad, že rezervaci založil asistent, i doklad, že ta rezervace opravdu existuje.

Zákazník se ptá na svou objednávku

Zákazník napíše do chatu, kde má objednávku číslo 1042. Bot se nezeptá na jméno, ale vyžádá si ověření. Do e-mailu přijde kód, zákazník ho opíše a nikde nezakládá účet. Teprve pak se bot podívá do WooCommerce a vrátí stav, položky a částku.

Zákazník během toho nikde nezadává svůj e-mail k objednávce. Bot si ho bere z ověření, takže si ho nemůže vymyslet ani nechat napovědět.

Pointa přijde na konci. Ve stejné konverzaci se zeptáte na jinou objednávku, jejíž číslo znáte, ale která patří někomu jinému. Bot ji nevydá a nepotvrdí ani to, že existuje. Číslo objednávky totiž není heslo. U spousty e-shopů se přitom chová přesně tak.

Co se mezitím zapisuje do tabulky

I u téhle ukázky posílají webhooky události ven.

Přistanou dva řádky. Jeden ve chvíli ověření, s adresou zákazníka a časem. Druhý ve chvíli, kdy bot sáhl pro objednávku, s názvem akce a číslem, na které se ptal.

Dvě věci na tom stojí za zdůraznění:

• Odpověď vašeho API se neposílá nikdy. Událost nese jen to, co se hledalo, ne to, co se našlo. Obsah objednávky vám z Breezara ven neodejde.
• Zapíše se i nepovedený pokus. Ten dotaz na cizí objednávku skončí v tabulce se stavem failed. Provozně je to cennější, než to zní, protože přesně tohle chcete vidět.

Na co si dát pozor

• Vlastní číslování objednávek. Pokud máte plugin, který zákazníkovi ukazuje jiné číslo než to interní, akce bude hledat podle interního a nenajde nic. Ověřte si to dřív, než akci pustíte na zákazníky.
• Ověřit jde jedině e-mailová adresa. Jméno je běžný vstup, který zákazník napíše. Kód z e-mailu totiž prokáže adresu, nic jiného, a jméno není nic, co by šlo doložit.
• Akce má deset vteřin. Když voláte službu napřímo, je to bez debat. Pokud mezi sebe vložíte automatizační scénář, musí se do limitu vejít celý.
• Adresa webhooku je heslo. Make ani Zapier podpis nekontrolují, takže ta adresa je jediné, co brání komukoli poslat vám podvržený řádek. Zacházejte s ní podle toho a nikam ji nevystavujte.
• Když nic nepřichází, otevřete Doručení. U endpointu je seznam s odpovědí druhé strany, takže rozliší nedoručenou událost od scénáře, který požadavek odmítá. Po dvaceti neúspěších se endpoint sám vypne.
• Časy porovnávejte jako čas. Když budete oba řádky párovat, počítejte s tím, že každá strana může použít jiný posun oproti UTC.

Jak to nastavíte

Ani jednu z těch akcí nemusíte skládat ručně. V sekci Vlastní akce jsou hotové šablony, které přijdou předvyplněné, takže doplňujete jen adresu svého obchodu nebo kalendáře a klíč k API. Ten se uloží jako tajná hlavička, kterou už nikdy neuvidíte ani vy. V posledním kroku pustíte test na skutečných datech a odklikáte pole, která má bot vidět.

U webhooku přidáte endpoint, vložíte adresu z automatizačního nástroje a vyberete události, které chcete odebírat. Podrobněji je to v článku o vlastních akcích a v ukázce s upozorněním, když zákazník chce člověka.

Časté dotazy

Může bot ukázat objednávku někomu cizímu? Ne, pokud u akce necháte zapnutý požadavek na ověřeného návštěvníka. Pravidlo porovnává ověřenou adresu s adresou na objednávce, takže samotná znalost čísla nestačí.

Založí bot rezervaci sám od sebe? Ne. Akce, která někam zapisuje, vždy nejdřív ukáže shrnutí s potvrzením. Bez stisku tlačítka se nestane nic.

Odchází přes webhook obsah odpovědi z mého systému? Ne. Událost nese název akce a hodnoty, se kterými se volala, ne to, co vaše API vrátilo.

Potřebuju k tomu programátora? Ne. Šablony a průvodce vás provedou vložením adresy a klíče. Programování by přišlo na řadu, až kdybyste si chtěli psát vlastní akci od nuly.

Chatbot, který sáhne do vašich systémů, je užitečný přesně tehdy, když je zároveň jasné, co smí udělat bez ptaní a komu data ukáže. Obě ty ukázky jsou přesně o tom.

Související: Vlastní akce · Chatbot a stav objednávky ve WooCommerce.