Adatsablon a szolgáltatási kérelmek kezeléséhez

Zendesk Support
Adatsablon a szolgáltatási kérelmek kezeléséhez

Adatsablon a szolgáltatási kérelmek kezeléséhez

Ez a sablon bemutatja, hogyan nyerheti ki a Zendesk Support rendszerből a szolgáltatásikérelem-kezelési folyamat elemzéséhez szükséges adatokat. Ismerteti a gyűjtendő attribútumokat, a követendő fontos tevékenységeket, valamint az adatok közvetlen rendszerből történő kinyerésének gyakorlati lépéseit. Használja ezt az útmutatót, hogy megfelelő eseménynaplót készítsen a process mining elemzésekhez.
  • Javasolt attribútumok a részletes elemzéshez
  • Követendő fontos tevékenységek a szolgáltatási kérelmeknél
  • Útmutató a Zendesk Support adatainak kinyeréséhez
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

A szolgáltatásikérelem-kezelés attribútumai

Ezeket az adatmezőket érdemes felvenni az eseménynaplóba, ha részletesen szeretné elemezni a szolgáltatási kérelmek kezelését a Zendesk Support rendszerben.
5 Kötelező 7 Javasolt 9 Nem kötelező
Név Leírás
Kezdési idő
EventTimestamp
A tevékenység pontos dátuma és időpontja.
Leírás

Az esemény időbélyege, vagyis a kezdési idő rögzíti, hogy pontosan mikor történt egy tevékenység. Megmutatja például, mikor rendeltek hozzá ügyintézőt, mikor küldtek nyilvános választ, vagy mikor változott a jegy állapota „Resolved” értékre. Az időadatok az egyes Zendesk-jegyek auditnaplójából származnak.

Ez az attribútum minden időalapú elemzéshez szükséges. Az események időrendi sorba rendezésére, a tevékenységek közötti idő kiszámítására, a várakozási idők mérésére és az ügy teljes átfutási idejének elemzésére használható. A szűk keresztmetszetek feltárásához és az SLA-khoz hasonló időalapú célértékek teljesülésének értékeléséhez is elengedhetetlen.

Miért fontos?

Az időbélyeg időrendbe rendezi az eseményeket, és szükséges az időtartamok, a teljesítmény és a szűk keresztmetszetek elemzéséhez.

Hol szerezhető be?

Zendesk Ticket Audits API, az egyes audit események „created_at” mezője.

Példák
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
Szolgáltatási kérelem azonosítója
ServiceRequestId
A Zendeskben minden szolgáltatási kérelemhez tartozó jegy egyedi azonosítója.
Leírás

A szolgáltatási kérelem azonosítója, amelyet a Zendeskben gyakran Ticket ID-nak neveznek, az egyes ügyek elsődleges kulcsa. Összekapcsolja a kérelem létrehozásától a lezárásáig tartó összes kapcsolódó tevékenységet, kommentet és állapotváltozást. Így egyetlen kérelem teljes életútja végigkövethető.

A process mining elemzésben ez az attribútum alapvető: ez határozza meg az ügyet, amelynek alapján rekonstruálhatók a folyamatok, azonosíthatók a változatok, és kiszámíthatók az ügy szintű mutatók, például az átfutási idő. Az adathalmaz minden eseményét hozzá kell rendelni egy szolgáltatásikérelem-azonosítóhoz, hogy az esemény a teljes folyamat összefüggésében értelmezhető legyen.

Miért fontos?

Ez az ügy egyedi azonosítója, amely összekapcsolja a szolgáltatási kérelem teljes útjának eseményeit, és lehetővé teszi a folyamat elejétől a végéig tartó elemzését.

Hol szerezhető be?

Zendesk Tickets API, „id” mező.

Példák
102451024610247
Tevékenység
ActivityName
A szolgáltatási kérelemhez kapcsolódó üzleti tevékenység vagy esemény neve.
Leírás

A tevékenység a szolgáltatási kérelem életútjának egy-egy különálló lépését vagy eseményét jelöli, például „Szolgáltatási kérelem létrehozva”, „Kérelem ügyintézőhöz rendelve” vagy „Szolgáltatási kérelem megoldva”. A tevékenységek a Zendesk-jegy auditnaplójában rögzített változásokból származnak. A napló olyan mezők módosításait követi, mint az állapot, a felelős és a prioritás, valamint a kommentek hozzáadását.

A tevékenységek elemzése a process mining alapja. Segítségével megjeleníthető a folyamattérkép, azonosíthatók a lépések közötti szűk keresztmetszetek, és elemezhetők az utómunka miatt ismétlődő lépések. A tevékenységek sorrendjének és gyakoriságának ismeretében feltárhatók a hatékonysági problémák és a folyamatfejlesztési lehetőségek.

Miért fontos?

Ez az attribútum határozza meg a folyamat lépéseit, így megjeleníthető a folyamattérkép, és elemezhető a folyamat menete, változatossága és a szabályoknak való megfelelés.

Hol szerezhető be?

