Nieuwe klantcontactsoftware moet bijdragen aan meer efficiency of een hogere kwaliteit in klantcontact. Maar als eindgebruikers onvoldoende worden betrokken bij de ontwikkeling en implementatie, kan het eindresultaat juist het omgekeerde zijn. In dit artikel tien tips voor een succesvolle adoptie van nieuwe applicaties – en twintig mogelijke oorzaken van een lage adoptiegraad.

 

Het cliché van een software implementatie: operatie geslaagd, patiënt overleden. Ofwel: de software werkt, maar wordt niet gebruikt. Medewerkers blijven bijvoorbeeld oude software langer gebruiken dan de bedoeling is, schakelen over op workarounds of stappen over op alternatieve oplossingen (shadow-IT).

Voorbeelden uit de klantcontactoperatie: na de introductie van een kennismanagementsysteem blijven medewerkers hun eigen naslagwerken en notities gebruiken omdat de zoekfunctie te traag werkt; call reasons worden niet vastgelegd omdat het daarvoor bestemde veld niet beschikbaar is aan het eind van een call; de app voor zelfroosteren wordt niet omarmd omdat er geen smartphones op de werkvloer zijn toegestaan; er worden screenshots van schermen met klantgegevens gemaild omdat dat sneller gaat dan de officiële manier om vanuit de CRM-applicatie gegevens te delen.

Wat is gebruikersadoptie?

Gebruikersadoptie bij software is de mate waarin die (nieuwe) software wordt gebruikt door de eindgebruikers. Een ruwe maatstaf voor de adoptiegraad is de verhouding tussen het aantal actieve gebruikers en het totaal aantal beoogde gebruikers. Ook wordt bij adoptieonderzoek gekeken naar de hoeveelheid tijd die een applicatie wordt gebruikt en welke functionaliteiten wel en niet worden gebruikt. Als de adoptie niet naar wens is, moet je op zoek naar oorzaken.

Wat zijn oorzaken van een lage adoptie?

De invoering van nieuwe applicaties of van wijzigingen in applicaties heeft altijd een doel: processen verbeteren, versnellen of eenvoudiger maken met als bovenliggend doel minder fouten, meer werkplezier, lagere kosten en hogere opbrengsten. Een goed verlopen technische implementatie is geen garantie voor een optimaal gebruik. Wanneer het gebruik van een nieuwe applicatie niet is zoals verwacht, moet je op zoek naar de oorzaken. Een van de mogelijke uitkomsten waar je rekening mee moet houden is dat je je huiswerk niet goed genoeg hebt gedaan.

Wat zijn de meest voorkomende oorzaken van een lage adoptiegraad?

• medewerkers begrijpen niet goed hoe de software te gebruiken;
• de software is te bewerkelijk (handmatige acties zijn noodzakelijk);
• de software werkt omslachtig (te veel schermen, opbouw van schermen);
• de user interface van de software is onhandig – denk aan toetscombinaties in plaats van muisclicks
• software en processen sluiten niet aan (fouten);
• medewerkers zien de toegevoegde waarde niet;
• door een te lange ontwikkeltijd zijn de omstandigheden (processen, producten, doelstellingen) ondertussen veranderd;
• de performance is slecht (responstijd op commando’s, snelheid waarmee schermen worden geladen);
• de uptime is onvoldoende (veelvuldig storingen, onderhoud/beheer, upgrades);
• de inlogprocedure is omslachtig;
• de opstarttijd is te lang;
• de training sluit niet aan op individuele leerstijlen en vaardigheden van medewerkers;
• de training is gericht op hoe systeem werkt, maar niet op belangrijkste handelingen van de medewerker;
• delen van de applicatie die gebruikt zouden moeten worden, zijn niet noodzakelijk voor de uitvoering van de taken;
• het gebruik van onderdelen van de applicatie zit andere KPI’s en doelstellingen in de weg (denk aan maximale nawerktijd van agents);
• de zoekfunctie in de applicatie werken niet goed;
• de applicatie werkt met verouderde data of informatie;
• datasets/gegevens zijn anders gedefinieerd dan voorheen, denk aan nummers of categorieën;
• andere afdelingen dringen aan op het gebruik van een ouder of ander systeem;
• de support-organisatie/helpdesk kan medewerkers niet helpen.

Wat zijn de negatieve effecten van een lage adoptiegraad?

De effecten van een lage adoptiegraad zijn legio. Niet alleen wordt je oorspronkelijke probleem minder snel of niet opgelost, je moet achteraf extra investeren om de tegenvallende resultaten om te buigen in succes. Het nadeel van een gebrekkige implementatie is dat je in ieder geval kunt rekenen op sceptische medewerkers.

Andere effecten waar je rekening mee kunt houden:

• er zijn herhaaltrainingen nodig;
• weerstand groeit bij medewerkers (‘zie je wel’) of managers van andere afdelingen;
• het aantal support tickets richting de helpdesk neemt toe;
• fouten in processen en/of data die hersteld moeten worden;
• improductieve uren;
• gebruik van shadow-IT of van schaduw-administraties op papier;
• vertraging in het behalen van je resultaten en doelstellingen.

Optimaliseer de adoptie: tien tips

1. De softwarekeuze begint bij het probleem dat moet worden opgelost, maar ook bij de gebruikers. De implementatie van software moet je behandelen als een veranderproces, ook in het contactcenter. Betrek eindgebruikers – agents, supervisors, coaches, WFM’ers, kennishouders – vanaf het allereerste begin bij de vraag of de doelstelling die centraal staat bij de ontwikkeling van nieuwe software. Eindgebruikers moeten het erover eens zijn dat nieuwe software (en niet iets anders) de beste oplossing is voor het geconstateerde probleem. Uiteraard moet de IT-beslissing in lijn zijn met de bedrijfsstrategie. Wees realistisch over de verwachte opbrengsten.

