Klantoperaties

Klantgesprekken migreren zonder context te verliezen

Migreer klantgesprekken met een bewijsgerichte aanpak die identiteit, volgorde, eigenaarschap, relaties, toestemming en vervolgactie bewaart.

Door DripTell EditorialGepubliceerd 17 augustus 2026Leestijd 6 min readLaatst gecontroleerd 21 augustus 2026
Een medewerker klantoperaties vergelijkt twee laptops terwijl de Context Keeper de migratie controleert

Een migratie van klantgesprekken is niet klaar wanneer de import 100 procent aangeeft. Ze is klaar wanneer een medewerker een echte case in het nieuwe systeem opent en nog steeds begrijpt wie de klant is, wat er is gebeurd, wie de volgende stap bezit en welk bericht niet opnieuw mag worden verstuurd.

Veel migratieplannen beginnen met velden en aantallen. Die controles bewijzen niet dat de operatie de verhuizing heeft overleefd. Een status of tag kan met een andere betekenis aankomen. Alle berichten kunnen aanwezig zijn terwijl de relatie met klant, bestelling, toestemming of eigenaar ontbreekt.

Bepaal wat waar moet blijven

Schrijf vóór de veldmapping een korte set voorwaarden op die na de overgang nog moeten kloppen.

  • Elk gesprek hoort bij de juiste klant en kanaalidentiteit.
  • Berichten, interne notities, bijlagen en tijdstippen blijven in de juiste volgorde.
  • Open werk heeft één actuele eigenaar, status, deadline en volgende actie.
  • Toestemming, afmelding en bronbewijs blijven iets anders dan gewone tags.
  • Rapporten onderscheiden gemigreerde historie van werk dat na livegang ontstond.

Dit is het acceptatiecontract. De actuele exporthandleiding van Zendesk laat zien waarom het formaat ertoe doet. CSV bevat geen reacties of beschrijvingen, terwijl JSON en XML een andere dekking en limieten hebben. Een geldig bestand kan dus de verkeerde bron zijn.

Breng betekenis vóór velden in kaart

Begin niet met een tabel waarin een bronstatus simpelweg aan een doelstatus wordt gekoppeld. Vraag eerst welk gedrag elke waarde in de oude operatie veroorzaakte.

Als wachten op de klant en wachten op een leverancier beide uitgesteld worden, verdwijnt het verschil tussen een klantbelofte en een externe afhankelijkheid. Herinneringen en rapportages veranderen zonder importfout.

Maak een betekeniskaart voor identiteiten, statussen, prioriteiten, tags, toewijzingen, relaties en tijdstippen. Leg de oude definitie, de nieuwe definitie, het gewenste gedrag en het bewijs van een goede mapping vast. Bewaar oude ID's in een apart extern veld, zodat een geïmporteerd record naar de bron te herleiden blijft.

Een modern gesprek bestaat uit meer dan berichttekst. De conversation API van Intercom beschrijft contacten, status, prioriteit, eigenaren, tags, aangepaste kenmerken, gespreksonderdelen en gekoppelde objecten. De documentatie noemt ook een limiet van 500 onderdelen bij het ophalen van een gesprek. Volledigheid moet daarom expliciet worden getest. Een geslaagd API-antwoord bevat niet vanzelf de hele geschiedenis.

Scheid levend werk van historie

Gesloten historie en actief klantwerk hebben een ander plan nodig. Historische records kunnen worden gekopieerd, gecontroleerd en alleen-lezen gemaakt. Een open gesprek ontvangt tijdens de migratie nog antwoorden, wisselt van eigenaar en beweegt richting een deadline.

De huidige migratiedocumentatie van Pylon maakt dit verschil concreet. De traditionele API-route migreert gesloten tickets als historische momentopnamen, maar geen open tickets, omdat het onderliggende communicatiekanaal niet met het record meegaat. Andere platforms kunnen een andere methode bieden, maar de operationele vraag blijft hetzelfde. Waar komt het volgende klantantwoord tijdens de overgang binnen?

Kies één systeem dat nieuwe activiteit mag verwerken. Laat open cases in het oude systeem tot ze sluiten, verhuis ze via een gecontroleerde procedure of schakel kanaallevering op één vast moment om en verzoen de overlap. Laat nooit beide systemen zelfstandig versturen. Dan ontstaan dubbele antwoorden, verdeeld eigenaarschap en twee tegenstrijdige tijdlijnen.

