> Continue procesverbetering > Incident Management > Freshservice > Datatemplate

Data Template: Incident Management

Freshservice

Incident Management-attributes (20) Incident Management-activiteiten (14) Extractie Guides (3)

Uw Incidentmanagement Data template

Dit template is ontworpen om u te helpen uw data voor te bereiden op effectieve analyse van incidentmanagement. Het schetst de essentiële attributes die verzameld moeten worden, de kritieke activiteiten die gevolgd moeten worden, en biedt praktische richtlijnen voor het extraheren van deze informatie uit uw source system. Gebruik deze resource om uw data preparation process te stroomlijnen.

Aanbevolen attributen om vast te leggen
Belangrijkste activiteiten om te volgen
Richtlijnen voor data-extractie

Nieuw met event logs? Leer hoe u een process mining event log creëert.

Template downloaden

Incident Management-attributes

Dit zijn de aanbevolen data-velden om op te nemen in uw event log voor een uitgebreide analyse van uw incidentmanagementproces.

5 Verplicht 7 Aanbevolen 8 Optioneel

	Naam	Beschrijving
	Incident ID IncidentId	De unieke identificatiecode voor elk incidentrecord, die dient als de primaire sleutel voor het volgen van de gehele incidentlevenscyclus.
Beschrijving De Incident ID is de hoeksteen van incidentbeheeranalyse. Het fungeert als de Case ID, waarbij alle gerelateerde activiteiten, timestamps en attribuutwijzigingen worden gekoppeld tot één samenhangende reis. In Process Mining is elk item in de event log verbonden met een Incident ID, wat de reconstructie van de end-to-end processtroom voor elk incident mogelijk maakt. Dit is essentieel voor het berekenen van cyclustijden, het analyseren van procesvarianten en het identificeren van knelpunten die specifiek zijn voor individuele cases. Zonder een unieke identifier zou het onmogelijk zijn om onderscheid te maken tussen verschillende incidenten en hun paden van melding tot oplossing te analyseren. Waarom het belangrijk is Het identificeert elk incident uniek, waardoor end-to-end tracking en analyse van de lifecycle mogelijk zijn van creatie tot afsluiting. Waar te verkrijgen Dit is de primaire identifier voor een ticket, beschikbaar via de Freshservice Tickets API als het 'id' field in het ticket object. Voorbeelden INC-10234INC-10235INC-10236
	Activiteitsnaam ActivityName	De naam van de specifieke bedrijfsactiviteit of het event dat plaatsvond op een bepaald tijdstip binnen de levenscyclus van het incident.
Beschrijving De Activiteitsnaam beschrijft een enkele stap of event in het incidentbeheerproces, zoals 'Incident toegewezen aan groep', 'Status gewijzigd naar In afwachting', of 'Incident opgelost'. Deze activiteiten zijn afgeleid van veranderingen in de data van het incident over tijd. Dit attribuut is fundamenteel voor Process Mining, aangezien het de knooppunten in de ontdekte proceskaart definieert. Door de volgorde en frequentie van deze activiteiten te analyseren, kunnen organisaties het daadwerkelijke incidentafhandelingsproces visualiseren, gemeenschappelijke paden identificeren, afwijkingen van de standaardprocedure detecteren en herwerklussen zoals frequente herbezettingen opsporen. Waarom het belangrijk is Het definieert de stappen in de proceskaart, waardoor visualisatie en analyse mogelijk zijn van de incidentoplossingsflow, knelpunten en afwijkingen. Waar te verkrijgen Dit attribuut is geen direct veld in Freshservice, maar is afgeleid van wijzigingen in ticketkenmerken zoals status, prioriteit, agent-/groepstoewijzing en de toevoeging van notities. Voorbeelden Incident GemeldIncident toegewezen aan groepOplossingsnotitie ToegevoegdIncident Opgelost
	Bronsysteem SourceSystem	Het systeem waaruit de data is geëxtraheerd, doorgaans 'Freshservice'.
Beschrijving Dit attribuut identificeert de herkomst van de data. Hoewel het in deze context consequent 'Freshservice' zal zijn, is het een cruciaal veld in omgevingen waar data uit meerdere systemen kan worden gecombineerd voor een holistisch procesoverzicht. Het opnemen van het attribuut 'Bronsysteem' is een best practice voor datagovernance en traceerbaarheid. Het zorgt voor duidelijkheid over de dataherkomst, wat belangrijk is voor validatie, debugging en toekomstige uitbreiding van het process mining project om andere servicemanagement- of operationele systemen te omvatten. Waarom het belangrijk is Het zorgt voor datatraceerbaarheid en governance door de oorsprong van de incidentmanagementdata duidelijk te identificeren. Waar te verkrijgen Dit is doorgaans een statische waarde die tijdens het data transformation (ETL) proces wordt toegevoegd om de dataset te labelen. Voorbeelden FreshserviceFreshservice-EUFreshservice-PROD
	Gebeurtenistijdstempel EventTimestamp	De exacte datum en tijd wanneer de activiteit of het event plaatsvond.
Beschrijving De Event Timestamp, of Starttijd, markeert het exacte moment dat een activiteit plaatsvond. Elke activiteit in de levenscyclus van het incident, van creatie tot afsluiting, heeft een geassocieerde timestamp. Dit attribuut is cruciaal voor alle tijdgerelateerde Process Mining-analyses. Het wordt gebruikt om events chronologisch te ordenen, de duur tussen activiteiten te berekenen, de totale cyclustijd van een case te meten en wachttijden te analyseren. Het is de basis voor het bouwen van dashboards die SLA-prestaties, overdrachtvertragingen en totale oplostijden monitoren. Waarom het belangrijk is Het biedt de chronologische volgorde van events, wat essentieel is voor het berekenen van duur, het analyseren van cycle times en het begrijpen van procesprestaties. Waar te verkrijgen Dit is afgeleid van diverse timestamp fields in Freshservice, zoals 'created_at', 'updated_at' en timestamps binnen de conversatie of audit logs van de ticket. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor dit proces voor het laatst is ververst of geëxtraheerd.
Beschrijving Dit attribuut biedt een timestamp voor wanneer de gehele dataset voor het laatst is bijgewerkt vanuit het bronsysteem. Het is een metadata-veld dat van toepassing is op de gehele dataset in plaats van op individuele events, maar het wordt vaak op eventniveau opgenomen voor consistentie. In analyse is deze informatie vitaal voor het begrijpen van de actualiteit van de data en het tijdsvenster dat door de dashboards en KPI's wordt bestreken. Het geeft gebruikers vertrouwen in de recentheid van de inzichten en helpt verwachtingen te managen over de vraag of de meest recente incidenten in de analyse zijn opgenomen. Waarom het belangrijk is Het informeert gebruikers over de actualiteit van de data, waarbij wordt gezorgd dat zij de tijdsperiode begrijpen die door de analyse wordt bestreken. Waar te verkrijgen Dit is een metadata timestamp die wordt gegenereerd tijdens het data-extractie (ETL) proces. Voorbeelden 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Incident Category IncidentCategory	De categorie die wordt gebruikt om het incident te classificeren, zoals Hardware, Software of Netwerk.
Beschrijving Incident Category biedt een manier om incidenten te classificeren op basis van het type gemelde probleem. Deze hiërarchische classificatie helpt bij het routeren van het incident naar het juiste team en is essentieel voor trendanalyse. Dit attribute wordt gebruikt in het Incident Categorization Accuracy-dashboard om te analyseren of initiële verkeerde categorisatie leidt tot langere oplostijden door herindelingen. Door incidenten per categorie te groeperen, kunnen organisaties terugkerende problemen identificeren, begrijpen waar de meeste supportinspanningen aan worden besteed en verbeterinitiatieven op maat maken. Waarom het belangrijk is Het maakt de analyse van incidenttrends mogelijk en helpt bepalen of onjuiste categorisatie vertragingen in de oplossing veroorzaakt. Waar te verkrijgen Dit is een standaard maar aanpasbaar field in Freshservice. Het is beschikbaar via de Tickets API als 'category', met gerelateerde fields 'sub_category' en 'item_category'. Voorbeelden HardwareSoftwareNetwerkprobleemAccounttoegang
	Incident Priority IncidentPriority	Het prioriteitsniveau van het incident, dat de urgentie van reactie en oplossing bepaalt.
