Ticketing ziet er op papier strak uit. Je krijgt de cijfers, de wachtrijen, de dashboards. Maar in werkelijkheid meet dat model alleen de pijn nadat het systeem al heeft gefaald. Het kostbare deel van het probleem begint meestal veel eerder. Het begint wanneer een medewerker 10 minuten verliest, dan 20, en uiteindelijk het opgeeft. Ze proberen het opnieuw. Ze vragen een collega. Ze missen de vergadering of delen het verkeerde bestand omdat de juiste weg niet meer werkte. En dat is het deel dat de meeste supportteams nog steeds niet zien. Het beste interne supportmodel van nu draait niet om snellere triage. Het draait om het volledig wegnemen van de noodzaak voor triage. Stel je een autonome agent in Microsoft 365 voor die de context observeert, wrijving vroeg opmerkt en actie onderneemt voordat iemand überhaupt denkt aan het openen van een portaal. In deze aflevering wil ik je laten zien waarom het helpdesk model faalt, wat het daadwerkelijk vervangt en hoe je dit kunt beheren zonder chaos te creëren.

Als deze verschuiving belangrijk is voor jouw werk, abonneer je dan op M365FM, want de niveau dieper is het echte probleem niet de wachtrij, maar het model erachter. De dood van het ticket. De oude supportflow is nog steeds overal aanwezig. Er gaat iets kapot. Een gebruiker merkt het op. De gebruiker probeert het uit te leggen. Vervolgens vertaalt die tedi uitleg naar een categorie, een prioriteit en misschien een toewijzingsgroep. Het probleem komt in een wachtrij terecht. Iemand voert de triage uit. Iemand anders vraagt om meer details. Een ander team wordt erbij betrokken. De tijd tikt door terwijl het echte werk stil blijft liggen. Dat proces voelt normaal omdat het vertrouwd is, maar vertrouwd en effectief zijn niet hetzelfde. Een ticket is geen support. Een ticket is het bewijs dat support te laat kwam. Tegen de tijd dat een ticket bestaat, heeft de medewerker al vertraging opgelopen en de context verloren.

Ze hebben hun aandacht al verlegd van het werk dat ze probeerden te doen. De wachtrij is niet de dienstverlening. De wachtrij is een registratie van falen. In grote Microsoft 365 omgevingen wordt handmatige triage het echte knelpunt. Dit gebeurt niet omdat support teams lui zijn. Het gebeurt omdat van mensen wordt gevraagd iets te doen dat niet langer past bij de schaal van de omgeving. Je hebt meer gebruikers, meer apparaten, meer apps, meer beleidsregels. Je hebt meer uitzonderingen die Teams, SharePoint, Exchange, Intune en Entra op exact hetzelfde moment door kruisen. Het volume groeit niet alleen. De combinaties groeien. Dat is waar het oude model breekt. De meeste Teams reageren door meer structuur toe te voegen. Ze bouwen nog een portaal, nog een bot of nog een routeringsregel. Maar in werkelijkheid voegt dat alleen maar een extra laag toe tussen de medewerker en de oplossing. Het systeem wacht nog steeds tot de gebruiker het probleem opmerkt, het beschrijft en op de juiste manier om hulp vraagt.

Werk begint niet in een support portal. Het begint in Teams, in Outlook, in een document dat iemand nu nodig heeft of een vergadering die over 30 seconden begint. Dat is waar de ondersteuningsvraag echt begint en het ticketmodel staat volledig los van dat moment. De verborgen kosten zijn veel groter dan je wachtrijrapport laat zien. Mensen schakelen constant tussen taken. Dubbele incidenten stapelen zich op onder verschillende labels. Kennisartikelen raken verouderd. Analisten besteden hun hele dag aan sorteren, doorsturen en verduidelijken in plaats van daadwerkelijk problemen op te lossen. De oplossingstijd rekt op omdat elke overdracht voor vertraging zorgt en elke vertraging verwijdert de oorspronkelijke context. Onderzoek naar agentgebaseerde AI en IT-operaties wijst op hetzelfde structurele probleem. Minstens 80% van de inzet zit nog steeds vast in reactief ITIL-achtig werk. Dat cijfer is belangrijk omdat het precies aangeeft waar de arbeid naartoe gaat.

