> Continu verbeteren van processen > Incidentbeheer > Freshservice > Datatemplate

Datatemplate voor incidentbeheer

Freshservice

Attributen voor incidentbeheer(19) Activiteiten voor incidentbeheer(14) Extractiegidsen(3)

Datatemplate voor incidentbeheer

Deze template helpt je data voor te bereiden voor een goede analyse van incidentbeheer. Je vindt erin welke attributen je verzamelt, welke belangrijke activiteiten je bijhoudt en hoe je deze informatie uit het bronsysteem haalt. Gebruik deze bron om de datavoorbereiding eenvoudiger te maken.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om bij te houden
Extractie-instructies

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor incidentbeheer

Dit zijn de aanbevolen datavelden voor je event log, zodat je het proces voor incidentbeheer goed kunt analyseren.

5 Verplicht 7 Aanbevolen 7 Optioneel

	Naam	Beschrijving
	Incident-ID IncidentId	De unieke identificatiecode van elk incidentrecord. Deze dient als primaire sleutel om de volledige levenscyclus van het incident te volgen.
Beschrijving De Incident-ID vormt de basis voor analyses van incidentbeheer. Deze ID fungeert als Case-ID en koppelt alle bijbehorende activiteiten, timestamps en wijzigingen in attributen aan één samenhangend proces. Bij process mining is elke vermelding in het event log gekoppeld aan een Incident-ID. Zo kun je het volledige procesverloop van elk incident reconstrueren. Dat is nodig om doorlooptijden te berekenen, procesvarianten te analyseren en bottlenecks in afzonderlijke cases te vinden. Zonder unieke identificatiecode kun je incidenten niet van elkaar onderscheiden en hun verloop van melding tot oplossing niet analyseren. Waarom dit belangrijk is Deze ID identificeert elk incident uniek, zodat je de volledige levenscyclus van aanmaak tot afsluiting kunt volgen en analyseren. Waar vind je dit? Dit is de primaire identificatiecode van een ticket. In de Freshservice Tickets API staat deze in het ticketobject in het veld 'id'. Voorbeelden INC-10234INC-10235INC-10236
	Activiteitsnaam ActivityName	De naam van de specifieke bedrijfsactiviteit of gebeurtenis die op een bepaald moment in de levenscyclus van het incident plaatsvond.
Beschrijving De Activiteitsnaam beschrijft één stap of gebeurtenis in het incidentbeheerproces, zoals 'Incident Assigned to Group', 'Status Changed to Pending' of 'Incident Resolved'. Deze activiteiten worden afgeleid uit wijzigingen in de incidentgegevens. Dit attribuut is belangrijk voor process mining, omdat het de knooppunten in de ontdekte proceskaart bepaalt. Door de volgorde en frequentie van activiteiten te analyseren, kunnen organisaties het werkelijke proces voor het oplossen van incidenten in beeld brengen. Zo worden veelvoorkomende routes zichtbaar, kun je afwijkingen van de standaardprocedure herkennen en herstelwerk opsporen, zoals herhaaldelijke hertoewijzingen. Waarom dit belangrijk is Dit attribuut bepaalt de stappen op de proceskaart. Daarmee kun je het verloop van incidentoplossingen, bottlenecks en afwijkingen in beeld brengen en analyseren. Waar vind je dit? Dit attribuut is geen rechtstreeks veld in Freshservice, maar wordt afgeleid uit wijzigingen in tಿಕೆteigenschappen, zoals status, prioriteit, toewijzing aan een medewerker of groep en toegevoegde notities. Voorbeelden Incident gemeldIncident toegewezen aan groepOplossingsnotitie toegevoegdIncident opgelost
	Bronsysteem SourceSystem	Het systeem waaruit de data zijn gehaald, meestal 'Freshservice'.
Beschrijving Dit attribuut geeft aan waar de data vandaan komen. In deze context is dat steeds 'Freshservice'. Het is een belangrijk veld in omgevingen waar data uit meerdere systemen worden gecombineerd voor een volledig beeld van het proces. Het attribuut Bronsysteem opnemen is een goede werkwijze voor datagovernance en traceerbaarheid. Zo is duidelijk waar de data vandaan komen. Dat is belangrijk voor validatie, foutopsporing en toekomstige uitbreiding van het process mining-project met andere servicebeheer- of bedrijfssystemen. Waarom dit belangrijk is Dit attribuut zorgt voor traceerbaarheid en datagovernance doordat de herkomst van de data over incidentbeheer duidelijk is. Waar vind je dit? Dit is meestal een vaste waarde die tijdens het data-transformatieproces (ETL) wordt toegevoegd om de dataset te labelen. Voorbeelden FreshserviceFreshservice-EUFreshservice-PROD
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor dit proces voor het laatst zijn vernieuwd of opgehaald.
Beschrijving Dit attribuut bevat de timestamp waarop de volledige dataset voor het laatst vanuit het bronsysteem is bijgewerkt. Het is een metadataveld voor de hele dataset, niet voor afzonderlijke gebeurtenissen. Toch wordt het vaak op gebeurtenisniveau opgenomen voor consistentie. Bij analyses laat deze informatie zien hoe actueel de data zijn en welke periode de dashboards en KPI’s bestrijken. Zo weten gebruikers hoe recent de inzichten zijn en of de nieuwste incidenten in de analyse zijn opgenomen. Waarom dit belangrijk is Dit laat gebruikers zien hoe actueel de data zijn en welke periode de analyse bestrijkt. Waar vind je dit? Dit is een metadatatimestamp die tijdens het data-extractieproces (ETL) wordt gegenereerd. Voorbeelden 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Timestamp van gebeurtenis EventTimestamp	De exacte datum en tijd waarop de activiteit of gebeurtenis plaatsvond.
Beschrijving De timestamp van de gebeurtenis, of Starttijd, geeft precies aan wanneer een activiteit plaatsvond. Bij elke activiteit in de levenscyclus van een incident, van aanmaak tot afsluiting, hoort een timestamp. Dit attribuut is nodig voor alle tijdsgebonden process mining-analyses. Je gebruikt het om gebeurtenissen chronologisch te ordenen, de tijd tussen activiteiten te berekenen, de totale doorlooptijd van een case te meten en wachttijden te analyseren. Het vormt de basis voor dashboards die SLA-prestaties, vertragingen bij overdrachten en totale oplostijden bijhouden. Waarom dit belangrijk is Dit attribuut geeft de chronologische volgorde van gebeurtenissen aan. Die is nodig om tijdsduren en doorlooptijden te berekenen en de procesprestaties te begrijpen. Waar vind je dit? Dit wordt afgeleid uit verschillende timestampvelden in Freshservice, zoals 'created_at' en 'updated_at', en uit timestamps in de gesprekken of auditlogboeken van het ticket. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Ernst van incident IncidentSeverity	De ernst van het incident, die de impact op de bedrijfsvoering aangeeft.
Beschrijving De Ernst van incident geeft aan welke impact een incident op de bedrijfsvoering heeft. De ernst wordt vaak ingedeeld als Laag, Gemiddeld, Hoog of Kritiek. Ernst hangt samen met prioriteit, maar geeft de impact aan, terwijl prioriteit de urgentie weergeeft. De combinatie van ernst en impact bepaalt vaak de uiteindelijke prioriteit. Analyse op basis van ernst laat zien hoe goed de organisatie incidenten met grote gevolgen voor de bedrijfsvoering afhandelt. Dashboards gebruiken dit attribuut om oplostijden en SLA-prestaties uit te splitsen. Zo krijgen incidenten met de grootste impact tijdens hun hele levenscyclus de juiste aandacht en middelen. Waarom dit belangrijk is Dit attribuut meet de impact van een incident op de bedrijfsvoering. Zo kun je de analyse richten op problemen met de grootste gevolgen. Waar vind je dit? Dit is een standaardveld in Freshservice, beschikbaar via de Tickets API als 'impact'. De waarden zijn numeriek. Voorbeelden LaagGemiddeldHoog
	Incidentcategorie IncidentCategory	De categorie waarmee het incident wordt ingedeeld, zoals Hardware, Software of Netwerk.