Beschrijving Incident Priority is een sleutelveld dat de vereiste snelheid en focus voor de afhandeling van een incident bepaalt. Het wordt doorgaans gedefinieerd op een schaal zoals Laag, Gemiddeld, Hoog en Urgent, en is vaak bepalend voor de SLA-doelstellingen. In process mining is prioriteit een kritische dimensie voor filtering en analyse. Het maakt het mogelijk om de oplossingsprocessen voor high-priority versus low-priority incidenten te vergelijken, zodat kritieke problemen efficiënt worden afgehandeld. Dashboards segmenteren vaak metrics zoals cycle time en SLA-naleving per prioriteit om bruikbare inzichten te bieden aan supportmanagers. Waarom het belangrijk is Het helpt de analyse te prioriteren op de meest kritieke incidenten en is essentieel voor het evalueren van SLA-prestaties en middelentoewijzing. Waar te verkrijgen Beschikbaar in de Freshservice Tickets API als het priority veld. De waarden zijn numeriek (bijv. 1 voor Laag, 4 voor Urgent). Voorbeelden LaagGemiddeldHoogUrgent
	Incident Severity IncidentSeverity	Het ernstniveau van het incident, dat de bedrijfsimpact aangeeft.
Beschrijving Incident Severity meet de impact die een incident heeft op de bedrijfsvoering, vaak gecategoriseerd als Laag, Gemiddeld, Hoog of Kritiek. Hoewel gerelateerd aan prioriteit, richt severity zich op impact, terwijl prioriteit zich richt op urgentie. De combinatie van severity en impact bepaalt vaak de uiteindelijke prioriteit. Analyseren op severity helpt te begrijpen hoe goed de organisatie omgaat met incidenten met aanzienlijke bedrijfseffecten. Het wordt gebruikt in dashboards om oplostijden en SLA-prestaties te segmenteren, zodat de meest impactvolle problemen gedurende hun levenscyclus de juiste aandacht en middelen krijgen. Waarom het belangrijk is Het meet de business impact van een incident, waardoor analyse mogelijk is gericht op het beperken van de meest schadelijke problemen. Waar te verkrijgen Dit is een standaard field in Freshservice, beschikbaar via de Tickets API als 'impact'. De waarden zijn numeriek. Voorbeelden LaagGemiddeldHoog
	Incident Status IncidentStatus	De huidige status van het incident in zijn levenscyclus, zoals Open, In afwachting, Opgelost of Gesloten.
Beschrijving De Incidentstatus geeft de huidige staat van het incident aan. Statuswijzigingen zijn belangrijke events die de basis vormen van de ontdekte proceskaart, zoals de overgang van 'In behandeling' naar 'In afwachting' of van 'Opgelost' naar 'Gesloten'. Dit attribuut is fundamenteel voor het begrijpen van de reis van het incident. Het analyseren van de tijd die in elke status wordt doorgebracht, helpt bij het identificeren van knelpunten, zoals incidenten die te lang in een 'In afwachting'-status verkeren, wachtend op een gebruikersreactie. Het is ook cruciaal voor het definiëren van de start- en eindpunten voor cyclustijdberekeningen. Waarom het belangrijk is Het volgt de voortgang van het incident gedurende de lifecycle en helpt stadia te identificeren waar vertragingen vaak voorkomen. Waar te verkrijgen Beschikbaar in de Freshservice Tickets API als het status veld. De waarden zijn numeriek. Voorbeelden OpenIn uitvoeringPendingResolvedGesloten
	SLA Doeltijd Oplossing ResolutionSlaTargetTime	De timestamp waarop het incident naar verwachting opgelost moet zijn volgens de SLA-policy.
Beschrijving Dit attribuut slaat de specifieke datum en tijd op die dient als deadline voor het oplossen van een incident. Deze doelstelling wordt bepaald door de Service Level Agreement (SLA)-policy die op het ticket wordt toegepast, welke doorgaans afhankelijk is van factoren zoals prioriteit. Deze doeltijd is essentieel voor het berekenen van de KPI 'SLA-Nalevingspercentage' en voor het aandrijven van het 'SLA-Prestatiedashboard'. Door de daadwerkelijke oplossingstimestamp te vergelijken met deze doelstelling, kunnen we bepalen of een incident op tijd is opgelost of de SLA heeft geschonden. Dit is fundamenteel voor het meten van de naleving van serviceniveaus. Waarom het belangrijk is Het biedt de deadline voor oplossing, wat nodig is voor het berekenen van SLA-compliance en het identificeren van incidenten met risico. Waar te verkrijgen Beschikbaar in de Freshservice Tickets API als de fr_due_by (eerste reactie) en due_by (oplossing) velden. Voorbeelden 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Toegewezen agent AssignedAgent	De naam of ID van de support agent die momenteel is toegewezen om het incident op te lossen.
Beschrijving De Toegewezen agent identificeert de individuele servicedeskmedewerker die op een bepaald moment verantwoordelijk is voor het incident. Wijzigingen in dit attribuut vertegenwoordigen een overdracht van eigenaarschap tussen agents. Dit attribuut is essentieel voor prestatieanalyse en maakt dashboards mogelijk die de werkdruk van agents, de gemiddelde oplostijd per agent en de resolutiepercentages bij eerste contact bijhouden. Het wordt ook gebruikt om overdrachten tussen agents te analyseren, wat een bron van vertraging en inefficiëntie kan zijn. Door agenttoewijzingen te volgen, kunnen managers trainingsbehoeften identificeren en hoogpresterende teamleden erkennen. Waarom het belangrijk is Het maakt analyse van agentprestaties, werkbelastingverdeling en de impact van agenthandoffs op oplossingstijden mogelijk. Waar te verkrijgen Beschikbaar in de Freshservice Tickets API als het responder_id veld. Deze ID kan worden gekoppeld aan de Agents API om de naam van de agent te krijgen. Voorbeelden John DoeJane SmithSupportBot
	Toegewezen groep AssignedGroup	De ondersteuningsgroep of het team dat momenteel aan het incident is toegewezen.
Beschrijving De Toegewezen groep geeft aan welk team, zoals 'Level 1 Support', 'Netwerkteam' of 'Databasebeheerders', verantwoordelijk is voor het incident. Wijzigingen in dit attribuut duiden op een escalatie of overdracht tussen verschillende functionele teams. Het analyseren van de Toegewezen groep is cruciaal voor het begrijpen van overdrachtsvertragingen. Process Mining kan de stroom van incidenten tussen groepen visualiseren, veelvoorkomende escalatiepaden belichten en de wachttijd meten voordat elke groep actie onderneemt. Dit helpt bij het identificeren van organisatorische knelpunten en kansen om de teamoverschrijdende samenwerking te stroomlijnen. Waarom het belangrijk is Het volgt welk team verantwoordelijk is, wat cruciaal is voor het analyseren van handoffs, escalaties en interteamvertragingen. Waar te verkrijgen Beschikbaar in de Freshservice Tickets API als het group_id veld. Deze ID kan worden gekoppeld aan de Groups API om de groepsnaam te krijgen. Voorbeelden ServicedeskNetwerkbeheerInfrastructuur Support
	Afdeling Aanvrager RequestersDepartment	De afdeling waartoe de gebruiker die het incident meldde, behoort.