Het gaat niet naar veerkracht of preventie, maar naar reactie. Zodra je dat ziet, lijkt het ticket minder op een bedrijfsmodel en meer op een symptoom. Het is een symptoom van een systeem dat pas reageert nadat de schade zichtbaar is. Dus de volgende vraag is niet hoe we tickets sneller verwerken, maar wat het systeem moet doen voordat een ticket überhaupt nodig is. Het model van de onzichtbare medewerker. Dus, wat vervangt eigenlijk het ticket? Het is niet zomaar weer een chatbot bovenop, dezelfde chaos, en het is zeker geen mooiere voordeur voor dezelfde oude wachtrij. De verschuiving gaat veel dieper dan dat omdat de onzichtbare medewerker een operationele werkkracht is die in je Microsoft 365 omgeving leeft. Deze agent heeft een eigen identiteit, een afgebakend takenpakket, geheugen van wat hij gisteren deed en strikte regels over wat hij wel en niet mag aanraken. Dat onderscheid is belangrijk.

Een chatbot wacht tot jij een prompt typt, maar een onzichtbare medewerker houdt veranderingen in omstandigheden in de gaten. Het vertrekt vanuit context in plaats van vanuit een gesprek. Omdat het inlogstatussen, apparaatgezondheid, licentiestatus en het delen van bestanden kan zien, hoeft het niet te wachten tot er frictie ontstaat. In plaats van te vragen hoe het kan helpen nadat iets kapot gaat, stelt het op de achtergrond constant een andere vraag. Wat wijkt af van de staat die deze medewerker nodig heeft om nu zijn werk te doen? Dat is waar de dingen veranderen. Het model is direct ingebed in het werk zelf. Wanneer iemand deelneemt aan een vergadering en de audiotoewijzing faalt, of een gast een zojuist verzonden bestand niet kan openen, creëert de oude wereld een rapport en een overdracht. In het nieuwe model herkent de agent het patroon direct, controleert of de situatie overeenkomt met een bekend probleem en voert de veilige actie uit om dit te herstellen.

Misschien reset het een pad of start het een beleidscontrole, of leidt het een verzoek om en vraagt om MFA voordat de oplossing wordt gedocumenteerd. Het punt is simpel. Bij de eerste reactie hoeft een mens niet langer een vage omschrijving te lezen en te raden wat er is gebeurd. Dit voelt onzichtbaar als het goed werkt omdat er geen wachtruimte is en geen selecteer een categorie, formulier om in te vullen. Ondersteuning uit zich als herstelde workflow. De medewerker gaat gewoon weer aan het werk en ziet in veel gevallen niet eens het systeem dat op de achtergrond draait. Je kunt al zien hoe dit je personeelslogica verandert. Het oude model neemt mensen aan om volume op te vangen, verzoeken te sorteren en verbroken verbanden tussen teams te herstellen. Het nieuwe model heeft minder mensen nodig voor triage en meer mensen die kaders ontwerpen, gewenste toestanden definiëren en toezien op het gedrag van deze agents.

Mensen blijven in het systeem, maar de hele vorm van hun dagelijkse werk verschuift. Onderzoek naar agentische AI in ondersteuning blijft in deze richting wijzen. Routine ondersteuning kan verschuiven naar uitzonderingsbeheer, wat enorme efficiëntiewinst oplevert wanneer de omgeving en het beleid goed zijn afgebakend. Dat laatste onderdeel is essentieel, want dit is geen magie. Als je data zwak is of je proces rommelig, wordt de agent niet slim alleen omdat je besluit hem autonoom te noemen. Dit werd mij duidelijk toen ik stopte met het zien van de agent als een softwarefunctie en hem ging beschouwen als een niet-menselijke werknemer met een badge. Een echte werknemer heeft een identiteit, een functieomschrijving, machtigingen en een manager nodig om aan te rapporteren. De agent heeft precies diezelfde dingen nodig omdat de waarde voortkomt uit betrouwbare actie in een systeem, niet uit slim taalgebruik in een chatvenster.

