Koppelingen ontwerpen · ASRR Tech
CRM koppelen aan website, Outlook of boekhouding: een betrouwbaar ontwerp
Begin een koppeling bij bronverantwoordelijkheid, identificatie en herstel bij fouten. Gebruik deze gegevensmatrix en acceptatietests om te bepalen wat een website-, agenda- of boekhoudkoppeling werkelijk moet uitwisselen.
Bijgewerkt · 4 min leestijd · ASRR Tech
“Er is een koppeling” is geen volledige scope
Een productlogo op een integratiepagina zegt niet welke gegevens uitgewisseld worden. Vraag naar richting, velden, timing, ondersteunde accounts, rechten en foutafhandeling. Klanten ophalen uit een boekhoudpakket is iets anders dan facturen schrijven of betalingen teruglezen.
Maak eerst duidelijk welke taak de koppeling ondersteunt. Voor een websiteaanvraag is dat een behandelbaar dossier; voor een agenda boekbare beschikbaarheid en een juiste afspraak; voor boekhouding een specifieke, afgesproken gegevensstroom.
Deze gids beschrijft ontwerpvragen. Ondersteuning van een concrete Alpha-koppeling en inrichting moet per scenario worden bevestigd.
Wijs per gegeven een bron aan
| Gegeven | Mogelijke bron | Doel | Besluit dat nodig is |
|---|---|---|---|
| Oorspronkelijke aanvraag | Websiteformulier | CRM | Originele tekst bewaren of omzetten? |
| Dossiereigenaar | CRM | Werkvoorraad | Mag een ander systeem dit wijzigen? |
| Bezet tijdstip | Agenda | Boekingsroute | Welke agenda's en soorten afspraken tellen mee? |
| Offertegegevens | Afgesproken verkoopsysteem | Ander systeem | Welke versie en status? |
| Factuurnummer/betaling | Boekhoudomgeving | CRM-weergave | Alleen lezen of ook schrijven? |
Dit is een voorbeeldmatrix, geen beschrijving van standaard productgedrag. Voorkom dat twee systemen hetzelfde gegeven ongecontroleerd terugschrijven. Spreek bij een conflict af welke bron leidend is en wie een uitzondering beoordeelt.
Gebruik stabiele referenties
Naam of e-mailadres alleen is onvoldoende als technische sleutel. Een naam kan veranderen en één e-mailadres kan meerdere contexten hebben. Bewaar de bronreferentie naast het doelrecord en leg verbanden expliciet vast.
Geef een technische inzending een herkenbare identificatie. Wordt dezelfde inzending na een storing opnieuw aangeboden, dan moet de uitkomst herkenbaar dezelfde verwerking zijn. Een tweede poging mag niet automatisch een tweede lead, afspraak of factuur veroorzaken.
Scheid dat van een nieuwe zakelijke vraag: dezelfde persoon kan terecht een nieuwe aanvraag doen. Herhaling van een technische gebeurtenis en herhaling van klantinteresse zijn verschillende problemen.
Ontwerp de storingsroute tegelijk met de normale route
Vraag wat er gebeurt bij time-out, verlopen toegang, ongeldig veld, verwijderde bron en tijdelijke uitval. Bepaal welke fouten opnieuw geprobeerd worden en welke menselijke beoordeling vragen.
Microsoft Graph beschrijft eisen aan tijdige webhookantwoorden en het onderhouden van notificatieabonnementen. Eenmalig succesvol verbinden bewijst dus geen blijvende synchronisatie.
Bewaar een zichtbaar verwerkingsresultaat en een eigenaar voor fouten. “Laatste synchronisatie geslaagd” is te algemeen als één record ertussen mislukt is. Een medewerker moet kunnen vaststellen welke aanvraag nog behandeling nodig heeft.
Outlook-beschikbaarheid en afspraak zijn aparte stromen
Graph getSchedule levert beschikbaarheidsinformatie. Een afspraak aanmaken, wijzigen, annuleren en een online vergadering bruikbaar maken zijn aanvullende onderdelen die je afzonderlijk moet testen.
Leg vast welke account organisator is, welke agenda beschikbaarheid bepaalt en waar wijzigingen ontstaan. Een afspraak kan in CRM bestaan terwijl een externe uitnodiging ontbreekt. Controleer daarom beide kanten met een testgebruiker en externe deelnemer.
Een fictieve websitefout doorlopen
Stel dat een formulier succesvol is opgeslagen, maar het antwoord naar de browser wegvalt. De bezoeker probeert opnieuw. Zonder herkenbare inzending kan de intake twee dossiers krijgen.
Een robuuste route herkent de herhaling, houdt één aanvraag aan en maakt de bevestigingsstatus duidelijk. Als de CRM-verwerking nog wacht, moet intern zichtbaar zijn wie dat bewaakt. Verberg het verschil tussen ontvangen en afgehandeld niet achter dezelfde succesmelding.
Acceptatiematrix voor je leverancier
- Een nieuwe aanvraag komt met oorspronkelijke vraag en bronreferentie aan.
- Dezelfde technische gebeurtenis opnieuw verwerken veroorzaakt geen dubbele uitkomst.
- Een ontbrekend verplicht doelveld verschijnt als behandelbare fout.
- Een wijziging gaat alleen in de afgesproken richting.
- Een tijdelijk probleem kan gecontroleerd worden hersteld.
- Annulering of verwijdering volgt een expliciet afgesproken regel.
- Alleen de juiste organisatie en gebruiker kunnen het resultaat zien.
Test met representatieve gegevens in een afgesproken omgeving. Leg de uitkomst per scenario vast en vraag welk beheer na oplevering nodig is. Lees daarna over afspraken testen en automatisering kiezen.
Bronnen en verantwoording
Bronnen geraadpleegd op 12 oktober 2026. Verwijzingen in de tekst onderbouwen de genoemde feiten. Stappenplannen, matrices en fictieve voorbeelden zijn door ASRR voor deze uitleg samengesteld. Voorbeeldbedragen en resultaten zijn geen klantresultaten, tarieven of benchmarks. Productdocumentatie van andere leveranciers bewijst geen beschikbaarheid in Alpha.