Fogalmilag a Zendesk Ticket Audits API-ban naplózott eseményekből származik. Például a „status” mező „new” értékről „open” értékre változása a „Kérelem előzetes besorolása” tevékenységhez rendelhető.

Példák
Szolgáltatási kérelem létrehozvaÜgyintéző áthelyezveSzolgáltatási kérelem megoldva
Forrásrendszer
SourceSystem
Megadja, melyik rendszerből származnak a kinyert adatok.
Leírás

Ez az attribútum jelzi a szolgáltatási kérelem adatainak forrását. Ebben a folyamatnézetben az értéke mindig „Zendesk Support”, amely a szolgáltatáskezelési tevékenységek nyilvántartó rendszere.

Több integrált rendszer használatakor ez a mező segít nyomon követni az adatok eredetét és elhárítani a hibákat. Biztosítja, hogy az elemzés a megfelelő rendszerre terjedjen ki, és segít megkülönböztetni a különböző forrásokból összevont adatokat.

Miért fontos?

Azonosítja az adatok forrásrendszerét, így nyomon követhető az adatok eredete, és elkerülhető a több rendszerből származó adatok összekeverése.

Hol szerezhető be?

Ez egy statikus érték („Zendesk Support”), amelyet az adatok kinyerése és átalakítása során adnak hozzá.

Példák
Zendesk Support
Utolsó adatfrissítés
LastDataUpdate
Az időbélyeg azt mutatja, mikor frissültek utoljára az adatok a forrásrendszerből.
Leírás

Ez az attribútum rögzíti a Zendesk Support rendszerből végzett legutóbbi adatkinyerés dátumát és időpontját. Megmutatja, mennyire frissek az elemzett adatok, így a felhasználók tudják, mennyire aktuális a folyamatnézet.

Folyamatos nyomon követés és dashboardok használata esetén ez az információ különösen hasznos. Az elemzők és az üzleti felhasználók láthatják, hogy közel valós idejű adatokat vagy egy korábbi időszak pillanatfelvételét vizsgálják. Ez befolyásolja a következtetések érvényességét.

Miért fontos?

Megmutatja, mennyire frissek az adatok, így a felhasználók tudják, mennyire aktuális az elemzés.

Hol szerezhető be?

Ez egy metaadatmező, amelyet az adatok kinyerésekor hoznak létre és rögzítenek az adathalmazban.

Példák
2023-10-27T08:00:00Z
Hozzárendelt csapat
AssignedTeam
A szolgáltatási kérelemhez rendelt ügyfélszolgálati csapat vagy csoport.
Leírás

Ez az attribútum jelzi, hogy az ügyfélszolgálati szervezet melyik csapata vagy csoportja felel a szolgáltatási kérelemért. A Zendeskben ezeket „Groups” néven tartják nyilván. A jegyeket gyakran először egy csoporthoz rendelik, és csak ezután veszi át őket egy ügyintéző.

A hozzárendelt csapat szerinti elemzés megmutatja a csapatok teljesítményét és munkaterhelését. Segít megválaszolni, melyik csapat milyen típusú kérelmeket kezel, mennyi az átlagos megoldási ideje, és milyen arányban teljesíti az SLA-kat. Ez az Ügyintézői és csapatteljesítmény dashboard egyik fő elemzési szempontja.

Miért fontos?

Segít elemezni a csapatok teljesítményét, kiegyensúlyozni a munkaterhelést és felmérni az ügyfélszolgálati csoportok közötti irányítás hatékonyságát.

Hol szerezhető be?

Zendesk Groups API, a Tickets API válaszában szereplő „group_id” mező összekapcsolásával.

Példák
1. szintű ügyfélszolgálatMűszaki ügyfélszolgálatSzámlázás
Jegycímkék
TicketTags
A szolgáltatási kérelem kategorizálására és irányítására használt címkék listája.
Leírás

A címkék rugalmas jelölők, amelyeket az ügyintézők kézzel adhatnak hozzá a jegyekhez, vagy üzleti szabályok rendelhetnek hozzájuk automatikusan. Olyan részleteket és kategóriákat jelölnek, amelyeket az olyan szabványos mezők, mint a típus vagy a prioritás, nem fednek le.

A címkék sokféleképpen használhatók process mining elemzésben. Segítségükkel szűrhetők a konkrét esetek, nyomon követhetők az egyéni munkafolyamatok, és feltárhatók a kiváltó okok. A „VIP” címkével például elemezhetők a kiemelt ügyfelek kérelmei, a „product_bug” címkével pedig végigkövethetők a hibajelentések.

Miért fontos?

Rugalmasan szűrhető és csoportosítható velük az adat, így részletesen elemezhetők az egyes részfolyamatok és a más mezőkben nem rögzített jegyjellemzők.

Hol szerezhető be?

Zendesk Tickets API, „tags” mező. Karakterláncok tömbje.