De onzichtbare werknemer is geen UI-truc. Het is een nieuwe ondersteuningslaag die toeziet op frictie binnen de Microsoft 365-omgeving, handelt volgens beleid en menselijke aandacht richt op uitzonderingen die daadwerkelijk beoordeling vereisen. Zodra dat model duidelijk is, hoort de volgende vraag heel praktisch. Hoe werkt Preempsi eigenlijk? De architectuur van Preempsi. Dus, hoe werkt Preempsi eigenlijk binnen Microsoft 365? De verschuiving gaat van verzoek en antwoord naar gebeurtenisredenering en orkestratie. Dat klinkt technisch, maar het model is simpel zodra je het uiteenzet. Eerst verandert er iets in de omgeving, dan interpreteert het systeem of die verandering risico of afwijking betekent, en tot slot voert het de goedgekeurde actie uit met de tools die al in je stack aanwezig zijn. Begin bij de gebeurtenislaag. Microsoft 365 produceert overal signalen, wat betekent dat entra-inloggedrag ziet terwijl in toen de status en compliance van apparaten bijhoudt.

Defender houdt verdachte activiteiten in de gaten en teams laat precies zien wanneer een vergadering mislukt of de gesprekskwaliteit afneemt. SharePoint en Exchange tonen toegangspatronen en inhoudsactiviteiten, terwijl signalen over de service status aangeven wanneer het platform zelf het probleem is. Wanneer je daar gebruikersacties aan toevoegt, heb je een constante stroom van context. De meeste organisaties verzamelen die signalen, maar slechts weinigen gebruiken ze daadwerkelijk als ondersteuningssysteem. Ruwe gebeurtenissen alleen helpen niet, want er is een reden neerlaag nodig om betekenis te geven aan de ruis. Dit is waar de onzichtbare medewerker stopt met het spelen van automatiseringstheater en begint te handelen als een echte operator. De agent bekijkt het signaal, vergelijkt de huidige status met de gewenste status en besluit welke actie veilig is om te ondernemen. Een audioprobleem bij een vergadering is niet hetzelfde als een riskante aanmelding en een kapotte gedeelde link is anders dan een licentiefout.

De agent moet het probleem eerst klassificeren, want actie ondernemen zonder klassificatie leidt alleen maar sneller tot fouten. Dan volgt de orkestratie. Zodra de agent het probleem begrijpt, kan hij het juiste mechanisme gebruiken om te reageren. Dat kan Power Automate zijn voor workflows, Copilot Studio voor logica of Microsoft Graph voor systeemacties en context. De tools zijn belangrijk, maar het grotere punt is hoe ze met elkaar verbonden zijn. Je bouwt niet één slimme prompt, maar een keten die kan detecteren, beslissen, handelen en verifiëren. Dat laatste onderdeel wordt telkens vergeten. Een zelfcorrigerend systeem stopt niet zodra de actie is uitgevoerd. Het draait een lus waarin het het probleem detecteert, de conditie test, de fix toepast en het resultaat verifieert voordat het vastlegt wat er is gebeurd. Onderzoek naar zelfcorrigerende logica maakt duidelijk dat deze systemen werken via feedback en correctiepatronen in plaats van één geïsoleerd antwoord van een taalmodel.

Als de eerste actie mislukt, heeft het systeem een manier nodig om te beoordelen waarom, zodat het de volgende stap kan herzien binnen de gestelde limieten. Je kunt je dit duidelijk voorstellen aan de hand van een paar Microsoft 365 gevallen. Wanneer een gebruiker wordt geblokkeerd omdat hun licentie en beleidsomvang niet overeen komen, detecteert de agent de discrepantie en controleert het beoogde rolprofiel. Het past de toegestane correctie toe, bevestigt dat de gebruiker toegang heeft en logt de wijziging zonder dat er iemand om hulp gevraagd hoeft te worden. Als er een riskante aanmelding verschijnt in Entra, ziet de agent de risicogebeurtenis en controleert direct je regels voor voorwaardelijke toegang. Het vraagt om sterkere verificatie of blokkeert de toegang op basis van je beleid en registreert vervolgens de uitkomst zodat de mens het later kan beoordelen. Wanneer een verouderde deling in SharePoint blijft falen, vergelijkt de agent het huidige rechtenpad met de verwachte deelregels.