Beschrijving Met Incidentcategorie kun je incidenten indelen op basis van het gemelde probleem. Deze hiërarchische indeling helpt om incidenten naar het juiste team door te sturen en is belangrijk voor trendanalyse. Het dashboard 'Nauwkeurigheid van incidentcategorisering' laat zien of een verkeerde eerste indeling tot langere oplostijden leidt doordat incidenten opnieuw worden toegewezen. Door incidenten per categorie te groeperen, kunnen organisaties terugkerende problemen herkennen, zien waar de meeste supporttijd naartoe gaat en verbeteringen daarop afstemmen. Waarom dit belangrijk is Hiermee kun je trends in incidenten analyseren en nagaan of een verkeerde indeling tot vertraging bij het oplossen leidt. Waar vind je dit? Dit is een standaardveld in Freshservice dat je kunt aanpassen. Het is beschikbaar in de Tickets API als 'category', met de verwante velden 'sub_category' en 'item_category'. Voorbeelden HardwareSoftwareNetwerkprobleemAccounttoegang
	Incidentprioriteit IncidentPriority	De prioriteit van het incident, die bepaalt hoe snel er moet worden gereageerd en hoe snel het moet worden opgelost.
Beschrijving Incidentprioriteit bepaalt hoe snel en met hoeveel aandacht een incident moet worden afgehandeld. De prioriteit wordt meestal aangegeven als Laag, Gemiddeld, Hoog of Urgent en bepaalt vaak de SLA-doelstellingen. Bij process mining is prioriteit een belangrijke dimensie om op te filteren en te analyseren. Je kunt de oplosprocessen van incidenten met hoge en lage prioriteit vergelijken en nagaan of urgente problemen efficiënt worden afgehandeld. Dashboards splitsen metrieken zoals doorlooptijd en het halen van SLA’s vaak uit naar prioriteit, zodat supportmanagers gerichte verbeteringen kunnen doorvoeren. Waarom dit belangrijk is Hiermee kun je de analyse richten op de meest urgente incidenten. Dit is nodig om SLA-prestaties en de inzet van middelen te beoordelen. Waar vind je dit? Beschikbaar in de Freshservice Tickets API als het veld 'priority'. De waarden zijn numeriek, bijvoorbeeld 1 voor Laag en 4 voor Urgent. Voorbeelden LaagGemiddeldHoogUrgent
	Incidentstatus IncidentStatus	De huidige status van het incident in de levenscyclus, zoals Open, Pending, Resolved of Closed.
Beschrijving De Incidentstatus geeft de huidige toestand van het incident aan. Statuswijzigingen zijn belangrijke gebeurtenissen waarop de ontdekte proceskaart is gebaseerd, zoals een wijziging van 'In Progress' naar 'Pending' of van 'Resolved' naar 'Closed'. Dit attribuut is nodig om het verloop van een incident te begrijpen. Door te analyseren hoelang een incident in elke status blijft, kun je bottlenecks vinden. Denk aan incidenten die te lang de status 'Pending' hebben omdat ze op een reactie van de gebruiker wachten. De status is ook belangrijk om begin- en eindpunten voor berekeningen van de doorlooptijd vast te stellen. Waarom dit belangrijk is Dit attribuut volgt de voortgang van het incident tijdens de levenscyclus en helpt fases te vinden waarin vaak vertraging ontstaat. Waar vind je dit? Beschikbaar in de Freshservice Tickets API als het veld 'status'. De waarden zijn numeriek. Voorbeelden OpenIn behandelingIn afwachtingOpgelostGesloten
	SLA-doeltijd voor oplossing ResolutionSlaTargetTime	De timestamp waarop het incident volgens het SLA-beleid opgelost moet zijn.
Beschrijving Dit attribuut bevat de datum en tijd waarop het incident uiterlijk opgelost moet zijn. Deze doelstelling wordt bepaald door het Service Level Agreement (SLA)-beleid dat op het ticket van toepassing is. De prioriteit speelt daarbij meestal een rol. Deze doeltijd is nodig om de KPI 'Percentage nagekomen SLA’s' te berekenen en het 'SLA-prestaties-dashboard' te vullen. Door de werkelijke timestamp van de oplossing met deze doeltijd te vergelijken, kun je vaststellen of het incident op tijd is opgelost of dat de SLA is overschreden. Zo meet je of de afspraken over serviceniveaus worden nagekomen. Waarom dit belangrijk is Dit geeft de uiterste tijd voor de oplossing aan. Die is nodig om te berekenen of de SLA is nagekomen en om incidenten met risico op overschrijding te herkennen. Waar vind je dit? Beschikbaar in de Freshservice Tickets API als de velden 'fr_due_by' (eerste reactie) en 'due_by' (oplossing). Voorbeelden 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Toegewezen groep AssignedGroup	De supportgroep of het team dat momenteel verantwoordelijk is voor het incident.
Beschrijving De Toegewezen groep geeft aan welk team, zoals 'Level 1 Support', 'Network Team' of 'Database Admins', verantwoordelijk is voor het incident. Wijzigingen in dit attribuut wijzen op een escalatie of overdracht tussen verschillende teams. Analyse van de Toegewezen groep is belangrijk om vertragingen bij overdrachten te begrijpen. Process mining kan laten zien hoe incidenten tussen groepen worden doorgegeven. Zo worden veelvoorkomende escalatieroutes zichtbaar en kun je meten hoelang elke groep wacht voordat die actie onderneemt. Dit helpt om organisatorische bottlenecks en mogelijkheden voor betere samenwerking tussen teams te vinden. Waarom dit belangrijk is Dit attribuut houdt bij welk team verantwoordelijk is. Dat is belangrijk voor de analyse van overdrachten, escalaties en vertragingen tussen teams. Waar vind je dit? Beschikbaar in de Freshservice Tickets API als het veld 'group_id'. Je kunt deze ID koppelen aan de Groups API om de naam van de groep op te halen. Voorbeelden ServicedeskNetwerkbeheerInfrastructuurondersteuning
	Toegewezen medewerker AssignedAgent	De naam of ID van de supportmedewerker die momenteel verantwoordelijk is voor het oplossen van het incident.
Beschrijving De Toegewezen medewerker is de servicedeskmedewerker die op een bepaald moment verantwoordelijk is voor het incident. Wijzigingen in dit attribuut geven aan dat de verantwoordelijkheid naar een andere medewerker is overgedragen. Dit attribuut is nodig om prestaties te analyseren. Dashboards kunnen bijvoorbeeld de werkdruk per medewerker, de gemiddelde oplostijd per medewerker en het percentage oplossingen bij het eerste contact bijhouden. Je kunt er ook overdrachten tussen medewerkers mee analyseren, die vertraging en inefficiëntie kunnen veroorzaken. Door toewijzingen bij te houden, kunnen managers opleidingsbehoeften vaststellen en goed presterende teamleden herkennen. Waarom dit belangrijk is Hiermee kun je de prestaties van medewerkers, de verdeling van de werkdruk en het effect van overdrachten op oplostijden analyseren. Waar vind je dit? Beschikbaar in de Freshservice Tickets API als het veld 'responder_id'. Je kunt deze ID koppelen aan de Agents API om de naam van de medewerker op te halen. Voorbeelden John DoeJane SmithSupportBot
	Aantal overdrachten HandoffCount	Het aantal keer dat een incident tussen verschillende medewerkers of groepen is overgedragen.
