De meest voorkomende fout bij Autotask implementaties

Nieuwe keuken, oud fornuis: waarom je Autotask niet moet inrichten als je vorige systeem

Je ziet het vaak: een MSP maakt de overstap naar Autotask. De verwachtingen zijn torenhoog, misschien zelfs een beetje euforisch. Nieuwe start, nieuwe tool, alles strak geregeld. Maar na een paar maanden begint het alweer te schuren. Workarounds sluipen erin, er wordt gevloekt op de servicedesk, rapportages kloppen nét niet. De oorzaak? Ze hebben het oude systeem gekopieerd naar het nieuwe.

Alsof je een nieuwe keuken laat bouwen, maar besluit om je vergeelde kastjes, scheve gasfornuis en afbladderend aanrechtblad gewoon mee te nemen. Want ja, dat is wat je gewend bent.

De verleiding is begrijpelijk. Je processen “werken toch”? Maar veel van die processen zijn een lappendeken van oude beslissingen. Een spoedticketcategorie voor die ene klant in 2017. Een status “Wachten op reactie” die nooit meer gebruikt wordt maar nog overal in hangt. Een rapport dat niemand leest, behalve op maandagochtend “omdat het zo hoort”.

Van chaos naar structuur: Maturity Mapping

Wat je feitelijk doet bij zo’n kopieermigratie, is blijven hangen in level 2 van de Dxfferent MSP Maturity Model-pijler Organisation. Daar draait alles nog om impliciete kennis en reactief handelen. De werking van je servicedesk leunt op ‘die ene collega die het allemaal weet’.

Wil je door naar level 3 – gestandaardiseerd – dan moet je durven slopen. Niet verder bouwen op wankele fundamenten, maar resetten. Stel simpele vragen: “Waarom doen we dit zo?” “Wat gebeurt er als we dit loslaten?”

Je legt je processen vast alsof niemand ze kent. Je visualiseert, test en toetst. Pas dan richt je Autotask in. Niet als een kopie van het verleden, maar als blauwdruk van hoe je wilt werken.

Hoe richt je Autotask dan wél goed in?

Begin bij de basis. Herdefinieer je Product- en DienstenCatalogus. Koppel deze aan je boekhouding: denk aan General Ledgers, Billingcodes, Contractcategorieën, SLA’s, Services, Worktypes, Rollen en Exclusion Sets.

Daarna ga je naar de operationele laag: issues, sub-issues, ticketcategorieën, queues en statussen die logisch zijn voor jouw werkwijze. Kies statussen die de workflow sturen, zoals een statusgroep “Beoordeeld” die pas verschijnt na een bepaalde actie.

Je dashboards worden je stuurwiel. Voor de servicedesk stel je KPI’s in als: First Response Needed, Klant heeft gereageerd (automatisch via de Incoming Email Processor), Inactive Tickets en Due Date Today. Alleen al deze vier geven rust en overzicht.

Wil je verder, zorg dan dat elk ticket een Primary Resource heeft. En automatiseer via een Workflow Rule dat de afsluitende medewerker automatisch deze eigenaar wordt. Zo weet je altijd wie verantwoordelijk was. Combineer dit met een regel: als de klant ontevreden is en reageert, heropent het ticket en staat het weer op de oorspronkelijke oplosser.

Validatie begint bij jezelf gedragen als klant

Plan voor elke grote wijziging of migratie een sessie met drie servicedeskers. Geef elk een willekeurig ticket en laat ze hardop denken van aanmaak tot sluiting. De inzichten die dan op tafel komen zijn vaak scherper dan wat je uit tien consultancy-uren haalt.

Wil je je SLA-prestaties en tickettrends ook visueel volgen? Bekijk de servicedesk rapporten in Power BI.