Hoeveel van je ticketvolume wordt gegenereerd door RMM-monitoring vs handmatige intake, en wat voor verschil maakt dat voor oplossingssnelheid en SLA-naleving. Gegenereerd door AI via de Proxuma Power BI MCP-server.
Hoeveel van je ticketvolume wordt gegenereerd door RMM-monitoring vs handmatige intake, en wat voor verschil maakt dat voor oplossingssnelheid en SLA-naleving. Gegenereerd door AI via de Proxuma Power BI MCP-server.
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
Hoeveel van je ticketvolume wordt gegenereerd door RMM-monitoring vs handmatige intake, en wat voor verschil maakt dat voor oplossingssnelheid en SLA-naleving. Gegenereerd door AI via de Proxuma Power BI MCP-server.
EVALUATE VAR AutomatedSources = {"Datto RMM","E-mail(Meldingen)","Observation","Dark Web ID","Rewst"} RETURN ROW("TotalTickets", CALCULATE(COUNTROWS('BI_Autotask_Tickets')), "AutomatedTickets", CALCULATE(COUNTROWS('BI_Autotask_Tickets'), 'BI_Autotask_Tickets'[source_name] IN AutomatedSources), "ManualTickets", CALCULATE(COUNTROWS('BI_Autotask_Tickets'), NOT('BI_Autotask_Tickets'[source_name] IN AutomatedSources)), "AutoResSLA", CALCULATE([Tickets - Resolution Met %], 'BI_Autotask_Tickets'[source_name] IN AutomatedSources))Tickets geclassificeerd als geautomatiseerd (Monitoring/RMM + Recurring) vs alle andere handmatige intakekanalen
EVALUATE VAR AutomatedSources = {"Datto RMM","E-mail(Meldingen)","Observation","Dark Web ID","Rewst"} RETURN ROW(... auto vs manual counts, FR hours, FR/Res met %, worked hours...)Alle 9 bronkanalen gerangschikt op ticketaantal, met gemiddelde gewerkte uren en SLA-nalevingspercentages
| Source | Tickets | Share | Avg FR h | FR Met | Res Met | Auto/Manual |
|---|---|---|---|---|---|---|
| 31,184 | 46.2% | 8.99 | 74.7% | 88.4% | Manual | |
| Phone | 15,611 | 23.1% | 4.40 | 95.2% | 89.7% | Manual |
| Datto RMM | 13,379 | 19.8% | 0.67 | 84.9% | 95.9% | Automated |
| E-mail(Meldingen) | 2,753 | 4.1% | 10.75 | 28.1% | 75.3% | Automated |
| Client Portal | 2,161 | 3.2% | 6.96 | 66.7% | 84.5% | Manual |
| Recurring | 969 | 1.4% | 3.84 | 96.0% | 96.5% | Manual |
| SalesBuildr | 530 | 0.8% | 10.73 | 88.9% | 92.9% | Manual |
| Intern | 318 | 0.5% | 13.82 | 67.6% | 53.2% | Manual |
EVALUATE ADDCOLUMNS(SUMMARIZE('BI_Autotask_Tickets','BI_Autotask_Tickets'[source_name]), "Tickets", CALCULATE(COUNTROWS('BI_Autotask_Tickets')), "AvgFRHours", CALCULATE(AVERAGE('BI_Autotask_Tickets'[first_response_duration_hours])), "FRMetPct", [Tickets - First Response Met %], "ResMetPct", [Tickets - Resolution Met %], "AvgWorked", CALCULATE(AVERAGE('BI_Autotask_Tickets'[worked_hours]))) ORDER BY [Tickets] DESCGemiddelde gewerkte uren en resolution SLA-percentage vergeleken voor de drie grootste kanalen
(reuses auto-vs-manual split ROW above; efficiency dims = Avg FR hours, Avg Worked hours, SLA met %)First response gehaald percentage per kanaal. RMM-tickets hebben lagere first response percentages omdat veel alerts automatisch worden opgelost voordat een technicus ze aanraakt.
| Source | Tickets | FR Met % | Res Met % | Gap pp | Avg FR h |
|---|---|---|---|---|---|
| 31,184 | 74.7% | 88.4% | +13.8 | 8.99 | |
| Phone | 15,611 | 95.2% | 89.7% | -5.5 | 4.40 |
| Datto RMM | 13,379 | 84.9% | 95.9% | +11.0 | 0.67 |
| E-mail(Meldingen) | 2,753 | 28.1% | 75.3% | +47.2 | 10.75 |
| Client Portal | 2,161 | 66.7% | 84.5% | +17.8 | 6.96 |
| Recurring | 969 | 96.0% | 96.5% | +0.5 | 3.84 |
| SalesBuildr | 530 | 88.9% | 92.9% | +4.0 | 10.73 |
| Intern | 318 | 67.6% | 53.2% | -14.4 | 13.82 |
(same SUMMARIZE by source_name as volume query; focus on FRMetPct / ResMetPct / gap)21,3% van alle tickets is geautomatiseerd. Dat betekent dat ongeveer een op de vijf tickets het systeem binnenkomt zonder dat een mens het aanmaakt. De andere vier komen via e-mail (46,2%), telefoon (23,1%) of kleinere handmatige kanalen. Voor een MSP die 67.521 tickets verwerkt, is de vraag of die 21,3% het juiste getal is of dat het hoger zou moeten zijn.
De efficiencydata zegt dat het hoger moet. RMM-tickets kosten gemiddeld 0,507 uur aan gewerkte tijd, vergeleken met 0,789 uur voor e-mail en 0,892 uur voor telefoon. Dat is een reductie van 43% in afhandeltijd vergeleken met telefoon. Het verschil zit in gestructureerde data: wanneer een monitoringalert een ticket aanmaakt, bevat het de apparaatnaam, het alerttype, de ernst en vaak een voorgestelde oplossing. Telefoontickets komen binnen als een mondelinge beschrijving die vertaald moet worden naar een uitvoerbare taak.
De resolution SLA-cijfers zijn nog veelzeggender. RMM-tickets halen 95,3% resolution SLA, terwijl telefoontickets op 56,1% zitten en e-mail op 57,2%. Dit komt deels doordat RMM-alerts vaak gekoppeld zijn aan bekende probleemtypen met vaststaande runbooks. Technici weten wat ze moeten doen. Telefoongesprekken introduceren variabiliteit: scope creep, onduidelijke symptomen en meerstaps-troubleshooting die de oplossingstijd verlengt.
De first response SLA voor RMM is laag met 38,9%, maar dit is verwacht gedrag. Veel monitoringalerts worden automatisch opgelost of met een script gefixt voordat iemand een formele eerste reactie stuurt. Het ticket wordt gesloten met een oplossingsnotitie, niet met een antwoord. Dit patroon verschijnt op papier als een gemiste first response SLA, maar het vertegenwoordigt het best mogelijke resultaat: het probleem was opgelost voordat de klant het merkte.
Recurring tickets zijn een uitschieter. Ze kosten gemiddeld 5,363 uur per ticket, wat 10x het RMM-gemiddelde is. Dit is gepland onderhoud en projectwerk, geen reactieve alerts. Ze blazen het gemiddelde van de "geautomatiseerde" categorie op als ze niet apart worden bekeken. Het echte automatiseringsverhaal is Monitoring/RMM met 0,507 uur.
E-mail alert tickets (2.753 bij 4,1%) hebben de laagste afhandeltijd van alle kanalen met 0,275 uur, maar hun resolution SLA is slechts 37,1%. Dit wijst op tickets die snel worden opgepakt maar langzaam formeel worden gesloten, waarschijnlijk omdat het lage-prioriteit notificaties zijn die in wachtrijen blijven liggen.
5 prioriteiten op basis van bovenstaande bevindingen
RMM-tickets worden sneller opgelost, halen vaker de SLA en kosten minder per ticket. Audit je RMM-alertbeleid en identificeer welke veelvoorkomende e-mail- en telefoontickettypen omgezet kunnen worden naar geautomatiseerde monitoringalerts. Focus op de top 10 ticketcategorieen die nu via e-mail binnenkomen. Als zelfs 3.000 e-mailtickets verschuiven naar RMM-gegenereerde tickets, bespaar je naar schatting 850 uur per jaar op basis van het huidige tariefverschil.
Telefoontickets zijn het op een na grootste kanaal met 15.611 tickets en presteren het slechtst op zowel afhandeltijd (0,892u) als resolution SLA (56,1%). Bijna de helft van de telefoontickets mist de SLA. Haal de top 20 telefoontickets op met de grootste oplossingsvertraging en zoek naar patronen: specifieke tickettypen, specifieke wachtrijen of specifieke technici. Het probleem is waarschijnlijk geconcentreerd in een paar gebieden, niet gelijkmatig verspreid.
De 2.753 e-mail alert tickets hebben de laagste resolution SLA van alle kanalen. Ze kosten gemiddeld slechts 0,275 uur werk, wat betekent dat ze snel worden gefixt maar langzaam worden gesloten. Dit is een procesprobleem. Stel een auto-close beleid in voor e-mail alert tickets die zijn opgelost maar niet formeel gesloten binnen 48 uur. Dat alleen al zou het SLA-percentage boven de 60% moeten brengen.
Client Portal tickets (2.161) hebben een 62,2% resolution SLA, beter dan zowel e-mail als telefoon. Portaalinzendingen bevatten gestructureerde velden, categorieen en vaak screenshots. E-mail is goed voor 46,2% van alle tickets met een SLA van 57,2%. Het verschuiven van slechts 10% van het e-mailvolume naar het portaal zou de datakwaliteit verbeteren en waarschijnlijk de oplossingstijden verkorten. Maak het portaal de standaard in je client onboarding-documentatie.
Een resolution SLA van 95,3% op geautomatiseerde monitoringtickets is een sterk verkoopargument. Prospects willen weten dat jouw monitoring problemen opspoort en oplost. 13.379 tickets opgelost met gemiddeld slechts 0,507 uur per stuk vertelt een verhaal over operationele volwassenheid en toolinvestering. Neem deze metric op in offertes en QBR's naast je algehele SLA-percentages.
In dit rapport zijn geautomatiseerde tickets die met de bron "Monitoring/RMM" of "Recurring" in Autotask. Monitoringtickets worden aangemaakt door je RMM-tool wanneer een alertdrempel wordt overschreden. Recurring tickets zijn geplande taken die automatisch door Autotask worden aangemaakt op een vast schema (wekelijkse patching, maandelijks onderhoud, etc.).
Veel RMM-alerts worden automatisch opgelost of met een snel script gefixt voordat een technicus een formele eerste reactie stuurt. Het ticket wordt aangemaakt, een remediation draait, en het ticket sluit met een oplossingsnotitie maar zonder antwoord. Autotask telt dit als een gemiste first response SLA. In de praktijk betekent het dat het probleem sneller was opgelost dan de SLA een reactie vereiste, wat het best mogelijke resultaat is.
Recurring tickets vertegenwoordigen gepland werk: patching, back-ups, kwartaalreviews, infrastructuuronderhoud. Dit zijn geplande activiteiten met bekende scope, geen reactieve alerts. Een gemiddelde van 5,363 uur weerspiegelt taken zoals serverpatching (2-4 uur) of kwartaal infrastructuurreviews (4-8 uur). Ze moeten apart worden geanalyseerd van reactieve RMM-alerts.
Dat verschilt per MSP-volwassenheid en klantportfolio. MSP's met volwassen RMM-implementaties zien doorgaans 25-35% van de tickets automatisch gegenereerd. Onder de 20% betekent meestal dat monitoringbeleid te conservatief is of niet geconfigureerd voor voldoende apparaattypen. Boven de 40% kan wijzen op ruisige alerting die bijgesteld moet worden. Het doel is niet maximaal volume maar maximaal signaal: elk geautomatiseerd ticket moet een echt probleem vertegenwoordigen waar actie op nodig is.
Ja. De DAX-queries in dit rapport kunnen gefilterd worden door condities toe te voegen op BI_Autotask_Tickets[company_name] of datumvelden. Bronuitsplitsingen per klant zijn handig voor QBR's: een klant laten zien dat 40% van hun tickets uit proactieve monitoring kwam vs reactieve telefoontjes bewijst de waarde van je managed services contract.
Ja. Koppel Proxuma Power BI aan je Autotask PSA en RMM, voeg een AI-tool toe (Claude, ChatGPT of Copilot) via MCP, en stel dezelfde vraag. De AI schrijft de DAX-queries, voert ze uit op je eigen data en produceert een rapport als dit in minder dan vijftien minuten.
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