Beschrijving Aantal overdrachten is een berekende metriek die telt hoe vaak een incident tijdens de levenscyclus opnieuw wordt toegewezen. Elke wijziging in het attribuut 'AssignedAgent' of 'AssignedGroup' verhoogt deze telling. Een hoog aantal overdrachten wijst vaak op inefficiënte processen, een onjuiste eerste toewijzing of onvoldoende kennis bij medewerkers. Deze metriek ondersteunt de KPI 'Aantal incidentoverdrachten' en het dashboard 'Analyse van vertragingen bij overdrachten'. Zo kun je incidenten of procesroutes vinden waarbij veel overdrachten tot vertraging leiden. Waarom dit belangrijk is Dit maakt herstelwerk en hertoewijzingen meetbaar en helpt inefficiëntie door verkeerde routering of kennishiaten op te sporen. Waar vind je dit? Dit is een berekende metriek. Je bepaalt de waarde door het aantal verschillende waarden of wijzigingen in de velden 'AssignedAgent' of 'AssignedGroup' tijdens de levenscyclus van één incident te tellen. Voorbeelden 0125
	Afdeling van aanvrager RequestersDepartment	De afdeling waartoe de gebruiker behoort die het incident heeft gemeld.
Beschrijving Dit attribuut geeft aan bij welke afdeling de aanvrager werkt, zoals 'Sales', 'Finance' of 'IT'. Deze informatie komt meestal uit het gebruikersprofiel in Freshservice. Door incidenten per afdeling van de aanvrager te analyseren, kun je zien of bepaalde bedrijfseenheden vaker met problemen te maken hebben of dat er afdelingsspecifieke problemen zijn. Dit geeft context bij de impact van incidenten op de bedrijfsvoering en helpt om oplossingen voor problemen in belangrijke afdelingen voorrang te geven. Waarom dit belangrijk is Dit geeft context over de bedrijfsvoering, zodat je trends in incidenten en de impact op specifieke afdelingen kunt analyseren. Waar vind je dit? Deze informatie is gekoppeld aan de aanvrager van het ticket. Je kunt de gegevens ophalen via het API-eindpunt 'Requesters'. Gebruik daarvoor de 'requester_id' van het ticket en haal vervolgens 'department_id' en de naam op. Voorbeelden VerkoopMarketingFinanciënPersoneelszaken
	Heropend? IsReopened	Een berekende aanduiding die waar is als een incident na de status 'Resolved' of 'Closed' opnieuw is geopend.
Beschrijving Dit booleaanse attribuut geeft aan welke incidenten opnieuw zijn geopend. De waarde wordt waar als de status van een incident na 'Resolved' of 'Closed' weer verandert in een open status of 'In Progress'. Deze aanduiding is nodig om de KPI 'Percentage heropende incidenten' te berekenen en het dashboard 'Terugkerende incidenten' te vullen. Een hoog percentage heropende incidenten kan wijzen op een gebrekkige eerste oplossing, een onvolledige oorzaakanalyse of voortijdige afsluiting. Door deze cases te analyseren, kun je de kwaliteit en duurzaamheid van oplossingen verbeteren. Waarom dit belangrijk is Dit laat zien waar het oplossen van incidenten misgaat. Je ziet welke eerste oplossingen niet werkten en tot herstelwerk leidden. Waar vind je dit? Dit is een berekend veld dat wordt afgeleid uit de volgorde van activiteiten in het event log. De waarde is waar als een activiteit zoals 'Incident Reopened' voorkomt, of als voor dezelfde Incident-ID een activiteit met een open status volgt op een activiteit met een gesloten status. Voorbeelden truefalse
	Hoofdoorzaak RootCause	De onderliggende reden of hoofdoorzaak die na onderzoek voor het incident is vastgesteld.
Beschrijving Het attribuut Hoofdoorzaak legt het onderliggende probleem vast dat tot het incident heeft geleid. Supportmedewerkers vullen dit meestal tijdens of na de oplossing in als onderdeel van een oorzaakanalyse. Dit attribuut is belangrijk voor het dashboard 'Terugkerende incidenten en hoofdoorzaken' en de KPI 'Voltooiingspercentage oorzaakanalyse'. Door veelvoorkomende hoofdoorzaken te analyseren, kunnen organisaties overstappen van reactief incidentbeheer naar proactief probleembeheer. Ze kunnen dan blijvende oplossingen invoeren die nieuwe incidenten voorkomen en herhaling verminderen. Waarom dit belangrijk is Dit ondersteunt proactief probleembeheer door te helpen de onderliggende oorzaken van terugkerende incidenten te vinden en weg te nemen. Waar vind je dit? Dit is vaak een aangepast veld in Freshservice, omdat de standaardfuncties mogelijk beperkt zijn. Controleer bij de configuratie van 'Ticket Fields' of er een veld met de naam 'Root Cause' of iets vergelijkbaars is. Voorbeelden SoftwarefoutConfiguratiefout in netwerkProbleem met gebruikerstrainingHardwarestoring
	Meldingskanaal ReportingChannel	De manier of het kanaal waarop het incident is gemeld, zoals E-mail, Portaal of Telefoon.
Beschrijving Het Meldingskanaal, ook wel de bron genoemd, geeft aan hoe een incident in het supportsysteem terechtkwam. Veelgebruikte kanalen zijn e-mail, een self-serviceportaal, telefoongesprekken en chat. Met dit attribuut kun je de efficiëntie van verschillende meldingskanalen beoordelen. Het dashboard 'Efficiëntie van meldingskanalen' vergelijkt het aantal incidenten en de gemiddelde oplostijd per kanaal. Zo zie je welke kanalen het beste werken en waar procesverbeteringen nodig zijn. Incidenten die via het portaal worden gemeld, kunnen bijvoorbeeld sneller worden opgelost als de melding vanaf het begin meer gestructureerde informatie bevat. Waarom dit belangrijk is Dit attribuut laat zien welke meldingskanalen het efficiëntst zijn en waar je het proces voor het aannemen van incidenten kunt verbeteren. Waar vind je dit? Beschikbaar in de Freshservice Tickets API als het veld 'source'. De waarden zijn numeriek. Voorbeelden E-mailPortaalTelefoonChat
	SLA overschreden? IsSlaBreached	Een berekende aanduiding die waar is als het incident niet binnen de vastgestelde SLA-doeltijd is opgelost.
Beschrijving Dit booleaanse attribuut is een berekende metriek die aangeeft of de oplostijd van een incident de SLA-doeltijd heeft overschreden. De waarde wordt bepaald door de werkelijke timestamp van de oplossing te vergelijken met 'ResolutionSlaTargetTime'. Deze aanduiding wordt gebruikt voor de KPI 'Percentage nagekomen SLA’s' en het 'SLA-prestaties-dashboard'. De duidelijke uitkomst, ja of nee, maakt het eenvoudiger om de SLA-prestaties per incident te analyseren, totalen te berekenen en trends te volgen. Zo zie je snel hoeveel incidenten en welk percentage ervan niet aan de serviceafspraken voldoen. Waarom dit belangrijk is Dit meet rechtstreeks of de SLA voor elk incident is nagekomen. Zo kun je eenvoudig het totale nalevingspercentage berekenen en probleemgebieden vinden. Waar vind je dit? Dit is een berekend veld dat tijdens de datatransformatie wordt afgeleid door de timestamp 'Incident Resolved' te vergelijken met het veld 'ResolutionSlaTargetTime'. Voorbeelden truefalse
	Workaround aangeboden WorkaroundProvided	Een aanduiding die aangeeft of de gebruiker een tijdelijke oplossing kreeg voordat het incident definitief werd opgelost.
