> Continue verbetering > Incidentbeheer > Freshservice > datatemplate

Je Incidentbeheer-datatemplate

Freshservice

Incidentbeheer Attributen (19) Incidentbeheer Activities (14) Extractiegidsen (3)

Je Incidentbeheer-datatemplate

Dit template is ontworpen om je te helpen je data voor te bereiden op effectieve analyse van incidentmanagement. Het schetst de essentiële attributen die verzameld moeten worden, de belangrijke activiteiten die gevolgd moeten worden, en biedt praktische richtlijnen voor het extraheren van deze Informatie uit je bronsysteem. Gebruik dit hulpmiddel om je datavoorbereiding process te vereenvoudigen.

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

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

Template downloaden

Incidentbeheer Attributen

Dit zijn de aanbevolen velden om op te nemen in je event log voor een grondige analyse van je incident management proces.

5 Verplicht 7 Aanbevolen 7 Optioneel

	Naam	Omschrijving
	Incident-ID IncidentId	De unieke ID voor elk incidentrecord, die dient als de primary key voor het volgen van de gehele incidentlevenscyclus.
Omschrijving De Incident-ID is de basis voor incidentbeheeranalyse. Het fungeert als de Case-ID, waarbij alle gerelateerde activiteiten, tijdstempels 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 belangrijk voor het berekenen van cyclustijden, het analyseren van procesvarianten en het vinden van knelpunten die specifiek zijn voor individuele cases. Zonder een unieke kenmerk zou het onmogelijk zijn om onderscheid te maken tussen verschillende incidenten en hun paden van melding tot oplossing te analyseren. Het belang Het identificeert elk incident uniek, waardoor end-to-end tracking en analyse van de levenscyclus mogelijk zijn van creatie tot afsluiting. Vindplaats Dit is de primaire kenmerk voor een ticket, beschikbaar via de Freshservice Tickets API als het 'id'-veld in het ticket-object. Voorbeelden INC-10234INC-10235INC-10236
	Activiteitsnaam ActivityName	De naam van de specifieke bedrijfsactiviteit of het gebeurtenis dat plaatsvond op een bepaald tijdsTip binnen de levenscyclus van het incident.
Omschrijving De Activiteitsnaam beschrijft een enkele stap of gebeurtenis 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 onmisbaar voor Process Mining, aangezien het de stappen in de bekijkte proceskaart definieert. Door de volgorde en frequentie van deze activiteiten te analyseren, kunnen organisaties het daadwerkelijke incidentafhandelingsproces visualiseren, gemeenschappelijke paden vinden, afwijkingen van de standaardprocedure detecteren en herstelwerk-loops zoals frequente herbezettingen opsporen. Het belang Het definieert de stappen in de proceskaart, waardoor visualisatie en analyse mogelijk zijn van de incidentoplossingsflow, knelpunten en afwijkingen. Vindplaats 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 opgehaald, doorgaans 'Freshservice'.
Omschrijving Dit attribuut identificeert de herkomst van de data. Hoewel het in deze context consequent 'Freshservice' zal zijn, is het een belangrijk veld in omgevingen waar data uit meerdere systemen kan worden gecombineerd voor een volledig procesoverzicht. Het opnemen van het attribuut 'Bronsysteem' is een best practice voor data-governance 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. Het belang Het zorgt voor datatraceerbaarheid en governance door de oorsprong van de incidentmanagementdata duidelijk te vinden. Vindplaats Dit is doorgaans een statische waarde die tijdens het datatransformatie (ETL)-proces wordt toegevoegd om de dataset te labelen. Voorbeelden FreshserviceFreshservice-EUFreshservice-PROD
	Tijdstempel EventTimestamp	De exacte datum en tijd wanneer de activiteit of het gebeurtenis plaatsvond.
