Zo bouw je de servicedeskpost in je begroting voor 2027

Het begrotingsseizoen is de enige tijd van het jaar waarin de servicedesk om geld kan pleiten zonder dat er een brand woedt. De meeste teams verspillen het. Ze kopiëren de post van vorig jaar, tellen er een percentage voor inflatie bij op, en sturen het door. Dat levert je een servicedesk op die elk jaar een beetje meer kost en niets verbetert. Een betere post voor 2027 scheidt wat de boel draaiende houdt van wat echt een getal beweegt, en laat een klein, eerlijk vak over om automatisering te proberen zonder er het hele jaar op te gokken.

Deze post gaat over hoe je die post opbouwt. Niet het ROI-rekenwerk, dat staat in hoe je de ROI van AI op je servicedesk berekent, en niet het intern verkopen ervan, dat staat in de interne businesscase bouwen voor een AI-servicedesk. Dit is het begroten zelf: wat waar hoort, en wat er bewust buiten blijft.

Scheid vaste lasten van verbeterbudget

De eerste stap is stoppen de servicedeskbegroting als één getal te behandelen. Het zijn er twee.

Vaste lasten zijn wat nodig is om de desk precies te laten draaien zoals hij vandaag draait. Personeel, de licentie van je ITSM-platform, telefoon- en kanaaltooling, de dingen die nog steeds hetzelfde zouden kosten als je niets veranderde. Dit is het saaie deel en dat hoort saai te zijn. Begroot het nauwkeurig, benoem de bekende stijgingen, en pomp het niet op. Vaste lasten oppompen om verborgen ruimte voor projecten te maken is hoe finance je cijfers niet meer vertrouwt.

Verbeterbudget is het deel dat iets hoort te veranderen. Nieuwe capaciteit, automatisering, een trainingsimpuls, een tool-wissel als er echt een nodig is. Dit is het interessante deel en hier vindt het gesprek over de toekomst van de desk daadwerkelijk plaats. De meeste desks financieren dit te krap omdat de vaste kant alles opeet, en vragen zich dan af waarom de desk er jaar na jaar hetzelfde uitziet.

De twee scheiden doet meteen één nuttig ding: het maakt het verbeterbudget zichtbaar als een keuze. Als het verstopt zit in één post, beslist niemand erover. Als het op zichzelf staat, moet iemand ernaar kijken en vragen wat het gaat opleveren. Die vraag is het hele punt.

Waar automatisering echt in de begroting hoort

Automatisering is geen vaste last en eigenlijk ook geen kapitaalproject. Het zit in het verbeterbudget, en het hoort daar als een specifieke, afgebakende post in plaats van een vage "AI-initiatief"-toewijzing.

De reden om het specifiek te houden is dat een vage post een vaag debat uitlokt. "Budget voor AI" wordt in het abstracte bediscussieerd, waar het concurreert met elk ander modewoord dat iemand ergens las. Een post die zegt "draai een afgebakende automatiseringspilot op de repetitieve ticketcategorieën, gemeten tegen onze huidige eerste-reactietijd" is iets wat een budgethouder daadwerkelijk kan goedkeuren, want hij benoemt wat het doet en hoe je weet of het werkte. Koppel het aan een metric die je al bijhoudt. Onze post over servicedesk-KPI's behandelt welke getallen het waard zijn om er een budgetdoel aan te hangen, en welke alleen goed staan op een dashboard.

Eén praktische noot over hoe de kosten zich gedragen. Een laag-erbovenop-aanpak, waarbij de AI bovenop je bestaande ITSM-platform zit via de webhooks in plaats van het te vervangen, is doorgaans een voorspelbare draaiende kost in plaats van een grote investering vooraf. Dat maakt het makkelijker in te passen in het verbeterbudget als een maandpost die je kunt stopzetten, in plaats van een project dat je moet uitzitten. Begroot het als iets omkeerbaars, want dat is het.

Reserveer ruimte voor een pilot zonder een project te beloven

Hier zit de spanning die elke IT-manager voelt in het begrotingsseizoen. Je wilt AI op de desk proberen. Je wilt niet opstaan en een transformatieprogramma beloven, want je hebt die zien uitlopen en je weet dat een belofte die je niet kunt waarmaken je volgend jaar geloofwaardigheid kost.

De uitweg is een pilot begroten, geen project. Een pilot is klein, afgebakend, en heeft een uitgang. Je vraagt genoeg om automatisering een paar weken in shadow mode te draaien op je eigen tickets, te meten wat het daadwerkelijk doet, en op basis van data te beslissen of je doorgaat. Dat is een bescheiden, verdedigbaar getal, en cruciaal is dat het je nergens aan bindt na de pilot. Als de pilot tegenvalt stop je, en heb je een klein bedrag uitgegeven om iets echts te leren in plaats van een groot bedrag om het te laat te leren.