Beschrijving Dit attribuut identificeert de bedrijfsafdeling van de aanvrager, zoals 'Sales', 'Finance' of 'IT'. Deze informatie is doorgaans afkomstig uit het gebruikersprofiel binnen Freshservice. Het analyseren van incidenten per afdeling van de aanvrager kan onthullen of bepaalde bedrijfseenheden onevenredig worden getroffen door problemen of dat er afdelingsspecifieke problemen zijn. Het biedt waardevolle context voor het begrijpen van de bedrijfsimpact van incidenten en kan helpen fixes te prioriteren die kritieke afdelingen beïnvloeden. Waarom het belangrijk is Het biedt business context, waardoor analyse mogelijk is van incidenttrends en impact op specifieke afdelingen. Waar te verkrijgen Deze informatie is gekoppeld aan de aanvrager van het ticket. Het kan worden opgehaald via het 'Requesters' API-endpoint met behulp van de 'requester_id' van het ticket, waarna de 'department_id' en naam kunnen worden benaderd. Voorbeelden VerkoopMarketingFinanciënHuman Resources
	Doorlooptijd Oplossing ResolutionCycleTime	De totale doorlooptijd vanaf het moment dat een incident voor het eerst werd gemeld tot het moment dat het werd opgelost.
Beschrijving Doorlooptijd Oplossing is een key performance indicator die voor elk incident wordt berekend. Het meet de totale duur van het incident management proces vanuit het perspectief van de gebruiker, van de initiële melding tot de bevestiging van de oplossing. Deze berekende metric is de basis van het 'Incident Doorlooptijd Oplossing' dashboard. Het wordt gebruikt om de algehele procesefficiëntie te meten en wordt vaak geanalyseerd over verschillende dimensies zoals priority, category en agent. Het identificeren van incidenten met lange doorlooptijden helpt systemische vertragingen en inefficiënties aan te wijzen. Waarom het belangrijk is Het is een primaire maatstaf voor procesprestaties, die direct aangeeft hoe lang het duurt om incidenten van begin tot eind op te lossen. Waar te verkrijgen Dit is een berekende metriek. Het is het verschil tussen de timestamp van de activiteit 'Incident Opgelost' en de activiteit 'Incident Gemeld'. Voorbeelden 259200000864000003600000
	Handoff Count HandoffCount	Het aantal keren dat een incident werd overgedragen tussen verschillende agents of groepen.
Beschrijving Handoff Count is een berekende metric die het aantal hernieuwde toewijzingen kwantificeert dat een incident ondergaat gedurende zijn levenscyclus. Elke verandering in het 'AssignedAgent' of 'AssignedGroup' attribute verhoogt deze teller. Een hoge handoff count is vaak een indicator van procesinefficiëntie, onjuiste initiële routering of een gebrek aan expertise van agents. Deze metric ondersteunt direct de 'Incident Handoff Count' KPI en het 'Handoff And Transfer Delay Analysis' dashboard, en helpt bij het identificeren van incidenten of procespaden met buitensporige overdrachten die leiden tot vertragingen. Waarom het belangrijk is Het kwantificeert herwerk en hertoewijzingen, wat helpt bij het identificeren van inefficiënties veroorzaakt door onjuiste routering of kennisleemtes. Waar te verkrijgen Dit is een berekende metriek, afgeleid door het tellen van het aantal unieke waarden of wijzigingen in de velden 'AssignedAgent' of 'AssignedGroup' gedurende de levenscyclus van één enkel incident. Voorbeelden 0125
	Is Heropend IsReopened	Een berekende vlag die 'waar' is als een incident is heropend nadat het was opgelost of gesloten.
Beschrijving Dit booleaanse attribuut is een berekende vlag die incidenten identificeert die zijn heropend. Het wordt ingesteld op 'waar' als een incident, na het bereiken van de status 'Resolved' of 'Closed', de status weer wordt gewijzigd naar een open of 'in uitvoering'-status. Deze vlag is kritiek voor het berekenen van de KPI 'Heropeningspercentage Incidenten' en voor het dashboard 'Terugkerende Incidenten'. Een hoog percentage heropende incidenten kan duiden op problemen met de kwaliteit van de initiële oplossing, onvolledige hoofdoorzaakanalyse of voortijdige sluiting. Het analyseren van deze gevallen helpt de kwaliteit en duurzaamheid van fixes te verbeteren. Waarom het belangrijk is Het identificeert falen in het oplossingsproces, waarbij incidenten worden belicht waarbij de initiële fix ineffectief was en resulteerde in herwerk. Waar te verkrijgen Dit is een berekend veld, afgeleid van de sequentie van activiteiten in het event log. Het is 'waar' als een activiteit zoals 'Incident Heropend' optreedt of als een activiteit in open status volgt op een activiteit in gesloten status voor dezelfde Incident ID. Voorbeelden truefalse
	Is SLA Geschonden IsSlaBreached	Een berekende vlag die 'waar' is als het incident niet binnen de gedefinieerde SLA-doeltijd is opgelost.
Beschrijving Dit booleaanse attribuut is een berekende metriek die aangeeft of de oplossingstijd van een incident de SLA-doelstelling heeft overschreden. Het wordt afgeleid door de daadwerkelijke oplossingstimestamp te vergelijken met het veld 'ResolutionSlaTargetTime'. Deze vlag is een directe input voor de KPI 'SLA-Nalevingspercentage' en het 'SLA-Prestatiedashboard'. Het vereenvoudigt de analyse door een duidelijk, binair resultaat te bieden voor de SLA-prestaties van elk incident, waardoor eenvoudige aggregatie en trendanalyse mogelijk is. Het helpt snel het volume en percentage incidenten te identificeren die niet voldoen aan de serviceafspraken. Waarom het belangrijk is Het meet direct de SLA-compliance voor elk incident, waardoor het eenvoudig is om de algehele nalevingspercentages te berekenen en probleemgebieden te identificeren. Waar te verkrijgen Dit is een berekend veld, afgeleid tijdens datatransformatie door de timestamp van 'Incident Opgelost' te vergelijken met het veld 'ResolutionSlaTargetTime'. Voorbeelden truefalse
	Rapportagekanaal ReportingChannel	De methode of het kanaal waardoor het incident werd gemeld, zoals E-mail, Portaal of Telefoon.
Beschrijving Het Meldingskanaal, ook bekend als de bron, identificeert hoe een incident in het supportsysteem terechtkwam. Veelvoorkomende kanalen zijn e-mail, een self-service portaal, telefoongesprekken of chat. Het analyseren van dit attribuut helpt de efficiëntie van verschillende meldingskanalen te evalueren. Het 'Efficiëntie van Meldingskanalen' dashboard vergelijkt het incidentvolume en de gemiddelde oplostijd per kanaal om te bepalen welke methoden het meest effectief zijn en welke mogelijk procesverbeteringen vereisen. Bijvoorbeeld, incidenten die via het portaal zijn gemeld, kunnen sneller worden opgelost als ze vanaf het begin meer gestructureerde informatie bevatten. Waarom het belangrijk is Het helpt de meest efficiënte rapportagekanalen te identificeren en onthult kansen om het incidentintakeproces te verbeteren. Waar te verkrijgen Beschikbaar in de Freshservice Tickets API als het source veld. De waarden zijn numeriek. Voorbeelden E-mailPortalTelefoonChat
	Root Cause RootCause	De onderliggende oorzaak of hoofdoorzaak die na onderzoek voor het incident is geïdentificeerd.
