Automatische doorschakelingen vallen na een migratie het vaakst uit doordat nummerconfiguraties, IVR-logica en routeringsregels niet één-op-één worden overgezet naar de nieuwe omgeving. De oplossing zit in grondige voorbereiding: documenteer alle bestaande doorschakelingen vóór de migratie, test ze systematisch in een acceptatieomgeving en zorg voor een terugvalscenario op de dag van livegang. In dit artikel beantwoorden we de meest gestelde vragen over call routing na een migratie, van risico-inventarisatie tot herstel en de rol van een externe partner.
Waarom vallen automatische doorschakelingen uit na een migratie?
Automatische doorschakelingen vallen uit na een migratie omdat de configuratie in het oude systeem zelden volledig gedocumenteerd is en niet automatisch wordt meegenomen naar het nieuwe platform. Routeringsregels, tijdschema’s, wachtrijen en IVR-menu’s zijn vaak over jaren gegroeid en bevatten afhankelijkheden die pas zichtbaar worden als ze niet meer werken.
Bij een telefoniemigratie of contactcentermigratie zijn er drie veelvoorkomende oorzaken:
- Nummertranslatie die niet klopt: Interne extensies of DDI-nummers worden anders genummerd in het nieuwe systeem, waardoor bestaande doorschakelingen naar een onbestaand doel verwijzen.
- Verlies van tijdgebonden logica: Openingstijden, feestdagenroosters en afwijkende schema’s staan vaak hardcoded in het oude systeem en worden niet automatisch geëxporteerd.
- Verbroken integraties: Doorschakelingen die afhankelijk zijn van een koppeling met een CRM, personeelsplanning of externe database werken niet meer als die koppeling tijdens de migratie tijdelijk of permanent wegvalt.
Een migratie is geen simpele kopieeroperatie. Elk platform heeft zijn eigen manier om routering op te slaan, en wat in systeem A één instelling is, kan in systeem B uit drie aparte configuratieschermen bestaan.
Welke doorschakelingen lopen het meeste risico tijdens een migratie?
De doorschakelingen die het meeste risico lopen tijdens een contactcentermigratie zijn de complexe, meerlagige routeringen die afhankelijk zijn van externe databronnen, tijdcondities of meerdere tussenstappen. Eenvoudige vaste doorschakelingen van nummer A naar nummer B overleven een migratie meestal zonder problemen.
Bijzondere aandacht verdienen:
- IVR-menu’s met conditionele logica die op basis van klantkeuze, tijdstip of wachttijd een andere route kiezen
- Noodscenario’s en afwijkende routering voor storingen, piekdrukte of feestdagen die zelden worden getest maar kritiek zijn
- Doorschakelingen naar externe nummers van thuiswerkers, externe dienstverleners of vestigingen met eigen telefoniesystemen
- Wachtrij-overflows die bij te lange wachttijden automatisch doorschakelen naar een ander team of een voicemail
- Skill-based routing waarbij gesprekken op basis van klantprofiel of taalvoorkeur naar specifieke medewerkers worden gestuurd
Deze doorschakelingen zijn het meest kwetsbaar omdat ze niet alleen een bestemmingsnummer bevatten, maar ook logica, condities en externe afhankelijkheden. Bij een IVR-migratie is het precies deze laag die handmatig moet worden nagebouwd en gevalideerd.
Hoe test je doorschakelingen vóór de livegang van een migratie?
Je test doorschakelingen vóór de livegang door een volledig testplan op te stellen op basis van een routeringsmatrix, alle scenario’s in een acceptatieomgeving door te lopen en de resultaten te vergelijken met het gedrag in het oude systeem. Testen na de migratie is te laat; testen moet een formele fase zijn in het migratieproject zelf.
Een effectief testproces bevat minimaal deze stappen:
- Inventariseer alle actieve doorschakelingen in het bestaande systeem, inclusief tijdelijke en seizoensgebonden varianten.
- Bouw een testmatrix met elk uniek scenario: normale kantoortijden, buiten openingstijden, feestdagen, piekbelasting en storingssituaties.
- Test in een geïsoleerde acceptatieomgeving die de productieomgeving zo nauwkeurig mogelijk nabootst, inclusief actieve integraties.
- Voer end-to-endgesprekstests uit vanuit externe nummers, zodat je het volledige pad van inkomend gesprek tot agent simuleert.
- Documenteer afwijkingen en herstel ze vóór livegang, niet erna.
Betrek ook de medewerkers die dagelijks met de doorschakelingen werken bij het testen. Zij kennen de uitzonderingen en randgevallen die in geen enkel technisch document staan. Call routing na een migratie is pas betrouwbaar als ook die impliciete kennis is gevalideerd.
Wat moet er in een routeringsmatrix staan om migratieproblemen te voorkomen?
Een routeringsmatrix is een gestructureerd overzicht van alle doorschakelingen, condities en bestemmingen in je telefonieomgeving. Om migratieproblemen te voorkomen, moet de matrix voor elke doorschakeling minimaal het bronaansluitnummer, de conditie, de bestemming, de terugvalbestemming en de verantwoordelijke eigenaar bevatten.
Een volledige routeringsmatrix bevat per rij:
- Bronaansluitnummer of wachtrij: het nummer of kanaal waarop de oproep binnenkomt
- Tijdconditie: wanneer geldt deze routering (dag, tijdstip, feestdag, uitzondering)?
- Primaire bestemming: waar gaat het gesprek naartoe onder normale omstandigheden?
- Overflow- of terugvalbestemming: wat gebeurt er als de primaire bestemming niet beschikbaar is?
- Afhankelijkheden: welke systemen of integraties zijn nodig voor deze routering?
- Testresultaat: is deze routering getest en goedgekeurd in de acceptatieomgeving?
- Eigenaar: wie is verantwoordelijk voor het beheer en de validatie van deze lijn?
Een routeringsmatrix is geen eenmalig document. Zorg dat hij na de migratie actueel blijft, want organisaties die dit verwaarlozen, hebben bij de volgende wijziging of migratie opnieuw een blinde vlek.
Hoe herstel je een doorschakeling die na de migratie niet meer werkt?
Als een doorschakeling na de migratie niet meer werkt, herstel je die door eerst de oorzaak te isoleren: ligt het aan een verkeerde bestemmingsconfiguratie, een verbroken integratie of een ontbrekende tijdregel? Pas daarna pas je de configuratie aan, test je het herstel en documenteer je de wijziging in de routeringsmatrix.
Doorloop bij een niet-werkende doorschakeling dit stappenplan:
- Reproduceer het probleem met een testgesprek vanuit een extern nummer, zodat je zeker weet wat er misgaat en waar het gesprek afbreekt of verkeerd terechtkomt.
- Vergelijk de huidige configuratie met de routeringsmatrix of de documentatie van het oude systeem om te zien wat er verschilt.
- Controleer afhankelijkheden: is de koppeling met het CRM of de wachtrij actief? Zijn de tijdregels correct ingesteld?
- Pas de configuratie aan in de beheeromgeving van het nieuwe systeem en test direct na de wijziging met een live testgesprek.
- Documenteer de oorzaak en de oplossing zodat je bij vergelijkbare problemen sneller kunt handelen.
Bij complexe IVR-migraties is het verstandig om in de eerste weken na livegang een verhoogde monitoringfrequentie aan te houden en een escalatiepad klaar te hebben voor meldingen van medewerkers of klanten die een verkeerde bestemming bereiken.
Wanneer schakel je een externe partner in bij een telefoniemigratie?
Je schakelt een externe partner in bij een telefoniemigratie wanneer de interne kennis van routeringsconfiguratie, integraties of het nieuwe platform onvoldoende is om de migratie zonder risico uit te voeren. Hoe complexer de bestaande omgeving, hoe eerder externe expertise loont.
Concrete signalen dat externe ondersteuning verstandig is:
- De bestaande routering is niet of nauwelijks gedocumenteerd en de kennis zit bij één of twee medewerkers
- Het nieuwe platform verschilt fundamenteel van het oude systeem in architectuur of configuratielogica
- Er zijn meerdere vestigingen, systemen of leveranciers betrokken bij het klantcontact
- De organisatie kan zich geen uitval of fouten in bereikbaarheid veroorloven vanwege bedrijfskritisch klantcontact
- Interne IT heeft onvoldoende capaciteit naast de dagelijkse beheertaken
Een externe partner voegt waarde toe in drie fases: vóór de migratie bij het documenteren en structureren van de bestaande omgeving, tijdens de migratie bij configuratie en testen, en erna bij monitoring en optimalisatie. Kies een partner die niet alleen adviseert maar ook de uitvoering en het beheer op zich neemt, zodat je één aanspreekpunt hebt voor het volledige traject.
Hoe Pegamento helpt bij een veilige migratie van je contactcenteromgeving
Wij begeleiden organisaties bij het volledige migratietraject van hun contactcenteromgeving, van de eerste inventarisatie tot de doorlopende optimalisatie na livegang. Dat betekent dat je bij ons alles onder één dak afneemt, zonder complex leveranciersmanagement of losse adviezen die je zelf moet uitvoeren.
Wat we concreet voor je doen:
- Volledige routeringsdocumentatie van je bestaande omgeving, inclusief IVR-logica, tijdschema’s en integraties
- Opbouw van een routeringsmatrix die als fundament dient voor de migratie en het beheer daarna
- Configuratie en testen van alle doorschakelingen in een acceptatieomgeving vóór de livegang
- Begeleiding op de migratiedag met een actief terugvalscenario en directe herstelcapaciteit
- Monitoring en optimalisatie in de weken na livegang om afwijkingen snel te signaleren en op te lossen
We werken met bewezen modules en slimme combinaties van standaardbouwblokken die aansluiten op jouw processen en systemen, geen kostbaar maatwerk. Onze oplossingen voor contactcentertechnologie en omnichannel bedrijfstelefonie zijn ontworpen om ook complexe omgevingen beheersbaar en toekomstbestendig te maken. Wil je weten hoe we jouw migratie kunnen begeleiden? Neem contact met ons op en we kijken samen naar de beste aanpak voor jouw situatie.
Veelgestelde vragen
Hoe lang duurt het gemiddeld om alle doorschakelingen correct te documenteren vóór een migratie?
De tijd die nodig is voor een volledige routeringsdocumentatie hangt sterk af van de complexiteit van je omgeving. Voor een middelgrote organisatie met meerdere wachtrijen, IVR-menu’s en tijdschema’s moet je rekenen op één tot drie weken intensief werk. Plan dit altijd ruim vóór de migratie in, zodat er nog tijd is om ontbrekende informatie op te halen bij medewerkers die de impliciete kennis in hun hoofd hebben.
Wat is een realistisch terugvalscenario als doorschakelingen op de migratiedag uitvallen?
Een goed terugvalscenario bestaat minimaal uit een tijdelijke omleiding van kritieke nummers naar een stabiele bestemming, zoals een mobiel nummer of een extern callcenter, en een duidelijk escalatiepad voor medewerkers om storingen direct te melden. Zorg dat dit scenario vooraf is geconfigureerd én getest, niet pas wordt bedacht op het moment dat er iets misgaat. De migratiedag is niet het moment om te improviseren.
Kunnen we de migratie gefaseerd uitvoeren om risico's op uitval te beperken?
Ja, een gefaseerde migratie is in veel gevallen de veiligste aanpak, waarbij je begint met minder kritieke nummers of vestigingen en pas overschakelt op de complexere routeringen nadat de eerste fase stabiel is. Dit geeft je de kans om problemen in een gecontroleerde omgeving te ontdekken en op te lossen voordat de hele organisatie op het nieuwe systeem draait. Bespreek deze aanpak wel vooraf met je leverancier, want niet elk platform ondersteunt een langdurig hybride scenario.
Hoe voorkom je dat de routeringsmatrix na de migratie verouderd raakt?
Wijs één eigenaar aan die verantwoordelijk is voor het actueel houden van de routeringsmatrix en maak het bijwerken ervan een vast onderdeel van het wijzigingsproces: geen aanpassing aan een doorschakeling zonder dat de matrix direct wordt bijgewerkt. Koppel dit idealiter aan een changemanagementprocedure, zodat elke wijziging gedocumenteerd, goedgekeurd en getest wordt. Organisaties die dit structureel inrichten, vermijden de blinde vlekken die bij een volgende migratie of audit direct opspelen.
Wat zijn de meest gemaakte fouten bij een IVR-migratie die achteraf veel herstelwerk kosten?
De drie meest kostbare fouten zijn: het niet testen van noodscenario’s en feestdagenroosters omdat ze op het moment van migratie niet actief zijn, het onderschatten van afhankelijkheden met externe systemen zoals CRM of personeelsplanning, en het ontbreken van een gestructureerde acceptatiefase waarbij eindgebruikers de routering valideren. Juist de uitzonderingssituaties die zelden voorkomen, zijn het lastigst om achteraf te herstellen omdat de oorzaak moeilijk te reproduceren is.
Hoe weet je of een externe partner genoeg ervaring heeft met jouw specifieke telefonieplatform?
Vraag de partner naar aantoonbare ervaring met migraties op jouw specifieke platform, bij voorkeur met referenties van vergelijkbare organisaties qua omvang en complexiteit. Laat ze ook uitleggen hoe ze omgaan met de verschillen in configuratielogica tussen het oude en het nieuwe systeem, want dat is precies waar de meeste migratieproblemen ontstaan. Een partner die alleen adviseert maar de uitvoering overlaat aan jouw interne team, biedt minder zekerheid dan een partner die het volledige traject inclusief testen en monitoring op zich neemt.
Hoe lang moet je verhoogde monitoring aanhouden na de livegang van een migratie?
Houd verhoogde monitoring minimaal vier tot zes weken aan na de livegang, want veel problemen met doorschakelingen komen pas aan het licht bij specifieke tijdcondities zoals de eerste feestdag, een piekmoment of een uitzonderlijk hoog belvolume. Stel in deze periode lage drempelwaarden in voor alerts op mislukte routeringen en zorg dat er direct iemand beschikbaar is om in te grijpen. Na deze stabilisatieperiode kun je terugschakelen naar regulier beheer, bij voorkeur met een gedocumenteerd escalatiepad voor toekomstige incidenten.
Gerelateerde artikelen
- Hoe voorkom je dat gespreksgeschiedenis verloren gaat tijdens een contactcentermigratie?
- Hoeveel extra werk veroorzaken onvolledige klantdossiers?
- Wat is het verschil tussen een intranet en een kennisbeheersysteem?
- Wat zijn de ethische aspecten van data soevereiniteit?
- Hoe richt je triage in voor klantenservice?