Példák
értékesítési_érdeklődésszámlázási_problémafunkciókéréskiemelt_ügyfél
Kérelem állapota
RequestStatus
A szolgáltatási kérelem állapota az esemény időpontjában, például új, nyitott vagy függőben lévő.
Leírás

A kérelem állapota a jegy adott időpontban érvényes helyzetét mutatja. A Zendesk szabványos állapotai közé tartozik a New, Open, Pending, On-hold, Solved és Closed. Ezek jelzik, hol tart a kérelem az életútján. A mező változásai indítják el az eseménynapló tevékenységeinek létrehozását.

A különböző állapotokban töltött idő elemzése a szűk keresztmetszetek feltárásának egyik alapja. Megmutatja, hol akadnak el a jegyek, például ha túl sok időt töltenek „Pending” vagy „On-hold” állapotban. Az állapotváltások megértése az ismétlődő lépések feltárásához is szükséges.

Miért fontos?

Az állapot nyomon követése alapvető a kérelem előrehaladásának megértéséhez és a várakozással, illetve az aktív ügyintézéssel töltött idő méréséhez.

Hol szerezhető be?

Zendesk Tickets API, „status” mező.

Példák
ÚjNyitottFüggőbenMegoldvaLezárva
Kérelem csatornája
RequestChannel
Az a csatorna, amelyen keresztül a szolgáltatási kérelmet beküldték, például e-mailben, webes űrlapon vagy telefonon.
Leírás

Ez az attribútum megmutatja, honnan érkezett a szolgáltatási kérelem. A Zendesk rögzíti, hogy a jegy e-mailben, webes portálon, API-integráción, chaten vagy más csatornán keresztül jött-e létre. Ez segít megérteni, hogyan lépett kapcsolatba az ügyfél az ügyfélszolgálattal.

A kérelem csatornája hasznos elemzési szempont. A „Kérelemcsatorna-hatékonyság” dashboardon összehasonlíthatók az egyes csatornák megoldási ideje, elégedettségi értékelései és utómunka-arányai. Az eredmények alapján fejleszthetők az ügyfélszolgálati csatornák, és a felhasználók a hatékonyabb csatornák felé irányíthatók.

Miért fontos?

Segít összehasonlítani a különböző ügyfélszolgálati csatornák hatékonyságát és eredményeit, így célzott fejlesztések végezhetők.

Hol szerezhető be?

Zendesk Tickets API, „via” objektum és annak „channel” tulajdonsága.

Példák
webe-mailapichat
Kérelem prioritása
RequestPriority
A szolgáltatási kérelemhez rendelt prioritási szint, például alacsony, normál, magas vagy sürgős.
Leírás

A kérelem prioritása a sürgősségét jelzi. Ez a szint gyakran meghatározza a megoldás célidejét és a jegyre alkalmazott SLA-szabályokat. A prioritást kezdetben a rendszer vagy a felhasználó állíthatja be, az ügyintéző pedig a jegy életútja során módosíthatja.

Ez az attribútum szükséges a csoportosításhoz és a kiváltó okok elemzéséhez. Segítségével összevethető, hogy a magas prioritású jegyek gyorsabban oldódnak-e meg, mint az alacsony prioritásúak. A „Szolgáltatási kérelmek eszkalációs trendjei” és az „SLA-teljesítés” dashboard egyik fő elemzési szempontja.

Miért fontos?

A kérelmek sürgősség szerinti csoportosításával elemezhető az SLA-k teljesítése, és ellenőrizhető, hogy a sürgős ügyek időben megoldódnak-e.

Hol szerezhető be?

Zendesk Tickets API, „priority” mező.

Példák
AlacsonyNormálMagasSürgős
Szolgáltatás típusa
ServiceType
A szolgáltatási kérelem kategóriája vagy típusa, például incidens, kérdés, probléma vagy feladat.
Leírás

A szolgáltatás típusa a kérelem jellegét határozza meg. A Zendesk „type” mezője különbözteti meg az ügyfélszolgálati megkeresések típusait. Ez a kezdeti besorolás segít a jegyet a megfelelő csapathoz irányítani, és a megfelelő folyamatot alkalmazni.

Ez az attribútum szükséges a szűréshez és az összehasonlításhoz. Az elemzők megvizsgálhatják a különböző típusú kérelmek folyamatait, amelyek megoldási útja és SLA-ja gyakran eltér. Az Ügyintézői és csapatteljesítmény dashboard egyik fő elemzési szempontja, mert megmutatja, ki kezeli a legjobban az egyes kérelemtípusokat.

Miért fontos?

A kérelmek kategorizálásával külön elemezhetők az eltérő folyamatok, például az incidensek és a kérdések, amelyek más-más útvonalat követnek.

Hol szerezhető be?

Zendesk Tickets API, „type” mező.

Példák
kérdésincidensproblémafeladat
Ügyintéző neve
AgentName
Az esemény időpontjában a szolgáltatási kérelemhez rendelt ügyintéző neve.
Leírás