Beschrijving Het attribuut 'Hoofdoorzaak' legt het fundamentele probleem vast dat tot het incident heeft geleid. Deze informatie wordt doorgaans door supportmedewerkers ingevuld tijdens of na de oplossing, als onderdeel van een hoofdoorzaakanalyse (RCA)-proces. Dit attribuut is cruciaal voor het dashboard 'Terugkerende Incidenten en Hoofdoorzaken' en de KPI 'Voltooiingspercentage Hoofdoorzaakanalyse'. Door veelvoorkomende hoofdoorzaken te analyseren, kunnen organisaties overstappen van het reactief oplossen van incidenten naar proactief probleembeheer, door permanente oplossingen te implementeren om toekomstige incidenten te voorkomen en terugkerende problemen te verminderen. Waarom het belangrijk is Het maakt proactief probleemmanagement mogelijk door te helpen de onderliggende oorzaken van terugkerende incidenten te identificeren en elimineren. Waar te verkrijgen Dit is vaak een custom field in Freshservice, aangezien de standaard functionaliteit beperkt kan zijn. Controleer de 'Ticket Fields' configuratie voor een field met de naam 'Root Cause' of iets soortgelijks. Voorbeelden SoftwarebugNetwerkconfiguratiefoutProbleem met gebruikerstrainingHardwarestoring
	Workaround Geboden WorkaroundProvided	Een vlag die aangeeft of een tijdelijke workaround aan de gebruiker is aangeboden vóór de definitieve oplossing.
Beschrijving Dit booleaanse attribuut geeft aan of een tijdelijke fix of workaround is geïmplementeerd om de impact van het incident te mitigeren terwijl een permanente oplossing werd ontwikkeld. Dit wordt vaak bijgehouden via een checkbox of een specifieke status. In process mining ondersteunt dit attribuut het dashboard 'Workaround Effectiviteitsmetrieken'. Het maakt een vergelijking mogelijk van oplossingstijden voor incidenten met en zonder workarounds, en helpt te bepalen of het bieden van tijdelijke fixes de bedrijfsverstoring effectief vermindert en bijdraagt aan een snellere algehele oplossing vanuit het perspectief van de gebruiker. Waarom het belangrijk is Het helpt de effectiviteit van tijdelijke workarounds te meten bij het verminderen van de impact van incidenten en het versnellen van de waargenomen oplossing. Waar te verkrijgen Dit is doorgaans een custom boolean (checkbox) field. Het bestaan ervan moet worden geverifieerd in de Freshservice 'Ticket Fields' configuratie. Voorbeelden truefalse

Verplicht Aanbevolen Optioneel

Incident Management-activiteiten

Dit zijn de belangrijkste stappen en mijlpalen die je in je event log vastlegt voor een goede process discovery en het opsporen van knelpunten.

7 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Incident Afgesloten	Vertegenwoordigt de definitieve, formele sluiting van het incidentrecord. Dit gebeurt doorgaans automatisch na een bepaalde periode in de status 'Resolved', of kan handmatig door een agent worden gedaan. Dit event markeert het einde van de levenscyclus van het incident.
Waarom het belangrijk is Deze activiteit is het definitieve eindpunt van het proces. De totale tijd tot dit event vertegenwoordigt de volledige doorlooptijd van de incidentlevenscyclus, inclusief eventuele gebruikersbevestigingsperioden. Waar te verkrijgen Afgeleid uit het activity log van het incident door te identificeren wanneer het veld 'Status' wordt bijgewerkt naar 'Closed'. Vastleggen Gebruik de timestamp uit de activity log entry voor de statuswijziging naar 'Gesloten'. Gebeurtenistype inferred
	Incident Gemeld	Markeert de creatie van een nieuw incidentrecord in Freshservice. Dit is het startpunt van de incident-lifecycle, doorgaans getriggerd door een eindgebruiker via een portaal, e-mail, of een servicedeskagent die namens hen een ticket aanmaakt. Deze event wordt expliciet gelogd met een creation timestamp.
Waarom het belangrijk is Deze activiteit is het primaire startevent voor het gehele proces. Het analyseren van de tijd vanaf dit event tot aan de oplossing is fundamenteel voor het meten van de algemene doorlooptijden en SLA-naleving. Waar te verkrijgen Vastgelegd vanuit de creatie-timestamp van de incidenttabel. Freshservice legt dit expliciet vast voor elk nieuw ticket. Vastleggen Gebruik de 'Created at' timestamp van het hoofd incident record. Gebeurtenistype explicit
	Incident Geprioriteerd	Vindt plaats wanneer de prioriteit van het incident wordt ingesteld of bijgewerkt. Het prioriteitsniveau bepaalt de urgentie en de SLA-doelen voor de oplossing. Dit wordt vastgelegd door wijzigingen in het veld 'Priority' binnen de incidentgeschiedenis te monitoren.
Waarom het belangrijk is Onjuiste of vertraagde prioritering kan leiden tot SLA-schendingen en inefficiënte middelentoewijzing. Het analyseren van deze activiteit helpt ervoor te zorgen dat kritieke incidenten onmiddellijke aandacht krijgen. Waar te verkrijgen Afgeleid uit het activity log van het incident, dat alle updates van het veld 'Prioriteit' volgt. Vastleggen Gebruik timestamps uit de audit log waar de 'Priority' field value werd ingesteld of gewijzigd. Gebeurtenistype inferred
	Incident Opgelost	Markeert het punt waarop de agent een fix heeft geïmplementeerd en het incident als opgelost beschouwt. Dit wordt vastgelegd wanneer de status van het incident wordt gewijzigd naar 'Resolved'. In Freshservice is dit een belangrijke mijlpaal die de SLA-klok stopt.
Waarom het belangrijk is Dit is een cruciale mijlpaal voor het meten van Time to Resolution (TTR). De periode tussen 'Opgelost' en 'Gesloten' is belangrijk voor het analyseren van vertragingen in gebruikersbevestigingen en beleid voor automatische sluiting. Waar te verkrijgen Afgeleid uit het activity log van het incident door te identificeren wanneer het veld 'Status' wordt bijgewerkt naar 'Resolved'. Vastleggen Gebruik de timestamp uit de activity log entry voor de statuswijziging naar 'Opgelost'. Gebeurtenistype inferred
	Incident toegewezen aan groep	Vertegenwoordigt de initiële toewijzing van een incident aan een supportgroep. Dit kan automatisch gebeuren via routeringsregels of handmatig door een dispatcher. Deze activiteit wordt vastgelegd door de initiële vulling van het veld 'Group' in de audit log van het incident te volgen.
Waarom het belangrijk is Het tracken van toewijzingen is cruciaal voor het meten van first-response times en het identificeren van bottlenecks in het dispatching process. Het helpt analyseren hoe efficiënt incidents naar het juiste team worden geleid. Waar te verkrijgen Afgeleid uit de eerste entry in het activity log van het incident die het veld 'Group' vult of wijzigt. Vastleggen Identificeer de eerste timestamp waarop het veld 'Group' is gevuld voor een incident. Gebeurtenistype inferred
	Oplossingsnotitie Toegevoegd	Vindt plaats wanneer een agent de oplossing van het incident documenteert door een oplossingsnotitie toe te voegen. Dit is een aparte actie in Freshservice voordat de status wordt gewijzigd in 'Resolved'. Deze actie en de inhoud ervan worden expliciet gelogd.
