We hebben een supportticket naar een AI gestuurd. Die heeft de integratie opnieuw opgebouwd en het proces afgerond.

Hoe Claude Code en APIANT een rommelige bug in de synchronisatie van meerdere betalingen hebben omgezet in een geverifieerde oplossing, waarbij pas aan het einde een mens zijn goedkeuring gaf.

Deze komt van CRMConnectAPIANT's kant-en-klare integratie zorgt ervoor dat Mindbody en HubSpot gesynchroniseerd blijven. Het beheert de klantgegevens, verwijdert duplicaten en koppelt velden correct, zodat een marketingteam kan werken met daadwerkelijke activiteiten in plaats van verouderde exports. Het specifieke onderdeel waar we het hier over hebben, is het gedeelte dat Mindbody-verkopen omzet in HubSpot-deals, zodat de omzet automatisch in het CRM terechtkomt, met het juiste bedrag gekoppeld aan de juiste klant.

Een klant betaalde ongeveer $8.400 aan de balie. In het CRM-systeem stond echter $400. Er was niets misgegaan, niets leek defect en de meeste verkopen werden correct gesynchroniseerd. Deze transactie verloor stilletjes het grootste deel van zijn waarde ergens tussen Mindbody en HubSpot.

Dat zijn de ergste bugs: de bugs die verstopt zitten in die 2% van de transacties die een beetje afwijkend zijn. We hebben deze bug aan een AI overgelaten en die het hele proces laten afhandelen, van diagnose tot een geteste oplossing en het antwoord aan de klant. Zo is het gegaan.

Het ticket

Een kleine fitnessstudio schreef ons met een klein, vervelend raadsel. De meeste verkopen van Mindbody naar HubSpot verliepen probleemloos. Deze ene deal niet.

De boosdoener bleek te liggen bij verkopen die op meerdere manieren waren betaald. Een betaling werd opgesplitst over een kaart en een rekeningsaldo, en de oude synchronisatie las een rapport uit dat niet alle betaalmethoden bevatte. Daardoor werd de transactie verwerkt voor een fractie van wat de klant daadwerkelijk had betaald.

Waarom dit normaal gesproken een langzame, pijnlijke oplossing is

Een bug als deze kost normaal gesproken dagen aan ontwikkeltijd. Iemand moet de integratie reconstrueren, uitzoeken welk van de verschillende synchronisatiepaden de fout veroorzaakt, de logica aanpassen zonder de paden die al werken te verstoren, en het vervolgens testen op een live systeem dat echt moeilijk te manipuleren is. Kassasoftware biedt je niet bepaald een testomgeving met een knop om een vreemde gesplitste betaling uit te voeren.

Het blijft dus vaak zo. De klant wacht. De oplossing is riskant. Iedereen is een beetje nerveus om aan een werkende integratie te sleutelen.

We hebben het in plaats daarvan aan de AI gegeven.

We gaven de opdracht aan Claude Code, die op APIANT draaide, en lieten hem zijn werk doen. Niet zomaar een codefragment voorstellen. Maar echt aan de slag: de integratie lezen, begrijpen, aanpassen, testen met het echte Mindbody-account en feedback geven. Dit is wat het deed, zonder dat er ook maar één regel code aan te pas kwam.

Het heeft de werkelijke oorzaak gevonden. Het probleem bleek te liggen in drie afzonderlijke oorzaken die schuilgingen achter één symptoom: de synchronisatie las gegevens uit een rapport waarin sommige betaalmethoden ontbraken, verkopen van meerdere artikelen werden onjuist geteld en meerdere verkopen konden met dezelfde identificatiecode botsen.

De integratie is correct hersteld. In plaats van een snelle noodoplossing werd de deallogica geherstructureerd tot één gedeelde component die zowel door de directe synchronisatie (die wordt geactiveerd zodra een verkoop plaatsvindt) als door de nachtelijke synchronisatie wordt gebruikt. Dezelfde logica, twee triggers, geen verschil meer tussen beide. Beide zijn overgezet naar een rijkere gegevensbron die daadwerkelijk elke betaling bevat, inclusief rekening- en lidmaatschapssaldi.

Het maakte het proces op grote schaal snel. Er is een cache toegevoegd, zodat de nachtelijke taak niet steeds dezelfde trage zoekopdrachten hoeft uit te voeren over duizenden eerdere verkopen. De eerste keer dat de taak wordt uitgevoerd, wordt de cache gevuld; bij elke volgende uitvoering wordt de kostbare zoekopdracht overgeslagen.

Het voegde het detail toe waar de klant om vroeg. Bij elke transactie wordt nu de gebruikte betaalmethode geregistreerd, zodat de studio in één oogopslag kan zien hoe een verkoop is betaald.

Vervolgens werd het getest op het echte systeem.

Dit is het gedeelte dat nog een beetje sciencefictionachtig aanvoelt.

De AI opende het daadwerkelijke Mindbody-kassasysteem in een browser en voerde zelf testverkopen uit. Eén artikel werd in één keer betaald. Eén artikel werd over twee betalingen verdeeld. Meerdere artikelen werden in één keer betaald. Meerdere artikelen werden over meerdere betalingen verdeeld. Een klant die zonder reservering binnenliep, werd ook geregistreerd. De AI doorliep het kassasysteem alsof het een medewerker was.

