Ügyfélszolgálati adatsablon
Ügyfélszolgálati adatsablon
- Javasolt attribútumok
- Követendő tevékenységek
- Adatkinyerési útmutató a Microsoft Dynamics 365 ügyfélszolgálatához
Ügyfélszolgálati attribútumok
| Név | Leírás | ||
|---|---|---|---|
|
Szervizkérelem
ServiceRequest
|
Az ügyfélszolgálati kérelem egyedi azonosítója. Ügyként vagy jegyként is ismert. | ||
|
Leírás
A szervizkérelem az elsődleges azonosító, amely egyetlen ügyfélkérdéshez vagy problémához kapcsolja az összes tevékenységet. A process mining során ez az ügyazonosító biztosítja, hogy minden ügyfélkapcsolat a létrehozástól a lezárásig teljes és következetes képet adjon. A szervizkérelem szerinti elemzéssel végigkövethető az ügy teljes útja, mérhetők a megoldási idők, és feltárhatók a hasonló ügyek közös mintázatai.
Miért fontos?
Ez az ügyazonosító kapcsolja össze az összes kapcsolódó eseményt egyetlen folyamatpéldánnyá, így lehetővé teszi a folyamat teljes körű elemzését.
Hol szerezhető be?
Ez a Microsoft Dynamics 365 Customer Service Case (incident) entitásának elsődleges kulcsa.
Példák
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
Forrásrendszer
SourceSystem
|
Megadja, melyik forrásrendszerből származnak a kinyert adatok. | ||
|
Leírás
Ez az attribútum az eseményadatok forrását jelöli. Ennél a folyamatnál következetesen a Microsoft Dynamics 365 Customer Service lesz a forrás. Több rendszer használatakor ez a mező segít megkülönböztetni az adatforrásokat és nyomon követni az adatok eredetét.
Miért fontos?
Egyértelműen nyomon követhetővé teszi az adatok eredetét. Ez fontos az adatirányításhoz és az adatok közötti eltérések kivizsgálásához, különösen több rendszer adatainak együttes elemzésekor.
Hol szerezhető be?
Ez általában egy rögzített érték, amelyet az adatkinyerés és -átalakítás során adnak hozzá az adathalmaz forrásának megjelölésére.
Példák
Microsoft Dynamics 365 Customer Service
|
|||
|
Kezdési idő
EventTime
|
Az a dátum és idő, amely megmutatja, mikor történt a tevékenység. | ||
|
Leírás
Ez az attribútum rögzíti, hogy egy adott tevékenység pontosan mikor történt. Szükséges az események helyes sorrendjének megállapításához és minden időalapú elemzéshez, például az átfutási idők, az időtartamok és a tevékenységek közötti várakozási idők kiszámításához. A pontos és következetes időbélyeg a process mining elemzés megbízhatóságának alapja.
Miért fontos?
Az időbélyeg időrendbe állítja az eseményeket, és lehetővé teszi az időtartamok kiszámítását. Ezek nélkülözhetetlenek a teljesítmény elemzéséhez és a szűk keresztmetszetek feltárásához.
Hol szerezhető be?
Ez a Case (incident) entitás vagy a kapcsolódó tevékenységentitások, például az Email, Task és Phone Call
Példák
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
Tevékenység
ActivityName
|
Egy adott időpontban, egy szervizkérelem kapcsán történt konkrét üzleti esemény neve. | ||
|
Leírás
Ez az attribútum az ügyfélszolgálati folyamat egy lépését vagy állapotváltozását írja le, például: „Ügy létrehozva”, „Ügyintéző kivizsgálta a problémát” vagy „Ügy megoldva”. Ezek a tevékenységek alkotják a folyamattérkép alapját, és lehetővé teszik a folyamat menetének megjelenítését és elemzését. Ha egy tevékenységhez időbélyeg is tartozik, az eseményként meghatározza a folyamat sorrendjét.
Miért fontos?
A tevékenységek a folyamat lépéseit jelölik. Sorrendjük és gyakoriságuk elemzése alapvető a folyamatmenet megértéséhez, az eltérések feltárásához és a szűk keresztmetszetek megtalálásához.
Hol szerezhető be?
Általában az állapotváltozások (statuscode) vagy a kapcsolódó entitások, például a feladatok, e-mailek vagy telefonhívások konkrét eseményeinek egységes tevékenységnévhez rendelésével állítható elő.
Példák
Ügy létrehozvaÜgyintéző kivizsgálta a problémátMegoldási javaslat elküldve az ügyfélnekÜgy lezárva
|
|||
|
Utolsó adatfrissítés
LastDataUpdate
|
Az adatok forrásrendszerből történő utolsó frissítésének vagy kinyerésének időbélyege. | ||
|
Leírás
Ez az attribútum jelzi, mikor nyerték ki utoljára az adatokat a Microsoft Dynamics 365 rendszerből. Segít megállapítani, mennyire frissek az elemzett adatok, és szükséges a jelentésekhez, valamint a nyomon követéshez. Így a felhasználók a dashboardok és elemzések értelmezésekor figyelembe vehetik az adatok aktualitását.
Miért fontos?
Tájékoztatja a felhasználókat az adatok frissességéről, ami segít időben és pontosan, a folyamatelemzésre alapozva üzleti döntéseket hozni.
Hol szerezhető be?
Ezt az értéket az adatkinyeréskor állítják elő, majd rögzítik az adathalmazon.
Példák
2023-10-27T08:00:00Z
|
|||
|
Állapot oka
StatusReason
|
Részletesebben megadja a szervizkérelem aktuális állapotának okát. | ||
|
Leírás
Az ügy általános állapota lehet például 'Active' vagy 'Resolved', az állapot oka pedig pontosabb információt ad, például „Információ megadva” vagy „Probléma megoldva”. Ez az attribútum segít megérteni, hogyan és miért haladnak végig az ügyek az életciklusukon. Megkülönböztethető például a sikeresen megoldott és az ügyfél által megszakított ügy, ami pontos eredményelemzést tesz lehetővé.
Miért fontos?
Részletes képet ad az ügy kimeneteléről és az állapotváltozások okáról. Így pontosabban elemezhetők a megoldási útvonalak és a kiváltó okok.
Hol szerezhető be?
A Case (incident) entitás 'Status Reason' (statuscode) mezőjének felel meg.
Példák
FolyamatbanFelfüggesztveProbléma megoldvaInformáció megadva
|
|||
|
Kapcsolattartási csatorna
Channel
|
Az a kommunikációs csatorna, amelyen keresztül a szervizkérelmet benyújtották. | ||
|
Leírás
Ez az attribútum azonosítja az ügyfélkapcsolat forrását, például telefon, e-mail, webes portál vagy chat. Az egyes csatornák folyamatai, ügyfélelvárásai és a megoldás összetettsége eltérhetnek. A csatorna szerinti elemzés segít az adott csatornához tartozó munkafolyamatok és erőforrások elosztásának javításában.
Miért fontos?
Megmutatja, hogyan befolyásolják az egyes ügyfélkapcsolati csatornák a folyamat hatékonyságát, a megoldási időt és az ügyfélelégedettséget.
Hol szerezhető be?
A Case (incident) entitás 'Case Origin' (caseorigincode) mezőjének felel meg.
Példák
TelefonE-mailWebChat
|
|||
|
Prioritás
Priority
|
A szervizkérelemhez rendelt prioritási szint, amely a sürgősségét jelzi. | ||
|
Leírás
Ez az attribútum a szervizkérelem sürgősségét határozza meg, jellemzően alacsony, normál, magas vagy sürgős értékkel. A prioritás alapján dől el, milyen sorrendben kezelik az ügyeket, és gyakran az SLA-célértékeket is meghatározza. Fontos megérteni, hogyan hat a prioritás a folyamat menetére, az erőforrások elosztására és a megoldási időkre, hogy a sürgős ügyeket időben kezeljék.
Miért fontos?
Segít megállapítani, hogy a magas prioritású kérelmeket gyorsabban dolgozzák-e fel, teljesítik-e a hozzájuk tartozó célértékeket, és hogyan befolyásolják a prioritási szintek a folyamat egészének teljesítményét.
Hol szerezhető be?
A Case (incident) entitás 'Priority' (prioritycode) mezőjének felel meg.
Példák
AlacsonyNormálMagas
|
|||
|
SLA szerinti megoldási határidő
SlaTargetResolutionTime
|
A szervizkérelem megoldására szerződésben vállalt határidő. | ||
|
Leírás
Ez az attribútum meghatározza, hogy az érvényes Service Level Agreement (SLA) szerint mennyi időn belül kell megoldani a szervizkérelmet. Ez az a célérték, amelyhez a tényleges teljesítményt viszonyítják. Az érték szükséges az SLA-k betartását figyelő dashboardhoz és az SLA-betartási arány KPI kiszámításához. Megmutatja, hol nem teljesülnek a szolgáltatási vállalások.
Miért fontos?
Ez az elsődleges viszonyítási alap a szolgáltatási teljesítmény vállalásokhoz méréséhez, és közvetlenül lehetővé teszi az SLA-k betartásának és megszegésének elemzését.
Hol szerezhető be?
Az értéket a Dynamics 365 SLA-beállításai határozzák meg, és az SLA KPI Instances rekordokon keresztül kapcsolódik az ügyhöz.
Példák
2592008640014400
|
|||
|
Szervizkérelem típusa
ServiceRequestType
|
A szervizkérelem elsődleges kategóriája vagy besorolása. | ||
|
Leírás
Ez az attribútum a szervizkérelmet annak jellege szerint kategorizálja, például „Számlázási kérdés”, „Műszaki támogatás” vagy „Termékkel kapcsolatos visszajelzés”. Segítségével külön elemezhetők a folyamat egyes típusai, és megérthető, hogyan kezelik a különböző kérelmeket. A típus szerinti elemzés feltárhatja, hogy bizonyos kategóriák megoldása tovább tart, gyakrabban eszkalálják őket, vagy más folyamaton mennek végig.
Miért fontos?
A folyamat típus szerinti bontásával feltárhatók az adott kategóriára jellemző szűk keresztmetszetek, erőforrásigények és fejlesztési lehetőségek. Ez segíti a megfelelőbb irányítási és ügykezelési gyakorlat kialakítását.
Hol szerezhető be?
Ezt az információt gyakran a Case (incident) entitás 'Subject' (subjectid) mezőjében vagy egy egyéni kategóriamezőben tárolják.
Példák
Számlázási kérdésMűszaki támogatásTermékkel kapcsolatos visszajelzésÜgyfélkapcsolat-kezelés
|
|||
|
Ügyfél neve
CustomerName
|
A szervizkérelemhez kapcsolódó ügyfél vagy ügyfélfiók neve. | ||
|
Leírás
Ez az attribútum azonosítja a szervizkérelmet benyújtó ügyfelet. Ügyfélszempontú elemzést tesz lehetővé, így kiderülhet, mely ügyfelek nyújtják be a legtöbb kérelmet, melyeknél tart legtovább a megoldás, vagy melyek ügyei a legösszetettebbek. Ez fontos az ügyfélkapcsolatok kezeléséhez és az egyes ügyfeleknek nyújtott szolgáltatás javításához.
Miért fontos?
Ügyfélszintű elemzéssel feltárhatók a mintázatok, javítható a kiemelt ügyfelek kiszolgálása, és jobban megérthető az ügyfélút.
Hol szerezhető be?
A Case (incident) entitás 'Customer' (customerid) keresőmezőjének felel meg, amely Account vagy Contact rekordra hivatkozhat.
Példák
Global Tech Inc.Jane DoeInnovate Solutions
|
|||
|
Ügyintéző neve
AgentName
|
A tevékenységért felelős ügyfélszolgálati ügyintéző vagy felhasználó neve. | ||
|
Leírás
Ez az attribútum azonosítja azt az ügyintézőt vagy rendszerfelhasználót, aki végrehajtott egy tevékenységet, például átvett egy elemet a várólistáról vagy megoldott egy ügyet. Fontos az ügyintézői teljesítmény, a munkaterhelés eloszlása és az erőforrások elosztása szempontjából. Az egyes ügyintézők tevékenységeinek követésével a szervezetek felismerhetik a kiemelkedő teljesítményt, a képzési igényeket és a kiegyensúlyozatlan terhelést.
Miért fontos?
Lehetővé teszi az egyéni és csapatszintű teljesítmény elemzését, segít kiegyensúlyozni a munkaterhelést, és feltárja a szolgáltatás minőségének javítását célzó fejlesztési lehetőségeket.
Hol szerezhető be?
A Case (incident) entitás 'Owner' (ownerid) mezőjének felel meg, amely a System User (systemuser) entitásra hivatkozik.
Példák
Alice SmithBob JohnsonRendszer
|
|||
|
CSAT-pontszám
CustomerSatisfactionScore
|
Az ügyfél által az ügy lezárása után adott elégedettségi pontszám. | ||
|
Leírás
Ez az attribútum az ügyfél-elégedettségi (CSAT) felmérés számszerű vagy kategóriákba sorolt értékelését tárolja, amelyet általában a szolgáltatási kérelem lezárása után gyűjtenek be. Közvetlenül mutatja, hogyan ítéli meg az ügyfél a szolgáltatás minőségét. Ezek az adatok szükségesek az ügyfél-elégedettségi trendeket bemutató dashboardhoz és a megoldás utáni átlagos CSAT-pontszám KPI-hoz, így a folyamat teljesítménye összekapcsolható az ügyfélélménnyel.
Miért fontos?
Közvetlenül méri az ügyfelek elégedettségét. Segítségével összevethető a folyamat működése az ügyfelek visszajelzéseivel, és meghatározhatók a fejlesztési lehetőségek.
Hol szerezhető be?
Az adat jellemzően egy kapcsolódó felmérési entitásból, például a Customer Voice-ból származik, és a Case (incident) entitáshoz kapcsolódik.
Példák
5341
|
|||
|
Érintett termék
ProductInvolved
|
A termék, amelyhez az ügyfél szolgáltatási kérelme kapcsolódik. | ||
|
Leírás
Ez az attribútum azonosítja azt a konkrét terméket vagy szolgáltatást, amelyre az ügyfél problémája vonatkozik. Lehetővé teszi a szolgáltatási folyamat termék szerinti elemzését. Így kiderülhet, hogy egyes termékekhez több támogatási kérelem érkezik-e, összetettebb problémákat okoznak-e, vagy speciális ügyintézői szaktudást igényelnek-e. Az elemzés a termékfejlesztést és az erőforrások tervezését is segíti.
Miért fontos?
Lehetővé teszi a folyamat termékenkénti elemzését, így feltárhatók a visszatérő termékproblémák, fejleszthető a támogatási dokumentáció, és hatékonyabban oszthatók be a szakértők.
Hol szerezhető be?
A Case (incident) entitás „Product” (productid) keresőmezőjének felel meg.
Példák
Alpha-100 nyomtatóZeta CRM-szoftverOmega adatcsomag
|
|||
|
Eszkalálva
IsEscalated
|
Jelzi, hogy eszkalálták-e a szolgáltatási kérelmet. | ||
|
Leírás
Ez a logikai attribútum jelzi, hogy eszkalálták-e a szolgáltatási kérelmet. Eszkalációra akkor kerül sor, ha az első szintű ügyfélszolgálat nem tudja megoldani a problémát, ezért egy magasabb szintű csapat vagy szakértő beavatkozására van szükség. Ennek az értéknek a követése szükséges a belső eszkalációs útvonalakat bemutató dashboardhoz és a belső eszkalációs arány KPI-hoz. Segítségével feltárhatók az eszkalációk kiváltó okai, valamint az első ügyfélszolgálati szintek hiányosságai.
Miért fontos?
Közvetlenül méri az eszkalációk gyakoriságát. Rávilágít az első kapcsolatfelvételkor történő megoldás problémáira, és megmutatja, hol van szükség a folyamatok fejlesztésére vagy az ügyintézők készségeinek bővítésére.
Hol szerezhető be?
A Case (incident) entitás „Is Escalated” (isescalated) mezőjének felel meg.
Példák
truefalse
|
|||
|
Felelős csapat
OwnerTeam
|
A szolgáltatási kérelemért jelenleg felelős csapat. | ||
|
Leírás
Ez az attribútum azonosítja a szolgáltatási kérelemért felelős csapatot. A kérelem felelőse lehet egy ügyintéző vagy egy csapat (várólista). A csapatok szerinti elemzés segít megérteni a csapatok teljesítményét, a munkaterhelés eloszlását a különböző ügyfélszolgálati szintek és szakterületek között, valamint feltárni a csapatok közötti folyamatbeli eltéréseket.
Miért fontos?
Lehetővé teszi a csapatok teljesítményének elemzését, ami elengedhetetlen az ügyfélszolgálati szintek és a szakterületi csoportok hatékony irányításához.
Hol szerezhető be?
A Case (incident) entitás „Owner” (ownerid) mezőjéből származik, ha a felelős egy Team rekord, nem pedig egy System User.
Példák
1. szintű ügyfélszolgálatSzámlázási osztályMűszaki szakértők
|
|||
|
Megoldás az első kapcsolatfelvételkor
IsFirstContactResolution
|
Jelzi, hogy a kérelmet az első kapcsolatfelvétel során megoldották-e. | ||
|
Leírás
Ez a számított attribútum azokat a szolgáltatási kérelmeket azonosítja, amelyeket az ügyfél további megkeresése vagy az ügyintézőváltást igénylő jelentős késedelem nélkül oldottak meg. A pontos meghatározás összetett lehet, de általában rövid átfutási időt, valamint az ügy újbóli megnyitásának és az első kapcsolatfelvétel utáni ügyfélmegkereséseknek a hiányát veszi figyelembe. Ez az első kapcsolatfelvételkor történő megoldás arányát mérő KPI alapja.
Miért fontos?
A szolgáltatás hatékonyságának és az ügyfelek elégedettségének fontos mérőszáma, mert megmutatja, hogy a problémákat milyen arányban sikerül gyorsan és teljes körűen megoldani.
Hol szerezhető be?
Az egyes ügyek eseménynaplójában szereplő tevékenységek sorrendje és időzítése alapján számítható ki.
Példák
truefalse
|
|||
|
SLA-túllépés
IsSlaBreached
|
Számított jelző, amely mutatja, hogy a szolgáltatási kérelem teljesítési ideje túllépte-e az SLA-célt. | ||
|
Leírás
Ez a logikai jelző a szolgáltatási kérelem tényleges megoldási idejét hasonlítja össze a „SLA Target Resolution Time” értékével. Értéke igaz, ha a tényleges idő meghaladja a célidőt. Ez az attribútum alapvető az SLA-megfelelés nyomon követésére szolgáló dashboardhoz és az SLA-megfelelési arány KPI kiszámításához. Egyértelmű, igen vagy nem eredményt ad minden ügy SLA-teljesítéséről.
Miért fontos?
Egyértelműen jelzi minden ügy esetében, hogy teljesült-e az SLA. Így könnyen szűrhetők, összesíthetők és elemezhetők a túllépések kiváltó okai.
Hol szerezhető be?
A „ServiceRequestCycleTime” és a „SlaTargetResolutionTime” összehasonlításával számítható ki.
Példák
truefalse
|
|||
|
Tudásbáziscikk azonosítója
KnowledgeArticleId
|
A szolgáltatási kérelemhez kapcsolódó tudásbáziscikk azonosítója. | ||
|
Leírás
Ez az attribútum rögzíti annak a tudásbáziscikknek az azonosítóját, amelyet a szolgáltatási kérelem megoldása során felhasználtak vagy ahhoz kapcsoltak. Közvetlenül méri, hogy az ügyintézők mennyire használják hatékonyan a tudásbázist az ügyfelek problémáinak megoldásához. Ezek az adatok a tudásbáziscikkek használatát bemutató dashboard és a hozzá tartozó KPI alapját adják, és segítenek felmérni a tudásbázis értékét és teljességét.
Miért fontos?
Nyomon követi a tudásbázis használatát, így láthatóvá válik, hogy az ügyintézők felhasználják-e a rendelkezésre álló erőforrásokat a problémák gyorsabb és következetesebb megoldásához.
Hol szerezhető be?
Ez az információ a Case (incident) és a Knowledge Article (knowledgearticle) entitások közötti kapcsolatban található.
Példák
KA-01337KA-02048
|
|||
|
Újramunka
IsRework
|
Számított jelző, amely mutatja, hogy az ügy során történt-e újramunka. | ||
|
Leírás
Ez a logikai jelző azokat az ügyeket azonosítja, amelyekben újramunkára utaló ismétlődő tevékenységek vagy folyamatkörök fordulnak elő. Ilyen például az „Információkérés az ügyféltől” esemény többszöri előfordulása, vagy az ügy megoldás utáni újbóli aktiválása. Az érték a tevékenységek sorrendjének elemzésével számítható ki, azonosítva a hatékonytalanságra vagy a probléma első alkalommal történő hibás megoldására utaló mintákat. Ez az attribútum az újramunkát és az ismételt kapcsolatfelvételeket elemző dashboard alapja.
Miért fontos?
Segít számszerűsíteni és elkülöníteni a folyamat hatékonytalanságait, így az elemzők az ismétlődő munkák és a felesleges ráfordítások kiváltó okaira összpontosíthatnak.
Hol szerezhető be?
A process mining elemzéseivel azonosíthatók a meghatározott tevékenységsorozatok, például a Megoldva → Újraaktiválva sorrend, illetve az ügyön belül ismétlődő tevékenységek.
Példák
truefalse
|
|||
Ügyfélszolgálati tevékenységek
| Tevékenység | Leírás | ||
|---|---|---|---|
|
SLA-időmérő elindult
|
Azt jelzi, hogy elindult az ügyhöz tartozó Service Level Agreement (SLA) időmérője. Ez egy meghatározott szolgáltatási mutató, például az „Első válasz határideje” vagy a „Megoldás határideje” alapján méri az időt. Az eseményt a Dynamics 365 SLA-motorja kezeli. | ||
|
Miért fontos?
Ez a tevékenység alapvető az SLA-k betartásának nyomon követéséhez és annak megértéséhez, hogy mikor indul a szolgáltatási vállalások teljesítésére rendelkezésre álló idő. Közvetlenül segít megállapítani, hogy teljesülnek-e a szolgáltatási célok.
Hol szerezhető be?
Az eseményt az 'Incident' entitáshoz kapcsolódó 'SLA KPI Instance' entitás rögzíti. A megfelelő SLA KPI Instance rekord 'createdon' időbélyege jelöli a kezdést.
Rögzítés
Használja az ügyhöz kapcsolódó 'SLA KPI Instance' rekord létrehozási időbélyegét.
Eseménytípus
explicit
|
|||
|
Ügy eszkalálva
|
Azt jelzi, hogy az ügyet hivatalosan magasabb támogatási szinthez vagy másik csapathoz irányították. Ez történhet például úgy, hogy egy felhasználó az ügyet egy kijelölt eszkalációs várólistához vagy felhasználóhoz rendeli. | ||
|
Miért fontos?
Az eszkalációk követése szükséges a „Belső eszkalációk aránya” KPI méréséhez, valamint azoknak az okoknak a feltárásához, amelyek miatt az első vonalbeli támogatás nem tudja megoldani az ügyeket. Az eszkalációk rámutatnak a folyamat hiányosságaira és a képzési lehetőségekre.
Hol szerezhető be?
Az 'ownerid' mező kijelölt eszkalációs várólistára vagy csapatra történő módosításából következtethető ki. Jelezheti az ügy eszkalálását egy erre szolgáló egyéni művelet is.
Rögzítés
Keresse meg azt az időbélyeggel rögzített módosítást, amikor az 'ownerid' egy ismert eszkalációs várólistára változik.
Eseménytípus
inferred
|
|||
|
Ügy kiosztva
|
Ez a tevékenység azt jelzi, hogy az ügyet kezelésre egy adott várólistához vagy felhasználóhoz rendelték. A rendszer rögzíti az ügy felelősének módosításait, amelyek az auditnaplókban követhetők. | ||
|
Miért fontos?
A kiosztások követése segít elemezni a munkaterhelés eloszlását, feltárni a kiosztással kapcsolatos késéseket és megérteni az irányítás hatékonyságát. Megmutatja például, milyen gyorsan kerülnek az ügyek a megfelelő csapathoz vagy személyhez.
Hol szerezhető be?
Az 'Incident' entitás 'ownerid' mezőjének módosításai alapján követhető. A módosítás időbélyege az auditnaplók előzményeiben található.
Rögzítés
Nyerje ki az auditnaplókból az 'ownerid' mező időbélyeggel ellátott módosításait.
Eseménytípus
explicit
|
|||
|
Ügy létrehozva
|
Ez a tevékenység jelöli az ügyfélszolgálati folyamat kezdetét: ekkor jön létre egy új ügyrekord a rendszerben. A létrehozás egyértelmű esemény, amelyhez a rendszer időbélyeget rögzít, amikor az 'Incident' entitás rekordját először mentik. | ||
|
Miért fontos?
Ez az elsődleges kezdő esemény szükséges az ügy teljes életciklusának kiszámításához és az ügyforgalom alakulásának megértéséhez. A további folyamatelemzés ehhez az eseményhez viszonyít.
Hol szerezhető be?
Az esemény minden új rekordnál az 'Incident' (Case) entitás 'createdon' időbélyegéből származik.
Rögzítés
Használja az Incident rekord 'createdon' időbélyegét.
Eseménytípus
explicit
|
|||
|
Ügy lezárva
|
Ez az ügyrekord végleges adminisztratív lezárása, amely történhet a megoldással egy időben vagy később. A tevékenységet az ügy 'Closed' állapotba váltása rögzíti. | ||
|
Miért fontos?
Ez jelenti a folyamat életciklusának tényleges végét a rendszerben. A 'Resolved' és a 'Closed' állapot közötti idő adminisztratív többletmunkára vagy a rekordok véglegesítésének késésére utalhat.
Hol szerezhető be?
Az 'Incident' entitás 'statecode' mezőjének 'Canceled' (2) vagy egy egyéni lezárt állapotra váltása rögzíti. Az időbélyeg az auditelőzményekben található.
Rögzítés
Kövesse nyomon azt az időbélyeget, amikor a 'statecode' mező a végleges lezárt állapotra vált, például Canceled vagy Closed értékre.
Eseménytípus
explicit
|
|||
|
Ügy megoldva
|
Ez a fontos mérföldkő azt jelzi, hogy az ügyintéző megoldottnak tekinti az ügyfél problémáját. A Dynamics 365 rendszerben ez egy konkrét művelet, amely az ügyhöz kapcsolódó 'Case Resolution' tevékenységrekordot hoz létre. | ||
|
Miért fontos?
Ez az elsődleges, sikeres lezárást jelző esemény szükséges a megoldási idők és a sikerarány kiszámításához. Szinte minden ügyfélszolgálati KPI mérésében szerepet játszik.
Hol szerezhető be?
Az esemény egy 'Resolution' (Case Resolution) tevékenységrekord létrehozásának felel meg. A rekord 'actualend' időbélyege jelöli a megoldás időpontját.
Rögzítés
Használja a kapcsolódó 'Resolution' tevékenységrekord 'actualend' vagy 'createdon' időbélyegét.
Eseménytípus
explicit
|
|||
|
Elégedettségi felmérés elküldve
|
Az ügyfél-elégedettségi felmérés elküldését jelzi, amelyet általában az ügy megoldása után automatikusan indítanak el. Az eseményt rendszerint kimenő e-mailként vagy Customer Voice felmérési tevékenységként rögzítik. | ||
|
Miért fontos?
Ez a tevékenység összekapcsolja a működési folyamatot az ügyfélélmény eredményeivel. Lehetővé teszi az elégedettségi pontszámok elemzését annak fényében, hogy az ügy milyen folyamaton ment végig.
Hol szerezhető be?
Az esemény egy felmérési hivatkozást tartalmazó kimenő 'Email' tevékenység vagy az ügyhöz kapcsolódó 'Customer Voice survey invite' tevékenységrekord létrehozásából következtethető ki.
Rögzítés
Használja a felméréshez kapcsolódó tevékenységrekord létrehozási időbélyegét.
Eseménytípus
inferred
|
|||
|
Megoldási javaslat elküldve az ügyfélnek
|
Ez a tevékenység azt jelzi, hogy az ügyintéző kidolgozott egy megoldást, és tájékoztatta róla az ügyfelet. Általában az ügy idővonaláról küldött kimenő e-mailből vagy a „Pending Customer Confirmation” állapotra váltásból következtethető ki. | ||
|
Miért fontos?
Ez a mérföldkő jelzi az átmenetet a kivizsgálásból a megoldás felé. A javaslat és a megerősítés közötti idő elemzése feltárhatja az ügyfél válaszának késését vagy a javasolt megoldás problémáit.
Hol szerezhető be?
Az ügyhöz kapcsolódó kimenő 'Email' tevékenység időbélyegéből vagy a statuscode megoldás előtti állapotra váltásából következtethető ki.
Rögzítés
Használja a kimenő e-mail tevékenység időbélyegét, vagy az állapot „Solution Proposed” értékre váltásának időpontját.
Eseménytípus
inferred
|
|||
|
További információ kérése az ügyféltől
|
Ez a tevékenység azt jelzi, hogy az ügyintézőnek további információra van szüksége az ügyféltől a folytatáshoz. Gyakran abból következtethető ki, hogy az ügy állapota „várakozik” értékre változik, vagy az ügy idővonaláról kimenő e-mailt küldenek. | ||
|
Miért fontos?
Ez az esemény szükséges az ügyfélre várakozás miatti késések méréséhez és az „Ügyféladatokra várakozás ideje” KPI megértéséhez. Segít elkülöníteni a külső válaszra várakozással töltött időt.
Hol szerezhető be?
Az 'Incident' entitás 'statuscode' mezőjének módosításából következtethető ki, például ha az érték 'On Hold' lesz, az ok pedig 'Waiting for Customer'. Az állapotmódosítás időbélyegét kell használni.
Rögzítés
Kövesse nyomon azt az időbélyeget, amikor a statuscode egy kijelölt, ügyfélre várakozó állapotra változik.
Eseménytípus
inferred
|
|||
|
Ügy kategóriája módosult
|
Ez az esemény akkor történik, amikor az ügyintéző az ügy létrehozása után módosítja annak kategóriáját vagy tárgyát. A rendszer ezt a módosítást az auditfunkcióval rögzíti. | ||
|
Miért fontos?
Az átsorolás követése szükséges a „Szervizkérelmek átsorolási aránya” KPI méréséhez. A gyakori átsorolás a kezdeti besorolás problémáira utalhat, amelyek hibás irányításhoz és késésekhez vezetnek.
Hol szerezhető be?
Az 'Incident' entitás auditelőzményeiből nyerhető ki, különösen a 'subjectid' mező vagy más egyéni kategóriamezők módosításainak követésével.
Rögzítés
Nyerje ki az auditnaplókból a 'subjectid' mező időbélyeggel ellátott módosításait.
Eseménytípus
explicit
|
|||
|
Ügy újraaktiválva
|
Akkor történik, amikor egy korábban megoldott ügyet automatikusan vagy manuálisan újranyitnak, általában azért, mert az ügyfél válaszolt, vagy jelezte, hogy a probléma nem oldódott meg. A rendszer ilyenkor az ügy állapotát 'Resolved' értékről ismét 'Active' értékre módosítja. | ||
|
Miért fontos?
Ez a tevékenység segít feltárni az ismételt munkavégzést és elemezni az „Első kapcsolatfelvételkor megoldott ügyek aránya” mutatót. A sok újraaktiválás arra utal, hogy az első megoldás hiányos vagy nem volt hatékony.
Hol szerezhető be?
Az 'Incident' entitás 'statecode' mezőjének 'Resolved' (1) értékről 'Active' (0) értékre váltása rögzíti. A módosítás időbélyege az auditelőzményekben található.
Rögzítés
Kövesse az auditnaplókban a 'statecode' Resolved értékről Active értékre váltásának időbélyegét.
Eseménytípus
explicit
|
|||
|
Ügyintéző átvette a várólistaelem kezelését
|
Ez az esemény akkor történik, amikor egy ügyintéző aktívan átvesz egy ügyet a közös várólistáról, hogy elkezdjen vele foglalkozni. Ez az ügyintéző tudatos művelete, nem azonos azzal, amikor a rendszer az ügyet a várólistához rendeli. | ||
|
Miért fontos?
Ezzel mérhető, mennyi ideig vár az ügy a várólistán, mielőtt egy ügyintéző elkezd vele foglalkozni. Segít feltárni a várólista szűk keresztmetszeteit és megérteni, mennyire kezdeményezők az ügyintézők.
Hol szerezhető be?
Akkor követhető, amikor egy felhasználó módosítja az ügyhöz kapcsolódó 'QueueItem' entitás 'workedbyid' mezőjét, vagy amikor az ügy felelőse várólistáról felhasználóra változik.
Rögzítés
Keresse meg azt az időbélyeget, amikor a QueueItem 'workedbyid' mezője értéket kap.
Eseménytípus
explicit
|
|||
|
Ügyintéző kivizsgálta a problémát
|
Azt jelzi, hogy az ügyintéző aktívan igyekszik megérteni és diagnosztizálni az ügyfél problémáját. Ez következtetett tevékenység: gyakran abból állapítható meg, hogy az ügyintéző Knowledge Article-t kapcsol az ügyhöz, ami arra utal, hogy utánanézett a problémának. | ||
|
Miért fontos?
A követésével mérhető a tudásanyagok használata és annak hatása a megoldási időre. Megmutatja, hogy az ügyintézők igénybe veszik-e a rendelkezésükre álló eszközöket a problémák hatékony megoldásához.
Hol szerezhető be?
Az 'IncidentKnowledgeBaseRecord' entitás rekordjának létrehozásából következtethető ki. Ez a rekord kapcsolja össze a Knowledge Article-t az üggyel. A rekord létrehozásának időbélyegét kell használni.
Rögzítés
Használja azt az időbélyeget, amikor a Knowledge Article-t az Incident rekordhoz kapcsolják.
Eseménytípus
inferred
|
|||
Adatkinyerési útmutatók
Készen áll a kezdésre?
Ezzel az adatsablonnal gyorsan elindíthatja a process mining használatát, és hatékonyabbá teheti az ügyfélszolgálati működést. Kezdje el még ma a munkafolyamatok fejlesztését, hogy ügyfelei jobb kiszolgálást kapjanak.
Fejlessze az ügyfélszolgálatot: növelje az első kapcsolatfelvételkor megoldott ügyek arányát, és csökkentse a költségeket
Tárja fel a szűk keresztmetszeteket, és érje el, hogy az ügyek 80%-a már az első kapcsolatfelvételkor megoldódjon.
Nincs szükség bankkártyára. Néhány perc alatt beállíthatja.