Hij vervangt de kapotte route door de goedgekeurde versie en stuurt de gecorrigeerde link in context, waardoor de cirkel rond is voordat een servicedeskmedewerker een ticket met de titel Dringend toegangsprobleem hoeft te lezen. Ondersteuning bij vergaderingen is een ander uitstekend voorbeeld. Als een vergaderruimteapparaat uitvalt of een verbindingsseconde voor de start van een gesprek wegvalt, kan de agent dit detecteren en de fout valideren. Hij probeert een herstelstap met een laag risico en stelt de organisator in Teams op de hoogte met een statusupdate, precies daar waar het werk plaatsvindt. Die communicatielaag vormt een enorm belangrijk onderdeel van het ontwerp. Ondersteuning moet aanwezig zijn waar de onderbreking plaatsvindt. Als je werk zich afspeelt in Teams, Outlook en de M365 werkruimte, dan moet de ondersteuning je daar ook antwoord geven. Je zou de gebruiker niet ergens anders naartoe moeten slepen als je het probleem in de huidige context kunt oplossen.

Dit betekent niet dat alles volledig geautomatiseerd moet worden, want dat zou roekeloos zijn. Acties met een laag risico kunnen automatisch verlopen, maar wijzigingen met grote impact vereisen nog steeds goedkeuring van een persoon. Dat goedkeuringsproces moet vanaf het begindeel uitmaken van de architectuur in plaats van achteraf te worden toegevoegd. De agent moet weten wanneer hij actie moet ondernemen, wanneer hij moet vragen en precies wanneer hij moet stoppen. En zodra je dat in de flow verwerkt, gaat het gesprek niet meer over automatiseringsfuncties. Het gaat dan over controle, governance, vertrouwen en de identiteit van de agent. Wanneer ondersteuning zelfstandig begint te werken, komt er direct een lastige vraag naar boven. Wie doet het werk eigenlijk? Als dat antwoord vaag is, valt het hele model uit elkaar. Een agent kan niet zomaar als een vage hulp met ruime toegang en zonder duidelijke eigenaar in je omgeving bestaan.

Hij heeft een echte identiteit in Entra nodig. Hij heeft een benoemde eigenaar nodig, een gedefinieerde scoop en een levenscyclus die begint en eindigt met een specifieke reden. Als die agent gegevens kan lezen, workflows kan activeren of je gebruikers kan berichten, moet je hem beheren als een actieve deelnemer in de tenant. Je kunt het niet behandelen als een functie die iemand heeft ingeschakeld en daarna is vergeten. Daarom is de identiteit van de agent zo cruciaal voor het systeem. Je moet precies weten wat de agent is, welke systemen hij kan aanraken en wie er gebeld wordt als de zaken uit de hand lopen. Least privilege moet hier de basislijn zijn. Je kunt niet genoegen nemen met ruim gemak of jezelf voorhouden dat je de rechten later wel zult beperken. Omdat de impactradius van een ondersteuningsagent volledig afhangt van zijn rechten, is het ontwerpen van die rechten een essentieel onderdeel van het ontwerpen van ondersteuning.

Agent 365 fungeert in deze opzet als een noodzakelijke controlelaag, omdat het het volledige agentlandschap in kaart brengt. Het biedt het register, de goedkeuringsworkflows en de beleidsschablonen die zorgen voor een veilige werking. Hoewel deze onderdelen misschien als administratieve klusjes klinken, lossen ze een groot structureel probleem op. De meeste organisaties worstelen niet door een gebrek aan AI-functies, maar omdat ze niet kunnen zien of controleren wat er al in hun omgeving draait. Het onderzoek hierover is onomwonden. Slechts een kleine minderheid van grote ondernemingen kan elke agent die momenteel in hun systeem draait volledig inventariseren. Voordat leiders praten over het schalen van autonome ondersteuning, moeten ze een veel simpelere vraag beantwoorden. Weten we überhaupt welke agents er bestaan en wat ze op dit moment doen? Toezicht moet ook in verhouding staan tot het bijbehorende risiconiveau.