Omschrijving 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 belangrijk voor alle tijdgerelateerde Process Mining-analyses. Het wordt gebruikt om gebeurtenissen 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. Het belang Het biedt de chronologische volgorde van gebeurtenissen, wat belangrijk is voor het berekenen van duur, het analyseren van doorlooptijden en het begrijpen van procesprestaties. Vindplaats Dit is afgeleid van diverse tijdstempelvelden in Freshservice, zoals 'created_at', 'updated_at' en tijdstempels binnen de conversatie of auditlogs van de ticket. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Tijdstip van extractie LastDataUpdate	De timestamp die aangeeft wanneer de data voor dit proces voor het voor het laatst is bijgewerkt of opgehaald.
Omschrijving 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 gebeurtenissen, maar het wordt vaak op gebeurtenisniveau opgenomen voor consistentie. In analyse is deze Informatie belangrijk voor het begrijpen van de relevantie 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. Het belang Het Informapakketmeert gebruikers over de relevantie van de data, waarbij wordt gezorgd dat zij de tijdsperiode begrijpen die door de analyse wordt bestreken. Vindplaats Dit is een metadata timestamp die wordt gegenereerd tijdens het data-extractieproces (ETL). Voorbeelden 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Incident prioriteit IncidentPriority	Het prioriteitsniveau van het incident, dat de urgentie van reactie en oplossing bepaalt.
Omschrijving 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 hoge prioriteit versus lage prioriteit incidenten te vergelijken, zodat kritieke problemen efficiënt worden afgehandeld. Dashboards segmenteren vaak meetwaarden zoals doorlooptijd en SLA-naleving per prioriteit om concrete inzichten te bieden aan supportmanagers. Het belang Het helpt de analyse te prioriteren op de meest kritieke incidenten en is belangrijk voor het ewaarderen van SLA-prestaties en middelentoewijzing. Vindplaats Beschikbaar in de Freshservice Tickets API als het priority-veld. De waarden zijn numeriek (bijv. 1 voor Laag, 4 voor Urgent). Voorbeelden LaagGemiddeldHoog`Urgent`
	Incident Severity IncidentSeverity	Het ernstniveau van het incident, dat de bedrijfsimpact aangeeft.
Omschrijving 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. Het belang Het meet de bedrijfsimpact van een incident, waardoor analyse mogelijk is gericht op het beperken van de meest schadelijke problemen. Vindplaats Dit is een standaardveld in Freshservice, beschikbaar via de Tickets API als 'impact'. De waarden zijn numeriek. Voorbeelden LaagGemiddeldHoog
	Incidentcategorie IncidentCategory	De categorie die wordt gebruikt om het incident te classificeren, zoals Hardware, Software of Netwerk.
Omschrijving 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 belangrijk voor trendanalyse. Dit attribuut wordt gebruikt in het Incident Categorization Accuracy-dashboard om te analyseren of initiële verkeerde categorisatie leidt tot langere oplostijden door herverdelingen. Door incidenten per categorie te groeperen, kunnen organisaties terugkerende problemen vinden, begrijpen waar de meeste supportinspanningen aan worden besteed en verbeterinitiatieven op maat maken. Het belang Het maakt de analyse van incidenttrends mogelijk en helpt bepalen of onjuiste categorisatie vertragingen in de oplossing veroorzaakt. Vindplaats Dit is een standaard maar aanpasbaar veld in Freshservice. Het is beschikbaar via de Tickets API als 'category', met gerelateerde velden 'sub_category' en 'item_category'. Voorbeelden HardwareSoftwareNetwerkprobleemAccounttoegang
	Incidentstatus IncidentStatus	De huidige status van het incident in zijn levenscyclus, zoals Open, In afwachting, Opgelost of Gesloten.
Omschrijving De Incidentstatus geeft de huidige staat van het incident aan. Statuswijzigingen zijn belangrijke gebeurtenissen die de basis vormen van de bekijkte proceskaart, zoals de overgang van 'In behandeling' naar 'In afwachting' of van 'Opgelost' naar 'Gesloten'. Dit attribuut is onmisbaar voor het begrijpen van de reis van het incident. Het analyseren van de tijd die in elke status wordt doorgebracht, helpt bij het vinden van knelpunten, zoals incidenten die te lang in een 'In afwachting'-status verkeren, wachtend op een gebruikersreactie. Het is ook belangrijk voor het definiëren van de start- en eindpunten voor cyclustijdberekeningen. Het belang Het volgt de voortgang van het incident gedurende de levenscyclus en helpt stadia te vinden waar vertragingen vaak voorkomen. Vindplaats Beschikbaar in de Freshservice Tickets API als het statusveld. De waarden zijn numeriek. Voorbeelden OpenIn uitvoeringPendingOpgelostGesloten
	SLA Doeltijd Oplossing ResolutionSlaTargetTime	De timestamp waarop het incident naar verwachting opgelost moet zijn volgens de SLA-policy.
