AI voor ICT-bedrijven: ticket-triage & portaal | EIGHTY8

ICT-bedrijf of MSP automatiseren: ticket-triage door een AI-agent, klantportaal met documenten en projecten, koppelingen tussen je tools. Op nacalculatie.

AI-automatisering voor ict-bedrijven en managed service providers pakt de ticketstroom en de leveringsvorm aan: meldingen voorsorteren, conceptantwoorden klaarzetten en opdrachtgevers hun eigen overzicht geven in een portaal. EIGHTY8 bouwt dat in de tooling die een provider al draait en koppelt het aan bestaande systemen, met een prijs vooraf vastgesteld op nacalculatie.

Een MSP leeft van meldingen die nooit stoppen. De ticketstroom mengt storingen, wensen en vragen door elkaar, en de eerste triage (hoe dringend is het, wie hoort de melding, zit er een contract achter) kost per stuk enkele minuten. Tel die minuten over een week op en je houdt een flink deel van een werkweek over. Die triage bepaalt bovendien de beleving: een storing die laat geprioriteerd wordt, is een telefoontje dat niet binnenkomt.

De tweede bron is de herhaling in de antwoorden. Dezelfde vraag over een wachtwoord, een backup of een instelling komt wekelijks binnen en verdient hetzelfde antwoord, mits iemand het formuleert. Tussendoor staan juist de ingewikkelde tickets open die aandacht vragen, en die verdrinken in de stapel van het gewone.

De derde stroom is het zicht naar de klant toe. Een opdrachtgever wil weten waar zijn aanvraag staat, welke documenten er open liggen en wat het onderhoud deze maand heeft opgeleverd. Zonder portaal komt die vraag als telefoontje of mail, en de medewerker die hem beantwoordt, stopt even met oplossen.

En dan de koppelingen: monitoring, tickettool, facturatie en documentopslag vertellen elk hun eigen verhaal. Wie die systemen met de hand bijhoudt, houdt drie versies van de waarheid bij. En de klant krijgt er zomaar één te zien die niet klopt.

De bouwstenen pakken de ticketstroom zelf aan én het zicht dat de opdrachtgever op zijn aanvragen krijgt. Een triage-agent die binnenkomende meldingen leest, die volgens jouw prioriteitsregels indeelt en bij de terugkerende vragen een conceptantwoord klaarzet. Met de medewerker als laatste blik voordat iets naar de klant gaat. Een klantportaal waarin projecten, documenten en tickets bij elkaar staan, zodat een opdrachtgever zelf kan volgen. Koppelingen tussen monitoring, tickets en facturatie, zodat één bron de waarheid heeft in plaats van drie. En een assistent op de eigen kennisbank, zodat de oplossing die collega's al twee keer schreven ook gevonden wordt. De kaarten hieronder laten de onderdelen zien; wat er eerst bij hoort, hangt af van waar jouw dienstverlening nu het meest vastloopt.

We beginnen met de stroom die het meest herhaalt. Bij de meeste providers is dat de tickettriage. In de discovery leggen we vast hoe meldingen nu binnenkomen, welke prioriteitsregels jullie hanteren en welke antwoorden standaard mogen zijn. Daaruit volgt een scope met aannames en een prijs op nacalculatie.

Daarna bouwen we in je bestaande omgeving: de tickettool, de monitoring, de documentopslag. De agent zet voorstellen klaar; de medewerker beslist. Elke stap die een klant of een factuur raakt, krijgt een controlemoment dat je strakker of losser kunt zetten naarmate het vertrouwen groeit. Zodra de triage draait, volgt het portaal als tweede traject. Een nieuwe site kan binnen 48 uur live staan zodra de scope vastligt. Handig als de leveringsvorm zelf ook op de agenda staat.

Hier staat het bewijs dichtbij: ons eigen platform is zelf zo'n traject. Het laat zien wat een klantportaal kan bevatten. Projecten, bestandsopslag, facturatie en abonnementen, meertalig tot en met rechts-naar-links, met een ingebouwde assistent die uit eigen documenten beantwoordt. Daarnaast staat in de cases een onderhoudsbedrijf dat in één klantomgeving werkt voor tickets, projecten en onderhoud, met AI-tools waaronder een calculator op de site. Wat je er niet leest: aantallen tickets, dienstverleningscijfers of namen van eindklanten; die horen bij die bedrijven, niet bij onze marketing.

Een provider beheert systemen van klanten, en daarmee materiaal dat onder vertrouwelijkheid staat, vaak van twee kanten tegelijk. Per werkstroom leggen we vast welke gegevens de triage-agent mag zien, waar documenten staan en wie er bij welke klant mag komen. Conceptantwoorden worden opgebouwd uit jouw eigen kennisbank, niet uit een algemeen modelantwoord, en de logging houdt bij welke automatische stap wanneer is uitgevoerd. Bestanden die via het portaal worden gedeeld, krijgen per opdracht hun toegangsregels en bewaartermijn. Voor een klant die vraagt hoe zijn gegevens worden behandeld, is dat verhaal in één document uit te leggen, en dat document schrijven we samen met jullie tijdens de bouw.

Ticket-triage en een klantportaal zijn twee verschillende bouwklussen, en dat zie je terug in de prijs. We prikken per onderdeel na de discovery wat het vraagt aan koppelingen, prioriteitsregels en controlemomenten, en offreren dat op nacalculatie. Er is geen standaardpakket voor providers, want twee MSP's met even grote klantenbestanden hebben totaal andere stromen.

Merken klanten dat geen mens hun ticket heeft gelezen?

Dat hangt af van hoe je het inricht, en de standaard is conservatief. De agent sorteert, geeft prioriteit en zet een concept klaar; naar de klant gaat niets zonder dat een medewerker het goedkeurt, zolang jij dat zo wilt houden. Later kun je voor de meest routinevragen de controle stap voor stap loslaten. Per categorie, met de logging ernaast om te zien waar het goed gaat en waar nog niet.

Wij monitoren met eigen tooling. Breekt zo'n traject die opzet?

Nee, het uitgangspunt is juist dat je tooling blijft staan. De automatisering werkt via de koppelingen en exports die je stack aanbiedt en voegt de stromen toe die ontbreken: triage, portaal, facturatie-doorloop. Monitoring blijft bij jouw pakket. Levert een onderdeel niets aan, dan zegt de discovery dat eerlijk. Beter één stroom minder dan een koppeling die iedereen moet omzeilen.

Kunnen opdrachtgevers in het portaal zien waar hun aanvraag staat?

Ja, dat is de bedoeling van de bouwsteen: status, documenten en het overzicht van wat het onderhoud oplevert, per klant afgeschermd van de andere. Jij bepaalt welke onderdelen zichtbaar zijn en welke interne notities achterblijven. Wat het portaal niet doet is beloftes doen namens jouw team; uitzonderingen en toezeggingen blijven werk van de medewerker die de klant kent.

Wat is een verstandig eerste traject voor een MSP, en hoe wordt het geprijsd?

Meestal de tickettriage, omdat daar de herhaling het dikst is en het effect direct merkbaar wordt voor het team. Het portaal is een logische tweede stap zodra de stroom stabiel draait. De prijs volgt uit de discovery: aantal koppelingen, prioriteitsregels en het aantal controlemomenten. Je ontvangt vooraf een schriftelijke scope en rekent af op nacalculatie, per onderdeel in plaats van als één blind pakket.

EIGHTY8