Gegenereerd door AI via Proxuma Power BI MCP-server. Tickettype-verdeling over 67.521 records uit Autotask PSA. Omvat 5 tickettypes, 41 issuecategorieën en 127 sub-typen met uitsplitsing naar prioriteit en wachtrij.
Gegenereerd door AI via Proxuma Power BI MCP-server. Tickettype-verdeling over 67.521 records uit Autotask PSA. Omvat 5 tickettypes, 41 issuecategorieën en 127 sub-typen met uitsplitsing naar prioriteit en wachtrij.
De data dekt het volledige bereik van Autotask PSA-records die relevant zijn voor deze analyse, uitgesplitst naar de belangrijkste dimensies die je team nodig heeft voor dagelijkse beslissingen en klantrapportage.
Wie dit zou moeten gebruiken: Service desk managers, dispatch leads, and operations teams
Hoe vaak: Dagelijks for queue management, weekly for trend analysis, monthly for capacity planning
Gegenereerd door AI via Proxuma Power BI MCP-server. Tickettype-verdeling over 67.521 records uit Autotask PSA. Omvat 5 tickettypes, 41 issuecategorieën en 127 sub-typen met uitsplitsing naar prioriteit en wachtrij.
EVALUATE TOPN(10, SUMMARIZECOLUMNS('BI_Autotask_Tickets'[ticket_category_name], "TicketCount", COUNTROWS('BI_Autotask_Tickets')), [TicketCount], DESC)Tickettype-uitsplitsing op aantallen, aandeel en gemiddeld aantal gewerkte uren per ticket.
Incidents en Alerts samen zijn goed voor 70,3% van het totale ticketvolume — dat is je reactieve werklast. Je engineers brengen het grootste deel van hun tijd door met reageren op dingen die al fout zijn gegaan of zijn gedetecteerd door monitoringssystemen. Serviceaanvragen voegen nog eens 18,7% toe, waarna Wijzigingsverzoeken op 10,7% staan en Problemen op een statistisch kleine maar onevenredig dure 0,2%.
Het gemiddeld aantal uren per ticket vertelt per type een scherp ander verhaal. Alerts gemiddeld slechts 0,58 uur, wat suggereert dat veel snel worden opgelost of minimale triage vereisen. Probleemtickets zitten aan de andere kant: 6,00 uur elk. Dat factor-10-verschil is precies waarom correcte ticketclassificatie relevant is voor capaciteitsplanning.
| Tickettype | Aantal | % Aandeel | Gem. Uren | Volume |
|---|---|---|---|---|
| Incident | 27.664 | 41,0% | 0,80u | Reactief |
| Alert | 19.790 | 29,3% | 0,58u | Monitoring |
| Serviceaanvraag | 12.653 | 18,7% | 1,05u | Proactief |
| Wijzigingsverzoek | 7.247 | 10,7% | 1,12u | Gepland |
| Probleem | 167 | 0,2% | 6,00u | Oorzaakanalyse |
EVALUATE
ADDCOLUMNS(
SUMMARIZE('BI_Autotask_Tickets', 'BI_Autotask_Tickets'[ticket_type_name]),
"Ticket Count", CALCULATE(COUNTROWS('BI_Autotask_Tickets')),
"Pct", DIVIDE(CALCULATE(COUNTROWS('BI_Autotask_Tickets')), COUNTROWS('BI_Autotask_Tickets')) * 100,
"Avg Hours", CALCULATE(AVERAGE('BI_Autotask_Tickets'[worked_hours]))
)
ORDER BY [Ticket Count] DESCPrioriteitsverdeling voor Incidents, met een opvallende anomalie in gemiddelde uren van P2 versus P1.
De meeste Incidents vallen op P4 Laag (55,1%) of P3 Medium (31,6%). Dat is verwacht voor een gezonde servicedesk, de meeste gebruikersmeldingen zijn niet kritiek. Wat opvalt is de P2/P1-omgekeerde: P2 Hoog-incidents gemiddeld 1,87 uur, terwijl P1 Kritisch gemiddeld 1,71 uur kost. P1-tickets zouden sneller moeten worden opgelost dan P2, niet langzamer. De meest waarschijnlijke verklaring: P1-tickets activeren onmiddellijke escalatie met toegewezen engineers, waardoor ze snel worden opgelost zelfs als ze complex zijn. P2-tickets kunnen langer in een standaardwachtrij blijven staan voordat escalatie plaatsvindt.
Voor Alerts is de prioriteitsverdeling opmerkelijk verspreid over alle vier niveaus (P4: 5.264, P1: 4.846, P3: 4.522, P2: 892). Die gelijkmatige verspreiding over P4 en P1 suggereert dat je monitoringsregels mogelijk niet consistent zijn gekalibreerd, of dat alerternst in je RMM niet altijd netjes vertaalt naar Autotask-prioriteitsniveaus.
| Prioriteit | Incidents | % van Incidents | Gem. Uren | Signaal |
|---|---|---|---|---|
| P4 — Laag | 15.233 | 55,1% | 0,72u | Verwachte meerderheid |
| P3 — Medium | 8.753 | 31,6% | 0,88u | Normaal |
| Service/Wijziging | 2.750 | 9,9% | 0,81u | Gemengd |
| P2 — Hoog | 774 | 2,8% | 1,87u | Anomalie: trager dan P1 |
| P1 — Kritisch | 154 | 0,6% | 1,71u | Kalibratie controleren |
EVALUATE
ADDCOLUMNS(
SUMMARIZE('BI_Autotask_Tickets',
'BI_Autotask_Tickets'[ticket_type_name],
'BI_Autotask_Tickets'[priority_name]
),
"Ticket Count", CALCULATE(COUNTROWS('BI_Autotask_Tickets')),
"Avg Hours", CALCULATE(AVERAGE('BI_Autotask_Tickets'[worked_hours]))
)
ORDER BY 'BI_Autotask_Tickets'[ticket_type_name], [Ticket Count] DESCWachtrijverdeling per tickettype onthult personeelsafstemming en automatiseringskansen.
L1 is je hoogstvolume-wachtrij voor zowel Incidents (52%, 14.511 tickets) als Serviceaanvragen (68%, 8.571 tickets). Dat is een gezond patroon: frontline engineers absorberen het bulk van reactief en aanvraagwerk. Het interessantere getal is Alerts: 53% routeert via Gecentraliseerde Services (10.546 tickets), met nog eens 20% naar L1. Die centralisatie is al een structureel voordeel. Het betekent dat jouw organisatie effectief een automatiseringsklare laag heeft gecreëerd voor monitoringsgebeurtenissen.
Probleemtickets vertellen een ander verhaal: 76% belandt in de Customer Success-wachtrij (127 tickets). Dat is logisch als je CSM's oorzaakgesprekken voeren met klanten, maar het is de moeite waard om te bevestigen of die 127 probleemtickets worden bewerkt met de diepte die ze nodig hebben, gezien probleemtickets in een professional services-context gemiddeld 62,9 uur kosten wanneer ze serieus worden onderzocht.
| Tickettype | Primaire Wachtrij | Aantal | % van Type | Secundaire Wachtrij | Aantal |
|---|---|---|---|---|---|
| Incident | L1 | 14.511 | 52% | Gecentraliseerde Services | 5.918 |
| Alert | Gecentraliseerde Services | 10.546 | 53% | L1 | 4.022 |
| Serviceaanvraag | L1 | 8.571 | 68% | L2 | 1.029 |
| Wijzigingsverzoek | L1 | 4.272 | 59% | L2 | 928 |
| Probleem | Customer Success | 127 | 76% | Gecentraliseerde Services | 13 |
EVALUATE
ADDCOLUMNS(
SUMMARIZE('BI_Autotask_Tickets',
'BI_Autotask_Tickets'[ticket_type_name],
'BI_Autotask_Tickets'[queue_name]
),
"Ticket Count", CALCULATE(COUNTROWS('BI_Autotask_Tickets')),
"Avg Hours", CALCULATE(AVERAGE('BI_Autotask_Tickets'[worked_hours])),
"FRM Pct", CALCULATE(AVERAGE('BI_Autotask_Tickets'[first_response_met]))
)
ORDER BY 'BI_Autotask_Tickets'[ticket_type_name], [Ticket Count] DESCVijf inzichten waar je servicemanager actie op kan ondernemen.
Je team brengt het grootste deel van zijn tijd door met reageren op gebeurtenissen in plaats van gepland werk te leveren. Dat is niet inherent verkeerd voor een MSP, maar het stelt een plafond aan proactieve dienstverlening. Bijhouden of dit aandeel in de loop der tijd verschuift, is een nuttig signaal voor of de omgevingen van je klanten stabieler worden.
19.790 Alerts à 0,58 uur elk vertegenwoordigen ruwweg 11.478 uur engineertijd. Zelfs 30% van die alerts automatiseren zou jaarlijks meer dan 3.400 uur vrijmaken. De vraag die je moet stellen: welke alertcategorieën sluiten consistent zonder betekenisvolle engineeractie? Dat zijn je eerste automatiseringskandidaten.
Wanneer Hoog-prioriteitstickets consistent meer tijd kosten dan Kritisch-prioriteitstickets, betekent dit doorgaans dat je P1-escalatiepad werkt (toegewezen engineers, onmiddellijke respons) terwijl P2-tickets in standaardwachtrijen staan te wachten. Controleer of je P2-SLA en escalatietriggers aansluiten bij de werkelijke urgentie die die tickets vertegenwoordigen.
167 probleemtickets met gemiddeld 6,00 uur elk vertegenwoordigt 1.002 uur oorzaakanalysewerk. Het lage volume kan erop wijzen dat je team niet altijd formele Probleem-records aanmaakt na herhaalde incidents. Dat proces formaliseren kan systeemische problemen blootleggen die individuele incidentresolutie mist.
Meer dan de helft van je alertvolume laten stromen via één wachtrij is structureel voordelig. Het creëert een consistente context voor automatiseringsregels, playbooks en RMM-integraties. De volgende stap is het controleren van de resolutiepatronen van die wachtrij om te ontdekken welke alerttypen naar auto-close of auto-remediate workflows kunnen worden verplaatst.
Veelgestelde vragen over ticketcategorieanalyse in Autotask PSA.
Een Incident is een handmatig aangemaakt ticket voor een door de gebruiker gerapporteerde verstoring. Een Alert wordt automatisch gegenereerd door je RMM of monitoringstool wanneer een drempelwaarde wordt overschreden. Alerts vertegenwoordigen door het systeem gedetecteerde gebeurtenissen; Incidents vertegenwoordigen door de gebruiker gevoelde impact. Het onderscheid is relevant voor automatisering: Alerts zijn kandidaten voor geautomatiseerde herstelacties, Incidents vereisen doorgaans eerst menselijke diagnose.
Problemen vertegenwoordigen in ITIL oorzaakanalyses: ze worden aangemaakt na meerdere gerelateerde incidents om de onderliggende oorzaak te vinden en op te lossen. Ze zijn zeldzaam omdat de meeste teams geen formeel Probleembeheerproces hebben, en wanneer ze wel worden geopend, vertegenwoordigen ze aanzienlijk onderzoekswerk. Als je problemen gemiddeld minder dan 2 uur kosten, is dat een signaal dat ze als categorielabel worden gebruikt in plaats van als echte oorzaakanalyse.
Niet allemaal, maar wel veel. Met 19.790 alerts met gemiddeld 0,58 uur is de vraag: welke sluiten consistent zonder betekenisvolle menselijke actie? Dat zijn kandidaten voor geautomatiseerde herstelacties. Alerts die regelmatig escaleren naar Incidents vereisen andere behandeling: ze kunnen echte infrastructuurlacunes aanwijzen. Begin met het segmenteren van je alerts op issuetype en kijk welke categorieën de laagste escalatierate en snelste resolutietijd hebben.
P1-tickets activeren onmiddellijke respons met toegewezen engineers, waardoor ze snel worden opgelost zelfs als ze complex zijn. P2-tickets kunnen langer in een wachtrij staan voordat escalatie plaatsvindt, wat verstreken tijd opeenstapelt. Het kan ook erop wijzen dat sommige complexe problemen als P2 worden gelogd terwijl ze eigenlijk P1 zouden moeten zijn. Controleer je P2-escalatietriggers en vergelijk de werktypen in elke groep om te bepalen of de prioriteitsdefinities consistent worden toegepast.
Stem je wachtrij-routing af op je ticketmix. L1 verwerkt 52% van de Incidents en 68% van de Serviceaanvragen: daar landt het volume. Gecentraliseerde Services verwerkt 53% van de Alerts: overweeg daar eerst automatiseringsinvesteringen. Technical Alignment verwerkt wijzigings- en servicewerk met ruwweg 3x de inspanning van L1: zet die engineers in voor diepgaand werk, niet voor ticketvolume. Begin bij de wachtrijen die de meeste uren absorberen, niet de meeste tickets.
Koppel Proxuma's Power BI integratie, gebruik een MCP-compatible AI om vragen te stellen en genereer op maat gemaakte rapporten - in minuten, niet in dagen.
Bekijk meer rapporten Aan de slag