Shadow mode is wat deze kadering eerlijk maakt in plaats van een uitvlucht. Tijdens de pilot leest de AI echte tickets en schrijft zijn analyse als interne notities die het team ziet, zonder iets naar gebruikers te sturen of iets af te sluiten. "Pilot" is dus geen eufemisme voor "het dunne uiteinde van een grote toezegging." Het is echt een meetoefening met een schone stop. Hoe je er een draait beschrijven we in een AI-uitrol draaien in shadow mode.

Kader de budgetvraag daarnaar. Niet "financiering voor onze AI-transformatie." Maar "een klein gereserveerd bedrag om een automatiseringspilot te draaien en te meten, met een go of no-go aan het eind." Budgethouders keuren afgebakende experimenten veel makkelijker goed dan open programma's, en deze kadering klopt ook gewoon beter met wat je daadwerkelijk zou moeten doen.

Om het concreet te houden zonder cijfers te verzinnen: zie het verbeterbudget als drie stukken, het grootste voor bekende toegezegde verbeteringen, een middenstuk voor geplande tooling of training, en een klein stuk gereserveerd voor de pilot. Die verhoudingen zijn illustratief, geen formule. Het gereserveerde pilotstuk is het kleinste, en dat is het punt, het moet klein genoeg zijn dat een no-go bijna niets kost.

Wat je niet moet begroten

Een goede begroting gaat net zozeer over wat je weglaat. Twee dingen worden begroot die dat meestal niet zouden moeten.

Het eerste is een tool-migratie die je niet nodig hebt. Er is een reflex, wanneer een team nieuwe capaciteit wil, om aan te nemen dat het huidige ITSM-platform vervangen moet worden om die te krijgen. Voor AI-automatisering klopt dat meestal niet. Freshservice, TOPdesk, ServiceNow, Halo, Zendesk en Jira Service Management zijn stuk voor stuk capabele platforms, en moderne automatisering legt zich erbovenop via hun bestaande webhooks. Als je platform werkt, is een migratie begroten om AI te krijgen een groot, traag, risicovol project begroten om een probleem op te lossen dat een klein laagje oplost. Zet geen migratie in de post voor 2027 tenzij het platform zelf het probleem is, los van AI. Dit is de minst glamoureuze post die je kunt schrappen en vaak de duurste.

Het tweede is een personeelsplan gebouwd op automatiseringsbesparingen die je nog niet hebt bewezen. Het is verleidelijk om de bezetting van volgend jaar te begroten op de aanname dat automatisering een deel van de last opvangt. Doe het niet, totdat een pilot je de echte opvanggraad heeft laten zien. Een personeelskrimp begroten tegen een onbewezen besparingsgetal is hoe je in Q2 onderbezet zit als de automatisering minder dekte dan de slide beloofde. Bewijs de graad eerst, plan daarna de bezetting, niet andersom.

Er is nog een subtieler ding om te vermijden: begroten voor schaal voordat je hebt begroot voor bewijs. Zet geen volledige uitrol in de post voor 2027 als toegezegd getal terwijl je de pilot die het rechtvaardigt niet hebt gedraaid. Reserveer de pilot, en behandel de uitrol als een beslissing die de pilot informeert, geen uitgemaakte post. Dit weerspiegelt het bredere punt in de AI-strategie van een IT-manager: rangschik de uitgave zo dat elke stap de volgende verdient.

Veelgestelde vragen

Hoeveel van de servicedeskbegroting hoort naar verbetering te gaan?

Er is geen universele fractie, en elk getal dat iemand je noemt is een gok over een desk die niet de jouwe is. De nuttige discipline is simpelweg om het verbeterbudget een zichtbare post te maken in plaats van iets dat opgaat in vaste lasten, zodat het elk jaar een bewuste beslissing is en geen ongeluk.

Waar zit een AI-pilot in de begrotingsstructuur?

In het verbeterbudget, als een klein gereserveerd vak gekaderd als een afgebakende, meetbare pilot in plaats van een project. Houd het specifiek, koppel het aan een metric die je al bijhoudt, en dimensioneer het zo dat een no-go aan het eind bijna niets kost.

Moet ik begroten om mijn ITSM-platform te vervangen om AI te krijgen?

Meestal niet. Als je huidige platform werkt, legt moderne automatisering zich erbovenop via de bestaande webhooks, dus een migratie is een groot project dat een probleem oplost dat een klein laagje al oplost. Begroot alleen een migratie als het platform zelf het probleem is om redenen los van AI.

Kan ik de bezettingsbesparing van automatisering vooraf begroten?

Niet voordat een pilot de echte opvanggraad bewijst. Een personeelskrimp begroten tegen een onbewezen besparingsgetal is hoe een desk onderbezet raakt als automatisering minder dekt dan verwacht. Meet eerst, plan daarna de bezetting.

Begroot het saaie deel nauwkeurig, reserveer een klein eerlijk vak om het interessante deel te bewijzen, en laat de migratie die je niet nodig hebt helemaal buiten de post. Echte service door echte mensen volgend jaar, met het administratieve geploeter overgelaten aan machines, begint met een post voor 2027 die bewijs financiert vóór schaal.