Beschrijving Dit booleaanse attribuut geeft aan of er een tijdelijke oplossing is toegepast om de impact van het incident te beperken terwijl aan een definitieve oplossing werd gewerkt. Dit wordt vaak bijgehouden met een selectievakje of een specifieke status. Bij process mining ondersteunt dit attribuut het dashboard 'Metrieken voor de effectiviteit van tijdelijke oplossingen'. Je kunt de oplostijden van incidenten met en zonder tijdelijke oplossing vergelijken. Zo zie je of tijdelijke oplossingen de verstoring van de bedrijfsvoering beperken en ervoor zorgen dat gebruikers het probleem sneller als opgelost ervaren. Waarom dit belangrijk is Hiermee kun je meten of tijdelijke oplossingen de impact van incidenten beperken en ervoor zorgen dat gebruikers het probleem sneller als opgelost ervaren. Waar vind je dit? Dit is meestal een aangepast booleaans veld (selectievakje). Controleer of het bestaat in de configuratie van 'Ticket Fields' in Freshservice. Voorbeelden truefalse

Verplicht Aanbevolen Optioneel

Activiteiten voor incidentbeheer

Dit zijn de belangrijkste processtappen en mijlpalen om in je event log vast te leggen. Zo kun je het proces goed in kaart brengen en bottlenecks opsporen.

7 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Incident gemeld	Dit markeert het aanmaken van een nieuw incidentrecord in Freshservice. Het is het begin van het incidentverloop. Meestal meldt een eindgebruiker het incident via een portaal of e-mail, of maakt een servicedeskmedewerker namens de gebruiker een ticket aan. Deze gebeurtenis wordt vastgelegd met een timestamp voor het aanmaken.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het hele proces. De tijd tussen deze gebeurtenis en de oplossing is essentieel om de totale doorlooptijden en naleving van SLA’s te meten. Waar vind je dit? Afgeleid van de timestamp voor het aanmaken in de incidenttabel. Freshservice legt deze voor elk nieuw ticket vast. Vastleggen Gebruik de timestamp ‘Aangemaakt op’ uit het hoofdrecord van het incident. Gebeurtenistype explicit
	Incident gesloten	Dit staat voor de definitieve, formele afsluiting van het incidentrecord. Dit gebeurt meestal automatisch nadat het incident een bepaalde tijd de status 'Resolved' heeft gehad, maar een medewerker kan het ook handmatig afsluiten. Deze gebeurtenis markeert het einde van de levenscyclus van het incident.
Waarom dit belangrijk is Deze activiteit is het definitieve eindpunt van het proces. De totale tijd tot deze gebeurtenis omvat de volledige levenscyclus van het incident, inclusief eventuele wachttijd op bevestiging van de gebruiker. Waar vind je dit? Afgeleid uit het activiteitenlogboek van het incident door te bepalen wanneer het veld 'Status' wordt bijgewerkt naar 'Closed'. Vastleggen Gebruik de timestamp van de logboekvermelding voor de statuswijziging naar 'Closed'. Gebeurtenistype inferred
	Incident opgelost	Dit markeert het moment waarop de agent een oplossing heeft toegepast en het incident als opgelost beschouwt. Je legt dit vast wanneer de status van het incident wordt gewijzigd in ‘Opgelost’. In Freshservice is dit een belangrijke mijlpaal die de SLA-klok stopt.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal voor het meten van de tijd tot oplossing (TTR). De periode tussen ‘Opgelost’ en ‘Gesloten’ is relevant voor het analyseren van vertragingen bij bevestiging door gebruikers en van automatisch sluitingsbeleid. Waar vind je dit? Afgeleid uit het activiteitenlogboek van het incident door te bepalen wanneer het veld 'Status' wordt bijgewerkt naar 'Resolved'. Vastleggen Gebruik de timestamp van de logboekvermelding voor de statuswijziging naar 'Resolved'. Gebeurtenistype inferred
	Incident toegewezen aan groep	Dit is de eerste toewijzing van een incident aan een supportgroep. Dit kan automatisch via routeringsregels gebeuren of handmatig door een medewerker die meldingen verdeelt. Je kunt deze activiteit vastleggen door in het auditspoor van het incident te volgen wanneer het veld ‘Groep’ voor het eerst wordt ingevuld.
Waarom dit belangrijk is Toewijzingen volgen is belangrijk om de eerste reactietijd te meten en bottlenecks in de verdeling van meldingen te vinden. Zo zie je hoe efficiënt incidenten bij het juiste team terechtkomen. Waar vind je dit? Afgeleid van de eerste vermelding in het activiteitenlog van het incident waarin het veld ‘Groep’ wordt ingevuld of gewijzigd. Vastleggen Zoek de eerste timestamp waarop het veld ‘Groep’ voor een incident wordt ingevuld. Gebeurtenistype inferred
	Oplossingsnotitie toegevoegd	Deze activiteit vindt plaats wanneer een agent de oplossing van een incident vastlegt in een oplossingsnotitie. Dit is een aparte handeling in Freshservice voordat de status wordt gewijzigd in ‘Opgelost’. De handeling en de inhoud van de notitie worden expliciet vastgelegd.
Waarom dit belangrijk is Dit markeert het moment waarop een oplossing is gevonden. De tijd tussen deze activiteit en de status ‘Incident opgelost’ kan wijzen op extra tijd voor interne beoordeling of documentatie. Waar vind je dit? Vastgelegd met de timestamp waarop een oplossingsnotitie aan het incident wordt toegevoegd. Deze staat in de gespreksgeschiedenis. Vastleggen Zoek de timestamp van de vermelding ‘Oplossingsnotitie’ in het gesprekslog van het incident. Gebeurtenistype explicit
	Prioriteit van incident ingesteld	Deze activiteit vindt plaats wanneer de prioriteit van een incident wordt ingesteld of gewijzigd. De prioriteit bepaalt hoe dringend het incident is en welke SLA-doelen gelden voor de oplossing. Je kunt dit vastleggen door wijzigingen in het veld ‘Prioriteit’ in de geschiedenis van het incident te volgen.
Waarom dit belangrijk is Een onjuiste of late prioritering kan leiden tot SLA-overschrijdingen en een inefficiënte inzet van middelen. Door deze activiteit te analyseren, zorg je ervoor dat kritieke incidenten meteen aandacht krijgen. Waar vind je dit? Afgeleid van het activiteitenlog van het incident, waarin alle wijzigingen in het veld ‘Prioriteit’ worden bijgehouden. Vastleggen Gebruik de timestamps uit het auditspoor waarop de waarde van het veld ‘Prioriteit’ is ingesteld of gewijzigd. Gebeurtenistype inferred
	Status gewijzigd in In behandeling	Deze activiteit markeert het officiële begin van het onderzoek en de werkzaamheden aan het incident. Je legt dit vast wanneer een agent de status van het incident wijzigt in ‘In behandeling’. Deze standaardstatuswijziging staat in de activiteitengeschiedenis van het ticket.