Een persoonlijke productiviteitsagent die binnen een smal kader werkt is één ding, maar een samenwerkingsagent die gedeelde inhoud raakt is iets heel anders. Daarnaast heb je enterprise agents die acties uitvoeren in gevoelige workflows wat in een andere risicocategorie valt. Dit is waarom het risico-zone-model persoonlijk, samenwerkend en enterprise zo belangrijk is. Je control-model moet meegroeien met de mogelijke impact. Als je elke agent hetzelfde behandelt, raakt werk met een laag risico bedoven onder trage goedkeuringen, terwijl werk met een hoog risico ontsnapt aan scherpe controle. Minimaal zou je control-stack in Microsoft 365 voor je team vertrouwd moeten aanvoelen. Je gebruikt identiteit in Entra, datagrenzen via Purview en monitoring via Defender. Je past toegangscondities toe via voorwaardelijke toegang en zorgt dat auditability vanaf het begin is ingebakken. Je moet precies kunnen reconstrueren wat er is gebeurd zonder te hoeven gissen nadat er een incident heeft plaatsgevonden.

Menselijk toezicht moet in de logica worden ingebouwd in plaats van geïmproviseerd tijdens een crisis. Acties met een grote impact moeten altijd pauzeren voor een menselijke goedkeuring. Redeneringen moeten worden vastgelegd in een vorm die mensen daadwerkelijk kunnen inzien en begrijpen. Er moeten terugdraaimogelijkheden bestaan voordat de allereerste autonome actie live gaat. Als een agent de toegang bijwerkt of een roteringsbeleid wijzigt, moet iemand die beslissing kunnen traceren en netjes omgedaan kunnen maken. Er is nog een factor die leiders vaak missen omdat de eerste demo's er zo goed uitzien. De kosten van herstelwerkzaamheden. Als een agent opruimcycli voor je team creëert, verdwijnen de verwachte besparingen onmiddellijk. Dit is de belasting op herstelwerk. Het is de tijd die wordt besteed aan het corrigeren van slechte output, het terugdraaien van verkeerde acties of het opsporen van onbedoelde neveneffecten.

Als je team 10 minuten bespaart op uitvoering, maar 8 minuten kwijt is aan het opruimen van de puinhoop, heb je de ondersteuning niet echt geautomatiseerd. Je hebt de frictie simpelweg verplaatst naar een ander deel van het proces. Vertrouwen komt niet voort uit een gepolijst beleidsdocument of een grote aankondiging. Het komt voort uit bewijs tijdens de uitvoering. Mensen moeten zien wat de agent zag, wat deze besloot en wat er daadwerkelijk in het systeem is veranderd. Zo bouw je vertrouwen op in autonome ondersteuning. Het bewijs moet zitten in het gedrag van de tool, niet in de branding van het project. Zodra dat fundament voor governance solide is, kan het gesprek eindelijk verschuiven van beveiligingsjargon naar bestuurlijke taal. Wat verandert dit eigenlijk voor het bedrijfsresultaat? Het nieuwe rendement van onzichtbare ondersteuning. Zodra leiders het controlemodel accepteren, beginnen de financiële vragen te verschuiven.

In het oude model wordt de waarde van ondersteuning gemeten aan zichtbaar werk, zoals afgehandelde tickets, gesprekken en slaapprestaties. Die cijfers doen er nog steeds toe, maar ze beschrijven alleen een reactie op een probleem. Ze vertellen niet hoeveel onderbrekingen de wachtrij nooit hebben bereikt of hoeveel tijd van werknemers behouden bleef omdat een probleem vroegtijdig werd opgelost. Dat is het kernprobleem van de boekhouding. Onzichtbare ondersteuning creëert waarde door afwezigheid. Je ziet de waarde wanneer er geen ticket is, geen escalatie en geen analist die 20 minuten besteedt aan het reconstrueren van een probleem op basis van halve notices. Als je alleen de zichtbare inspanning van het ondersteuningsteam meet, mis je het resultaat dat je eigenlijk wilde. Je wilde stabiel werk met minder onderbrekingen. Ticketvolume is een zwak signaal als het op zichzelf staat. Een daling in tickets kan betekenen dat de vraag is afgenomen, maar het kan ook betekenen dat de omgeving gezonder is geworden en de ondersteuningslaag slimmer.