Omschrijving 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 belangrijk 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 onmisbaar voor het meten van de naleving van serviceniveaus. Het belang Het biedt de deadline voor oplossing, wat nodig is voor het berekenen van SLA-compliance en het vinden van incidenten met risico. Vindplaats 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.
Omschrijving 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 medewerkers. Dit attribuut is belangrijk voor prestatieanalyse en maakt dashboards mogelijk die de werkdruk van medewerkers, de gemiddelde oplostijd per agent en de resolutiepercentages bij eerste contact bijhouden. Het wordt ook gebruikt om overdrachten tussen medewerkers te analyseren, wat een bron van vertraging en inefficiëntie kan zijn. Door agenttoewijzingen te volgen, kunnen managers trainingsbehoeften vinden en hoogpresterende teamleden erkennen. Het belang Het maakt analyse van agentprestaties, werkbelastingverdeling en de impact van agentoverdrachten op oplossingstijden mogelijk. Vindplaats 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.
Omschrijving 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 belangrijk 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 vinden van organisatorische knelpunten en kansen om de teamoverschrijdende samenwerking te vereenvoudigen. Het belang Het volgt welk team verantwoordelijk is, wat belangrijk is voor het analyseren van overdrachten, escalaties en interteamvertragingen. Vindplaats 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 `Service Desk``Netwerkbeheer`Infrastructuur Support
	Aantal overdrachten HandoffCount	Het aantal keren dat een incident werd overgedragen tussen verschillende medewerkers of groepen.
Omschrijving Handoff Count is een berekende metriek die het aantal hernieuwde toewijzingen kwantificeert dat een incident ondergaat gedurende zijn levenscyclus. Elke verandering in het 'AssignedAgent' of 'AssignedGroup' attribuut verhoogt deze teller. Een hoge handoff count is vaak een indicator van procesinefficiëntie, onjuiste initiële routering of een gebrek aan expertise van medewerkers. Deze metriek ondersteunt direct de 'Incident Handoff Count' KPI en het 'Handoff And Transfer Delay Analysis' dashboard, en helpt bij het vinden van incidenten of procespaden met buitensporige overdrachten die leiden tot vertragingen. Het belang Het kwantificeert rework en hertoewijzingen, wat helpt bij het vinden van knelpunten veroorzaakt door onjuiste routering of kennisleemtes. Vindplaats 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
	Afdeling Aanvrager RequestersDepartment	De afdeling waartoe de gebruiker die het incident meldde, behoort.
Omschrijving 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 zichtbaar maken 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. Het belang Het biedt zakelijke context, waardoor analyse mogelijk is van incidenttrends en impact op specifieke afdelingen. Vindplaats 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ënPersoneelszaken
	Is `SLA` Geschonden IsSlaBreached	Een berekende vlag die 'waar' is als het incident niet binnen de gedefinieerde SLA-doeltijd is opgelost.
Omschrijving Deze vlag 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 vinden die niet voldoen aan de serviceafspraken. Het belang Het meet direct de SLA-compliance voor elk incident, waardoor het eenvoudig is om de algehele nalevingspercentages te berekenen en probleemgebieden te vinden. Vindplaats Dit is een berekend veld, afgeleid tijdens datatransformatie door de timestamp van 'Incident Opgelost' te vergelijken met het veld 'ResolutionSlaTargetTime'. Voorbeelden truefalse
	Is Heropend IsReopened	Een berekende vlag die 'waar' is als een incident is heropend nadat het was opgelost of gesloten.
Omschrijving Deze vlag is een berekende vlag die incidenten identificeert die zijn heropend. Het wordt ingesteld op 'waar' als een incident, na het bereiken van de status 'Opgelost' of 'Closed', de status weer wordt gewijzigd naar een open of 'in uitvoering'-status. Deze vlag is belangrijk 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. Het belang Het identificeert falen in het oplossingsproces, waarbij incidenten worden belicht waarbij de initiële fix ineffectief was en resulteerde in rework. Vindplaats Dit is een berekend veld, afgeleid van de volgorde 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
	Rapportagekanaal ReportingChannel	De methode of het kanaal waardoor het incident werd gemeld, zoals E-mail, Portaal of Telefoon.