Waarom het belangrijk is Dit markeert de identificatie van een oplossing. De tijd tussen dit en de status 'Incident Opgelost' kan wijzen op interne review of documentatie overhead. Waar te verkrijgen Vastgelegd vanuit de timestamp van een oplossingsnotitie aan het incident, geregistreerd in de conversatiegeschiedenis. Vastleggen Identificeer de timestamp van de 'Resolution Note' vermelding in het gesprekslogboek van het incident. Gebeurtenistype explicit
	Status gewijzigd naar 'In behandeling'	Deze activiteit markeert de officiële start van actief onderzoek en werkzaamheden aan het incident. Het wordt vastgelegd wanneer een agent de status van het incident wijzigt naar 'In Progress'. Dit is een standaard statuswijziging die wordt vastgelegd in de activiteitengeschiedenis van het ticket.
Waarom het belangrijk is Deze mijlpaal helpt onderscheid te maken tussen wachttijd en actieve werktijd. Het analyseren van de duur dat een incident de status 'In Behandeling' heeft, is cruciaal voor het begrijpen van de oplossingsinspanning. Waar te verkrijgen Afgeleid uit het activity log van het incident door te identificeren wanneer het veld 'Status' wordt bijgewerkt naar 'In Progress'. Vastleggen Filter de activity log op een statuswijziging naar 'In Progress' en gebruik de bijbehorende timestamp. Gebeurtenistype inferred
	Agent toegewezen aan incident	Deze activiteit markeert wanneer een specifieke agent wordt toegewezen om het incident af te handelen. Het duidt op individueel eigenaarschap van het ticket. De toewijzing wordt vastgelegd in de activiteitengeschiedenis van het ticket, waarbij wordt getoond welke agent is toegewezen en wanneer.
Waarom het belangrijk is Dit maakt analyse mogelijk van de werkdruk, prestaties van agenten en de tijd die nodig is om een incident door een individu op te pakken na groepstoewijzing. Het is cruciaal voor dashboards voor agentprestaties. Waar te verkrijgen Bijgehouden via wijzigingen in het 'Agent' field in het activity log of audit trail van het incident. Vastleggen Identificeer timestamps die overeenkomen met wijzigingen in het veld 'Agent'. Gebeurtenistype inferred
	Eerste Reactie Verzonden	Deze activiteit vertegenwoordigt de eerste communicatie van een agent met de gebruiker nadat het incident is gemeld. Dit kan een openbare notitie of een direct antwoord zijn. Freshservice registreert alle communicatie van agenten met timestamps.
Waarom het belangrijk is Het voldoen aan de First Response SLA is een kritieke KPI voor klanttevredenheid. Deze activiteit maakt de meting en analyse mogelijk van hoe snel agents nieuwe incidenten oppakken. Waar te verkrijgen Geïdentificeerd door de timestamp te vinden van de eerste openbare notitie of reactie toegevoegd door een agent in het gesprekslogboek van het incident. Vastleggen Filter de gesprekshistorie van het incident op de vroegste invoer gedaan door een agent. Gebeurtenistype explicit
	Incident Heropend	Vindt plaats wanneer een incident dat eerder als 'Resolved' was gemarkeerd, wordt teruggezet naar een open status, meestal doordat de gebruiker het niet eens is met de oplossing. Dit wordt afgeleid uit een statuswijziging van 'Resolved' terug naar een status zoals 'Open' of 'In Progress'.
Waarom het belangrijk is Een hoge heropeningsgraad wijst op problemen met de oplossingskwaliteit of onvolledige oplossingen. Dit is een belangrijke metriek voor het analyseren van herwerk en de agentprestaties. Waar te verkrijgen Afgeleid uit het activity log van het incident door een statuswijziging te detecteren van 'Resolved' naar een actieve status. Vastleggen Filter de activity log op een 'Status' wijziging van 'Resolved' naar 'Open' of 'In Progress'. Gebeurtenistype inferred
	Incident Herverdeeld	Geeft aan dat het incident is overgedragen van de ene agent of groep naar de andere. Dit duidt op een handoff in het oplossingsproces. Deze event wordt afgeleid door het detecteren van opeenvolgende wijzigingen in de velden 'Agent' of 'Group' na de initiële toewijzing.
Waarom het belangrijk is Frequente hernieuwde toewijzingen of overdrachten duiden vaak op procesinefficiënties, kennisleemtes of onjuiste initiële routering. Het analyseren van deze events helpt bij het identificeren en verminderen van vertragingen. Waar te verkrijgen Afgeleid uit het activity log van het incident door elke wijziging in de velden 'Agent' of 'Group' te volgen na de eerste toewijzing. Vastleggen Detecteer veranderingen in de velden 'Agent' of 'Group' in de audithistorie van het ticket. Gebeurtenistype inferred
	SLA-doelstelling overschreden	Dit is een berekende event die optreedt wanneer de verstreken tijd voor een incident de gedefinieerde SLA-doelstelling voor reactie of oplossing overschrijdt. Freshservice houdt intern de SLA-status bij en dit event kan worden afgeleid door timestamps te vergelijken met SLA-beleid.
Waarom het belangrijk is Meet direct de compliance met servicelevelafspraken. Vaststellen wanneer en waarom schendingen optreden is essentieel voor het SLA Performance Dashboard en continue verbetering. Waar te verkrijgen Berekend door de oplossing- of reactietijd te vergelijken met de SLA-doeltijd. Freshservice markeert tickets vaak als 'SLA Overtreden'. Vastleggen Afleiden door de 'Resolved at' timestamp te vergelijken met de 'Due by' timestamp, of wanneer het veld 'SLA Status' verandert in 'Violated'. Gebeurtenistype calculated
	Status gewijzigd naar 'In afwachting'	Vertegenwoordigt een punt waarop het oplossingsproces wordt gepauzeerd, meestal in afwachting van informatie van de gebruiker of een derde partij. Dit wordt afgeleid uit een statuswijziging naar een 'Pending' status. De tijd die in deze status wordt doorgebracht, wordt vaak uitgesloten van SLA-berekeningen.
Waarom het belangrijk is Het identificeren van de tijd die wordt besteed in wachtstatussen is cruciaal voor het begrijpen van externe afhankelijkheden en vertragingen. Het helpt de werktijd van de agent te scheiden van de wachttijd. Waar te verkrijgen Afgeleid uit het activity log van het incident wanneer het veld 'Status' wordt bijgewerkt naar een waarde zoals 'Pending' of 'Awaiting User Response'. Vastleggen Filter de activity log op statuswijzigingen naar een wachtstatus en gebruik de bijbehorende timestamp. Gebeurtenistype inferred
	Workaround Geboden	Deze activiteit geeft aan dat een tijdelijke oplossing of workaround is gecommuniceerd naar de gebruiker om de impact van het incident te mitigeren. Het vastleggen hiervan vereist vaak specifieke systeemconfiguratie, zoals een specifieke checkbox, een bepaald notitietype, of trefwoordanalyse in agentnotities.