Dat zijn twee heel verschillende verhalen. Directieleden hebben een set KPIs nodig die het verschil tussen die twee kan duiden. Begin bij het kijken naar de autonome oplossingsgraad. Dit gaat niet over hoeveel gesprekken de bot heeft gevoerd, maar hoeveel ondersteuningsgebeurtenissen volledig zijn opgelost zonder menselijke tussenkomst. Je moet ook de vermindering van de gemiddelde oplostijd bijhouden. In AI-gedreven omgevingen zien diagnose-intensieve stromen vaak verbeteringen in de range van 40 tot 60 procent. Daarna kun je kijken naar de kosten per oplossing en de teruggewonnen productiviteit van de gebruiker. Die laatste metriek is makkelijk over te slaan omdat deze niet netjes in een standaard-service deskrapport staat. Echter, daar zit vaak de werkelijke waarde. Iemand die 15 minuten geblokkeerd is voordat hij zelfs maar een ticket opent, heeft al kosten voor het bedrijf gemaakt. Wanneer je dat vermenigvuldigt met vergaderonderbrekingen en toegangsbelemmeringen in een grote tenant, is het verborgen verlies veel groter dan de wachtrij suggereert.

Dit is waarom het model voor kosten van niets doen zo belangrijk is voor de business case. Je berekent de uren die zijn besteed aan handmatige inspanning voordat de formele ondersteuning zelfs begint. Daar tel je vervolgens de kosten van fouten en herhaalt werk bij op. Plotseling klinkt het argument voor preventie niet langer als een theorie. Je financieert niet alleen een futuristische ondersteuningslaag. Je heft een belasting op die al jaren in je dagelijkse werkzaamheden verweven zit. De economie van een specifieke casus maakt dit nog duidelijker. Onderzoek naar agentgestuurde IT-ondersteuning schat menselijke afhandeling op ongeveer 8 dollar en 75 cent per issue. Daarentegen kan specifieke agent afhandeling dalen tot onder de 50 cent per issue zodra het systeem is ontwikkeld. Dit betekent niet dat elke ondersteuningsactie zo goedkoop zal zijn. Leiders moeten voorzichtig zijn met algemene gemiddelde.

De kwaliteit van telemetrie en governance zullen altijd de uiteindelijke kosten beïnvloeden, maar de trend is onmiskenbaar. Dit is het moment waarop IT het oude verhaal van de kostenpost achter zich laat. Niet omdat ondersteuning verdwijnt, maar omdat ondersteuning verandert in een betrouwbaarheidslaag... ...die de productiviteit van medewerkers op de achtergrond beschermt. Het bedrijf ervaart dit als soepeler werk in plaats van een dramatisch incident. Je krijgt minder onderbrekingen, sneller herstel en minder verspeelde arbeid aan doorverwijzing en opheldering. Toch kan een slechte meting eenvoudig vooruitgang feinzen. Als je telemetrie zwak is, vat de agent een storing misschien alleen sneller samen in plaats van deze daadwerkelijk te voorkomen. Als herstelwerk niet in het dashboard verschijnt, ziet de rewa er veel rooskleuriger uit dan deze in werkelijkheid is. Als teruggewonnen tijd weglekt naar activiteiten met lage waarde, zullen leiders de winst overschatten.

De financiële onderbouwing moet gebaseerd blijven op hard bewijs, zoals voorkomen incidenten en minder handmatige handelingen. Je moet de tijd meten die werkelijk is teruggeven aan nuttig werk. Zodra je dat correct meet, lijkt de ondersteuningsfunctie niet langer op een overheadpost die moet worden gesneden. Het begint te lijken op operationele capaciteit die het bedrijf eindelijk terugkrijgt. Wat doet dit met het ondersteuningsteam? Denk na over wat dit werkelijk betekent voor het team op de werkvloer, want deze verschuiving gaat niet over personeelsreductie... ...maar over het veranderen van wat je mensen dagelijks doen. In de oude situatie wordt het grootste deel van je ondersteuningscapaciteit opgeslokt door wachtwoordresets, ticketroutering en eindeloze verduidelijkingsrondes. Je hebt mensen die achter updates aanjagen en data verplaatsen tussen systemen die nooit ontworpen zijn om met elkaar te communiceren.