Omschrijving 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 ewaarderen. 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. Het belang Het helpt de meest efficiënte rapportagekanalen te vinden en onthult kansen om het incidentintakeproces te verbeteren. Vindplaats 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.
Omschrijving 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 belangrijk 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. Het belang Het maakt proactief probleemmanagement mogelijk door te helpen de onderliggende oorzaken van terugkerende incidenten te vinden en elimineren. Vindplaats Dit is vaak een aangepast veld in Freshservice, aangezien de standaard functionaliteit beperkt kan zijn. Controleer de 'Ticket Fields' configuratie voor een veld met de naam 'Root Cause' of iets soortgelijks. Voorbeelden Software BugNetwerkconfiguratiefoutProbleem met gebruikerstrainingHardwarestoring
	Workaround geleverd WorkaroundProvided	Een indicator die aangeeft of een tijdelijke workaround aan de gebruiker is aangeboden vóór de definitieve oplossing.
Omschrijving Deze vlag 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. Het belang Het helpt de effectiviteit van tijdelijke workarounds te meten bij het verminderen van de impact van incidenten en het versnellen van de waargenomen oplossing. Vindplaats Dit is doorgaans een custom boolean (checkbox) veld. Het bestaan ervan moet worden geverifieerd in de Freshservice 'Ticket Fields' configuratie. Voorbeelden truefalse

Verplicht Aanbevolen Optioneel

Incidentbeheer Activities

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	Omschrijving
	`Incident` gemeld	Markeert de creatie van een nieuw incidentrecord in Freshservice. Dit is het startpunt van de incident-levenscyclus, doorgaans getriggerd door een eindgebruiker via een portaal, e-mail, of een servicedeskagent die namens hen een ticket aanmaakt. Deze gebeurtenis wordt expliciet gelogd met een creation timestamp.
Het belang Deze activiteit is het primaire startgebeurtenis voor het gehele proces. Het analyseren van de tijd vanaf dit gebeurtenis tot aan de oplossing is onmisbaar voor het meten van de algemene doorlooptijden en SLA-naleving. Vindplaats 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.
Het belang Onjuiste of vertraagde prioritering kan leiden tot SLA-overschrijdingen en inefficiënte middelentoewijzing. Het analyseren van deze activiteit helpt ervoor te zorgen dat kritieke incidenten onmiddellijke aandacht krijgen. Vindplaats Afgeleid uit het activity log van het incident, dat alle updates van het veld 'Prioriteit' volgt. Vastleggen Gebruik tijdstempels uit de auditlog waar de 'Priority' veld waarde werd ingesteld of gewijzigd. Gebeurtenistype inferred
	Incident Gesloten	Vertegenwoordigt de definitieve, formele sluiting van het incidentrecord. Dit gebeurt doorgaans automatisch na een bepaalde periode in de status 'Opgelost', of kan handmatig door een agent worden gedaan. Dit gebeurtenis markeert het einde van de levenscyclus van het incident.
Het belang Deze activiteit is het definitieve eindpunt van het proces. De totale tijd tot dit gebeurtenis vertegenwoordigt de volledige doorlooptijd van de incidentlevenscyclus, inclusief eventuele gebruikersbevestigingsperioden. Vindplaats Afgeleid uit het activity log van het incident door te vinden 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 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 'Opgelost'. In Freshservice is dit een belangrijke mijlpaal die de SLA-klok stopt.
Het belang Dit is een belangrijke 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. Vindplaats Afgeleid uit het activity log van het incident door te vinden wanneer het veld 'Status' wordt bijgewerkt naar 'Opgelost'. 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 auditlog van het incident te volgen.
Het belang Het tracken van toewijzingen is belangrijk voor het meten van first-response times en het vinden van knelpunten in het dispatching proces. Het helpt analyseren hoe efficiënt incidents naar het juiste team worden geleid. Vindplaats 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 'Opgelost'. Deze actie en de inhoud ervan worden expliciet gelogd.
Het belang Dit markeert de identificatie van een oplossing. De tijd tussen dit en de status 'Incident Opgelost' kan wijzen op interne review of documentatie overhead. Vindplaats 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.
Het belang 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 belangrijk voor het begrijpen van de oplossingsinspanning. Vindplaats Afgeleid uit het activity log van het incident door te vinden 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.
Het belang 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 belangrijk voor dashboards voor agentprestaties. Vindplaats Bijgehouden via wijzigingen in het 'Agent' veld in het activity log of audit trail van het incident. Vastleggen Identificeer tijdstempels 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 tijdstempels.
Het belang Het voldoen aan de First Response SLA is een kritieke KPI voor klanttevredenheid. Deze activiteit maakt de meting en analyse mogelijk van hoe snel medewerkers nieuwe incidenten oppakken. Vindplaats 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 heringedeeld	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 gebeurtenis wordt afgeleid door het detecteren van opeenvolgende wijzigingen in de velden 'Agent' of 'Group' na de initiële toewijzing.
Het belang Frequente hernieuwde toewijzingen of overdrachten duiden vaak op procesinefficiënties, kennisleemtes of onjuiste initiële routering. Het analyseren van deze gebeurtenissen helpt bij het vinden en verminderen van vertragingen. Vindplaats 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
	Incident heropend	Vindt plaats wanneer een incident dat eerder als 'Opgelost' 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 'Opgelost' terug naar een status zoals 'Open' of 'In Progress'.