Ez az attribútum azonosítja a szolgáltatási kérelemért felelős ügyfélszolgálati ügyintézőt. A jegy életútja során többször is változhat a hozzárendelt ügyintéző, ez a mező pedig minden lépésnél rögzíti, ki volt a felelős.

Az ügyintéző neve fontos a teljesítmény elemzéséhez. Az adatok szűrhetők és csoportosíthatók a munkaterhelés eloszlásának, az ügyintézőnkénti megoldási időknek és az áthelyezések gyakoriságának vizsgálatához. Ez segít az Ügyintézői és csapatteljesítmény dashboard összeállításában, valamint az egyéni hozzájárulások megértésében.

Miért fontos?

Ez az attribútum segít elemezni az ügyintézők teljesítményét, a munkaterhelés eloszlását és az áthelyezések megoldási időre gyakorolt hatását.

Hol szerezhető be?

Zendesk Users API, a Tickets API válaszában szereplő „assignee_id” mező összekapcsolásával.

Példák
Jane DoeJohn SmithEmily Jones
Befejezési idő
EndTime
A tevékenység befejezésének pontos dátuma és időpontja.
Leírás

A befejezési idő jelzi, mikor ért véget egy tevékenység. A Zendeskben sok esemény pillanatszerű, ezért a befejezési idő megegyezik a kezdési idővel. Az állapothoz kötött tevékenységeknél, például a „Kérelem függőben” esetén, a befejezési idő az a pillanat, amikor a jegy kikerül a függő állapotból.

Ez az attribútum szükséges az egyes tevékenységek időtartamának kiszámításához, ami segít feltárni a szűk keresztmetszeteket. A kezdési és a befejezési idő összevetésével közvetlenül mérhető a feldolgozási idő, így megállapítható, mely lépések tartanak a legtovább.

Miért fontos?

Lehetővé teszi az egyes tevékenységek időtartamának kiszámítását, ami szükséges a folyamat szűk keresztmetszeteinek feltárásához és a lépések hatékonyságának méréséhez.

Hol szerezhető be?

Különálló eseményeknél ez gyakran megegyezik a StartTime értékével. Az állapot időtartamánál a következő, állapotváltozást okozó esemény időbélyege jelenti a befejezési időt.

Példák
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
Elégedettségi értékelés
SatisfactionRating
A kérelmező által a jegy megoldása után adott elégedettségi értékelés.
Leírás

Ez az attribútum az ügyfél ügyfélszolgálati tapasztalatáról adott visszajelzését rögzíti. Az értékelést általában a jegy megoldottként való megjelölése után, kérdőívben gyűjtik be. A gyakori válaszok közé tartozik a „Jó” és a „Rossz”, esetenként szöveges megjegyzéssel kiegészítve.

Az elégedettségi értékelés fontos eredménymutató. Ha összevetjük a folyamatmintákkal, kiderülhet, mely folyamatok járnak elégedett vagy elégedetlen ügyfelekkel. Az elemzés például kimutathatja, hogy a gyakori áthelyezés vagy a hosszú megoldási idő szorosan összefügg a negatív értékelésekkel.

Miért fontos?

Közvetlen kapcsolatot teremt a folyamat végrehajtása és az ügyfélélmény között, így feltárhatók az elégedettséget befolyásoló folyamatok.

Hol szerezhető be?

Zendesk Tickets API, „satisfaction_rating.score” vagy „satisfaction_rating.reason” mező.

Példák
JóRosszFelajánlva
Első kapcsolatfelvételkor megoldva
IsFirstContactResolution
Jelzi, hogy az elsőként kijelölt ügyintéző átruházás és az ügyfél újabb válasza nélkül megoldotta-e a kérelmet.
Leírás

Az első kapcsolatfelvételkor történő megoldás (FCR) azt mutatja, hogy az ügyfél problémája egyetlen kapcsolatfelvétel során megoldódott-e. Ez a számított logikai attribútum akkor igaz, ha a jegyet az elsőként kijelölt ügyintéző oldotta meg, nem történt átruházás, és az ügyintéző csak egyszer válaszolt.

Az attribútum közvetlenül támogatja az „Első kapcsolatfelvételkor történő megoldás aránya” KPI-t. Az FCR-esetek jellemzőinek elemzése megmutathatja, hogyan javítható a folyamat. Az FCR-t nem teljesítő esetek vizsgálata pedig rámutathat a jobb ügyintézői képzés, a tudásbázis cikkeinek fejlesztése vagy a hatékonyabb kezdeti besorolás lehetőségeire.

Miért fontos?

Azt méri, hogy a problémák egyetlen ügyintézési lépésben, hatékonyan megoldhatók-e. Ez jelentősen javíthatja az ügyfelek elégedettségét és a működés hatékonyságát.

Hol szerezhető be?

Összetett, számított attribútum. A jegy eseménynaplójának elemzésével ellenőrzi az ügyintézőváltásokat és az ügyintézők nyilvános válaszainak számát.

Példák
truefalse
Kérelmező neve
RequestorName
A szolgáltatási kérelmet beküldő végfelhasználó vagy ügyfél neve.
Leírás