Waarom het belangrijk is Dit helpt bij het analyseren van de effectiviteit van workarounds bij het verminderen van de bedrijfsimpact en hun relatie tot de uiteindelijke oplossingstijd. Het ondersteunt het dashboard 'Workaround Effectiviteitsmetrieken'. Waar te verkrijgen Dit is waarschijnlijk geen expliciete event. Het kan worden afgeleid door notities met keywords zoals 'workaround' te markeren, of als een custom 'Workaround Provided' checkbox field wordt gebruikt en de wijziging daarvan wordt gelogd. Vastleggen Afgeleid uit een wijziging in een custom field of keyword-analyse van agentnotities. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractie Guides

Hoe u uw data uit Freshservice haalt

Stappen

Toegang tot Freshservice Analytics: Log in op uw Freshservice-instantie met een account dat machtigingen heeft om rapporten te openen en te maken. Navigeer vanuit het hoofdmenu naar de Analytics-module.
Nieuw Rapport Maken: Klik op de knop Nieuw Rapport. Geef een beschrijvende naam op, zoals "Incident Management Event Log". Selecteer de Incident Management-module wanneer u wordt gevraagd een databron te kiezen.
Rapport Widget Selecteren: Voeg in de rapporteditor een nieuwe widget toe en selecteer het Tabel-type. Dit vormt de basis van uw event log data.
Primaire Datakolommen Toevoegen: Sleep vanuit het databronpaneel aan de rechterkant de benodigde velden naar de kolomconfiguratie van de tabel. Begin met Incident ID, Created at, Agent, Group, Priority, Severity, Status en Category.
Activiteitsdata Opnemen: Om individuele events vast te leggen, moet u data uit de ticketactiviteiten samenvoegen of opnemen. Voeg de Activities databron toe aan uw widget. Voeg uit deze bron Performed at (voor de event timestamp) en Activity description of vergelijkbare velden toe die de verandering beschrijven die heeft plaatsgevonden.
Berekende 'ActivityName'-kolom Maken: Dit is de meest cruciale stap. Maak een nieuwe berekende kolom of formuleveld. Gebruik geneste IF-statements of een CASE-functie om ruwe activiteitsdata te vertalen naar de vereiste ActivityName waarden. Zie de Query-sectie voor de gedetailleerde logica voor elk van de 14 activiteiten.
'EventTimestamp' Configureren: Maak een andere berekende kolom voor de EventTimestamp. De logica voor deze kolom moet de Created at timestamp selecteren voor de 'Incident Reported' activiteit en de Performed at timestamp van de activiteit voor alle andere events.
Rapportfilters Toepassen: Configureer de rapportfilters om de data te verfijnen. Stel minimaal een datumbereikfilter in op het 'Created at' veld. Een bereik van de laatste 3 tot 6 maanden wordt aanbevolen. U moet ook een filter toevoegen om alleen tickets op te nemen waar 'Ticket Type' 'Incident' is.
Rapport Uitvoeren en Verfijnen: Voer het rapport uit om een preview van de data te genereren. Controleer de output om te garanderen dat de ActivityName en EventTimestamp kolommen correct worden gevuld. Pas formules en filters aan indien nodig.
Rapport Opslaan en Exporteren: Zodra u tevreden bent met de output van het rapport, slaat u het op. Gebruik de Export optie en selecteer CSV als formaat.
Export Plannen (Optioneel): Voor doorlopende analyse kunt u het rapport plannen om automatisch uit te voeren en te exporteren. Stel een schema in (bijv. dagelijks of wekelijks) om de CSV naar uw e-mail of een andere bestemming te laten bezorgen.
Data Voorbereiden voor Upload: Open het geëxporteerde CSV-bestand. Hernoem de kolomheaders zodat ze overeenkomen met het vereiste schema voor ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Voeg de statische kolommen SourceSystem (met de waarde 'Freshservice') en LastDataUpdate (met de huidige timestamp) toe. Het bestand is nu klaar voor upload.

Configuratie

Analytics Module: Voor deze extractie is toegang tot de Freshservice Analytics-module nodig, die beschikbaar is in hogere abonnementen (bijv. Pro, Enterprise).
Vereiste Machtigingen: Uw gebruikersaccount heeft een rol nodig met machtigingen om rapporten te maken, bewerken en uit te voeren in de Analytics-module.
Datumbereik: Het is cruciaal om een datumbereikfilter in te stellen op de aanmaakdatum van het incident om het datavolume te beheren. Een voortschrijdende periode van 3-6 maanden wordt aanbevolen voor een balans tussen historische context en prestaties.
Rapportfilters: Filter altijd op 'Ticket Type' is 'Incident' om serviceaanvragen of andere tickettypes uit te sluiten van uw procesanalyse.
Berekende Velden: Deze methode is sterk afhankelijk van het gebruik van berekende velden (formules) om de ActivityName en EventTimestamp voor elke event af te leiden. Bekendheid met de Freshservice formule-editor is nuttig.
Datavolume: Wees u ervan bewust dat voor elk incident deze extractie meerdere rijen (één voor elke activity) genereert. Voor grote Freshservice-instanties kan het resulterende CSV-bestand erg groot worden, wat de rapportgeneratietijd en exportsnelheid beïnvloedt.

a Voorbeeldquery config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Stappen

Vereisten: Zorg ervoor dat u Python 3.6+ heeft geïnstalleerd, samen met de requests en pandas bibliotheken. U kunt deze installeren met pip: pip install requests pandas.
API-sleutel genereren: Log in op uw Freshservice-instantie als beheerder. Ga naar uw Profielinstellingen door op uw profielfoto in de rechterbovenhoek te klikken. Ga naar de sectie 'API Key' en kopieer uw persoonlijke API-sleutel. Behandel deze sleutel als een wachtwoord.
Script instellen: Sla de meegeleverde Python-code op in een bestand genaamd extract_freshservice_incidents.py op uw lokale machine.
Parameters configureren: Open het scriptbestand in een teksteditor. Werk de placeholderwaarden bij voor FRESHSERVICE_DOMAIN (bijv. 'yourcompany.freshservice.com'), API_KEY (de sleutel die u zojuist hebt gekopieerd) en START_DATE_STR (het begin van uw gewenste extractieperiode in 'JJJJ-MM-DD-formaat').
Scriptlogica begrijpen: Het script haalt eerst alle incidenttickets op die zijn aangemaakt na de opgegeven startdatum. Het doorloopt elke pagina met resultaten die door de API worden geretourneerd. Voor elk ticket maakt het een tweede API-aanroep om de gedetailleerde activity log op te halen.
Event Log genereren: Het script verwerkt de kerndata van het ticket en de activity log om records te identificeren en aan te maken voor elk van de 14 vereiste bedrijfsactiviteiten. Bijvoorbeeld, 'Incident Reported' wordt gebaseerd op de aanmaakdatum van het ticket, terwijl 'Status Changed to In Progress' is afgeleid van een specifieke vermelding in de activity log.
Complexe events afleiden: Events zoals 'SLA Target Breached' worden afgeleid. Het script controleert of de resolution SLA van een ticket is geschonden. Indien dit het geval is, creëert het een event met als timestamp de due_by-datum, wat het moment markeert waarop de schending plaatsvond.
Script uitvoeren: Open een terminal of opdrachtprompt, navigeer naar de map waarin u het script hebt opgeslagen en voer het uit met het commando: python extract_freshservice_incidents.py.
Uitvoering monitoren: Het script print voortgangsupdates naar de console, waarin wordt getoond hoeveel tickets zijn verwerkt. Afhankelijk van het aantal tickets en API rate limits, kan dit enige tijd duren.
Output controleren: Zodra het script is voltooid, genereert het een CSV-bestand genaamd freshservice_incident_event_log.csv in dezelfde map. Dit bestand bevat de complete event log.
Voorbereiden op uploaden: Open het CSV-bestand in een spreadsheetprogramma om te controleren of de kolommen (IncidentId, ActivityName, EventTimestamp, etc.) zoals verwacht zijn ingevuld. Het bestand is nu klaar voor upload naar ProcessMind of een andere process mining tool.