Niets van dat werk maakt de omgeving stabieler, het zorgt er alleen voor dat de wachtrij niet overloopt. Wanneer agents dat voorspelbare routinewerk overnemen, stijgt de menselijke inzet eindelijk naar een hoger niveau. Support engineers besteden hun tijd aan het definiëren van een gezonde status en het bijsturen van de logica achtergoedkeuringen. Ze richten zich op het verbeteren van kennisbronnen, het testen van beleidsregels en zorgen ervoor dat de agent binnen de gestelde kaders blijft. Dat is een compleet andere baan dan de hele dag naar onderwerpregels staren en proberen te raden wat een gebruiker echt wil. Dit is precies waar de meeste implementaties vastlopen. Organisaties proberen hun oude, gebrekkige processen te behouden en plaatsen er simpelweg een agent bovenop, in de hoop op een beter resultaat. Maar het proces blijft reactief, de overdrachten blijven rommelig en de onderliggende kennis blijft zwak.

De agent wordt dan slechts een nieuwe laag verf op een afbrokkelende muur. Hij beantwoordt misschien een vraag sneller, maar kan geen support model repareren dat op vertraging is gebouwd. De betere aanpak is om het werk eerst opnieuw in te richten. Je moet bepalen welke taken menselijk blijven omdat ze beoordelingsvermogen of gevoelige communicatie vereisen. Daarna beslis je welk werk naar autonome stromen verhuisd omdat de uitkomst voorspelbaar is en de acties veilig zijn. Deze verdeling is essentieel, want support teams verdwijnen niet. Ze worden simpelweg de mensen die de controles ontwerpen en de uitzonderingen afhandelen. Dat betekent dat de manier waarop we mensen trainen ook moet veranderen. Teams moeten leren hoe ze een systeem overzien in plaats van alleen handmatige taken uitvoeren. Ze moeten rollback logica en audit reviews begrijpen en weten hoe ze een agent testen voordat deze live gaat.

Ze moeten ook kunnen zien wanneer een model faalt, want een geautomatiseerde slechte workflow blijft een slechte workflow. Het maakt de dingen alleen maar sneller kapot. Als je aanneemt voor deze toekomst, heb je waarschijnlijk geen extra generalist nodig voor het triëren van tickets. Je hebt iemand nodig die stromen binnen de Microsoft 365 stack kan orkestreren en controles kan definiëren die agents in toom houden. Je wilt mensen die de omgeving kunnen verbeteren, zodat de vraag naar support daalt in plaats van zich opstapelt. Dus, hoe begin je hier eigenlijk aan zonder dat het uitmondt in een enorm meerjarig transformatieproject? De beste set is om één specifieke stroom te kiezen die constant voor wrijving zorgt in je Microsoft 365 omgeving. Toegangsherstel is meestal een goede kandidaat, maar je kunt ook kijken naar support voor vergaderingen of device compliance overdrachten. Het maakt niet uit welke je kiest, zolang het patroon vaak voorkomt en je precies weet hoe een succesvol resultaat eruit hoort te zien.

Zodra je het doel hebt, moet je de basis met echte discipline definiëren. Je moet weten wat gezond is en welke specifieke gebeurtenissen aangeven dat zaken uit koers raken. Bepaal welke acties veilig te automatiseren zijn en waar precies de menselijke escalatie moet beginnen. Zorg voor dat je iets live brengt voor een nulmeting van je ticketaantallen, handmatige acties en hoe lang gebruikers momenteel wachten op een oplossing. Je moet ook vanaf de eerste dag je governance op orde hebben. Geef de agent een specifieke identiteit, wijs er een menselijke eigenaar aan toe en stel duidelijke goedkeuringsregels vast. Elke actie die de agent uitvoert, moet worden gelogd. Zorg ook voor een plan voor wanneer de agent wordt stopgezet of verplaatst, zodat het geen spookautomatisering wordt. Wanneer die eerste flow begint te werken, verschuift je hele bedrijfsmodel. Support fungeert niet langer als een receptie die alleen op problemen reageert.

In plaats daarvan gedraagt het zich als een betrouwbaarheidsmotor die direct in het systeem is ingebouwd. Support verschuift van een zichtbare reactie naar ingebedde preventie. De ticket was nooit de dienstverlening. Het was het bewijs dat de dienstverlening te laat kwam. Kies dit kwartaal één support flow en ontwerp deze opnieuw voor preventie in plaats van voor reactie. Wil je meer weten over M365 Copilot, Azure, Beveiliging en AI-besturingsmodellen? Abonneer je op M365 FM en laat een recensie achter. Maak verbinding met mij, Mirko Pieter, op LinkedIn met het volgende onderwerp dat je uitgediept wilt hebben.