Zendesk-automatisering: triggers, automatiseringar, makron och routning

Alla tre verktygen ändrar ärenden, men de startar på olika sätt. Zendesk formulerar det själv så här: skillnaden mellan triggers och automatiseringar ligger inte i vilka åtgärder de kan utföra, utan i vilka villkor som sätter i gång dem. Makron har inga villkor alls, eftersom ingenting utvärderar ärendet automatiskt. Det är en agent som bestämmer när ett makro ska tillämpas.

De tre fungerar bra tillsammans. Ett vanligt mönster är ett makro som lägger till en tagg, vilket direkt sätter i gång en trigger som letar efter just den taggen. Observera att ett makro bara kan göra det som den aktuella användaren har behörighet till, så en agent med begränsade behörigheter kanske inte kan tillämpa alla ändringar som ett makro innehåller.

Varje gång ett ärende skapas eller uppdateras körs alla ärendetriggers mot det i en cykel, i den ordning de står i listan. Om en trigger uppdaterar ärendet börjar cykeln om och alla triggers körs igen, utom de som redan har körts och uppdaterat ärendet. En triggers ändring kan alltså göra en annan triggers villkor sanna, även om de inte var det en stund tidigare.

Zendesks rekommenderade ordning för ärendetriggers:

1. Triggers som ändrar ärendevärden som status, prioritet eller andra fält.
2. Triggers som tilldelar ärendet.
3. Aviseringstriggers, sist, så att mejl och meddelanden speglar ärendets slutliga tillstånd.

Om du använder triggerkategorier måste kategoriernas ordning motsvara den ordning du vill att triggrarna ska köras i; du ändrar den med Edit order i triggerlistan. Använd villkoret Ticket | Is | Created för regler som bara ska gälla nya ärenden (routning är det klassiska exemplet), och Ticket | Is | Updated för till exempel aviseringar om uppdateringar. Ärendetriggers körs inte på stängda ärenden.

Automatiseringar körs en gång i timmen på alla ärenden som inte är stängda. Tidpunkten är ungefärlig: en automatisering startar någon gång under timmen, inte på en fast minut. Varje automatisering kan hantera upp till 1 000 ärenden per timme, och resten får vänta till senare körningar.

Eftersom automatiseringar kontrollerar samma ärenden varje timme kräver Zendesk att varje automatisering innehåller ett villkor som bara är sant en gång, eller en åtgärd som upphäver minst ett villkor. Utan det fortsätter villkoren att matcha och automatiseringen körs i en oändlig loop. Standardautomatiseringen 'close ticket after solved' löser detta naturligt: när ärendet stängs uppfyller det inte längre villkoret 'Status is Solved'. För egna automatiseringar är den vanliga lösningen att lägga till en tagg och utesluta den taggen i villkoren.

Triggers kan routa ärenden genom att ange en grupp, en tilldelad agent eller kompetenser (skills), men Zendesk har också särskilda routningsfunktioner:

• Omnikanalroutning (omnichannel routing) skickar ärenden från mejl, samtal och meddelanden till agenter utifrån deras tillgänglighet och kapacitet, och kan även ta hänsyn till prioritet och kompetenser.
• Kompetenser kan läggas till på ärenden av triggers och markeras som obligatoriska eller valfria. Obligatoriska kompetenser begränsar vilka agenter som kan få ärendet; valfria kompetenser kan få en tidsgräns så att ärendet faller tillbaka på den vanliga routningsmodellen.
• Fristående kompetensbaserad routning är en pull-modell: ärenden sorteras efter kompetens och agenter hämtar arbete från kompetensbaserade vyer. Den kan inte användas för röst- eller meddelandeärenden.

För samtal är omnikanalroutning det enda sättet för triggers att påverka routningen, eftersom ett ärende skapas så snart ett samtal kommer in i kön. Routningsfunktionerna skiljer sig mellan planer, så kontrollera vad din plan innehåller innan du bygger upplägget kring kompetenser.

När en regel behöver meddela ett annat system något använder du en webhook. Du skapar den i Admin Center och väljer anslutningstyp: Zendesk-händelser, eller trigger eller automatisering. En webhook kan använda den ena eller den andra, inte båda, och du kan inte ändra anslutningsmetoden i efterhand. I en trigger eller automatisering lägger du till åtgärden 'Notify webhook', väljer webhooken och anger payloaden. Anropets body kan vara JSON, XML eller formulärkodad, och payloaden får inte överstiga 16 000 tecken. Varje webhook har alternativet Test webhook så att du kan kontrollera anropet innan det tas i drift.

När logiken behöver läsa data, fatta beslut i kod eller skriva tillbaka till ärenden använder du Ticketing API. Ärenden skapas med en POST till tickets-endpointen och uppdateras med en PUT till ärendets egen URL, med bulkvarianter för många ärenden samtidigt. Anrop kan autentiseras med en OAuth-åtkomsttoken som skickas i en Bearer-header.

Bra första kandidater för Zendesk-automatisering:

• Routa nya ärenden till rätt grupp utifrån kanal, formulär, språk eller nyckelord.
• Påminnelser och eskaleringar för ärenden som har väntat för länge på svar.
• Posta ärenden med hög prioritet och VIP-ärenden i en Slack-kanal via en webhook.
• Hämta order- eller kontodata till ett ärende via API:et innan en agent öppnar det.

TascaLab arbetar i ditt befintliga Zendesk-konto, utan plattformsbyte, med Zendesk API, webhooks och Make eller n8n där de passar. Ticket Routing & Categorization är ett engångsprojekt för 7 700 kr; Custom Automation för flöden som går över flera system kostar från 11 900 kr. Varje projekt inkluderar 30 dagars support efter lansering, grundläggande dokumentation och inga dolda avgifter, och de flesta upplägg tar 1–3 veckor. Du kan börja med ett kostnadsfritt Health Check-samtal på 30 minuter.