Configuratie

FRESHSERVICE_DOMAIN: Uw bedrijfsspecifieke Freshservice URL, bijvoorbeeld mycompany.freshservice.com. Dit is een vereiste parameter in het script.
API_KEY: De persoonlijke API-sleutel voor een gebruiker met voldoende machtigingen om alle incidentdata te lezen. Dit is een vereiste parameter.
START_DATE_STR: De startdatum voor de data-extractie in 'YYYY-MM-DD' formaat. Het wordt aanbevolen om een initiële periode van 3-6 maanden aan data te extraheren voor zinvolle analyse.
PAGE_SIZE: Ingesteld op 100, het maximum toegestaan door de Freshservice API, om het aantal API-aanroepen te minimaliseren en de prestaties te verbeteren. Het wordt over het algemeen niet aanbevolen om deze waarde te wijzigen.
API Rate Limiting: Het script bevat een standaard time.sleep(1) aanroep na het verwerken van elk ticket om de API-snelheidslimieten van Freshservice te respecteren. Voor high-volume instanties is het mogelijk nodig dit aan te passen om fouten te voorkomen.
Required Permissions: De gebruikte API-sleutel moet toebehoren aan een gebruikersaccount (bijv. een dedicated serviceaccount) met ten minste 'SD Agent' rolmachtigingen om te garanderen dat alle benodigde ticketvelden en activity logs in verschillende servicedesk-groepen toegankelijk zijn.

a Voorbeeldquery python

import requests
import pandas as pd
import time
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[your_api_key]"
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD)
START_DATE_STR = class="hl-string">"2023-01-01"

class=class="hl-string">"hl-comment"># --- Constants ---
BASE_URL = fclass="hl-string">"https протокол://{FRESHSERVICE_DOMAIN}/api/v2"
PAGE_SIZE = 100
OUTPUT_FILENAME = class="hl-string">"freshservice_incident_event_log.csv"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def create_event(incident_id, activity_name, event_timestamp, ticket_data, source_system, last_data_update):
    class="hl-string">"""Helper function to create a structured event dictionary."""
    class=class="hl-string">"hl-comment"># Use latest known values for attributes if available
    sla_policy = ticket_data.get(class="hl-string">'sla_policy', {})
    resolution_due = None
    if sla_policy and sla_policy.get(class="hl-string">'resolution_sla', {}):
        resolution_due = sla_policy.get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'due_by')

    return {
        class="hl-string">"IncidentId": incident_id,
        class="hl-string">"ActivityName": activity_name,
        class="hl-string">"EventTimestamp": event_timestamp,
        class="hl-string">"SourceSystem": source_system,
        class="hl-string">"LastDataUpdate": last_data_update,
        class="hl-string">"AssignedAgent": ticket_data.get(class="hl-string">'responder_id'),
        class="hl-string">"AssignedGroup": ticket_data.get(class="hl-string">'group_id'),
        class="hl-string">"IncidentPriority": ticket_data.get(class="hl-string">'priority'),
        class="hl-string">"IncidentSeverity": ticket_data.get(class="hl-string">'impact'), class=class="hl-string">"hl-comment"># Impact is often used for Severity
        class="hl-string">"IncidentStatus": ticket_data.get(class="hl-string">'status'),
        class="hl-string">"IncidentCategory": ticket_data.get(class="hl-string">'category'),
        class="hl-string">"ResolutionSlaTargetTime": resolution_due
    }

def get_all_tickets(session, start_date):
    class="hl-string">"""Fetches all tickets from Freshservice updated since the start date, handling pagination."""
    tickets = []
    page = 1
    while True:
        params = {
            class="hl-string">"updated_since": start_date + class="hl-string">"T00:00:00Z",
            class="hl-string">"per_page": PAGE_SIZE,
            class="hl-string">"page": page,
            class="hl-string">"order_type": class="hl-string">"asc" class=class="hl-string">"hl-comment"># Process tickets in chronological order
        }
        try:
            response = session.get(fclass="hl-string">"{BASE_URL}/tickets", params=params)
            response.raise_for_status()
            data = response.json().get(class="hl-string">"tickets", [])
            if not data:
                break
            tickets.extend(data)
            print(fclass="hl-string">"Fetched page {page}, {len(data)} tickets...")
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return tickets