Waarom dit belangrijk is Met deze mijlpaal kun je wachttijd onderscheiden van actieve werktijd. De tijd dat een incident de status ‘In behandeling’ heeft, is belangrijk om te begrijpen hoeveel werk de oplossing vraagt. Waar vind je dit? Afgeleid uit het activiteitenlog van het incident door te bepalen wanneer het veld ‘Status’ wordt gewijzigd in ‘In behandeling’. Vastleggen Filter het activiteitenlog op een statuswijziging naar ‘In behandeling’ en gebruik de bijbehorende timestamp. Gebeurtenistype inferred
	Agent toegewezen aan incident	Deze activiteit markeert wanneer een specifieke agent de afhandeling van het incident krijgt toegewezen. Daarmee wordt de agent verantwoordelijk voor het ticket. De toewijzing staat in de activiteitengeschiedenis van het ticket, met de naam van de agent en het tijdstip.
Waarom dit belangrijk is Hiermee kun je de werkdruk en prestaties van agents analyseren en zien hoelang het na de toewijzing aan een groep duurt voordat een individuele agent het incident oppakt. Dit is belangrijk voor dashboards over agentprestaties. Waar vind je dit? Te volgen via wijzigingen in het veld ‘Agent’ in het activiteitenlog of auditspoor van het incident. Vastleggen Zoek de timestamps die horen bij wijzigingen in het veld ‘Agent’. Gebeurtenistype inferred
	Eerste reactie verzonden	Deze activiteit is het eerste bericht van een agent aan de gebruiker nadat het incident is gemeld. Dit kan een openbare notitie of een rechtstreeks antwoord zijn. Freshservice legt alle communicatie van agents vast met timestamps.
Waarom dit belangrijk is De SLA voor de eerste reactie halen is een belangrijke KPI voor klanttevredenheid. Met deze activiteit kun je meten en analyseren hoe snel agents op nieuwe incidenten reageren. Waar vind je dit? Bepaal de timestamp van de eerste openbare notitie of reactie van een agent in het gesprekslog van het incident. Vastleggen Filter de gespreksgeschiedenis van het incident op de eerste vermelding van een agent. Gebeurtenistype explicit
	Incident heropend	Dit gebeurt wanneer een incident dat eerder de status 'Resolved' had, weer een open status krijgt. Meestal is de gebruiker het dan niet eens met de oplossing. Je kunt dit afleiden uit een statuswijziging van 'Resolved' naar bijvoorbeeld 'Open' of 'In Progress'.
Waarom dit belangrijk is Een hoog percentage heropende incidenten wijst op problemen met de kwaliteit van de oplossing of op onvolledige oplossingen. Dit is een belangrijke metriek voor het analyseren van herstelwerk en de prestaties van medewerkers. Waar vind je dit? Afgeleid uit het activiteitenlogboek van het incident door een statuswijziging van 'Resolved' naar een actieve status te herkennen. Vastleggen Filter het activiteitenlogboek op een wijziging van 'Status' van 'Resolved' naar 'Open' of 'In Progress'. Gebeurtenistype inferred
	Incident opnieuw toegewezen	Dit geeft aan dat het incident is overgedragen van de ene agent of groep naar een andere. Zo’n gebeurtenis markeert een overdracht in het oplossingsproces. Je kunt dit afleiden uit wijzigingen in de velden ‘Agent’ of ‘Groep’ na de eerste toewijzing.
Waarom dit belangrijk is Veel nieuwe toewijzingen of overdrachten wijzen vaak op inefficiënte processen, kennishiaten of een onjuiste eerste routering. Door deze gebeurtenissen te analyseren, kun je vertragingen opsporen en beperken. Waar vind je dit? Afgeleid uit het activiteitenlog van het incident door wijzigingen in de velden ‘Agent’ of ‘Groep’ na de eerste toewijzing te volgen. Vastleggen Zoek in het auditspoor van het ticket naar wijzigingen in de velden ‘Agent’ of ‘Groep’. Gebeurtenistype inferred
	SLA-doelstelling overschreden	Dit is een berekende gebeurtenis die optreedt wanneer de verstreken tijd voor een incident de vastgestelde SLA-doelstelling voor reactie of oplossing overschrijdt. Freshservice houdt de SLA-status intern bij. Je kunt deze gebeurtenis afleiden door timestamps te vergelijken met de SLA-beleidsregels.
Waarom dit belangrijk is Meet rechtstreeks of de afspraken over serviceniveaus worden nagekomen. Het is belangrijk om vast te stellen wanneer en waarom SLA-doelstellingen worden overschreden. Dat is nodig voor het SLA-prestaties-dashboard en voor continue verbetering. Waar vind je dit? Berekend door de timestamp van de oplossing of reactie te vergelijken met de uiterste tijd volgens de SLA-doelstelling. Freshservice markeert tickets vaak als 'SLA Violated'. Vastleggen Leid dit af door de timestamp 'Resolved at' te vergelijken met 'Due by', of wanneer het veld 'SLA Status' verandert in 'Violated'. Gebeurtenistype calculated
	Status gewijzigd in In afwachting	Dit markeert een pauze in het oplossingsproces, meestal omdat er informatie van de gebruiker of een derde partij nodig is. Je kunt dit afleiden uit een statuswijziging naar een status ‘In afwachting’. De tijd in deze status telt vaak niet mee voor de SLA-berekening.
Waarom dit belangrijk is De tijd in statussen waarin een incident in afwachting is, laat zien waar je afhankelijk bent van anderen en waar vertraging ontstaat. Zo kun je de werktijd van agents onderscheiden van wachttijd. Waar vind je dit? Afgeleid uit het activiteitenlog van het incident wanneer het veld ‘Status’ wordt gewijzigd in bijvoorbeeld ‘In afwachting’ of ‘Wacht op reactie van gebruiker’. Vastleggen Filter het activiteitenlog op statuswijzigingen naar een status waarin het incident in afwachting is en gebruik de bijbehorende timestamp. Gebeurtenistype inferred
	Workaround aangeboden	Deze activiteit betekent dat een tijdelijke oplossing of workaround met de gebruiker is gedeeld om de impact van het incident te beperken. Om dit vast te leggen, moet het systeem vaak specifiek zijn ingericht, bijvoorbeeld met een apart selectievakje, een bepaald type notitie of een zoekopdracht naar trefwoorden in notities van agents.
Waarom dit belangrijk is Zo kun je analyseren hoe goed workarounds de impact op de bedrijfsvoering beperken en hoe ze samenhangen met de uiteindelijke oplostijd. Dit ondersteunt het dashboard voor statistieken over de effectiviteit van workarounds. Waar vind je dit? Waarschijnlijk is dit geen expliciete gebeurtenis. Je kunt de activiteit afleiden door notities met trefwoorden zoals ‘workaround’ te markeren, of door wijzigingen bij te houden in een aangepast selectievakje ‘Workaround aangeboden’. Vastleggen Afgeleid van een wijziging in een aangepast veld of een analyse van trefwoorden in notities van agents. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit Freshservice

Stappen

