Automatyzacja Zendesk: triggery, automatyzacje, makra i routing

Wszystkie trzy narzędzia zmieniają zgłoszenia, ale uruchamiają się w inny sposób. Jak ujmuje to sam Zendesk: triggery i automatyzacje różnią się nie tym, jakie akcje mogą wykonać, lecz tym, jakie warunki je uruchamiają. Makra nie mają żadnych warunków, bo nic nie ocenia zgłoszenia automatycznie. To agent decyduje, kiedy je zastosować.

Te trzy narzędzia dobrze się uzupełniają. Częsty schemat to makro, które dodaje tag, a ten natychmiast uruchamia trigger szukający właśnie tego tagu. Pamiętaj, że makro może zrobić tylko to, na co pozwalają uprawnienia bieżącego użytkownika, więc agent z ograniczonymi uprawnieniami może nie być w stanie zastosować wszystkich zmian zawartych w makrze.

Za każdym razem, gdy zgłoszenie jest tworzone lub aktualizowane, wszystkie triggery zgłoszeń są wobec niego uruchamiane w cyklu, w kolejności z listy. Jeśli trigger zaktualizuje zgłoszenie, cykl zaczyna się od nowa i każdy trigger działa ponownie, z wyjątkiem tych, które już się uruchomiły i zaktualizowały zgłoszenie. Zmiana wprowadzona przez jeden trigger może więc sprawić, że warunki innego triggera zostaną spełnione, nawet jeśli chwilę wcześniej nie były.

Kolejność triggerów zgłoszeń zalecana przez Zendesk:

1. Triggery zmieniające wartości zgłoszenia, takie jak status, priorytet czy inne pola.
2. Triggery przypisujące zgłoszenie.
3. Triggery powiadomień – na samym końcu, aby e-maile i wiadomości odzwierciedlały ostateczny stan zgłoszenia.

Jeśli korzystasz z kategorii triggerów, kolejność kategorii musi odpowiadać kolejności, w jakiej mają działać triggery; zmienisz ją opcją 'Edit order' na liście triggerów. Warunku Ticket | Is | Created używaj w regułach, które mają działać tylko na nowych zgłoszeniach (klasyczny przykład to routing), a Ticket | Is | Updated np. w powiadomieniach o aktualizacjach. Triggery zgłoszeń nie działają na zamkniętych zgłoszeniach.

Automatyzacje działają raz na godzinę na wszystkich niezamkniętych zgłoszeniach. Moment uruchomienia jest przybliżony: automatyzacja startuje w którymś momencie w ciągu godziny, a nie o stałej minucie. Każda automatyzacja może objąć do 1 000 zgłoszeń na godzinę, a nadwyżka czeka na kolejne uruchomienia.

Ponieważ automatyzacje co godzinę ponownie sprawdzają te same zgłoszenia, Zendesk wymaga, aby każda z nich zawierała warunek spełniony tylko raz albo akcję, która unieważnia co najmniej jeden warunek. Bez tego warunki wciąż pasują, a automatyzacja uruchamia się w nieskończonej pętli. Standardowa automatyzacja 'close ticket after solved' załatwia to w naturalny sposób: zamknięcie zgłoszenia wyłącza je z warunku 'Status is Solved'. W przypadku własnych automatyzacji typowym rozwiązaniem jest dodanie tagu i wykluczenie tego tagu w warunkach.

Triggery mogą kierować zgłoszenia, ustawiając grupę, osobę przypisaną lub umiejętności, ale Zendesk ma też dedykowane funkcje routingu:

• Routing omnichannel przekazuje agentom zgłoszenia z e-maili, połączeń i messagingu na podstawie ich dostępności i obciążenia, a do tego może uwzględniać priorytet i umiejętności.
• Umiejętności (skills) mogą być dodawane do zgłoszeń przez triggery i oznaczane jako wymagane lub opcjonalne. Wymagane umiejętności zawężają grono agentów, którzy mogą otrzymać zgłoszenie; opcjonalne mogą wygasnąć, dzięki czemu zgłoszenie wraca do standardowego modelu routingu.
• Samodzielny routing oparty na umiejętnościach to model typu pull: zgłoszenia są sortowane według umiejętności, a agenci wybierają pracę z widoków opartych na umiejętnościach. Nie można go używać ze zgłoszeniami głosowymi ani z messagingu.

W przypadku połączeń telefonicznych routing omnichannel to jedyny sposób, w jaki triggery mogą wpływać na routing, ponieważ zgłoszenie powstaje, gdy tylko połączenie trafi do kolejki. Funkcje routingu różnią się w zależności od planu, więc zanim zaprojektujesz rozwiązanie oparte na umiejętnościach, sprawdź, co obejmuje Twój plan.

Gdy reguła ma przekazać informację innemu systemowi, użyj webhooka. Tworzysz go w Admin Center i wybierasz typ połączenia: zdarzenia Zendesk albo trigger lub automatyzacja. Webhook może korzystać z jednego z nich, nie z obu, a metody połączenia nie da się później zmienić. W triggerze lub automatyzacji dodaj akcję 'Notify webhook', wybierz webhook i wpisz payload. Treść żądania może mieć format JSON, XML lub form-encoded, a payload nie może przekraczać 16 000 znaków. Każdy webhook ma opcję 'Test webhook', która pozwala sprawdzić żądanie przed uruchomieniem na produkcji.

Gdy logika musi odczytywać dane, podejmować decyzje w kodzie lub zapisywać zmiany w zgłoszeniach, użyj Ticketing API. Zgłoszenia tworzy się żądaniem POST do endpointu tickets, a aktualizuje żądaniem PUT na własny URL zgłoszenia; są też warianty zbiorcze dla wielu zgłoszeń naraz. Żądania można uwierzytelniać tokenem dostępu OAuth przesyłanym w nagłówku Bearer.

Dobrzy kandydaci na pierwsze automatyzacje w Zendesk:

• Kierowanie nowych zgłoszeń do właściwej grupy według kanału, formularza, języka lub słów kluczowych.
• Przypomnienia i eskalacje dla zgłoszeń, które zbyt długo czekają na odpowiedź.
• Publikowanie zgłoszeń o wysokim priorytecie lub od klientów VIP na kanale Slack przez webhook.
• Pobieranie danych zamówienia lub konta do zgłoszenia przez API, zanim agent je otworzy.

TascaLab pracuje na Twoim istniejącym koncie Zendesk, bez zmiany platformy, wykorzystując Zendesk API, webhooki oraz Make lub n8n tam, gdzie się sprawdzają. Ticket Routing & Categorization to jednorazowy projekt za 3000 zł; Custom Automation dla procesów obejmujących kilka systemów kosztuje od 4650 zł. Każdy projekt obejmuje 30 dni wsparcia po uruchomieniu i podstawową dokumentację, bez ukrytych opłat, a większość wdrożeń trwa 1–3 tygodnie. Możesz zacząć od bezpłatnej 30-minutowej rozmowy Health Check.