Je website koppelen aan de tools die je al gebruikt: een gids over koppelingen in gewone taal

Elk bedrijf draait op meerdere systemen: een website, een CRM, boekhouding, e-mail, een agenda, misschien een webshop, een boekingstool of een voorraadsysteem. Een koppeling is simpelweg de afspraak waardoor gegevens automatisch tussen twee daarvan bewegen, zodat niemand ze hoeft over te typen. Het technische middel is meestal een API, de interface die elk systeem biedt zodat andere software zijn gegevens kan lezen en schrijven.

Dat is het hele idee. Het interessante deel is kiezen welke koppelingen je bouwt, en hoe.

De koppelingen die de meeste bedrijven het eerst nodig hebben

• Websiteaanvraag naar CRM. Een ingevuld formulier maakt een lead aan met de juiste bron en eigenaar, in plaats van een e-mail die iemand moet overtypen.
• Bestellingen naar boekhouding. Online bestellingen worden automatisch facturen of verkoopregels, met gekoppelde betalingen.
• Boekingen naar agenda en herinneringen. Een boeking op de site verschijnt in de agenda van het team en zet een bevestiging per e-mail of WhatsApp in gang.
• Betalingen. Een betaalprovider die is gekoppeld, zodat de site weet wat er is betaald en de boekhouding ook.
• Voorraad en prijzen. Beschikbaarheid en prijzen op de site volgen het voorraadsysteem, niet een wekelijkse handmatige update.
• Nieuwsbrief en marketinglijsten. Inschrijvingen en klanten stromen naar de mailtool, met de toestemming vastgelegd.

Elk ervan verwijdert een handmatige stap die vele malen per dag wordt gedaan, en daar zit de waarde.

Automatiseringsplatform of maatwerkcode?

Platformen zoals Zapier, Make en n8n laten je gangbare tools koppelen zonder te programmeren: als dit gebeurt in systeem A, doe dat in systeem B. Ze zijn de juiste keuze als:

• beide systemen populair zijn en goed worden ondersteund op het platform,
• de logica eenvoudig is ("nieuwe formulierinzending, maak contact aan"),
• het volume bescheiden is, en
• je bereid bent een maandbedrag per workflow te betalen.

Maatwerkcode is de betere keuze als:

• een van de systemen ongewoon is, intern is gebouwd of een slechte connector heeft,
• de logica regels bevat ("alleen als de bestelling boven dit bedrag is en de klant nieuw is, dan..."),
• het volume hoog genoeg is dat prijzen per taak duur worden,
• de koppeling betrouwbaar moet zijn bij storingen, met herhaalpogingen en meldingen, of
• gegevens om privacy- of contractuele redenen niet via een platform van derden mogen lopen.

Veel bedrijven gebruiken beide: een platform voor de eenvoudige koppelingen, maatwerkcode voor de een of twee die er het meest toe doen.

Wat je beslist voordat er iets wordt gekoppeld

1. Welk systeem is de bron van de waarheid voor elk soort gegeven? Als het adres van een klant verandert, waar wordt het dan gewijzigd, en welke kant stroomt het op? Tweerichtingssynchronisatie is veel lastiger dan eenrichting; vermijd die tenzij je hem echt nodig hebt.
2. Wat gebeurt er als het misgaat? Systemen vallen uit en API's veranderen. Een goede koppeling probeert opnieuw, logt wat ze deed en waarschuwt iemand als ze het opgeeft. Bepaal wie die iemand is.
3. Welke gegevens gaan over welke grens? Klantgegevens die naar een nieuwe leverancier gaan, mogelijk in een ander land, zijn een privacyvraag. Controleer wat je privacyverklaring zegt en of de voorwaarden van de leverancier passen.
4. Wie beheert de sleutels? API-sleutels horen van het bedrijf te zijn, veilig opgeslagen en intrekbaar als een leverancier of ontwikkelaar wisselt. Ze horen nooit in een spreadsheet.
5. Wat zijn de limieten? De meeste API's begrenzen hoeveel verzoeken je mag doen. Een nachtelijke synchronisatie van tienduizend producten is een ander ontwerp dan een realtime-update van één.

Begin met één

De beste eerste koppeling is die welke de meest vervelende dagelijkse taak wegneemt, duidelijke regels heeft en twee systemen met fatsoenlijke API's betreft. Bouw die, laat hem een paar weken draaien, en je begrijpt je eigen gegevensstromen veel beter voordat je de volgende aanpakt. Alles tegelijk willen koppelen is hoe koppelingsprojecten vastlopen.

Onderhoud hoort erbij

API's krijgen nieuwe versies, sleutels verlopen, een leverancier wordt overgenomen en hernoemt dingen. Een koppeling heeft iemand nodig die de logboeken in de gaten houdt en hem af en toe bijwerkt. Neem dat vanaf het begin op in de afspraak, of het nu jijzelf bent, je ontwikkelaar of de support van een platform.

Kun je de twee tools noemen en zeggen wat ertussen moet stromen, dan kunnen we in een kort gesprek meestal de eenvoudigste betrouwbare manier schetsen om ze te koppelen. Dat is een goed beginpunt.