Open Freshservice Analyse: Meld je aan bij je Freshservice-omgeving met een account dat rapporten mag bekijken en maken. Open de module Analyse via het hoofdmenu.
Maak een nieuw rapport: Klik op de knop Nieuw rapport. Geef het rapport een duidelijke naam, bijvoorbeeld "Event log voor incidentbeheer". Selecteer de module Incidentbeheer wanneer je een databron moet kiezen.
Selecteer een rapportwidget: Voeg in de rapporteditor een widget toe en kies het type Tabel. Deze tabel vormt de basis voor je event log.
Voeg de belangrijkste datakolommen toe: Sleep de benodigde velden vanuit het gegevenspaneel rechts naar de kolominstellingen van de tabel. Begin met Incident-ID, Aangemaakt op, Medewerker, Groep, Prioriteit, Ernst, Status en Categorie.
Voeg activiteitsdata toe: Om afzonderlijke gebeurtenissen vast te leggen, moet je data uit de ticketactiviteiten koppelen of opnemen. Voeg de databron Activiteiten toe aan de widget. Voeg vanuit deze bron Uitgevoerd op toe als timestamp van de gebeurtenis, plus Activiteitsbeschrijving of vergelijkbare velden die de wijziging beschrijven.
Maak een berekende kolom 'ActivityName': Dit is de belangrijkste stap. Maak een berekende kolom of formuleveld. Gebruik geneste IF-statements of een CASE-functie om ruwe activiteitsdata om te zetten naar de vereiste ActivityName-waarden. Raadpleeg het onderdeel Query voor de logica van elk van de 14 activiteiten.
Stel 'EventTimestamp' in: Maak nog een berekende kolom voor EventTimestamp. Gebruik voor de activiteit 'Incident gemeld' de timestamp waarop het incident is aangemaakt. Gebruik voor alle andere gebeurtenissen de timestamp Uitgevoerd op van de activiteit.
Stel rapportfilters in: Beperk de data met rapportfilters. Stel minimaal een datumbereikfilter in op het veld 'Aangemaakt op'. Een periode van de afgelopen 3 tot 6 maanden wordt aanbevolen. Voeg ook een filter toe zodat alleen tickets met 'Tickettype' 'Incident' worden opgenomen.
Voer het rapport uit en verfijn het: Voer het rapport uit om een voorbeeld van de data te maken. Controleer of de kolommen ActivityName en EventTimestamp correct worden gevuld. Pas formules en filters zo nodig aan.
Sla het rapport op en exporteer het: Sla het rapport op zodra de uitvoer klopt. Kies Exporteren en selecteer CSV als bestandsindeling.
Plan de export (optioneel): Voor doorlopende analyse kun je het rapport automatisch laten uitvoeren en exporteren. Stel een schema in, bijvoorbeeld dagelijks of wekelijks, zodat het CSV-bestand naar je e-mail of een andere bestemming wordt gestuurd.
Bereid de data voor om te uploaden: Open het geëxporteerde CSV-bestand. Hernoem de kolomkoppen zodat ze overeenkomen met het vereiste schema van ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, enzovoort. Voeg de vaste kolommen SourceSystem (met de waarde 'Freshservice') en LastDataUpdate (met de huidige timestamp) toe. Het bestand is nu klaar om te uploaden.

Configuratie

Module Analyse: Voor deze extractie heb je toegang nodig tot de module Freshservice Analyse. Deze is beschikbaar in uitgebreidere abonnementen, zoals Pro en Enterprise.
Vereiste rechten: Je account moet een rol hebben waarmee je rapporten in de module Analyse kunt maken, bewerken en uitvoeren.
Datumbereik: Stel een datumbereikfilter in op de aanmaakdatum van incidenten om de hoeveelheid data te beperken. Een voortschrijdende periode van 3 tot 6 maanden biedt een goede balans tussen historische context en prestaties.
Rapportfilters: Filter altijd op 'Tickettype' is gelijk aan 'Incident', zodat serviceaanvragen en andere tickettypen buiten de procesanalyse blijven.
Berekende velden: Deze methode maakt veel gebruik van berekende velden (formules) om voor elke gebeurtenis ActivityName en EventTimestamp af te leiden. Kennis van de formule-editor van Freshservice is handig.
Datavolume: Voor elk incident levert deze extractie meerdere rijen op, één per activiteit. Bij grote Freshservice-omgevingen kan het CSV-bestand daardoor erg groot worden. Dat kan de rapportgeneratie en exportsnelheid beïnvloeden.

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 dat Python 3.6 of hoger is geïnstalleerd, samen met de bibliotheken requests en pandas. Installeer ze met pip: pip install requests pandas.
Genereer een API-sleutel: Meld je als beheerder aan bij je Freshservice-omgeving. Open je profielinstellingen door rechtsboven op je profielfoto te klikken. Ga naar het onderdeel 'API Key' en kopieer je persoonlijke API-sleutel. Behandel deze sleutel als een wachtwoord.
Stel het script in: Sla de meegeleverde Python-code op je computer op in een bestand met de naam extract_freshservice_incidents.py.
Stel de parameters in: Open het scriptbestand in een teksteditor. Vervang de tijdelijke waarden voor FRESHSERVICE_DOMAIN (bijvoorbeeld 'yourcompany.freshservice.com'), API_KEY (de sleutel die je net hebt gekopieerd) en START_DATE_STR (de begindatum van de gewenste extractieperiode in de notatie 'YYYY-MM-DD').
Bekijk hoe het script werkt: Het script haalt eerst alle incidenttickets op die na de opgegeven begindatum zijn aangemaakt. Het doorloopt elke pagina met resultaten van de API. Voor elk ticket doet het een tweede API-aanroep om de gedetailleerde activiteitengeschiedenis op te halen.
Genereer het event log: Het script verwerkt de ticketgegevens en het activiteitenlogboek om records aan te maken voor elk van de 14 vereiste bedrijfsactiviteiten. 'Incident gemeld' wordt bijvoorbeeld afgeleid van de aanmaakdatum van het ticket. 'Status gewijzigd in In behandeling' komt voort uit een specifieke vermelding in het activiteitenlogboek.
Leid complexe gebeurtenissen af: Gebeurtenissen zoals 'SLA-doel overschreden' worden afgeleid. Het script controleert of de oplos-SLA van een ticket is overschreden. Zo ja, dan maakt het een gebeurtenis met de datum uit due_by als timestamp, het moment waarop de overschrijding plaatsvond.
Voer het script uit: Open een terminal of opdrachtprompt, ga naar de map waarin je het script hebt opgeslagen en voer het uit met de opdracht: python extract_freshservice_incidents.py.
Volg de uitvoering: Het script toont in de console de voortgang en het aantal verwerkte tickets. Afhankelijk van het aantal tickets en de API-limieten kan dit even duren.
Controleer de uitvoer: Na afloop maakt het script in dezelfde map een CSV-bestand met de naam freshservice_incident_event_log.csv. Dit bestand bevat het volledige event log.
Maak het bestand klaar om te uploaden: Open het CSV-bestand in een spreadsheetprogramma en controleer of de kolommen (IncidentId, ActivityName, EventTimestamp enzovoort) de verwachte waarden bevatten. Het bestand is nu klaar om te uploaden naar ProcessMind of een andere process mining-tool.

Configuratie