Bouw een moeilijke bewijsset

Een pilot met alleen nette records bewijst weinig. Neem een lang gesprek met bijlagen en interne notities, één klant met meerdere kanaalidentiteiten, een open case met deadline en eigenaar, een heropende of overgedragen case, een record met toestemmings- of afmeldbewijs en een case die aan een bestelling, bedrijf of lead is gekoppeld.

Controleer relaties afzonderlijk. De huidige ticket API van HubSpot behandelt relaties met contacten, bedrijven en activiteiten als expliciete onderdelen van een ticketrecord. Als de tekst meegaat maar die koppelingen verdwijnen, blijft de inhoud bestaan en gaat de werkcontext verloren.

Vergelijk elk bewijsrecord naast elkaar in bron en doel. Controleer aantal en volgorde van berichten, auteurschap, tijdzones, toegang tot bijlagen, identiteit, status, eigenaar, relaties en volgende actie. Laat daarna een medewerker de volgende echte taak in het nieuwe platform uitvoeren. Visuele gelijkenis is niet genoeg. Het record moet bruikbaar blijven.

Schakel in lagen over

Bevries tijdens het testen de definities van tags en statussen, aangepaste velden en routeringsregels, niet de klantenservice. Maak een volledige beveiligde export. Test de bewijsset. Importeer historie. Vergelijk aantallen per object en periode. Verplaats of rond het actieve werk af. Schakel kanaallevering één keer om.

Let in het eerste operationele venster op mislukte imports, cases zonder eigenaar, dubbele identiteiten, onverwachte meldingen en ontbrekende bijlagen. Bepaal vooraf wanneer je terugdraait. Ontbrekend actief werk, een verbroken klantkoppeling, verkeerde toestemming of een dubbel bericht is onacceptabel.

Bewaar alleen wat te verantwoorden is

Migratie is ook een bewaarkeuze. Elk oud record kopiëren omdat het bestaat, neemt verouderde persoonsgegevens en kapotte classificaties mee. De Britse Information Commissioner's Office richtlijn over opslagbeperking stelt dat persoonsgegevens niet langer dan nodig mogen worden bewaard en dat bewaartermijnen te rechtvaardigen moeten zijn.

Bepaal wat operationeel moet blijven, wat in een beperkt archief hoort en wat volgens het geldende beleid weg kan. Neem verwijderverplichtingen en juridische bewaarplichten mee. Maak van het nieuwe platform geen permanente kopie van iedere oude fout.

Maak het nieuwe record werkbaar

Een gedeelde inbox houdt historie, toewijzing, notities en status rond hetzelfde werk. Een gekoppeld klantrecord houdt velden, tags, toestemming en eigenaarschap bruikbaar.

Neem bij de evaluatie van DripTell of een ander doelplatform de bewijsset mee. Vraag de leverancier de geïmporteerde records te tonen en de volgende actie uit te voeren. Een overtuigende migratiedemo is geen voortgangsbalk. Het is een medewerker die een echt gesprek voortzet zonder de klant het verleden opnieuw te laten vertellen.

Veelgestelde vragen

Welke gegevens uit klantgesprekken moeten worden gemigreerd

Migreer inhoud en relaties die nodig zijn om service voort te zetten, bewaarplichten na te komen, eerdere besluiten uit te leggen en juist te rapporteren. Archiveer of verwijder de rest volgens vastgelegd beleid.

Hoe ga je om met open gesprekken tijdens de migratie

Geef nieuwe activiteit één gezaghebbend systeem. Laat open cases in het oude systeem tot sluiting, verhuis ze gecontroleerd of schakel levering op een vast moment om en verzoen de overlap.

Hoe controleer je dat er geen context verloren is gegaan

Vergelijk met een moeilijke bewijsset identiteit, chronologie, auteurschap, bijlagen, status, eigenaar, relaties, deadlines en de volgende actie. Voer daarna een echte taak in het nieuwe platform uit.

Moeten oude tags exact worden gekopieerd

Niet automatisch. Bewaar een tag pas nadat is vastgelegd wat hij betekent, wie hem toepast, welke regel hem gebruikt en hoe het doelplatform dat gedrag reproduceert.

DT

DripTell Editorial

Praktische uitleg, gecontroleerd door het product- en klantworkflowteam van DripTell.

Lees hoe DripTell productclaims controleert, primaire bronnen gebruikt en correcties verwerkt.

Redactioneel en bronnenbeleid