Ez az attribútum azonosítja a szolgáltatási kérelmet kezdeményező személyt. Ha a kérelmet egy adott ügyfélhez kapcsoljuk, az ügyfélszolgálati folyamat az ügyfél szempontjából is vizsgálható.

A folyamat elemzésekor a kérelmező adatai alapján feltárhatók az egyes ügyfelekre vagy ügyfélszegmensekre jellemző minták. Megvizsgálható például, hogy bizonyos ügyfelek kérelmeinek megoldása tovább tart-e, vagy gyakrabban igényelnek-e utómunkát. Ez az általuk használt termékkel vagy szolgáltatással kapcsolatos problémára utalhat.

Miért fontos?

Az ügyfélhez kapcsolja a folyamatot, így elemezhetők az ügyfélspecifikus problémák, az ismétlődő kérelmek és az elégedettség.

Hol szerezhető be?

Zendesk Users API, a Tickets API válaszában szereplő „requester_id” mező összekapcsolásával.

Példák
Alice JohnsonBob WilliamsCharlie Brown
Kérelmező szervezete
RequestorOrganization
A szervezet vagy vállalat, amelyhez a kérelmező tartozik.
Leírás

Ez az attribútum egy adott ügyfélszervezethez kapcsolja a szolgáltatási kérelmet. Különösen fontos B2B ügyfélszolgálat esetén, ahol a szolgáltatási szintre vonatkozó megállapodások és a támogatási szerződések gyakran szervezeti szinten érvényesek.

A szervezet szerinti elemzés vállalati szinten mutatja meg az ügyfélszolgálat teljesítményét. Segít azonosítani azokat a szervezeteket, amelyek sok jegyet hoznak létre, visszatérő problémákkal küzdenek, vagy alacsony elégedettségi értékelést adnak. Ez hasznos az ügyfélkapcsolatok kezeléséhez és az ügyfelek általános állapotát jelző trendek feltárásához.

Miért fontos?

A kérelmek vállalat szerinti csoportosításával elemezhető a B2B szolgáltatás, és szervezeti szinten kezelhetők az ügyfélkapcsolatok és az SLA-k.

Hol szerezhető be?

Zendesk Organizations API, a Tickets API válaszában szereplő „organization_id” mező összekapcsolásával.

Példák
Acme CorporationGlobal Tech Inc.Innovate Solutions
SLA-sértés történt
IsSlaBreached
Jelzi, hogy a szolgáltatási kérelem túllépte-e valamelyik SLA-célértéket.
Leírás

Ez a logikai vagy kategóriaváltozó azt mutatja, hogyan teljesült a jegy SLA-ja. Lehetséges értékei például: „Teljesült”, „Sértés történt” vagy „Aktív”. Az érték az alkalmazott SLA-szabályzatban meghatározott célértékek és a tényleges válaszadási vagy megoldási idők összevetéséből adódik.

Ez az attribútum elengedhetetlen az „SLA-teljesítés és -sértések elemzése” dashboardhoz. Segítségével könnyen megszámolhatók és megjeleníthetők a megfelelő, illetve nem megfelelő jegyek. Ezután a megsértett SLA-jú jegyek folyamatait vizsgálva feltárhatók a kiváltó okok, például a hosszú várakozási idők vagy a túl sok átruházás.

Miért fontos?

Közvetlenül méri a szolgáltatási szintre tett vállalások teljesülését, ami a szolgáltatás minőségének és az ügyfelek elégedettségének fontos mutatója.

Hol szerezhető be?

A Zendesk Ticket Metrics API adataiból származik, amely minden jegyhez megadja az SLA állapotát.

Példák
TeljesültSértés történtAktív
SLA-szabályzat neve
SlaPolicyName
A kérelemre alkalmazott szolgáltatási szintre vonatkozó megállapodás (SLA) szabályzatának neve.
Leírás

Ez az attribútum azonosítja, hogy melyik SLA-szabályzat határozza meg a szolgáltatási kérelemre vonatkozó válaszadási és megoldási határidőket. A szabályzatot általában olyan tényezők alapján választják ki, mint a kérelem prioritása és típusa, illetve az ügyfél előfizetési szintje.

Az alkalmazott SLA-szabályzat ismerete elengedhetetlen az „SLA-teljesítés és -sértések elemzése” dashboard használatához. Megadja a teljesítmény értékeléséhez szükséges hátteret, hiszen az egyes szabályzatok eltérő célértékeket határoznak meg. Így pontosan és méltányosan megítélhető, hogy a jegy teljesítette-e a rá vonatkozó szolgáltatási célokat.

Miért fontos?

Az SLA-elemzéshez megmutatja, hogy a kérelmet mely célértékek alapján mérték, így pontosan jelenthető a megfelelés.

Hol szerezhető be?

Zendesk Ticket Metrics API. Az SLA-adatok gyakran a jegy metrikáihoz kapcsolódnak.