FRESHSERVICE_DOMAIN: De specifieke Freshservice-URL van je bedrijf, bijvoorbeeld mycompany.freshservice.com. Dit is een verplichte parameter in het script.
API_KEY: De persoonlijke API-sleutel van een gebruiker met voldoende rechten om alle incidentdata te lezen. Dit is een verplichte parameter.
START_DATE_STR: De begindatum voor de data-extractie in de notatie 'YYYY-MM-DD'. Voor een bruikbare analyse wordt aanbevolen om aanvankelijk 3 tot 6 maanden aan data te extraheren.
PAGE_SIZE: Ingesteld op 100, het maximum dat de Freshservice API toestaat. Zo beperk je het aantal API-aanroepen en verbeter je de prestaties. Het is doorgaans niet aan te raden deze waarde te wijzigen.
API-limieten: Na het verwerken van elk ticket wacht het script met een eenvoudige time.sleep(1)-aanroep één seconde, zodat het binnen de API-limieten van Freshservice blijft. Bij omgevingen met veel data moet je dit mogelijk aanpassen om fouten te voorkomen.
Vereiste rechten: De gebruikte API-sleutel moet horen bij een gebruikersaccount, bijvoorbeeld een speciaal serviceaccount, met minimaal de rolrechten van 'SD Agent'. Zo heeft het account toegang tot alle benodigde ticketvelden en activiteitenlogboeken van verschillende servicedesk-groepen.

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

Controleer of je Freshservice-abonnement en beheerdersrechten toegang geven tot regels van Workflow Automator, webhookacties, incidenten en de activiteitengeschiedenis van tickets. Stem het bestemmingsendpoint, de authenticatiemethode, TLS-vereisten en het bewaarbeleid af met het ontvangende team.
Leg het gebeurteniscontract vast voordat je de automatisering instelt. Gebruik per webhooklevering één JSON-object met IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory en ResolutionSlaTargetTime. Stel de ontvanger zo in dat de oorspronkelijke webhookpayload en de bezorgtijd behouden blijven.
Maak een Workflow Automator-regel voor het aanmaken van incidenten. Stel de regel zo in dat deze wordt uitgevoerd wanneer een incident wordt aangemaakt. Voeg daarna een webhookactie toe die de activiteit Incident gemeld verstuurt. Stel EventTimestamp in op de aanmaaktimestamp van het incident en ActivityName op Incident gemeld.
Maak regels voor wijzigingen in toewijzing, prioriteit, status, communicatie, notities, SLA en afsluiting. Stel voorwaarden in op basis van de incidentvelden en activiteitengeschiedenis die beschikbaar zijn in je Freshservice-account. Elke regel moet bij de bijbehorende activiteit een afzonderlijke webhookgebeurtenis versturen. Vertrouw er niet op dat ProcessMind activiteiten afleidt uit een momentopname van een afgesloten incident.
Stel de activiteitenkoppeling expliciet in. Verstuur Incident toegewezen aan groep wanneer het veld Groep voor het eerst een waarde krijgt, Medewerker toegewezen aan incident wanneer het veld Medewerker voor het eerst een waarde krijgt, Incidentprioriteit gewijzigd wanneer Prioriteit wordt ingesteld of gewijzigd, Eerste reactie verstuurd wanneer de eerste in aanmerking komende openbare reactie of notitie van een medewerker wordt vastgelegd, Incident opnieuw toegewezen wanneer Medewerker of Groep na de eerste toewijzing verandert, Status gewijzigd in In behandeling en Status gewijzigd in In afwachting bij de bijbehorende statusovergangen, Tijdelijke oplossing geboden alleen wanneer een ingestelde indicator voor een tijdelijke oplossing aanwezig is, Oplossingsnotitie toegevoegd wanneer een oplossingsnotitie wordt toegevoegd, Incident opgelost wanneer de status verandert in Opgelost, SLA-doel overschreden wanneer aan de ingestelde voorwaarde voor SLA-overschrijding is voldaan, Incident heropend wanneer de status verandert van Opgelost naar een open status, en Incident gesloten wanneer de status verandert in Gesloten.
Stel de webhookaanvraag in op JSON en neem het incident-ID, de activiteitsnaam, de gebeurtenistimestamp, het bronsysteem, de laatste data-update en de aanbevolen contextuele attributen op. Gebruik de webhookvariabelen die in je Freshservice-account beschikbaar zijn. Is een vereiste variabele niet beschikbaar in de webhookeditor, vul deze dan in bij de ontvangende service via een goedgekeurde Freshservice-interface. Laat de waarde anders leeg, in plaats van iets te verzinnen.
Stel idempotentie en de afhandeling van leveringen in op het endpoint. Gebruik een stabiele gebeurtenis-ID als Freshservice die beschikbaar stelt. Maak anders een ontdubbelingssleutel op basis van IncidentId, ActivityName, EventTimestamp en de bron-ID van de levering. Geef pas een succesvolle HTTP-respons terug nadat de payload duurzaam is opgeslagen.
Test elke regel met gecontroleerde incidenten. Maak een incident aan, wijs een groep en medewerker toe, wijzig de prioriteit en status, verstuur een geschikte reactie en voeg waar ingesteld een tijdelijke oplossing en oplossingsnotitie toe. Los het incident op, heropen het en sluit het. Test een SLA-overschrijding afzonderlijk met een gecontroleerd beleid of een testwachtrij. Controleer of elke verwachte activiteit als afzonderlijke webhookpayload binnenkomt.
Sla de webhookpayloads op in een duurzame tussenopslag, zet timestamps om naar één tijdzone en zet elke payload om naar één rij in het event log. Behoud één rij per expliciete webhookactiviteit. Vul LastDataUpdate met de timestamp van de extractie of gegevensverversing, niet met de timestamp van de bedrijfsgebeurtenis.
Valideer het klaargezette event log, verwijder alleen exact dubbele leveringen en behoud legitieme herhaalde activiteiten, zoals meerdere prioriteitswijzigingen of statusovergangen. Controleer of IncidentId, ActivityName, EventTimestamp, SourceSystem en LastDataUpdate in elke rij aanwezig zijn.
Exporteer het genormaliseerde event log als CSV of een andere indeling die ProcessMind ondersteunt. Gebruik exact deze kolomnamen: IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory en ResolutionSlaTargetTime. Upload het bestand of koppel de voorbereide gebeurtenisbron aan ProcessMind. Wijs IncidentId toe als case-ID en ActivityName als activiteitsveld.

Configuratie