def get_ticket_activities(session, ticket_id):
    class="hl-string">"""Fetches all activities (audit log) for a specific ticket."""
    try:
        response = session.get(fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/activities")
        response.raise_for_status()
        return response.json().get(class="hl-string">"activities", [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching activities for ticket {ticket_id}: {e}")
        return []

def main():
    class="hl-string">"""Main function to run the extraction process."""
    session = requests.Session()
    session.auth = (API_KEY, class="hl-string">'X') class=class="hl-string">"hl-comment"># class="hl-string">'X' is a placeholder password
    session.headers.update({class="hl-string">'Content-Type': class="hl-string">'application/json'})

    last_data_update = datetime.datetime.now(datetime.timezone.utc).isoformat()
    source_system = class="hl-string">'Freshservice'
    event_log = []

    print(class="hl-string">"Starting Freshservice incident extraction...")
    all_tickets = get_all_tickets(session, START_DATE_STR)
    print(fclass="hl-string">"Total tickets to process: {len(all_tickets)}")

    for i, ticket in enumerate(all_tickets):
        incident_id = ticket[class="hl-string">'id']
        print(fclass="hl-string">"Processing ticket {i+1}/{len(all_tickets)}: ID {incident_id}")

        class=class="hl-string">"hl-comment"># 1. Incident Reported
        event_log.append(create_event(incident_id, class="hl-string">"Incident Reported", ticket[class="hl-string">'created_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Fetch detailed activities for more events
        activities = get_ticket_activities(session, incident_id)
        
        assigned_group_done = False
        agent_assigned_done = False
        first_response_done = False

        for activity in sorted(activities, key=lambda x: x[class="hl-string">'performed_at']):
            activity_ts = activity[class="hl-string">'performed_at']
            class=class="hl-string">"hl-comment"># 2. Incident Assigned to Group (first occurrence)
            if not assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Assigned to Group", activity_ts, ticket, source_system, last_data_update))
                assigned_group_done = True
            
            class=class="hl-string">"hl-comment"># 3. Agent Assigned to Incident (first occurrence)
            if not agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Agent Assigned to Incident", activity_ts, ticket, source_system, last_data_update))
                agent_assigned_done = True

            class=class="hl-string">"hl-comment"># 4. Incident Prioritized
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'priority' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Prioritized", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 5. First Response Sent (first public note by an agent)
            if not first_response_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'private') is False and activity.get(class="hl-string">'performer_type') == class="hl-string">'User':
                event_log.append(create_event(incident_id, class="hl-string">"First Response Sent", activity_ts, ticket, source_system, last_data_update))
                first_response_done = True

            class=class="hl-string">"hl-comment"># 6. Incident Reassigned (subsequent assignments)
            if (assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {})) or \
               (agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {})):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Reassigned", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># Status Changes
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'status' in activity.get(class="hl-string">'changes', {}):
                new_status = activity[class="hl-string">'changes'][class="hl-string">'status'][1]
                class=class="hl-string">"hl-comment"># 7. Status Changed to In Progress
                if new_status == 3: class=class="hl-string">"hl-comment"># Assuming 3 is class="hl-string">'In Progress'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to In Progress", activity_ts, ticket, source_system, last_data_update))
                class=class="hl-string">"hl-comment"># 8. Status Changed to Pending
                elif new_status == 6: class=class="hl-string">"hl-comment"># Assuming 6 is class="hl-string">'Pending'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to Pending", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 9. Workaround Provided (Keyword search in notes)
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and class="hl-string">'workaround' in activity.get(class="hl-string">'note', {}).get(class="hl-string">'body_text', class="hl-string">'').lower():
                event_log.append(create_event(incident_id, class="hl-string">"Workaround Provided", activity_ts, ticket, source_system, last_data_update))
            
            class=class="hl-string">"hl-comment"># 10. Resolution Note Added
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'note_type') == class="hl-string">'resolution':
                event_log.append(create_event(incident_id, class="hl-string">"Resolution Note Added", activity_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 11. Incident Resolved
        if ticket.get(class="hl-string">'resolved_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Resolved", ticket[class="hl-string">'resolved_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 12. SLA Target Breached
        if ticket.get(class="hl-string">'sla_policy') and ticket[class="hl-string">'sla_policy'].get(class="hl-string">'violation_details', {}).get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'is_violated'):
            breach_time = ticket[class="hl-string">'sla_policy'][class="hl-string">'violation_details'][class="hl-string">'resolution_sla'][class="hl-string">'due_by']
            event_log.append(create_event(incident_id, class="hl-string">"SLA Target Breached", breach_time, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 13. Incident Reopened
        if ticket.get(class="hl-string">'reopened'):
            class=class="hl-string">"hl-comment"># Finding the exact reopened timestamp can be tricky, we approximate from class="hl-string">'stats'
            reopen_ts = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at', ticket[class="hl-string">'updated_at'])
            event_log.append(create_event(incident_id, class="hl-string">"Incident Reopened", reopen_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 14. Incident Closed
        if ticket.get(class="hl-string">'closed_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Closed", ticket[class="hl-string">'closed_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Be respectful of API rate limits
        time.sleep(1)

    class=class="hl-string">"hl-comment"># Convert to DataFrame and save
    if event_log:
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(OUTPUT_FILENAME, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events for {df['IncidentId'].nunique()} incidents.")
        print(fclass="hl-string">"Event log saved to {OUTPUT_FILENAME}")
    else:
        print(class="hl-string">"No events were generated.")

if __name__ == class="hl-string">"__main__":
    main()

Stappen

Toegang tot Freshservice Analytics: Log in op uw Freshservice-instantie met een account dat machtigingen heeft om rapporten te openen en te maken. Navigeer vanuit het hoofdmenu naar de Analytics-module.
Nieuw Rapport Maken: Klik op de knop Nieuw Rapport. Geef een beschrijvende naam op, zoals "Incident Management Event Log". Selecteer de Incident Management-module wanneer u wordt gevraagd een databron te kiezen.
Rapport Widget Selecteren: Voeg in de rapporteditor een nieuwe widget toe en selecteer het Tabel-type. Dit vormt de basis van uw event log data.
Primaire Datakolommen Toevoegen: Sleep vanuit het databronpaneel aan de rechterkant de benodigde velden naar de kolomconfiguratie van de tabel. Begin met Incident ID, Created at, Agent, Group, Priority, Severity, Status en Category.
Activiteitsdata Opnemen: Om individuele events vast te leggen, moet u data uit de ticketactiviteiten samenvoegen of opnemen. Voeg de Activities databron toe aan uw widget. Voeg uit deze bron Performed at (voor de event timestamp) en Activity description of vergelijkbare velden toe die de verandering beschrijven die heeft plaatsgevonden.
Berekende 'ActivityName'-kolom Maken: Dit is de meest cruciale stap. Maak een nieuwe berekende kolom of formuleveld. Gebruik geneste IF-statements of een CASE-functie om ruwe activiteitsdata te vertalen naar de vereiste ActivityName waarden. Zie de Query-sectie voor de gedetailleerde logica voor elk van de 14 activiteiten.
'EventTimestamp' Configureren: Maak een andere berekende kolom voor de EventTimestamp. De logica voor deze kolom moet de Created at timestamp selecteren voor de 'Incident Reported' activiteit en de Performed at timestamp van de activiteit voor alle andere events.
Rapportfilters Toepassen: Configureer de rapportfilters om de data te verfijnen. Stel minimaal een datumbereikfilter in op het 'Created at' veld. Een bereik van de laatste 3 tot 6 maanden wordt aanbevolen. U moet ook een filter toevoegen om alleen tickets op te nemen waar 'Ticket Type' 'Incident' is.
Rapport Uitvoeren en Verfijnen: Voer het rapport uit om een preview van de data te genereren. Controleer de output om te garanderen dat de ActivityName en EventTimestamp kolommen correct worden gevuld. Pas formules en filters aan indien nodig.
Rapport Opslaan en Exporteren: Zodra u tevreden bent met de output van het rapport, slaat u het op. Gebruik de Export optie en selecteer CSV als formaat.
Export Plannen (Optioneel): Voor doorlopende analyse kunt u het rapport plannen om automatisch uit te voeren en te exporteren. Stel een schema in (bijv. dagelijks of wekelijks) om de CSV naar uw e-mail of een andere bestemming te laten bezorgen.
Data Voorbereiden voor Upload: Open het geëxporteerde CSV-bestand. Hernoem de kolomheaders zodat ze overeenkomen met het vereiste schema voor ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Voeg de statische kolommen SourceSystem (met de waarde 'Freshservice') en LastDataUpdate (met de huidige timestamp) toe. Het bestand is nu klaar voor upload.

Configuratie

Analytics Module: Voor deze extractie is toegang tot de Freshservice Analytics-module nodig, die beschikbaar is in hogere abonnementen (bijv. Pro, Enterprise).
Vereiste Machtigingen: Uw gebruikersaccount heeft een rol nodig met machtigingen om rapporten te maken, bewerken en uit te voeren in de Analytics-module.
Datumbereik: Het is cruciaal om een datumbereikfilter in te stellen op de aanmaakdatum van het incident om het datavolume te beheren. Een voortschrijdende periode van 3-6 maanden wordt aanbevolen voor een balans tussen historische context en prestaties.
Rapportfilters: Filter altijd op 'Ticket Type' is 'Incident' om serviceaanvragen of andere tickettypes uit te sluiten van uw procesanalyse.
Berekende Velden: Deze methode is sterk afhankelijk van het gebruik van berekende velden (formules) om de ActivityName en EventTimestamp voor elke event af te leiden. Bekendheid met de Freshservice formule-editor is nuttig.
Datavolume: Wees u ervan bewust dat voor elk incident deze extractie meerdere rijen (één voor elke activity) genereert. Voor grote Freshservice-instanties kan het resulterende CSV-bestand erg groot worden, wat de rapportgeneratietijd en exportsnelheid beïnvloedt.

a Voorbeeldquery config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Data Template: Incident Management

Uw Incidentmanagement Data template

Incident Management-attributes

Incident Management-activiteiten

Extractie Guides

Freshservice Analytics Module Data Export to CSV

Stappen

Configuratie

a Voorbeeldquery config

Python Script Extractie via Freshservice REST API

Stappen

Configuratie

a Voorbeeldquery python

Realtime Data Push via Workflow Automator Webhooks.

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te starten?

Voorkom SLA-schendingen: Optimaliseer incidentbeheer vandaag nog