Twee systemen met een ander idee van een klant
HubSpot denkt in bedrijven, contacten en deals, gevormd rond werk binnenhalen. Exact denkt in relaties en rekeningen, gevormd rond het factureren ervan. Allebei hebben ze gelijk over hun eigen helft, en geen van beide heeft een begrip dat netjes op het andere past. Elke integratie tussen die twee is in wezen een discussie over identiteit, en hoe vroeger die discussie expliciet beslecht wordt, hoe minder je er later met de hand oplost.
Kies één sleutel, en laat het de enige sleutel zijn
Matchen op bedrijfsnaam voelt logisch en faalt meteen, want dezelfde organisatie staat op vier manieren geschreven over twee systemen en geen van beide is fout. Gebruik het btw- of ondernemingsnummer: het is uniek, allebei de systemen kunnen het bijhouden, en het is dezelfde identificatie die de klant over zichzelf gebruikt. Sla na een match het id van het tegenoverliggende record aan beide kanten op, en match vanaf dan op dat id. De naam wordt iets dat je toont, nooit iets waarop je koppelt.
Eigenaarschap per veld, niet per record
De reflex is beslissen welk systeem de master is. De bruikbare versie is fijner dan dat: beslis per veld. Lifecycle-fase, eigenaar en pipeline horen bij HubSpot en mogen nooit van buitenaf geschreven worden. Factuurstatus, betalingstermijn en openstaand saldo horen bij Exact en mogen nooit in HubSpot aangepast worden. Adres en btw-nummer hebben één aangeduide eigenaar nodig, en welke dat is doet er minder toe dan dat het opgeschreven staat. Een veld met twee eigenaars is een veld dat op een schema dat niemand zich herinnert te hebben ingesteld tussen twee waarden heen en weer gaat klapperen.
Eén richting waar één richting volstaat
Tweerichtingssynchronisatie is de standaardvraag en zelden het juiste antwoord. Financiële gegevens die van Exact naar HubSpot stromen zodat sales de betaalstatus ziet, is één richting en lost het grootste deel van de echte behoefte op. Er tweerichting van maken zodat iemand een factuur kan aanpassen vanuit een CRM-kaart, voegt conflictafhandeling toe, een auditprobleem, en een nieuwe manier waarop het grootboek fout kan staan. Bouw de richting die gevraagd is, niet de symmetrische versie die vollediger klinkt.
Ontwerp voor gedeeltelijk falen, want je krijgt het
De integratie zal halverwege een batch zitten wanneer een token vervalt, een rate limit aanslaat, of Exact een validatiefout teruggeeft op één record op vijftig. Elke schrijfactie moet veilig herhaalbaar zijn, wat betekent dat je op het tegenoverliggende id keyt in plaats van bij elke run aan te maken, en elke mislukking moet genoeg achterlaten om vanaf te hervatten. Een sync die alleen vanaf het begin kan draaien, is een sync die niet meer gedraaid wordt.
Wat je niet synchroniseert
De verleiding is alles te spiegelen op grond van dat het ooit van pas kan komen. Doe het niet: elk gesynchroniseerd veld is een veld dat nu op twee plaatsen fout kan staan, en de meeste worden nooit gelezen. Synchroniseer wat iemand hardop gezegd heeft nodig te hebben. Individuele factuurlijnen vallen daar bijna nooit onder; een openstaand saldo en een betaalstatus meestal wel.
Wat het oplevert
Een verkoper die op de bedrijfsfiche ziet dat deze klant een factuur van negentig dagen open heeft staan, vóór hij een upsell voorstelt. Een boekhouding die daar niet langer via chat om gevraagd wordt. En één plek waar de vraag of een klant het najagen waard is, beide helften van het antwoord bevat. Dat is de hele opbrengst, en het is genoeg.