Vervolgens controleerde het systeem elke verkoopstroom door de integratie en las de resultaten regel voor regel. Werd het juiste aantal deals aangemaakt? Klopten de bedragen voor het totale verkoopbedrag? Werd de betaalmethode weergegeven? Leverde het twee keer synchroniseren duplicaten op, of herkende het systeem correct dat de verkoop al was verwerkt?

Alle transacties waren correct. De bedragen kwamen overeen. Geen dubbele transacties. De betaalmethoden zijn correct verwerkt.

Het ontdekte zijn eigen fout.

Halverwege introduceerde een van de eigen wijzigingen een kleine terugval. Een nieuw veld was niet correct geconfigureerd, waardoor het aanmaken van nieuwe deals stilletjes werd verstoord.

De AI merkte het op, omdat ze de live uitvoeringsgegevens las in plaats van aan te nemen dat haar werk correct was. Ze vond de exacte oorzaak, herstelde de bedrading, voerde de daadwerkelijke mislukte verkoop opnieuw uit en bevestigde dat de oplossing het juiste resultaat opleverde, waarbij ze het hele proces documenteerde.

Dat is het verschil tussen code genereren en eigenaar zijn van een resultaat.

Daarmee was de cirkel rond met de klant.

Nadat de oplossing was geverifieerd, schreef de AI een antwoord aan de klant in begrijpelijke taal: wat er aan de hand was, waarom het bedrag onjuist leek, welke wijzigingen er nu zijn en de geruststelling dat eerdere verkopen automatisch zouden worden gecorrigeerd bij de volgende synchronisatie. Het bericht werd klaargezet voor gebruik in het ticket.

Een mens heeft het gelezen, goedgekeurd en verzonden. Een mens heeft ook de definitieve goedkeuring gegeven om de wijziging in productie te nemen. Dat is de bedoeling. De AI doet het zware, precieze en tijdrovende werk. Mensen houden de controle over de twee beslissingen die altijd door een mens genomen moeten worden: wat we tegen een klant zeggen en wat er live gaat.

Eén oplossing, voor elke klant.

Dit is het belangrijkste als je je brood verdient met het bouwen van integraties. Dit was geen eenmalig script dat aan één account werd toegevoegd. De Mindbody-HubSpot-synchronisatie is een volwaardig product. API-app: één integratie, gebouwd en onderhouden op één centrale plek, die voor elke klant die er gebruik van maakt, werkt. Dus toen de AI de deallogica opnieuw opbouwde, loste het niet alleen het probleem voor deze ene studio op. Het dichtte dezelfde kloof in gesplitste betalingen voor iedereen die van die integratie gebruikmaakt, en elke nieuwe klant erft de gecorrigeerde versie vanaf dag één.

Dat is het model waar systeemintegrators steeds om vragen. Ontwikkel een oplossing één keer, verkoop hem vele malen en verbeter hem op één centrale plek. Zo'n oplossing verhoogt de kwaliteit van het product voor de gehele gebruikersbasis in één keer, en dat is precies wat een gestandaardiseerde integratie verandert in een echte bron van terugkerende inkomsten in plaats van een stapel maatwerk per klant die alleen maar kwetsbaarder wordt naarmate de klantbasis groeit.

Waarom APIANT dit mogelijk maakt

Een AI kan alleen functioneren op basis van wat het kan zien en aanraken. De meeste integratieplatformen zijn een black box, waardoor de AI gedwongen is suggesties van buitenaf te ontvangen.

APIANT is juist andersom opgebouwd. Elke integratie bestaat uit onderdelen die de AI daadwerkelijk kan inspecteren, bewerken en uitvoeren: de automatiseringen, de gedeelde subroutines, de veldtoewijzingen, de live uitvoeringsgeschiedenis en de gecachede waarden. De AI kan een onderdeel wijzigen, uitvoeren, precies lezen wat er bij elke stap is gebeurd en bijsturen. In combinatie met browserbesturing van het bronsysteem kan de AI testen aan de hand van de werkelijkheid in plaats van te gokken.

Die combinatie zorgde ervoor dat een rommelig, praktisch ticket werd omgezet in een volledige, geverifieerde refactoring.

De conclusie

Dit was geen kleinigheid. Het was een subtiele bug met meerdere oorzaken in een live integratie tussen twee serieuze systemen, het soort bug dat normaal gesproken een nerveuze engineer en een trage week betekent.

Een AI heeft het hele proces van begin tot eind afgehandeld. Het systeem diagnosticeerde de werkelijke oorzaak, herbouwde de integratie op de juiste manier, testte elk traject aan de hand van het daadwerkelijke verkooppunt, spoorde zijn eigen fouten op en corrigeerde deze, en stelde het klantantwoord op. Mensen hoefden alleen nog maar het bericht en de implementatie goed te keuren.

Dat is waar het naartoe gaat. Niet AI die een stukje code voor je schrijft, maar AI die een complex, specifiek probleem aanpakt en het helemaal tot een werkende, geteste oplossing brengt op een platform dat daar precies voor is gebouwd. Als je integraties hebt die bijna goed zijn, of bugs die slechts in die zeldzame 2% van de gevallen opduiken, dan begint dit eruit te zien als de manier waarop je ze kunt oplossen.

Neem contact met ons op over APIANT