Het belang Een hoge heropeningsgraad wijst op problemen met de oplossingskwaliteit of onvolledige oplossingen. Dit is een belangrijke metriek voor het analyseren van rework en de agentprestaties. Vindplaats Afgeleid uit het activity log van het incident door een statuswijziging te detecteren van 'Opgelost' naar een actieve status. Vastleggen Filter de activity log op een 'Status' wijziging van 'Opgelost' naar 'Open' of 'In Progress'. Gebeurtenistype inferred
	SLA-doelstelling overschreden	Dit is een berekende gebeurtenis 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 gebeurtenis kan worden afgeleid door tijdstempels te vergelijken met SLA-beleid.
Het belang Meet direct de naleving van servicelevelafspraken. Vaststellen wanneer en waarom schendingen optreden is belangrijk voor het SLA Performance Dashboard en continue verbetering. Vindplaats Berekend door de oplossing- of reactietijd te vergelijken met de SLA-doeltijd. Freshservice markeert tickets vaak als 'SLA Overtreden'. Vastleggen Afleiden door de 'Opgelost 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.
Het belang Het vinden van de tijd die wordt besteed in wachtstatussen is belangrijk voor het begrijpen van externe afhankelijkheden en vertragingen. Het helpt de werktijd van de agent te scheiden van de wachttijd. Vindplaats Afgeleid uit het activity log van het incident wanneer het veld 'Status' wordt bijgewerkt naar een waarde zoals 'Pending' of 'Awaiting Gebruiker Response'. Vastleggen Filter de activity log op statuswijzigingen naar een wachtstatus en gebruik de bijbehorende timestamp. Gebeurtenistype inferred
	Workaround geleverd	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.
Het belang 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'. Vindplaats Dit is waarschijnlijk geen expliciete gebeurtenis. Het kan worden afgeleid door notities met keywords zoals 'workaround' te markeren, of als een custom 'Workaround Provided' checkbox veld wordt gebruikt en de wijziging daarvan wordt gelogd. Vastleggen Afgeleid uit een wijziging in een aangepast veld of keyword-analyse van agentnotities. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Hoe u uw `data` uit Freshservice haalt

Stappen

Toegang tot Freshservice Analytics: Log in op je 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 "Incidentbeheer Event Log". Selecteer de Incidentbeheer-module wanneer je 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 je gebeurtenislog-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 gebeurtenissen vast te leggen, moet je data uit de ticketactiviteiten samenvoegen of opnemen. Voeg de Activities databron toe aan je widget. Voeg uit deze bron Performed at (voor de gebeurtenis timestamp) en Activiteit description of vergelijkbare velden toe die de verandering beschrijven die heeft plaatsgevonden.
Berekende 'ActiviteitNaam'-kolom Maken: Dit is de meest belangrijke stap. Maak een nieuwe berekende kolom of formuleveld. Gebruik geneste IF-statements of een CASE-functie om ruwe activiteitsdata te vertalen naar de vereiste ActiviteitNaam 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 gebeurtenissen.
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. Je 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 ActiviteitNaam en EventTimestamp kolommen correct worden gevuld. Pas formules en filters aan indien nodig.
Rapport Opslaan en Exporteren: Zodra je tevreden bent met de output van het rapport, slaat je het op. Gebruik de Export optie en selecteer CSV als formaat.
Export Plannen (Optioneel): Voor doorlopende analyse kun je het rapport plannen om automatisch uit te voeren en te exporteren. Stel een schema in (bijv. dagelijks of wekelijks) om de CSV naar je 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, ActiviteitNaam, EventTimestamp, AssignedAgent, AssignedGroup, etc. Voeg de statische kolommen Bronsysteem (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).
Verplichte Machtigingen: Je gebruikersaccount heeft een rol nodig met machtigingen om rapporten te maken, bewerken en uit te voeren in de Analytics-module.
Datumbereik: Het is belangrijk 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 je procesanalyse.
Berekende Velden: Deze methode is sterk afhankelijk van het gebruik van berekende velden (formules) om de ActiviteitNaam en EventTimestamp voor elke gebeurtenis af te leiden. Bekendheid met de Freshservice formule-editor is nuttig.
Datavolume: Wees je 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