Bereik van triggers: Stel afzonderlijke Workflow Automator-regels in voor het aanmaken van incidenten en elke wijzigingsvoorwaarde. Eén brede regel voor wijzigingen kan dubbele of onduidelijke gebeurtenissen opleveren, tenzij de ontvanger activiteiten strikt koppelt.
Webhookpayload: Neem alle vereiste attributen op in elke payload. Voeg aanbevolen attributen toe als die op het moment van de gebeurtenis beschikbaar zijn. Bewaar de ruwe payload voor controle en opnieuw afspelen.
Betekenis van activiteiten: Maak onderscheid tussen de eerste toewijzing aan een groep of medewerker en latere wijzigingen. Latere wijzigingen leiden tot Incident opnieuw toegewezen. De eerste invulling leidt tot de bijbehorende activiteit voor de eerste toewijzing.
Statusafhandeling: Koppel de exacte statuswaarden die in het Freshservice-account zijn ingesteld. Als het account aangepaste statussen voor In afwachting of Open gebruikt, stel dan expliciete koppelingen voor die waarden in.
Eerste reactie: Bepaal of een openbare reactie, openbare notitie of ander communicatietype meetelt. Pas deze definitie consequent toe en verstuur de gebeurtenis alleen voor de eerste geschikte communicatie per incident.
Detectie van tijdelijke oplossingen: Stel hiervoor een apart veld, selectievakje, notitietype of goedgekeurde trefwoordregel in. Zonder zo’n instelling kun je de activiteit Tijdelijke oplossing geboden niet betrouwbaar vaststellen.
SLA-overschrijding: Stel een expliciete trigger voor SLA-overschrijding in, of gebruik een afzonderlijk gepland proces dat de huidige tijd vergelijkt met ResolutionSlaTargetTime. Alleen een momentopname van een afgesloten incident is niet genoeg om de timestamp van de overschrijding te reconstrueren.
Datumbereik: Gebruik voor de eerste validatie ongeveer 3 tot 6 maanden aan incidenten. Begin voor realtime gebruik met het inlezen van data vóór de analyseperiode en bewaar de webhookgeschiedenis om gebeurtenissen opnieuw af te spelen.
Filters: Gebruik alleen goedgekeurde filters voor bedrijf, workspace, afdeling, dienst, categorie of datum. Ga niet uit van Freshservice-veldnamen of filtersyntaxis die niet in de accountinstellingen beschikbaar zijn.
Prestaties: Verwerk webhooks asynchroon, zet binnenkomende aanvragen in een wachtrij, bundel vervolgbewerkingen en indexeer IncidentId en EventTimestamp. Voorkom synchrone verrijkingsaanroepen wanneer een webhook binnenkomt.
Betrouwbaarheid: Stel nieuwe pogingen, afhandeling van niet-bezorgde berichten, monitoring en onderdrukking van duplicaten in. Leg mislukte leveringen vast en speel ze na correctie opnieuw af.
Vereisten: Beheerdersrechten, toegang tot Workflow Automator en webhooks, een HTTPS-endpoint, ingestelde authenticatie, voldoende functies in het Freshservice-abonnement en een geschikte manier om data klaar te zetten of te uploaden naar ProcessMind.
Beveiliging: Gebruik HTTPS, beperk waar mogelijk inkomende toegang, ververs inloggegevens regelmatig, beperk gevoelige velden en bescherm incidentbeschrijvingen en notities als die in payloads staan.

Voorbeeldquery config

const REQUIRED_ACTIVITIES = [
  "Incident Reported",
  "Incident Assigned to Group",
  "Agent Assigned to Incident",
  "Incident Prioritized",
  "First Response Sent",
  "Incident Reassigned",
  "Status Changed to In Progress",
  "Status Changed to Pending",
  "Workaround Provided",
  "Resolution Note Added",
  "Incident Resolved",
  "SLA Target Breached",
  "Incident Reopened",
  "Incident Closed"
];

const REQUIRED_COLUMNS = [
  "IncidentId",
  "ActivityName",
  "EventTimestamp",
  "SourceSystem",
  "LastDataUpdate",
  "AssignedAgent",
  "AssignedGroup",
  "IncidentPriority",
  "IncidentSeverity",
  "IncidentStatus",
  "IncidentCategory",
  "ResolutionSlaTargetTime"
];

function normalizeTimestamp(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  const date = new Date(value);
  if (Number.isNaN(date.getTime())) {
    throw new Error("Invalid timestamp: " + String(value));
  }
  return date.toISOString();
}

function textOrNull(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  return String(value);
}

function getField(payload, names) {
  for (const name of names) {
    if (payload[name] !== undefined && payload[name] !== null) {
      return payload[name];
    }
  }
  return null;
}

function normalizeWebhookPayload(payload, receivedAt) {
  const incidentId = getField(payload, ["IncidentId", "incident_id", "ticket_id", "id"]);
  const activityName = getField(payload, ["ActivityName", "activity_name"]);
  const eventTimestamp = getField(payload, ["EventTimestamp", "event_timestamp", "timestamp", "created_at", "updated_at"]);

  if (incidentId === null || incidentId === "") {
    throw new Error("IncidentId is required");
  }
  if (activityName === null || activityName === "") {
    throw new Error("ActivityName is required");
  }
  if (!REQUIRED_ACTIVITIES.includes(String(activityName))) {
    throw new Error("Unsupported ActivityName: " + String(activityName));
  }
  if (eventTimestamp === null || eventTimestamp === "") {
    throw new Error("EventTimestamp is required");
  }

  const row = {
    IncidentId: textOrNull(incidentId),
    ActivityName: textOrNull(activityName),
    EventTimestamp: normalizeTimestamp(eventTimestamp),
    SourceSystem: textOrNull(getField(payload, ["SourceSystem", "source_system"])) || "Freshservice",
    LastDataUpdate: normalizeTimestamp(getField(payload, ["LastDataUpdate", "last_data_update"])) || normalizeTimestamp(receivedAt),
    AssignedAgent: textOrNull(getField(payload, ["AssignedAgent", "assigned_agent", "agent"])),
    AssignedGroup: textOrNull(getField(payload, ["AssignedGroup", "assigned_group", "group"])),
    IncidentPriority: textOrNull(getField(payload, ["IncidentPriority", "incident_priority", "priority"])),
    IncidentSeverity: textOrNull(getField(payload, ["IncidentSeverity", "incident_severity", "severity"])),
    IncidentStatus: textOrNull(getField(payload, ["IncidentStatus", "incident_status", "status"])),
    IncidentCategory: textOrNull(getField(payload, ["IncidentCategory", "incident_category", "category"])),
    ResolutionSlaTargetTime: normalizeTimestamp(getField(payload, ["ResolutionSlaTargetTime", "resolution_sla_target_time"]))
  };

  for (const column of REQUIRED_COLUMNS) {
    if (!(column in row)) {
      throw new Error("Missing output column: " + column);
    }
  }
  return row;
}

function deduplicateRows(rows) {
  const seen = new Set();
  return rows.filter((row) => {
    const key = [
      row.IncidentId,
      row.ActivityName,
      row.EventTimestamp,
      row.SourceSystem
    ].join("|");
    if (seen.has(key)) {
      return false;
    }
    seen.add(key);
    return true;
  });
}

async function processWebhookBatch(webhookPayloads, receivedAt) {
  const rows = webhookPayloads.map((payload) => normalizeWebhookPayload(payload, receivedAt));
  const deduplicatedRows = deduplicateRows(rows);
  deduplicatedRows.sort((left, right) => {
    if (left.IncidentId !== right.IncidentId) {
      return left.IncidentId.localeCompare(right.IncidentId);
    }
    return left.EventTimestamp.localeCompare(right.EventTimestamp);
  });
  return deduplicatedRows;
}

module.exports = {
  REQUIRED_ACTIVITIES,
  REQUIRED_COLUMNS,
  normalizeWebhookPayload,
  deduplicateRows,
  processWebhookBatch
};

Klaar om te beginnen?

Gebruik deze template om je data goed in te richten en inzicht te krijgen in workflows voor incidentbeheer. Begin vandaag met het verbeteren van de oplostijden.

Terug naar de verbetergids

Template downloaden

Voorkom SLA-overschrijdingen: verbeter incidentbeheer vandaag

Sluit je aan bij bedrijven die hun MTTR met 35% verlagen en kostbare SLA-overschrijdingen voorkomen.

Start je gratis proefperiode

14 dagen gratis proberen, zonder creditcard.

Datatemplate voor incidentbeheer

Datatemplate voor incidentbeheer

Attributen voor incidentbeheer

Activiteiten voor incidentbeheer

Extractiegidsen

Data-export naar CSV vanuit de Freshservice-module Analyse

Stappen

Configuratie

Voorbeeldquery config

Data extraheren met een Python-script via de Freshservice REST API

Stappen

Configuratie

Voorbeeldquery python

Realtime data versturen via webhooks van Workflow Automator

Stappen

Configuratie

Voorbeeldquery config

Klaar om te beginnen?

Voorkom SLA-overschrijdingen: verbeter incidentbeheer vandaag