Példák
Sürgős, 1 órán belüli válaszNormál, 24 órán belüli megoldásPrémium ügyfélre vonatkozó SLA
Ügyintézőváltások száma
AgentReassignmentCount
Hányszor került át a kérelem egyik ügyintézőtől a másikhoz.
Leírás

Ez az attribútum minden alkalommal eggyel növekszik, amikor megváltozik a jegy „assignee_id” mezője. Ha egy jegyet sokszor átruháznak, annak többféle folyamathiba állhat a hátterében: például hibás kezdeti hozzárendelés, az ügyintéző hiányos ismeretei vagy olyan összetett kérelem, amelyet egyetlen ügyintéző nem tud kezelni.

Ez az egyik fontos mutató a folyamat hatékonyságának mérésére, és közvetlenül támogatja az „Ügyintézőváltások aránya” KPI-t. A sok átruházással járó esetek elemzése megmutathatja, hogyan javíthatók az útválasztási szabályok, az ügyintézők képzése vagy a tudásbázis tartalmai, hogy a jegyek gyorsabban a megfelelő emberhez kerüljenek.

Miért fontos?

Számszerűsíti a belső átadásokat, és feltárja a folyamat akadozásait. A gyakori átruházás ugyanis sokszor késedelmet és hatékonyságvesztést okoz.

Hol szerezhető be?

A jegyenkénti „assignee_id” változások számát a Zendesk Ticket Audits API adatai alapján számítja ki.

Példák
013
Újramunka történt
IsRework
Akkor igaz, ha a szolgáltatási kérelmet a megoldása után újranyitották.
Leírás

Ez a logikai változó az újramunkát igénylő eseteket jelöli. Általában akkor tekintünk egy szolgáltatási kérelmet újramunkának, ha az állapota „Megoldva” értékről ismét nyitottra vált. Ez azt jelzi, hogy az első megoldás nem volt megfelelő, és az ügyfélnek ugyanazzal a problémával ismét jelentkeznie kellett.

Ez az attribútum szükséges a „Szolgáltatási kérelmek újramunkaaránya” KPI kiszámításához és az „Újramunka és újranyitások elemzése” dashboardhoz. Az újramunkát igénylő esetek elkülönítésével az elemzők feltárhatják a folyamat hatékonytalanságait és az újranyitások okait, majd javíthatják az első kapcsolatfelvételkor történő megoldás arányát.

Miért fontos?

Feltárja azokat a folyamathibákat, amelyeknél a megoldás nem bizonyult véglegesnek. Így láthatóvá válnak a minőségi és hatékonysági problémák, amelyek közvetlenül rontják az ügyfelek elégedettségét.

Hol szerezhető be?

A jegy állapotváltozásainak sorrendjét elemzi a Zendesk Ticket Audits API adatai alapján. Az újramunkát a „megoldva” állapotból „nyitott” állapotba történő váltás jelzi.

Példák
truefalse
Kötelező Javasolt Nem kötelező

A szolgáltatásikérelem-kezelés tevékenységei

Ezeket a fontos folyamatlépéseket és mérföldköveket rögzítse az eseménynaplóban, hogy pontosan feltárhassa a szolgáltatási kérelmek folyamatát.
7 Javasolt 6 Nem kötelező
Tevékenység Leírás
Kérelem ügyintézőhöz rendelve
Ez a tevékenység akkor történik, amikor a szolgáltatási kérelmet először egy adott ügyintézőhöz rendelik. A jegyellenőrzési napló „Change” eseményéből következtethető ki, amikor az „assignee_id” mező értéke nulláról vagy egy csoportazonosítóról ügyintéző-azonosítóra változik.
Miért fontos?

Ez jelöli az ügyintéző tényleges munkájának kezdetét. Fontos az első válaszidő, az első kijelölésig eltelt idő és az ügyintézők munkaterhelésének méréséhez.

Hol szerezhető be?

A jegyellenőrzési napló első olyan „Change” eseményéből következtethető ki, amelyben az „assignee_id” mező értéke egy adott felhasználóazonosítóra változik.

Rögzítés

Az első olyan módosítási eseményből következtethető ki, amely az „assignee_id” mezőben egy ügyintézőt jelöl ki.

Eseménytípus inferred
Nyilvános válasz elküldve
Ez a tevékenység az ügyintéző és a kérelmező közötti kommunikációt jelöli. A Zendesk jegyadataiban külön „Comment” esemény rögzíti, ha a „public” attribútum értéke true.
Miért fontos?

Ezek az események segítenek elemezni a kommunikáció gyakoriságát, mérni az ügyintézők válaszidejét, valamint megállapítani, hány interakció szükséges a megoldáshoz.

Hol szerezhető be?

A jegyadatokban külön „Comment” eseményként szerepel. Az esemény részletei között a „public: true” attribútum jelzi, hogy nem belső megjegyzésről van szó.

Rögzítés

A jegy „Comment” eseményeiből származik, ha a „public” jelző értéke true.

