Je voorkomt dat rapportages veranderen of verdwijnen na een contactcentermigratie door vóór de migratie een volledige inventarisatie te maken van alle bestaande rapportages, KPI-definities en databronnen, en door duidelijke afspraken te maken over hoe historische data wordt overgezet en gevalideerd. Zonder die voorbereiding loop je het risico dat stuurinformatie na de livegang niet meer klopt, ontbreekt of anders wordt berekend dan verwacht.
Dit geldt voor elke organisatie die overstapt naar een nieuw contactcenterplatform, ongeacht de schaal van de migratie. De vragen hieronder geven je een concreet kader, van risico-inventarisatie tot validatie na livegang.
Welke rapportages lopen het meeste risico bij een contactcentermigratie?
Rapportages die het meeste risico lopen bij een contactcentermigratie zijn die welke afhankelijk zijn van platformspecifieke datastructuren, zoals wachttijdrapportages, servicelevelrapporten en agentprestatiemetingen. Deze zijn vaak diep verweven met de interne logica van het oude systeem en worden niet automatisch correct vertaald naar een nieuw platform.
Concreet zijn dit de categorieën die je extra aandacht moet geven:
- Realtime dashboards die live data ophalen uit het oude systeem en na migratie een nieuwe databron nodig hebben
- Historische trendrapportages waarbij vergelijkbaarheid over tijd essentieel is voor capaciteitsplanning of kwaliteitsmonitoring
- Gecombineerde rapportages die data samenvoegen uit meerdere systemen, zoals CRM, telefonie en chat
- Handmatige rapportages die medewerkers zelf samenstellen op basis van exports, want die zijn vaak slecht gedocumenteerd
- Compliancerapportages die voor audits of toezichthouders worden gebruikt en waarbij afwijkingen direct consequenties hebben
Rapportages die puur in een BI-tool of extern datawarehouse leven, zijn minder kwetsbaar, mits de onderliggende datafeed na migratie correct wordt doorgezet. Maar ook daar geldt: controleer of de veldnamen, aggregatieniveaus en tijdzoneconfiguraties overeenkomen met wat het nieuwe platform levert.
Waarom veranderen KPI-definities na een platformwissel?
KPI-definities veranderen na een platformwissel omdat elk contactcenterplatform zijn eigen manier heeft om meetwaarden te berekenen. Wat het ene systeem een "afgehandeld gesprek" noemt, telt het andere pas mee als de nawerktijd is afgerond. Die technische verschillen zijn niet zichtbaar in de rapportagenamen, maar wel in de cijfers.
Een paar veelvoorkomende oorzaken van KPI-drift na migratie:
- Andere definitie van servicelevel: sommige platforms meten de tijd tot de eerste ringtoon, andere pas vanaf het moment dat een agent beschikbaar is
- Afwijkende berekening van gemiddelde afhandeltijd (AHT): inclusief of exclusief nawerktijd, wachttijd in de wachtrij of doorverbindtijd
- Hoe abandoned calls worden geteld: direct ophangen versus ophangen na een bepaald aantal seconden
- Tijdzone-instellingen: rapportages die op UTC draaien in het nieuwe systeem terwijl het oude systeem lokale tijd gebruikte
Het gevolg is dat je na de migratie lagere of hogere KPI-scores ziet zonder dat de werkelijke prestatie is veranderd. Dat ondermijnt het vertrouwen in data en maakt sturing moeilijker. Leg daarom vóór de migratie per KPI vast hoe deze wordt berekend in het huidige systeem, en toets dat aan de definitie in het nieuwe platform.
Hoe maak je een volledige inventarisatie van bestaande rapportages?
Een volledige inventarisatie van bestaande rapportages maak je door systematisch alle rapportages te verzamelen die door of voor het contactcenter worden gebruikt, inclusief informele exports en handmatige overzichten. Betrek daarbij niet alleen de beheerders, maar ook de dagelijkse gebruikers, want die weten welke rapportages echt worden gebruikt en welke al jaren niet meer worden geopend.
Doorloop deze stappen:
- Verzamel alle rapportages uit het huidige systeem, inclusief geplande e-mailrapporten, dashboards en ad-hocqueries
- Voeg handmatige rapportages toe die medewerkers zelf bijhouden in Excel of andere tools
- Documenteer per rapportage: naam, eigenaar, frequentie, gebruikers, databron, KPI-definities en doel
- Prioriteer op basis van gebruik en impact: welke rapportages zijn bedrijfskritisch, welke worden zelden geraadpleegd?
- Markeer afhankelijkheden: welke rapportages zijn input voor andere processen, beslissingen of externe partijen?
Een praktisch hulpmiddel is een rapportageregister in een eenvoudig spreadsheet. Dat register wordt later de basis voor je migratieplanning en validatiechecklist. Houd het behapbaar: focus eerst op de rapportages die dagelijks of wekelijks worden gebruikt.
Wat moet er geregeld zijn voordat historische data wordt gemigreerd?
Voordat historische data wordt gemigreerd, moet je weten welke data je wilt bewaren, in welk formaat het nieuwe platform die data verwacht, en hoe je de integriteit van de overgezette data controleert. Zonder die voorbereiding migreer je data die niet leesbaar, niet vergelijkbaar of niet compleet is in het nieuwe systeem.
Zorg dat de volgende zaken zijn geregeld:
- Dataretentiebeleid: hoeveel maanden of jaren aan historische data wil je meenemen, en wat is wettelijk verplicht?
- Dataformaat en veldmapping: zijn de velden en waarden uit het oude systeem te vertalen naar de structuur van het nieuwe platform?
- Archiveringsstrategie voor onmigreerbare data: niet alle historische data past in het nieuwe systeem; bepaal wat wordt gearchiveerd en hoe het raadpleegbaar blijft
- Privacytoets: voldoet de datamigratie aan de AVG, en zijn er gegevens die niet mogen worden overgezet?
- Testmigratie: voer een proefmigratie uit met een beperkte dataset voordat je de volledige historische data overzet
Een veelgemaakte fout is om historische data pas op het laatste moment te regelen. Neem dit op in de projectplanning als een apart werkpakket met eigen doorlooptijd, want datakwaliteit en privacy-checks kosten meer tijd dan verwacht.
Hoe valideer je rapportages na livegang van het nieuwe systeem?
Na livegang valideer je rapportages door de uitkomsten van het nieuwe systeem gedurende een afgesproken periode parallel te vergelijken met de uitkomsten van het oude systeem of een betrouwbare referentie. Pas als de afwijkingen binnen een acceptabele marge vallen, schakel je volledig over op de nieuwe rapportages.
Een werkbare aanpak voor validatie:
- Stel een parallelle periode in van minimaal twee weken waarin beide systemen actief zijn en rapportages naast elkaar worden bijgehouden
- Definieer acceptabele afwijkingen per KPI voordat je begint, zodat je objectief kunt beoordelen of een verschil een fout is of een verwacht gevolg van een andere definitie
- Test op meerdere niveaus: totalen op organisatieniveau, per team, per kanaal en per tijdseenheid
- Betrek eindgebruikers bij de validatie, want zij herkennen afwijkingen die technisch moeilijk te detecteren zijn
- Documenteer afwijkingen en hun oorzaak, ook als ze acceptabel zijn, zodat je later kunt uitleggen waarom cijfers voor en na de migratie verschillen
Zorg ook dat je een formeel akkoord vraagt van de eigenaren van bedrijfskritische rapportages voordat je het oude systeem afsluit. Dat voorkomt discussies achteraf over of de data wel klopt.
Wanneer is het beter om rapportages opnieuw op te bouwen dan te migreren?
Het is beter om rapportages opnieuw op te bouwen dan te migreren wanneer de bestaande rapportages zijn gegroeid rondom beperkingen van het oude systeem, niet meer aansluiten op actuele stuurbehoeften, of zo complex zijn geworden dat migratie meer risico geeft dan een frisse start. Migratie is geen doel op zich als het resultaat een digitale kopie is van een verouderd rapport.
Situaties waarin opnieuw opbouwen de betere keuze is:
- De rapportage bevat workarounds of correctiefactoren die compenseerden voor tekortkomingen van het oude platform
- Niemand weet meer waarom bepaalde berekeningen zo zijn ingericht, en er is geen documentatie
- Het nieuwe platform biedt native rapportagemogelijkheden die de bestaande rapportage overbodig maken
- De rapportage wordt zelden gebruikt en de opbouwtijd is lager dan de migratietijd
- De stuurinformatiebehoefte is veranderd en de bestaande rapportage sluit daar niet meer op aan
Gebruik de inventarisatie die je eerder hebt gemaakt om per rapportage een bewuste keuze te maken: migreren, opnieuw opbouwen of laten vervallen. Die driedeling maakt de scope beheersbaar en voorkomt dat je energie steekt in het conserveren van rapportages die niemand meer nodig heeft.
Hoe Pegamento helpt bij het behouden van rapportages na een contactcentermigratie
Wij begeleiden organisaties bij het volledige migratietraject, van de eerste inventarisatie tot de validatie na livegang. Daarbij zorgen we ervoor dat rapportages en historische data niet verloren gaan of ongemerkt veranderen. Wat we concreet voor je regelen:
- Rapportage-inventarisatie en prioritering: we brengen alle bestaande rapportages in kaart, inclusief informele exports en handmatige overzichten, en bepalen samen met jou wat wordt gemigreerd, opnieuw opgebouwd of afgebouwd
- KPI-mapping: we documenteren hoe elke KPI is gedefinieerd in het huidige systeem en toetsen dat aan de definities in het nieuwe platform, zodat je na de migratie appels met appels blijft vergelijken
- Datamigratieregie: we regelen de technische en organisatorische voorbereiding voor historische datamigratie, inclusief privacytoets en archiveringsstrategie
- Parallelle validatie: we begeleiden de parallelle periode na livegang en beoordelen samen met jou of rapportages correct functioneren voordat het oude systeem wordt afgesloten
- Eén aanspreekpunt voor het totaalpakket: van contactcentertechnologie tot omnichannelcommunicatie, je hoeft niet te schakelen tussen meerdere leveranciers
We werken met een slimme combinatie van bewezen modules, geen kostbaar maatwerk, maar oplossingen op maat met standaard bouwblokken die aansluiten op jouw processen en systemen. Zo houd je grip op je data, je rapportages en je stuurinformatie, ook na een ingrijpende platformwissel.
Wil je weten hoe we jouw migratie kunnen begeleiden zonder dataverlies of rapportageproblemen? Neem contact met ons op en we denken graag met je mee.
Veelgestelde vragen
Hoe lang duurt een typische parallelle validatieperiode en wat als het oude systeem al is afgesloten?
Een parallelle validatieperiode duurt idealiter twee tot vier weken, afhankelijk van de complexiteit van je rapportages en het aantal kanalen dat je beheert. Als het oude systeem al is afgesloten voordat validatie heeft plaatsgevonden, kun je terugvallen op geëxporteerde snapshots of gearchiveerde data als referentie — mits je die vóór de migratie hebt veiliggesteld. Dit is precies waarom het vastleggen van een nulmeting vóór livegang een verplicht onderdeel van je migratieplan moet zijn, niet een optionele stap.
Wat doe je als eindgebruikers na de migratie klagen dat de cijfers 'niet kloppen', maar je technisch geen fout kunt vinden?
Dit is vaak een signaal van KPI-drift: de cijfers zijn technisch correct, maar anders berekend dan gebruikers gewend zijn. De oplossing is niet opnieuw rekenen, maar uitleggen — documenteer per KPI wat er is veranderd in de definitie en communiceer dit actief naar alle gebruikers. Maak ook een overgangsdocument met een vergelijking van de oude en nieuwe berekeningswijze, zodat teamleiders en managers de context hebben om rapportages correct te interpreteren.
Welke informatie moet je minimaal per rapportage vastleggen in een rapportageregister?
Leg per rapportage minimaal de volgende informatie vast: naam en beschrijving, eigenaar en gebruikersgroep, rapportagefrequentie, databron(nen), gebruikte KPI’s met hun definities, het doel van de rapportage en eventuele afhankelijkheden met andere processen of systemen. Voeg ook een kolom toe voor de migratiebeslissing — migreren, opnieuw opbouwen of laten vervallen — zodat het register direct als planningsinstrument dient tijdens het migratietraject.
Hoe ga je om met rapportages die data combineren uit het nieuwe contactcenterplatform én uit systemen die niet worden gemigreerd, zoals een CRM?
Gecombineerde rapportages vereisen een aparte aanpak: breng per rapportage in kaart welke datafeed uit welk systeem komt, en toets na de migratie elke feed afzonderlijk voordat je de gecombineerde output valideert. Let daarbij specifiek op veldnamen, unieke sleutels die worden gebruikt voor de koppeling (zoals klant-ID of gesprek-ID) en tijdzoneconfiguraties, want kleine afwijkingen daarin zorgen voor onjuiste samenvoegingen die moeilijk te detecteren zijn in het eindrapport.
Is het verstandig om de rapportagestructuur tijdens de migratie meteen te herzien, of is het beter om eerst één op één te migreren?
De aanbevolen aanpak is om bedrijfskritische rapportages eerst één op één te migreren en pas daarna te optimaliseren — het gelijktijdig wijzigen van platform én rapportagestructuur vergroot het risico op fouten en maakt validatie aanzienlijk moeilijker. Gebruik de inventarisatie om een duidelijke scheiding te maken: wat moet direct werken na livegang, en wat kan in een tweede fase worden verbeterd of herontworpen. Die gefaseerde aanpak houdt de migratie beheersbaar en het vertrouwen in de data intact.
Welke AVG-aandachtspunten zijn specifiek relevant bij de migratie van historische contactcenterdata?
Bij de migratie van historische contactcenterdata moet je rekening houden met bewaartermijnen per datatype — gespreksopnames mogen vaak niet langer worden bewaard dan strikt noodzakelijk — en met de vraag of persoonsgegevens überhaupt mogen worden overgezet naar een nieuw platform met mogelijk een andere verwerkingslocatie. Controleer ook of de nieuwe leverancier een geldige verwerkersovereenkomst heeft en of de datamigratie zelf, inclusief eventuele tussentijdse opslag, voldoet aan de AVG. Schakel je privacyfunctionaris (FG) vroegtijdig in, zodat een privacytoets geen vertraging veroorzaakt vlak voor de livegang.
Hoe betrek je teamleiders en operationeel managers bij de migratie van rapportages zonder hen te overladen met technische details?
Betrek teamleiders en managers op het niveau dat voor hen relevant is: laat hen de inventarisatie valideren door te bevestigen welke rapportages zij daadwerkelijk gebruiken voor sturing, en vraag hen expliciet om akkoord bij de validatie na livegang. Vertaal technische bevindingen — zoals een gewijzigde AHT-definitie — naar de operationele impact: wat betekent dit voor de targets en hoe moeten zij de cijfers voortaan lezen? Zo worden zij eigenaar van de rapportages in het nieuwe systeem in plaats van sceptische gebruikers die de data wantrouwen.
Gerelateerde artikelen
- Welke invloed hebben onderhoudskosten op de terugverdientijd van klantcontactautomatisering?
- Wat is de impact van kennisverlies op de continuïteit van je bedrijf?
- Wat levert klantsentiment analyse op voor je klantcontact?
- Wanneer is klantsentiment analyse zinvol voor jouw organisatie?
- Hoe log en audit je AI-beslissingen in geautomatiseerde e-mailafhandeling?
