Een fictief CRM-voorbeeld laat zien waarom relaties stabiele bronreferenties nodig hebben. Bekijk matchregels, gedeelde e-mailadressen en menselijke beoordeling.
De gesproken uitleg, per hoofdstuk.
Deze uitleg hoort bij ons artikel over CRM-integratie. Voordat systemen contacten uitwisselen, moet vaststaan welke records dezelfde persoon of organisatie vertegenwoordigen en welke gegevens ieder systeem beheert.
Twee fictieve contactpersonen gebruiken één algemeen e-mailadres. Een koppeling die alleen daarop vergelijkt, zou hun records kunnen samenvoegen. Later verandert één contactpersoon bovendien van adres.
Elk bronsysteem houdt zijn eigen vaste identificatie. Een expliciete relatietabel verbindt die referenties met het juiste doelrecord. De identiteit verandert niet alleen doordat een contactnaam of adres wijzigt.
Leg vast wanneer een relatie bestaat, welke combinatie controle vraagt en wie een nieuwe koppeling mag bevestigen. Geen match of meerdere mogelijkheden betekent niet automatisch een nieuwe klant aanmaken.
Het CRM kan de accountmanager beheren, terwijl de administratie factuurgegevens beheert. Een overdracht wijzigt alleen toegestane velden. Een teruggestuurd record mag geen voortdurende lus van wijzigingen veroorzaken.
Bij ons gedeelde e-mailadres bekijkt een medewerker de bronreferenties en relatiegegevens. Pas na beoordeling wordt een koppeling vastgelegd. De oorspronkelijke historie wordt niet op basis van gelijkenis samengevoegd.
Test gewijzigde e-mailadressen, samengevoegde contacten, gelijktijdige berichten en archivering. Vergelijk aangemaakte, gewijzigde en afgewezen records met de bron, zodat onvolledige synchronisatie niet onopgemerkt blijft.
Maak zichtbaar welk record is geweigerd en waarom. Een beheerder moet een fout kunnen corrigeren en gericht opnieuw verwerken, zonder de hele synchronisatie of een tweede relatie te starten.
CRM-integratie begint bij identiteit en verantwoordelijkheid, niet bij een zoekopdracht op naam. Het bronartikel werkt herkenning, veldafspraken, foutafhandeling en gecontroleerde synchronisatie verder uit.
1:46Een fictieve CRM-aanvraag toont hoe een API-koppeling omgaat met dubbele berichten, ongeldige velden en een time-out waarvan de uitkomst nog onbekend is.
BronartikelAPI-koppeling laten maken tussen je bedrijfssystemen
1:53Volg klantgegevens, werkstatus en factuurgegevens door drie fictieve systemen. Zie waarom een softwarekoppeling per veld een bron en richting nodig heeft.
BronartikelSoftware koppelingen voor je bedrijfssystemen
1:43Leer met een fictieve salesaanvraag hoe een AI-agent feiten, onbekende gegevens en voorstellen scheidt, terwijl een verkoper de commerciële beslissing houdt.
BronartikelAI Sales Agent