Eseménytípus explicit
SLA-célérték túllépve
Ez a tevékenység azt az időpontot jelöli, amikor a szolgáltatási kérelem nem teljesíti az előírt SLA-célértéket, például az első válasz vagy a megoldás határidejét. A Zendesk külön eseményként naplózza, ha egy célérték nem teljesül.
Miért fontos?

Ez az esemény fontos a megfelelés nyomon követéséhez, és az SLA-teljesítési arány KPI egyik fő bemeneti adata. Megmutatja, mikor nem teljesültek a szolgáltatási vállalások.

Hol szerezhető be?

A Zendesk jegyeseményei vagy auditnaplója „SLABreach” eseményéből származik. Az esemény megadja, melyik SLA-mutató lépte túl a célértéket.

Rögzítés

A jegyadatokban szereplő külön „SLABreach” esemény alapján azonosítható.

Eseménytípus explicit
Szolgáltatási kérelem létrehozva
Ez jelöli a szolgáltatási kérelem életciklusának kezdetét, amikor a kérelmező bármely csatornán új jegyet küld be. Az esemény a Zendesk jegyellenőrzési naplójában „Create” eseményként szerepel, így pontosan meghatározható a folyamat kezdete.
Miért fontos?

Ez a tevékenység minden szolgáltatási kérelem első eseménye. Nélkülözhetetlen a teljes átfutási idő kiszámításához és a beérkező kérelmek mennyiségének elemzéséhez.

Hol szerezhető be?

A Zendesk jegyellenőrzési naplójában „Create” eseménytípusként szerepel. Az esemény időbélyege a szolgáltatási jegy létrehozásának időpontja.

Rögzítés

Közvetlenül a jegyellenőrzési napló „Create” eseményéből származik.

Eseménytípus explicit
Szolgáltatási kérelem lezárva
A szolgáltatási kérelem végleges lezárását jelenti. A jegy egy meghatározott idő elteltével automatikusan „closed” állapotba kerül, miután „solved” állapotú lett, és ezután már nem nyitható újra.
Miért fontos?

Ez a tevékenység jelöli a szolgáltatási kérelem folyamatának végleges végét. A teljes ügyintézési idő kiszámításához ez adja a végpontot.

Hol szerezhető be?

A jegy auditnaplójának „status” mezőjén rögzített „Change” eseményből következtethető ki, ha az új érték „closed”.

Rögzítés

Az auditnapló „Change” eseményéből következtethető ki, amikor az állapot „closed” értékre változik.

Eseménytípus inferred
Szolgáltatási kérelem megoldva
Ez a tevékenység azt jelöli, amikor az ügyintéző megoldást ad, és a jegy állapotát „solved” értékre állítja. Az ügyintéző szempontjából a kérelem ekkor lezárult, de a kérelmező még újranyithatja.
Miért fontos?

Ez fontos mérföldkő, amely az aktív ügyintézői munka végét jelzi. Az állapot eléréséhez szükséges idő a megoldás hatékonyságának egyik fő mérőszáma.

Hol szerezhető be?

A jegy auditnaplójának „status” mezőjén rögzített „Change” eseményből következtethető ki, ha az új érték „solved”.

Rögzítés

Az auditnapló „Change” eseményéből következtethető ki, amikor az állapot „solved” értékre változik.

Eseménytípus inferred
Szolgáltatási kérelem újranyitva
Akkor történik, amikor a kérelmező válaszol egy „solved” állapotú kérelemre, és annak állapota automatikusan ismét „open” lesz. Ez azt jelzi, hogy a javasolt megoldás nem volt megfelelő.
Miért fontos?

Ez a tevékenység az utómunka legfontosabb jelzője. Gyakoriságának elemzésével mérhető a megoldások minősége, és feltárhatók az ügyfél-elégedetlenség okai.

Hol szerezhető be?

A jegy auditnaplójának „status” mezőjén rögzített „Change” eseményből következtethető ki, ha a korábbi érték „solved”, az új pedig „open”.

Rögzítés

A „solved” állapot „open” értékre változásából következtethető ki.

Eseménytípus inferred
Belső megjegyzés hozzáadva
Az ügyintéző belső megjegyzést vagy kommentet fűzött a szolgáltatási kérelemhez, amelyet csak a többi ügyintéző láthat. Ezt olyan „Comment” esemény rögzíti, amelynél a „public” attribútum értéke false.
Miért fontos?

A belső megjegyzések nyomon követése megmutatja, hogyan működnek együtt az ügyintézők és a csapatok. Az együttműködés késedelmet okozhat, de a problémák hatékony megoldását is segítheti.

Hol szerezhető be?

A jegyadatokban külön „Comment” eseményként szerepel. Az esemény részletei között a „public: false” attribútum jelzi, hogy belső megjegyzésről van szó.

Rögzítés

A jegy „Comment” eseményeiből származik, ha a „public” jelző értéke false.