Verplichten: Zorg ervoor dat je Python 3.6+ heeft geïnstalleerd, samen met de requests en pandas bibliotheken. Je kunt deze installeren met pip: pip install requests pandas.
API-sleutel genereren: Log in op je Freshservice-instantie als beheerder. Ga naar je Profielinstellingen door op je profielfoto in de rechterbovenhoek te klikken. Ga naar de sectie 'API Key' en kopieer je 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 je 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 je zojuist hebt gekopieerd) en START_DATE_STR (het begin van je 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 vinden 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 gebeurtenissen 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 gebeurtenis 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 je 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_gebeurtenis_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, ActiviteitNaam, EventTimestamp, etc.) zoals verwacht zijn ingevuld. Het bestand is nu klaar voor upload naar ProcessMind of een andere process mining-tool.

Configuratie

FRESHSERVICE_DOMAIN: Je 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 processen 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 je 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 "Incidentbeheer Event Log". Selecteer de Incidentbeheer-module wanneer je 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 je gebeurtenislog-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 gebeurtenissen vast te leggen, moet je data uit de ticketactiviteiten samenvoegen of opnemen. Voeg de Activities databron toe aan je widget. Voeg uit deze bron Performed at (voor de gebeurtenis timestamp) en Activiteit description of vergelijkbare velden toe die de verandering beschrijven die heeft plaatsgevonden.
Berekende 'ActiviteitNaam'-kolom Maken: Dit is de meest belangrijke stap. Maak een nieuwe berekende kolom of formuleveld. Gebruik geneste IF-statements of een CASE-functie om ruwe activiteitsdata te vertalen naar de vereiste ActiviteitNaam 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 gebeurtenissen.
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. Je 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 ActiviteitNaam en EventTimestamp kolommen correct worden gevuld. Pas formules en filters aan indien nodig.
Rapport Opslaan en Exporteren: Zodra je tevreden bent met de output van het rapport, slaat je het op. Gebruik de Export optie en selecteer CSV als formaat.
Export Plannen (Optioneel): Voor doorlopende analyse kun je het rapport plannen om automatisch uit te voeren en te exporteren. Stel een schema in (bijv. dagelijks of wekelijks) om de CSV naar je 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, ActiviteitNaam, EventTimestamp, AssignedAgent, AssignedGroup, etc. Voeg de statische kolommen Bronsysteem (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).
Verplichte Machtigingen: Je gebruikersaccount heeft een rol nodig met machtigingen om rapporten te maken, bewerken en uit te voeren in de Analytics-module.
Datumbereik: Het is belangrijk 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 je procesanalyse.
Berekende Velden: Deze methode is sterk afhankelijk van het gebruik van berekende velden (formules) om de ActiviteitNaam en EventTimestamp voor elke gebeurtenis af te leiden. Bekendheid met de Freshservice formule-editor is nuttig.
Datavolume: Wees je 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'

Je Incidentbeheer-datatemplate

Je Incidentbeheer-datatemplate

Incidentbeheer Attributen

Incidentbeheer Activities

Extractiegidsen

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-overschrijdingen: Optimaliseer incidentbeheer vandaag nog

Je Incidentbeheer-datatemplate

Je Incidentbeheer-datatemplate

Incidentbeheer Attributen

Incidentbeheer Activities

Extractiegidsen

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

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Voorkom SLA-overschrijdingen: Optimaliseer incidentbeheer vandaag nog