WEBVTT 00:00:00.140 --> 00:00:04.200 Ticketing ziet er op papier strak uit. Je krijgt de cijfers, de wachtrijen, de dashboards. 00:00:04.400 --> 00:00:07.980 Maar in werkelijkheid meet dat model alleen de pijn nadat het systeem al heeft gefaald. 00:00:08.140 --> 00:00:10.740 Het kostbare deel van het probleem begint meestal veel eerder. 00:00:10.920 --> 00:00:14.240 Het begint wanneer een medewerker 10 minuten verliest, dan 20, en uiteindelijk het opgeeft. 00:00:14.420 --> 00:00:16.560 Ze proberen het opnieuw. Ze vragen een collega. 00:00:16.820 --> 00:00:19.940 Ze missen de vergadering of delen het verkeerde bestand omdat de juiste weg niet meer werkte. 00:00:20.120 --> 00:00:22.560 En dat is het deel dat de meeste supportteams nog steeds niet zien. 00:00:22.720 --> 00:00:25.640 Het beste interne supportmodel van nu draait niet om snellere triage. 00:00:25.880 --> 00:00:28.560 Het draait om het volledig wegnemen van de noodzaak voor triage. 00:00:28.560 --> 00:00:33.080 Stel je een autonome agent in Microsoft 365 voor die de context observeert, 00:00:33.280 --> 00:00:37.340 wrijving vroeg opmerkt en actie onderneemt voordat iemand überhaupt denkt aan het openen van een portaal. 00:00:37.480 --> 00:00:40.600 In deze aflevering wil ik je laten zien waarom het helpdesk model faalt, 00:00:40.780 --> 00:00:43.980 wat het daadwerkelijk vervangt en hoe je dit kunt beheren zonder chaos te creëren. 00:00:44.160 --> 00:00:48.400 Als deze verschuiving belangrijk is voor jouw werk, abonneer je dan op M365FM, 00:00:48.500 --> 00:00:51.620 want de niveau dieper is het echte probleem niet de wachtrij, maar het model erachter. 00:00:51.780 --> 00:00:55.160 De dood van het ticket. De oude supportflow is nog steeds overal aanwezig. 00:00:55.160 --> 00:00:57.560 Er gaat iets kapot. Een gebruiker merkt het op. 00:00:57.560 --> 00:00:59.240 De gebruiker probeert het uit te leggen. 00:00:59.440 --> 00:01:03.520 Vervolgens vertaalt die tedi uitleg naar een categorie, een prioriteit en misschien een toewijzingsgroep. 00:01:03.600 --> 00:01:05.120 Het probleem komt in een wachtrij terecht. 00:01:05.380 --> 00:01:06.580 Iemand voert de triage uit. 00:01:06.780 --> 00:01:08.120 Iemand anders vraagt om meer details. 00:01:08.360 --> 00:01:09.740 Een ander team wordt erbij betrokken. 00:01:09.940 --> 00:01:12.200 De tijd tikt door terwijl het echte werk stil blijft liggen. 00:01:12.400 --> 00:01:16.360 Dat proces voelt normaal omdat het vertrouwd is, maar vertrouwd en effectief zijn niet hetzelfde. 00:01:16.560 --> 00:01:17.780 Een ticket is geen support. 00:01:18.000 --> 00:01:20.060 Een ticket is het bewijs dat support te laat kwam. 00:01:20.060 --> 00:01:24.440 Tegen de tijd dat een ticket bestaat, heeft de medewerker al vertraging opgelopen en de context verloren. 00:01:24.440 --> 00:01:27.360 Ze hebben hun aandacht al verlegd van het werk dat ze probeerden te doen. 00:01:27.520 --> 00:01:28.980 De wachtrij is niet de dienstverlening. 00:01:29.200 --> 00:01:30.900 De wachtrij is een registratie van falen. 00:01:31.060 --> 00:01:34.960 In grote Microsoft 365 omgevingen wordt handmatige triage het echte knelpunt. 00:01:35.160 --> 00:01:37.000 Dit gebeurt niet omdat support teams lui zijn. 00:01:37.200 --> 00:01:41.000 Het gebeurt omdat van mensen wordt gevraagd iets te doen dat niet langer past bij de schaal van de omgeving. 00:01:41.180 --> 00:01:44.400 Je hebt meer gebruikers, meer apparaten, meer apps, meer beleidsregels. 00:01:44.580 --> 00:01:49.700 Je hebt meer uitzonderingen die Teams, SharePoint, Exchange, Intune en Entra op exact hetzelfde moment door kruisen. 00:01:49.700 --> 00:01:54.280 Het volume groeit niet alleen. De combinaties groeien. Dat is waar het oude model breekt. 00:01:54.460 --> 00:01:56.780 De meeste Teams reageren door meer structuur toe te voegen. 00:01:56.960 --> 00:01:59.760 Ze bouwen nog een portaal, nog een bot of nog een routeringsregel. 00:01:59.920 --> 00:02:03.760 Maar in werkelijkheid voegt dat alleen maar een extra laag toe tussen de medewerker en de oplossing. 00:02:04.020 --> 00:02:09.380 Het systeem wacht nog steeds tot de gebruiker het probleem opmerkt, het beschrijft en op de juiste manier om hulp vraagt. 00:02:09.640 --> 00:02:17.360 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. 00:02:17.360 --> 00:02:21.900 Dat is waar de ondersteuningsvraag echt begint en het ticketmodel staat volledig los van dat moment. 00:02:22.120 --> 00:02:24.820 De verborgen kosten zijn veel groter dan je wachtrijrapport laat zien. 00:02:25.040 --> 00:02:29.060 Mensen schakelen constant tussen taken. Dubbele incidenten stapelen zich op onder verschillende labels. 00:02:29.500 --> 00:02:35.460 Kennisartikelen raken verouderd. Analisten besteden hun hele dag aan sorteren, doorsturen en verduidelijken in plaats van daadwerkelijk problemen op te lossen. 00:02:35.600 --> 00:02:41.020 De oplossingstijd rekt op omdat elke overdracht voor vertraging zorgt en elke vertraging verwijdert de oorspronkelijke context. 00:02:41.260 --> 00:02:45.360 Onderzoek naar agentgebaseerde AI en IT-operaties wijst op hetzelfde structurele probleem. 00:02:45.360 --> 00:02:48.980 Minstens 80% van de inzet zit nog steeds vast in reactief ITIL-achtig werk. 00:02:49.180 --> 00:02:52.380 Dat cijfer is belangrijk omdat het precies aangeeft waar de arbeid naartoe gaat. 00:02:52.540 --> 00:02:55.260 Het gaat niet naar veerkracht of preventie, maar naar reactie. 00:02:55.500 --> 00:02:59.200 Zodra je dat ziet, lijkt het ticket minder op een bedrijfsmodel en meer op een symptoom. 00:02:59.360 --> 00:03:02.680 Het is een symptoom van een systeem dat pas reageert nadat de schade zichtbaar is. 00:03:02.840 --> 00:03:07.600 Dus de volgende vraag is niet hoe we tickets sneller verwerken, maar wat het systeem moet doen voordat een ticket überhaupt nodig is. 00:03:07.740 --> 00:03:09.720 Het model van de onzichtbare medewerker. 00:03:09.720 --> 00:03:11.460 Dus, wat vervangt eigenlijk het ticket? 00:03:11.680 --> 00:03:17.060 Het is niet zomaar weer een chatbot bovenop, dezelfde chaos, en het is zeker geen mooiere voordeur voor dezelfde oude wachtrij. 00:03:17.240 --> 00:03:24.120 De verschuiving gaat veel dieper dan dat omdat de onzichtbare medewerker een operationele werkkracht is die in je Microsoft 365 omgeving leeft. 00:03:24.360 --> 00:03:30.880 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. 00:03:31.080 --> 00:03:32.340 Dat onderscheid is belangrijk. 00:03:32.640 --> 00:03:37.160 Een chatbot wacht tot jij een prompt typt, maar een onzichtbare medewerker houdt veranderingen in omstandigheden in de gaten. 00:03:37.160 --> 00:03:40.020 Het vertrekt vanuit context in plaats van vanuit een gesprek. 00:03:40.120 --> 00:03:46.620 Omdat het inlogstatussen, apparaatgezondheid, licentiestatus en het delen van bestanden kan zien, hoeft het niet te wachten tot er frictie ontstaat. 00:03:46.760 --> 00:03:51.880 In plaats van te vragen hoe het kan helpen nadat iets kapot gaat, stelt het op de achtergrond constant een andere vraag. 00:03:52.100 --> 00:03:55.680 Wat wijkt af van de staat die deze medewerker nodig heeft om nu zijn werk te doen? 00:03:55.900 --> 00:03:57.320 Dat is waar de dingen veranderen. 00:03:57.480 --> 00:03:59.880 Het model is direct ingebed in het werk zelf. 00:03:59.880 --> 00:04:08.440 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. 00:04:08.620 --> 00:04:15.560 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. 00:04:15.800 --> 00:04:21.940 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. 00:04:21.940 --> 00:04:27.680 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. 00:04:27.880 --> 00:04:32.980 Dit voelt onzichtbaar als het goed werkt omdat er geen wachtruimte is en geen selecteer een categorie, formulier om in te vullen. 00:04:33.400 --> 00:04:35.180 Ondersteuning uit zich als herstelde workflow. 00:04:35.480 --> 00:04:40.360 De medewerker gaat gewoon weer aan het werk en ziet in veel gevallen niet eens het systeem dat op de achtergrond draait. 00:04:40.520 --> 00:04:43.060 Je kunt al zien hoe dit je personeelslogica verandert. 00:04:43.260 --> 00:04:48.900 Het oude model neemt mensen aan om volume op te vangen, verzoeken te sorteren en verbroken verbanden tussen teams te herstellen. 00:04:48.900 --> 00:04:56.640 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. 00:04:56.900 --> 00:05:00.680 Mensen blijven in het systeem, maar de hele vorm van hun dagelijkse werk verschuift. 00:05:00.880 --> 00:05:04.380 Onderzoek naar agentische AI in ondersteuning blijft in deze richting wijzen. 00:05:04.580 --> 00:05:11.720 Routine ondersteuning kan verschuiven naar uitzonderingsbeheer, wat enorme efficiëntiewinst oplevert wanneer de omgeving en het beleid goed zijn afgebakend. 00:05:11.900 --> 00:05:14.620 Dat laatste onderdeel is essentieel, want dit is geen magie. 00:05:14.620 --> 00:05:20.200 Als je data zwak is of je proces rommelig, wordt de agent niet slim alleen omdat je besluit hem autonoom te noemen. 00:05:20.420 --> 00:05:26.420 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. 00:05:26.620 --> 00:05:31.340 Een echte werknemer heeft een identiteit, een functieomschrijving, machtigingen en een manager nodig om aan te rapporteren. 00:05:31.480 --> 00:05:37.760 De agent heeft precies diezelfde dingen nodig omdat de waarde voortkomt uit betrouwbare actie in een systeem, niet uit slim taalgebruik in een chatvenster. 00:05:37.760 --> 00:05:49.440 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. 00:05:49.680 --> 00:05:52.780 Zodra dat model duidelijk is, hoort de volgende vraag heel praktisch. 00:05:52.960 --> 00:05:54.160 Hoe werkt Preempsi eigenlijk? 00:05:54.480 --> 00:05:55.940 De architectuur van Preempsi. 00:05:56.120 --> 00:05:58.900 Dus, hoe werkt Preempsi eigenlijk binnen Microsoft 365? 00:05:59.500 --> 00:06:03.100 De verschuiving gaat van verzoek en antwoord naar gebeurtenisredenering en orkestratie. 00:06:03.260 --> 00:06:06.300 Dat klinkt technisch, maar het model is simpel zodra je het uiteenzet. 00:06:06.300 --> 00:06:11.200 Eerst verandert er iets in de omgeving, dan interpreteert het systeem of die verandering risico of afwijking betekent, 00:06:11.500 --> 00:06:14.820 en tot slot voert het de goedgekeurde actie uit met de tools die al in je stack aanwezig zijn. 00:06:15.020 --> 00:06:16.480 Begin bij de gebeurtenislaag. 00:06:16.720 --> 00:06:24.140 Microsoft 365 produceert overal signalen, wat betekent dat entra-inloggedrag ziet terwijl in toen de status en compliance van apparaten bijhoudt. 00:06:24.260 --> 00:06:29.640 Defender houdt verdachte activiteiten in de gaten en teams laat precies zien wanneer een vergadering mislukt of de gesprekskwaliteit afneemt. 00:06:29.800 --> 00:06:32.640 SharePoint en Exchange tonen toegangspatronen en inhoudsactiviteiten, 00:06:32.640 --> 00:06:36.300 terwijl signalen over de service status aangeven wanneer het platform zelf het probleem is. 00:06:36.460 --> 00:06:39.900 Wanneer je daar gebruikersacties aan toevoegt, heb je een constante stroom van context. 00:06:40.120 --> 00:06:44.720 De meeste organisaties verzamelen die signalen, maar slechts weinigen gebruiken ze daadwerkelijk als ondersteuningssysteem. 00:06:44.880 --> 00:06:48.980 Ruwe gebeurtenissen alleen helpen niet, want er is een reden neerlaag nodig om betekenis te geven aan de ruis. 00:06:49.160 --> 00:06:53.740 Dit is waar de onzichtbare medewerker stopt met het spelen van automatiseringstheater en begint te handelen als een echte operator. 00:06:53.980 --> 00:06:59.220 De agent bekijkt het signaal, vergelijkt de huidige status met de gewenste status en besluit welke actie veilig is om te ondernemen. 00:06:59.220 --> 00:07:05.020 Een audioprobleem bij een vergadering is niet hetzelfde als een riskante aanmelding en een kapotte gedeelde link is anders dan een licentiefout. 00:07:05.180 --> 00:07:10.220 De agent moet het probleem eerst klassificeren, want actie ondernemen zonder klassificatie leidt alleen maar sneller tot fouten. 00:07:10.400 --> 00:07:11.720 Dan volgt de orkestratie. 00:07:11.940 --> 00:07:15.680 Zodra de agent het probleem begrijpt, kan hij het juiste mechanisme gebruiken om te reageren. 00:07:15.860 --> 00:07:21.020 Dat kan Power Automate zijn voor workflows, Copilot Studio voor logica of Microsoft Graph voor systeemacties en context. 00:07:21.220 --> 00:07:24.480 De tools zijn belangrijk, maar het grotere punt is hoe ze met elkaar verbonden zijn. 00:07:24.480 --> 00:07:29.300 Je bouwt niet één slimme prompt, maar een keten die kan detecteren, beslissen, handelen en verifiëren. 00:07:29.460 --> 00:07:31.540 Dat laatste onderdeel wordt telkens vergeten. 00:07:31.700 --> 00:07:34.960 Een zelfcorrigerend systeem stopt niet zodra de actie is uitgevoerd. 00:07:35.100 --> 00:07:41.640 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. 00:07:41.800 --> 00:07:49.360 Onderzoek naar zelfcorrigerende logica maakt duidelijk dat deze systemen werken via feedback en correctiepatronen in plaats van één geïsoleerd antwoord van een taalmodel. 00:07:49.360 --> 00:07:55.800 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. 00:07:55.960 --> 00:07:59.560 Je kunt je dit duidelijk voorstellen aan de hand van een paar Microsoft 365 gevallen. 00:07:59.800 --> 00:08:06.000 Wanneer een gebruiker wordt geblokkeerd omdat hun licentie en beleidsomvang niet overeen komen, detecteert de agent de discrepantie en controleert het beoogde rolprofiel. 00:08:06.160 --> 00:08:11.800 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. 00:08:11.960 --> 00:08:17.660 Als er een riskante aanmelding verschijnt in Entra, ziet de agent de risicogebeurtenis en controleert direct je regels voor voorwaardelijke toegang. 00:08:17.660 --> 00:08:24.140 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. 00:08:24.360 --> 00:08:30.360 Wanneer een verouderde deling in SharePoint blijft falen, vergelijkt de agent het huidige rechtenpad met de verwachte deelregels. 00:08:30.560 --> 00:08:34.540 Hij vervangt de kapotte route door de goedgekeurde versie en stuurt de gecorrigeerde link in context, 00:08:34.800 --> 00:08:40.020 waardoor de cirkel rond is voordat een servicedeskmedewerker een ticket met de titel Dringend toegangsprobleem hoeft te lezen. 00:08:40.300 --> 00:08:42.820 Ondersteuning bij vergaderingen is een ander uitstekend voorbeeld. 00:08:42.820 --> 00:08:48.820 Als een vergaderruimteapparaat uitvalt of een verbindingsseconde voor de start van een gesprek wegvalt, kan de agent dit detecteren en de fout valideren. 00:08:48.940 --> 00:08:54.340 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. 00:08:54.420 --> 00:08:57.180 Die communicatielaag vormt een enorm belangrijk onderdeel van het ontwerp. 00:08:57.560 --> 00:08:59.900 Ondersteuning moet aanwezig zijn waar de onderbreking plaatsvindt. 00:09:00.020 --> 00:09:05.480 Als je werk zich afspeelt in Teams, Outlook en de M365 werkruimte, dan moet de ondersteuning je daar ook antwoord geven. 00:09:05.480 --> 00:09:09.820 Je zou de gebruiker niet ergens anders naartoe moeten slepen als je het probleem in de huidige context kunt oplossen. 00:09:10.040 --> 00:09:13.860 Dit betekent niet dat alles volledig geautomatiseerd moet worden, want dat zou roekeloos zijn. 00:09:14.060 --> 00:09:18.860 Acties met een laag risico kunnen automatisch verlopen, maar wijzigingen met grote impact vereisen nog steeds goedkeuring van een persoon. 00:09:19.080 --> 00:09:23.880 Dat goedkeuringsproces moet vanaf het begindeel uitmaken van de architectuur in plaats van achteraf te worden toegevoegd. 00:09:23.980 --> 00:09:28.000 De agent moet weten wanneer hij actie moet ondernemen, wanneer hij moet vragen en precies wanneer hij moet stoppen. 00:09:28.140 --> 00:09:31.480 En zodra je dat in de flow verwerkt, gaat het gesprek niet meer over automatiseringsfuncties. 00:09:31.480 --> 00:09:36.300 Het gaat dan over controle, governance, vertrouwen en de identiteit van de agent. 00:09:36.500 --> 00:09:40.600 Wanneer ondersteuning zelfstandig begint te werken, komt er direct een lastige vraag naar boven. 00:09:40.820 --> 00:09:41.960 Wie doet het werk eigenlijk? 00:09:42.180 --> 00:09:44.780 Als dat antwoord vaag is, valt het hele model uit elkaar. 00:09:44.980 --> 00:09:49.440 Een agent kan niet zomaar als een vage hulp met ruime toegang en zonder duidelijke eigenaar in je omgeving bestaan. 00:09:49.620 --> 00:09:51.620 Hij heeft een echte identiteit in Entra nodig. 00:09:51.820 --> 00:09:56.760 Hij heeft een benoemde eigenaar nodig, een gedefinieerde scoop en een levenscyclus die begint en eindigt met een specifieke reden. 00:09:56.760 --> 00:10:02.920 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. 00:10:03.120 --> 00:10:06.540 Je kunt het niet behandelen als een functie die iemand heeft ingeschakeld en daarna is vergeten. 00:10:06.760 --> 00:10:09.560 Daarom is de identiteit van de agent zo cruciaal voor het systeem. 00:10:09.720 --> 00:10:14.620 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. 00:10:14.860 --> 00:10:16.900 Least privilege moet hier de basislijn zijn. 00:10:17.100 --> 00:10:21.140 Je kunt niet genoegen nemen met ruim gemak of jezelf voorhouden dat je de rechten later wel zult beperken. 00:10:21.140 --> 00:10:28.220 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. 00:10:28.380 --> 00:10:34.960 Agent 365 fungeert in deze opzet als een noodzakelijke controlelaag, omdat het het volledige agentlandschap in kaart brengt. 00:10:35.060 --> 00:10:39.960 Het biedt het register, de goedkeuringsworkflows en de beleidsschablonen die zorgen voor een veilige werking. 00:10:40.160 --> 00:10:44.820 Hoewel deze onderdelen misschien als administratieve klusjes klinken, lossen ze een groot structureel probleem op. 00:10:44.820 --> 00:10:51.240 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. 00:10:51.400 --> 00:10:53.140 Het onderzoek hierover is onomwonden. 00:10:53.420 --> 00:10:58.780 Slechts een kleine minderheid van grote ondernemingen kan elke agent die momenteel in hun systeem draait volledig inventariseren. 00:10:59.000 --> 00:11:03.740 Voordat leiders praten over het schalen van autonome ondersteuning, moeten ze een veel simpelere vraag beantwoorden. 00:11:03.980 --> 00:11:06.940 Weten we überhaupt welke agents er bestaan en wat ze op dit moment doen? 00:11:07.100 --> 00:11:10.020 Toezicht moet ook in verhouding staan tot het bijbehorende risiconiveau. 00:11:10.020 --> 00:11:16.240 Een persoonlijke productiviteitsagent die binnen een smal kader werkt is één ding, maar een samenwerkingsagent die gedeelde inhoud raakt is iets heel anders. 00:11:16.480 --> 00:11:21.300 Daarnaast heb je enterprise agents die acties uitvoeren in gevoelige workflows wat in een andere risicocategorie valt. 00:11:21.520 --> 00:11:25.580 Dit is waarom het risico-zone-model persoonlijk, samenwerkend en enterprise zo belangrijk is. 00:11:25.740 --> 00:11:28.200 Je control-model moet meegroeien met de mogelijke impact. 00:11:28.420 --> 00:11:35.200 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. 00:11:35.400 --> 00:11:39.820 Minimaal zou je control-stack in Microsoft 365 voor je team vertrouwd moeten aanvoelen. 00:11:39.820 --> 00:11:44.140 Je gebruikt identiteit in Entra, datagrenzen via Purview en monitoring via Defender. 00:11:44.340 --> 00:11:49.600 Je past toegangscondities toe via voorwaardelijke toegang en zorgt dat auditability vanaf het begin is ingebakken. 00:11:49.780 --> 00:11:54.440 Je moet precies kunnen reconstrueren wat er is gebeurd zonder te hoeven gissen nadat er een incident heeft plaatsgevonden. 00:11:54.680 --> 00:11:58.720 Menselijk toezicht moet in de logica worden ingebouwd in plaats van geïmproviseerd tijdens een crisis. 00:11:59.000 --> 00:12:02.240 Acties met een grote impact moeten altijd pauzeren voor een menselijke goedkeuring. 00:12:02.580 --> 00:12:06.100 Redeneringen moeten worden vastgelegd in een vorm die mensen daadwerkelijk kunnen inzien en begrijpen. 00:12:06.100 --> 00:12:10.180 Er moeten terugdraaimogelijkheden bestaan voordat de allereerste autonome actie live gaat. 00:12:10.300 --> 00:12:16.160 Als een agent de toegang bijwerkt of een roteringsbeleid wijzigt, moet iemand die beslissing kunnen traceren en netjes omgedaan kunnen maken. 00:12:16.340 --> 00:12:19.840 Er is nog een factor die leiders vaak missen omdat de eerste demo's er zo goed uitzien. 00:12:20.020 --> 00:12:21.620 De kosten van herstelwerkzaamheden. 00:12:21.840 --> 00:12:25.840 Als een agent opruimcycli voor je team creëert, verdwijnen de verwachte besparingen onmiddellijk. 00:12:25.980 --> 00:12:27.340 Dit is de belasting op herstelwerk. 00:12:27.340 --> 00:12:33.000 Het is de tijd die wordt besteed aan het corrigeren van slechte output, het terugdraaien van verkeerde acties of het opsporen van onbedoelde neveneffecten. 00:12:33.120 --> 00:12:38.620 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. 00:12:38.760 --> 00:12:41.460 Je hebt de frictie simpelweg verplaatst naar een ander deel van het proces. 00:12:41.760 --> 00:12:44.740 Vertrouwen komt niet voort uit een gepolijst beleidsdocument of een grote aankondiging. 00:12:44.880 --> 00:12:46.620 Het komt voort uit bewijs tijdens de uitvoering. 00:12:46.840 --> 00:12:50.200 Mensen moeten zien wat de agent zag, wat deze besloot en wat er daadwerkelijk in het systeem is veranderd. 00:12:50.400 --> 00:12:52.500 Zo bouw je vertrouwen op in autonome ondersteuning. 00:12:52.500 --> 00:12:56.180 Het bewijs moet zitten in het gedrag van de tool, niet in de branding van het project. 00:12:56.440 --> 00:13:02.280 Zodra dat fundament voor governance solide is, kan het gesprek eindelijk verschuiven van beveiligingsjargon naar bestuurlijke taal. 00:13:02.440 --> 00:13:04.560 Wat verandert dit eigenlijk voor het bedrijfsresultaat? 00:13:04.720 --> 00:13:06.920 Het nieuwe rendement van onzichtbare ondersteuning. 00:13:07.180 --> 00:13:10.780 Zodra leiders het controlemodel accepteren, beginnen de financiële vragen te verschuiven. 00:13:10.940 --> 00:13:16.160 In het oude model wordt de waarde van ondersteuning gemeten aan zichtbaar werk, zoals afgehandelde tickets, gesprekken en slaapprestaties. 00:13:16.360 --> 00:13:19.860 Die cijfers doen er nog steeds toe, maar ze beschrijven alleen een reactie op een probleem. 00:13:19.860 --> 00:13:25.400 Ze vertellen niet hoeveel onderbrekingen de wachtrij nooit hebben bereikt of hoeveel tijd van werknemers behouden bleef omdat een probleem vroegtijdig werd opgelost. 00:13:25.620 --> 00:13:27.360 Dat is het kernprobleem van de boekhouding. 00:13:27.720 --> 00:13:30.140 Onzichtbare ondersteuning creëert waarde door afwezigheid. 00:13:30.280 --> 00:13:37.260 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. 00:13:37.540 --> 00:13:42.340 Als je alleen de zichtbare inspanning van het ondersteuningsteam meet, mis je het resultaat dat je eigenlijk wilde. 00:13:42.340 --> 00:13:44.740 Je wilde stabiel werk met minder onderbrekingen. 00:13:45.060 --> 00:13:47.540 Ticketvolume is een zwak signaal als het op zichzelf staat. 00:13:47.720 --> 00:13:53.020 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. 00:13:53.240 --> 00:13:54.900 Dat zijn twee heel verschillende verhalen. 00:13:55.320 --> 00:13:58.600 Directieleden hebben een set KPIs nodig die het verschil tussen die twee kan duiden. 00:13:58.840 --> 00:14:01.300 Begin bij het kijken naar de autonome oplossingsgraad. 00:14:01.480 --> 00:14:07.520 Dit gaat niet over hoeveel gesprekken de bot heeft gevoerd, maar hoeveel ondersteuningsgebeurtenissen volledig zijn opgelost zonder menselijke tussenkomst. 00:14:07.680 --> 00:14:10.400 Je moet ook de vermindering van de gemiddelde oplostijd bijhouden. 00:14:10.400 --> 00:14:15.580 In AI-gedreven omgevingen zien diagnose-intensieve stromen vaak verbeteringen in de range van 40 tot 60 procent. 00:14:15.780 --> 00:14:19.720 Daarna kun je kijken naar de kosten per oplossing en de teruggewonnen productiviteit van de gebruiker. 00:14:19.920 --> 00:14:24.400 Die laatste metriek is makkelijk over te slaan omdat deze niet netjes in een standaard-service deskrapport staat. 00:14:24.600 --> 00:14:26.600 Echter, daar zit vaak de werkelijke waarde. 00:14:26.780 --> 00:14:31.740 Iemand die 15 minuten geblokkeerd is voordat hij zelfs maar een ticket opent, heeft al kosten voor het bedrijf gemaakt. 00:14:32.000 --> 00:14:38.400 Wanneer je dat vermenigvuldigt met vergaderonderbrekingen en toegangsbelemmeringen in een grote tenant, is het verborgen verlies veel groter dan de wachtrij suggereert. 00:14:38.400 --> 00:14:41.880 Dit is waarom het model voor kosten van niets doen zo belangrijk is voor de business case. 00:14:42.040 --> 00:14:45.880 Je berekent de uren die zijn besteed aan handmatige inspanning voordat de formele ondersteuning zelfs begint. 00:14:46.080 --> 00:14:48.680 Daar tel je vervolgens de kosten van fouten en herhaalt werk bij op. 00:14:48.760 --> 00:14:51.480 Plotseling klinkt het argument voor preventie niet langer als een theorie. 00:14:51.660 --> 00:14:54.300 Je financieert niet alleen een futuristische ondersteuningslaag. 00:14:54.420 --> 00:14:57.580 Je heft een belasting op die al jaren in je dagelijkse werkzaamheden verweven zit. 00:14:57.740 --> 00:15:00.300 De economie van een specifieke casus maakt dit nog duidelijker. 00:15:00.500 --> 00:15:05.440 Onderzoek naar agentgestuurde IT-ondersteuning schat menselijke afhandeling op ongeveer 8 dollar en 75 cent per issue. 00:15:05.440 --> 00:15:10.800 Daarentegen kan specifieke agent afhandeling dalen tot onder de 50 cent per issue zodra het systeem is ontwikkeld. 00:15:10.960 --> 00:15:13.760 Dit betekent niet dat elke ondersteuningsactie zo goedkoop zal zijn. 00:15:13.880 --> 00:15:15.820 Leiders moeten voorzichtig zijn met algemene gemiddelde. 00:15:15.980 --> 00:15:21.280 De kwaliteit van telemetrie en governance zullen altijd de uiteindelijke kosten beïnvloeden, maar de trend is onmiskenbaar. 00:15:21.540 --> 00:15:24.800 Dit is het moment waarop IT het oude verhaal van de kostenpost achter zich laat. 00:15:25.020 --> 00:15:28.440 Niet omdat ondersteuning verdwijnt, maar omdat ondersteuning verandert in een betrouwbaarheidslaag... 00:15:28.440 --> 00:15:31.640 ...die de productiviteit van medewerkers op de achtergrond beschermt. 00:15:31.720 --> 00:15:35.140 Het bedrijf ervaart dit als soepeler werk in plaats van een dramatisch incident. 00:15:35.460 --> 00:15:40.320 Je krijgt minder onderbrekingen, sneller herstel en minder verspeelde arbeid aan doorverwijzing en opheldering. 00:15:40.500 --> 00:15:43.080 Toch kan een slechte meting eenvoudig vooruitgang feinzen. 00:15:43.280 --> 00:15:48.100 Als je telemetrie zwak is, vat de agent een storing misschien alleen sneller samen in plaats van deze daadwerkelijk te voorkomen. 00:15:48.260 --> 00:15:52.260 Als herstelwerk niet in het dashboard verschijnt, ziet de rewa er veel rooskleuriger uit dan deze in werkelijkheid is. 00:15:52.260 --> 00:15:56.820 Als teruggewonnen tijd weglekt naar activiteiten met lage waarde, zullen leiders de winst overschatten. 00:15:57.000 --> 00:16:02.040 De financiële onderbouwing moet gebaseerd blijven op hard bewijs, zoals voorkomen incidenten en minder handmatige handelingen. 00:16:02.160 --> 00:16:04.720 Je moet de tijd meten die werkelijk is teruggeven aan nuttig werk. 00:16:04.960 --> 00:16:09.180 Zodra je dat correct meet, lijkt de ondersteuningsfunctie niet langer op een overheadpost die moet worden gesneden. 00:16:09.360 --> 00:16:13.160 Het begint te lijken op operationele capaciteit die het bedrijf eindelijk terugkrijgt. 00:16:13.340 --> 00:16:14.260 Wat doet dit met het ondersteuningsteam? 00:16:15.080 --> 00:16:20.260 Denk na over wat dit werkelijk betekent voor het team op de werkvloer, want deze verschuiving gaat niet over personeelsreductie... 00:16:20.260 --> 00:16:22.200 ...maar over het veranderen van wat je mensen dagelijks doen. 00:16:22.360 --> 00:16:28.440 In de oude situatie wordt het grootste deel van je ondersteuningscapaciteit opgeslokt door wachtwoordresets, ticketroutering en eindeloze verduidelijkingsrondes. 00:16:28.620 --> 00:16:33.260 Je hebt mensen die achter updates aanjagen en data verplaatsen tussen systemen die nooit ontworpen zijn om met elkaar te communiceren. 00:16:33.480 --> 00:16:37.380 Niets van dat werk maakt de omgeving stabieler, het zorgt er alleen voor dat de wachtrij niet overloopt. 00:16:37.580 --> 00:16:42.320 Wanneer agents dat voorspelbare routinewerk overnemen, stijgt de menselijke inzet eindelijk naar een hoger niveau. 00:16:42.600 --> 00:16:47.980 Support engineers besteden hun tijd aan het definiëren van een gezonde status en het bijsturen van de logica achtergoedkeuringen. 00:16:47.980 --> 00:16:54.020 Ze richten zich op het verbeteren van kennisbronnen, het testen van beleidsregels en zorgen ervoor dat de agent binnen de gestelde kaders blijft. 00:16:54.160 --> 00:16:59.360 Dat is een compleet andere baan dan de hele dag naar onderwerpregels staren en proberen te raden wat een gebruiker echt wil. 00:16:59.540 --> 00:17:02.080 Dit is precies waar de meeste implementaties vastlopen. 00:17:02.080 --> 00:17:07.980 Organisaties proberen hun oude, gebrekkige processen te behouden en plaatsen er simpelweg een agent bovenop, in de hoop op een beter resultaat. 00:17:08.120 --> 00:17:12.700 Maar het proces blijft reactief, de overdrachten blijven rommelig en de onderliggende kennis blijft zwak. 00:17:12.820 --> 00:17:15.680 De agent wordt dan slechts een nieuwe laag verf op een afbrokkelende muur. 00:17:15.840 --> 00:17:19.740 Hij beantwoordt misschien een vraag sneller, maar kan geen support model repareren dat op vertraging is gebouwd. 00:17:19.900 --> 00:17:22.280 De betere aanpak is om het werk eerst opnieuw in te richten. 00:17:22.400 --> 00:17:26.780 Je moet bepalen welke taken menselijk blijven omdat ze beoordelingsvermogen of gevoelige communicatie vereisen. 00:17:26.780 --> 00:17:31.520 Daarna beslis je welk werk naar autonome stromen verhuisd omdat de uitkomst voorspelbaar is en de acties veilig zijn. 00:17:31.740 --> 00:17:34.300 Deze verdeling is essentieel, want support teams verdwijnen niet. 00:17:34.480 --> 00:17:37.600 Ze worden simpelweg de mensen die de controles ontwerpen en de uitzonderingen afhandelen. 00:17:37.800 --> 00:17:40.400 Dat betekent dat de manier waarop we mensen trainen ook moet veranderen. 00:17:40.540 --> 00:17:44.480 Teams moeten leren hoe ze een systeem overzien in plaats van alleen handmatige taken uitvoeren. 00:17:44.680 --> 00:17:49.460 Ze moeten rollback logica en audit reviews begrijpen en weten hoe ze een agent testen voordat deze live gaat. 00:17:49.660 --> 00:17:54.460 Ze moeten ook kunnen zien wanneer een model faalt, want een geautomatiseerde slechte workflow blijft een slechte workflow. 00:17:54.460 --> 00:17:56.440 Het maakt de dingen alleen maar sneller kapot. 00:17:56.440 --> 00:18:00.440 Als je aanneemt voor deze toekomst, heb je waarschijnlijk geen extra generalist nodig voor het triëren van tickets. 00:18:00.620 --> 00:18:06.600 Je hebt iemand nodig die stromen binnen de Microsoft 365 stack kan orkestreren en controles kan definiëren die agents in toom houden. 00:18:06.720 --> 00:18:11.720 Je wilt mensen die de omgeving kunnen verbeteren, zodat de vraag naar support daalt in plaats van zich opstapelt. 00:18:11.900 --> 00:18:16.140 Dus, hoe begin je hier eigenlijk aan zonder dat het uitmondt in een enorm meerjarig transformatieproject? 00:18:16.340 --> 00:18:21.660 De beste set is om één specifieke stroom te kiezen die constant voor wrijving zorgt in je Microsoft 365 omgeving. 00:18:21.660 --> 00:18:27.160 Toegangsherstel is meestal een goede kandidaat, maar je kunt ook kijken naar support voor vergaderingen of device compliance overdrachten. 00:18:27.380 --> 00:18:33.260 Het maakt niet uit welke je kiest, zolang het patroon vaak voorkomt en je precies weet hoe een succesvol resultaat eruit hoort te zien. 00:18:33.500 --> 00:18:36.940 Zodra je het doel hebt, moet je de basis met echte discipline definiëren. 00:18:37.140 --> 00:18:42.000 Je moet weten wat gezond is en welke specifieke gebeurtenissen aangeven dat zaken uit koers raken. 00:18:42.000 --> 00:18:46.780 Bepaal welke acties veilig te automatiseren zijn en waar precies de menselijke escalatie moet beginnen. 00:18:47.040 --> 00:18:53.000 Zorg voor dat je iets live brengt voor een nulmeting van je ticketaantallen, handmatige acties en hoe lang gebruikers momenteel wachten op een oplossing. 00:18:53.240 --> 00:18:55.540 Je moet ook vanaf de eerste dag je governance op orde hebben. 00:18:55.800 --> 00:19:00.700 Geef de agent een specifieke identiteit, wijs er een menselijke eigenaar aan toe en stel duidelijke goedkeuringsregels vast. 00:19:00.900 --> 00:19:03.440 Elke actie die de agent uitvoert, moet worden gelogd. 00:19:03.440 --> 00:19:09.100 Zorg ook voor een plan voor wanneer de agent wordt stopgezet of verplaatst, zodat het geen spookautomatisering wordt. 00:19:09.100 --> 00:19:12.820 Wanneer die eerste flow begint te werken, verschuift je hele bedrijfsmodel. 00:19:13.020 --> 00:19:16.420 Support fungeert niet langer als een receptie die alleen op problemen reageert. 00:19:16.600 --> 00:19:20.900 In plaats daarvan gedraagt het zich als een betrouwbaarheidsmotor die direct in het systeem is ingebouwd. 00:19:21.140 --> 00:19:24.260 Support verschuift van een zichtbare reactie naar ingebedde preventie. 00:19:24.420 --> 00:19:25.960 De ticket was nooit de dienstverlening. 00:19:26.180 --> 00:19:28.220 Het was het bewijs dat de dienstverlening te laat kwam. 00:19:28.220 --> 00:19:32.320 Kies dit kwartaal één support flow en ontwerp deze opnieuw voor preventie in plaats van voor reactie. 00:19:32.500 --> 00:19:36.900 Wil je meer weten over M365 Copilot, Azure, Beveiliging en AI-besturingsmodellen? 00:19:36.900 --> 00:19:40.020 Abonneer je op M365 FM en laat een recensie achter. 00:19:40.260 --> 00:19:43.980 Maak verbinding met mij, Mirko Pieter, op LinkedIn met het volgende onderwerp dat je uitgediept wilt hebben.