Eseménytípus explicit
Kérelem eszkalálva
A szolgáltatási kérelem hivatalos továbbítását jelenti egy magasabb szintű ügyfélszolgálati csoporthoz, egy másik csapathoz vagy a vezetőséghez. Erre általában a jegyhez rendelt csoport változásából vagy az eszkalációk nyomon követésére szolgáló egyéni mező módosulásából lehet következtetni.
Miért fontos?

Az eszkalációk nyomon követése segít azonosítani az összetett kérelmeket, a frontvonalban dolgozó ügyintézők képzési igényeit és a magasabb szintű beavatkozást igénylő rendszerszintű problémákat.

Hol szerezhető be?

Ez nem szabványos esemény. Az eszkalációs csoporthoz tartozó „group_id” mező „Change” eseményéből vagy az eszkalációk nyomon követésére használt egyéni jegymező módosulásából kell következtetni rá.

Rögzítés

A „group_id” mező vagy egy egyéni „escalation” mező változásából következtethető ki.

Eseménytípus inferred
Kérelem függőben
Ez a tevékenység akkor történik, amikor a szolgáltatási kérelem állapota „on-hold” értékre változik. Ez általában azt jelenti, hogy az ügyintéző a kérelmezőtől vagy egy harmadik féltől vár információt. Az esemény az állapotváltozásból következtethető ki.
Miért fontos?

Így elkülöníthetők és mérhetők azok a várakozási idők, amelyekre az ügyfélszolgálati csapatnak nincs közvetlen ráhatása. Ez pontosabb képet ad az ügyintézői kezelési időről.

Hol szerezhető be?

A jegy auditnaplójának „status” mezőjén rögzített „Change” eseményből következtethető ki, ha az új érték „on-hold”.

Rögzítés

Az auditnapló „Change” eseményéből következtethető ki, amikor az állapot „on-hold” értékre változik.

Eseménytípus inferred
Prioritás módosítva
Azt jelzi, hogy módosult a szolgáltatási kérelem prioritása, például „Alacsony”, „Normál”, „Magas” vagy „Sürgős” értékre. A jegyellenőrzési naplóban a „priority” mező „Change” eseményeként szerepel.
Miért fontos?

A prioritásváltozások elemzésével azonosíthatók azok a kérések, amelyek sürgőssége idővel nő, és felmérhető, mennyire hatékony a prioritások kezelése.

Hol szerezhető be?

A Zendesk-jegy auditnaplójában a „priority” mező „Change” eseményeként szerepel, a korábbi és az új értékkel együtt.

Rögzítés

Az auditnapló „priority” mezőjének „Change” eseményeiből következtethető ki.

Eseménytípus inferred
SLA-cél alkalmazva
Azt az időpontot jelöli, amikor egy szolgáltatási szintre vonatkozó megállapodás (SLA) szabálya érvénybe lép a szolgáltatási jegyre. Az esemény akkor kerül a naplóba, amikor a jegy tulajdonságai megfelelnek egy aktív SLA-szabály feltételeinek.
Miért fontos?

Az SLA alkalmazási időpontjának követése elengedhetetlen a megfelelés nyomon követéséhez, az esetleges SLA-sértések elemzéséhez és a különböző kérelmekre vonatkozó elvárt szolgáltatási határidők megértéséhez.

Hol szerezhető be?

A Zendesk jegyeseményei vagy ellenőrzési naplója „SLAPolicyApplied” eseményéből származik. Az esemény megadja, hogy melyik szabály lépett érvénybe.

Rögzítés

A jegyadatokban szereplő „SLAPolicyApplied” esemény alapján azonosítható.

Eseménytípus explicit
Ügyintéző áthelyezve
Azt jelzi, hogy a szolgáltatási kérelem felelőse az egyik ügyintézőről egy másikra változik. Erre az első hozzárendelést követő, „assignee_id” mezőn rögzített bármely „Change” eseményből lehet következtetni.
Miért fontos?

Az áthelyezések nyomon követése szükséges az ügyintéző-áthelyezési arány KPI kiszámításához. Ez segít feltárni a folyamat hatékonysági problémáit, a hibás irányítást és a tudáshiányt.

Hol szerezhető be?

A jegy auditnaplójának „assignee_id” mezőjén rögzített „Change” eseményekből következtethető ki, a jegy első hozzárendelési eseményét nem számítva.

Rögzítés

Az „assignee_id” mező második és további „Change” eseményeiből következtethető ki.

Eseménytípus inferred
Javasolt Nem kötelező

Útmutatók az adatok kinyeréséhez

Adatok kinyerése a Zendesk Support rendszerből

Kezdje el most?

Kezdje el még ma optimalizálni a szolgáltatási kérelmek folyamatát. Ezzel az adatsablonnal feltárhatja a szűk keresztmetszeteket, és hatékonyabbá teheti a Zendesk Support működését.

Optimalizálja a szolgáltatásikérelem-kezelést. Csökkentse a késedelmeket még ma.

Szüntesse meg a lassú ügyintézést és a felhasználói elégedetlenséget. Érjen el 70%-os automatizálást.

Próbálja ki ingyen

Nincs szükség bankkártyára. Gyors beállítás.