Breng verschillende subgroepen in de gebruikerspopulatie in kaart en betrek leden van deze groepen bij het selectie- en ontwikkelproces. Vraag actief naar de uitdagingen in de huidige processen en de bestaande applicaties, breng in kaart welke workarounds en welke shadow-IT wordt gebruikt.

Richt gebruikersgroepen in, die tijdens het gehele traject van ontwikkeling tot en met gebruikerstrainingen actief betrokken blijven. Betrek een diverse groep van customerservice-medewerkers en geef ze verschillende rollen in het project. Toets bedachte keuzes in feedback-bijeenkomsten alvorens ze definitief te maken. Laat ook thuiswerkende agents naar kantoor komen om mee te draaien in projectgroepen.

2. Communiceer van begin tot eind veel, vaak en duidelijk, over het doel en het waarom. Communicatie is een belangrijk onderdeel én het begin van je adoptieplan, dat weer een onderdeel is van je IT-project. Besteed bij de communicatie niet alleen aandacht aan de why van de softwarevernieuwing, maar ook aandacht aan hoe training, support en feedback straks geregeld zullen worden. Geef ook duidelijke kaders aan en manage de verwachtingen: niet alle wensen van alle eindgebruikers komen terug in het eindresultaat. Test iedere communicatiestap vooraf bij je groep super users. Herhaal boodschappen via meerdere kanalen. Stel vragen aan de eindgebruikers, voorkom dat je alleen aan het zenden bent. Maak ook negatieve feedback bekend.

3. Stel snel een MVP beschikbaar. Laat de gebruikersgroep in een zo vroeg mogelijk stadium kennismaken met (en feedback geven op) de demoversie, en in de ontwikkelfase met een MVP (minimum viable product). Verzamel feedback, leg in latere bijeenkomsten steeds uit welke feedback wel en niet is meegenomen en waarom, en communiceer wanneer de volgende iteratie gepland staat.

4. Zorg voor een goede testperiode. Rammelende software (downtime door storing of voor beheer) is dodelijk voor de acceptatie en dus voor de adoptie. Besteed hierbij aandacht aan doorlooptijd van processen, aan overbodige systeemhandelingen, Ga naast de eindgebruiker zitten. Gebruik eventueel gamification om problemen op te sporen en op te lossen.

5. Besteed voldoende tijd en geld aan training, maar vergeet ook de funfactor niet. Maak eventueel gebruik van gamification tijdens de uitrol en leg de bedoeling hiervan al uit voorafgaand aan de implementatie. Rol de software eventueel stapsgewijs uit (per team of per functionaliteit) zodat er voldoende tijd is om aandacht te geven aan eindgebruikers.

6. Voorzie de eindgebruikers van support in de operatie. Denk aan informatie, documentatie, workflows, instructies, FAQ’s, stappenplannen en buddies die tijdens de eerste dagen of weken na de live date de eindgebruikers op de werkvloer terzijde staan. Regel een vergelijkbare ondersteuning voor thuiswerkende collega’s. Deze buddies werken mee in de operatie, zijn duidelijk herkenbaar en zijn beschikbaar voor hun collega’s.

7. Geef super users een duidelijke taak en rol. Bevorder het gebruik door super users aan te wijzen in zowel de front- als backoffice die als ambassadeurs en als doorgeefluik optreden richting het management en de IT-organisatie of de projectleiding. Zij kunnen de feedback van de werkvloer (van eindgebruikers en buddies) analyseren en suggesties aanreiken voor changes. Wees helder over doorlooptijden.

8. Activeer de helpdesk en zorg ervoor dat de helpdesk goed op sterkte is rond de go live datum, maar ook daarna. Richt eventueel een apart team of loket in. Zorg vooraf voor noodplannen als een belangrijke applicatie niet goed functioneert en communiceer deze ook. Geef eindgebruikers inzicht in wat ze wel en niet van de helpdesk kunnen verwachten.

9. Meet het gebruik van de nieuwe applicatie. Hoe doe je dit? Dat kan via Digital Endpoint Monitoring. Hiervoor wordt een software-agent op een device geïnstalleerd die daarna realtime informatie uitwisselt met een DEM-applicatie. Het gaat dan om informatie over de identiteit van het device, de gezondheid van de accu, de werking van het besturingssysteem (denk aan de opstartsnelheid of de status van het werkgeheugen), de kwaliteit van de connectiviteit en de performance van de afzonderlijke applicaties. DEM-applicaties worden ook wel aangeduid met DEX-tools (Digital Experience), waarbij de laatste categorie rekening houdt met eindgebruikersbeleving.

10. Analyseer de feedback van eindgebruikers. Een van de belangrijkste informatiebronnen bestaat uit de tickets van de helpdesk. Daarnaast kan je feedbacksessies organiseren via eindgebruikerspanels en eindgebruikers expliciet uitnodigen om feedback te geven tijdens het gebruik. Naarmate het gebruik van een applicatie toeneemt, kan de complexiteit van de vragen veranderen.

11. Bonustip: doe inspiratie op en leer van de ervaringen uit een andere sector. Michel Peters, voormalig CIO bij SIZA (SIZA ondersteunt mensen met niet aangeboren lichamelijke beperkingen en geestelijke handicaps) vertelt over het toepassen van het design thinking principe bij applicaties. “Waar is behoefte aan? Wat wil je nou eigenlijk bereiken met nieuwe IT?”

(Ziptone/redactie)

Featured, Human Resources, Kennisbank