Bij ForaVida is de Connect-basis gerealiseerd die WooCommerce, AFAS en routeplanning als één traceerbare orderstroom laat samenwerken. Een bestelling wordt niet alleen van systeem A naar systeem B gekopieerd. De gegevens worden gecontroleerd, vertaald en verdeeld naar de toepassingen die ze voor administratie en uitvoering nodig hebben.
Dat onderscheid is belangrijk bij configureerbare producten en verschillende levermethoden. Na de checkout volgen nog veel operationele beslissingen: is de order compleet, welke artikelen en aantallen horen erbij, hoe wordt geleverd, welke datum geldt en wat gebeurt er wanneer informatie ontbreekt? De waarde van de integratie zit daarom net zo goed in foutafhandeling als in de normale route.
Deze uitwerking beschrijft de gerealiseerde Connect-basis. Yindle Desk is bij ForaVida in gebruik voor klantvragen en de afhandeling van orders.
De order begint in WooCommerce
De klant stelt een product samen, rondt de bestelling af en kiest een passende levervorm. WooCommerce is daarmee het startpunt van de commerciële transactie. Maar een webshoporder is nog niet automatisch bruikbaar voor alle vervolgsystemen.
Een administratie kan andere veldnamen, referenties of verplichte waarden verwachten. Een routeplanning heeft vooral aflevergegevens, datum en uitvoeringskenmerken nodig. Pakketvervoer en afhalen volgen weer een andere route. Wanneer iedere overdracht los wordt gebouwd, ontstaan dubbele regels en onduidelijk eigenaarschap.
Yindle Connect vormt daarom de verbindende laag. De webshop blijft de webshop en AFAS blijft de administratieve bron voor de onderdelen die daar thuishoren. Connect maakt de gebeurtenis voor ieder doel bruikbaar.
Zes stappen van bestelling naar uitvoering
- Ontvangen: een relevante ordergebeurtenis uit WooCommerce start de verwerking.
- Identificeren: de bestelling, klant en orderregels worden als één samenhangende gebeurtenis behandeld.
- Valideren: verplichte gegevens en bekende mappings worden gecontroleerd voordat de overdracht doorgaat.
- Vertalen: velden, statussen en procesregels worden omgezet naar de betekenis die AFAS of de uitvoering verwacht.
- Verdelen: alleen de informatie die een bestemming nodig heeft, gaat naar de juiste leverstroom.
- Vastleggen: iedere stap krijgt een herkenbare status, zodat succes, overslaan en mislukken achteraf te volgen zijn.
De volgorde voorkomt dat een vervolgstap alvast begint terwijl de kern van de order nog niet betrouwbaar is verwerkt. Een logistieke opdracht hoort bijvoorbeeld niet vooruit te lopen op een order die in de administratie is afgewezen.
Niet iedere bestelling volgt dezelfde route
Een belangrijke ontwerpkeuze is dat de levermethode geen los tekstveld blijft. Zij bepaalt welke operationele route van toepassing is. Op hoofdlijnen kan een bestelling bijvoorbeeld naar eigen transport, pakketvervoer of afhalen op afspraak gaan.
| Leverstroom | Benodigde context | Typische uitzondering |
|---|---|---|
| Eigen bezorging | Adres, postcodezone, geplande dag en route | Datum of zone past niet meer |
| Pakketvervoer | Verzendbare artikelen en trackingcontext | Order is administratief verwerkt maar nog niet aangeboden |
| Afhalen | Afhaalmoment, beschikbare orderregels en overdracht | Klant komt op een ander moment of order is niet compleet |
Door die routes expliciet te maken, kan de organisatie per stroom bepalen welke informatie leidend is en welke status voor de klant betekenis heeft. “Verwerkt” in de administratie betekent immers iets anders dan “ingepland” of “door vervoerder ontvangen”.
Traceerbaarheid wordt belangrijk bij de uitzondering
Een integratie is niet betrouwbaar omdat de ideale order één keer goed aankomt. Zij is betrouwbaar wanneer een afwijking zichtbaar blijft en gecontroleerd kan worden hersteld.
Denk aan een artikel dat nog geen geldige mapping heeft, een verplicht adresveld dat ontbreekt of een extern systeem dat tijdelijk niet reageert. De verwerking mag dan niet geruisloos verdwijnen. Ook blind opnieuw proberen is riskant: als de eerste poging misschien wel is gelukt, kan een tweede poging een dubbele order of dubbele vervolgactie veroorzaken.
Een herstelbare stroom heeft daarom vier eigenschappen:
- de oorspronkelijke gebeurtenis en relevante bron blijven herkenbaar;
- een stap krijgt een duidelijke status en foutcontext;
- herhaling kan plaatsvinden zonder een al afgerond resultaat te dupliceren;
- afhankelijke stappen starten alleen wanneer hun voorwaarden zijn vervuld.
Voor medewerkers betekent dit dat zij niet in logs hoeven te raden waar de order is gebleven. Zij kunnen gerichter bepalen of de oorzaak in gegevens, mapping, bereikbaarheid of proceskeuze zit.
Wat gebeurt er bij snel opeenvolgende wijzigingen?
Webshops kunnen rond het aanmaken van een order meerdere gebeurtenissen kort na elkaar afgeven. De order ontstaat, betaling wordt verwerkt en gegevens worden nog bijgewerkt. Wanneer iedere melding als volledig nieuw werk wordt behandeld, ontstaan onnodige aanroepen en een risico dat een oudere toestand een nieuwere overschrijft.
De orderstroom bundelt daarom samenhangende gebeurtenissen en verwerkt voor dezelfde order de meest actuele relevante toestand. Oudere gebeurtenissen verdwijnen niet uit de geschiedenis, maar worden herkenbaar als achterhaald behandeld. Dat combineert efficiëntie met een audittrail.
Van operationele context naar service in Desk
Dezelfde traceerbaarheid kan klantenservice ondersteunen. Een klant vraagt bijvoorbeeld: “Welke bezorgdatum is nu definitief?” Zonder gezamenlijke context moet een medewerker webshop, AFAS en planning naast elkaar leggen. Een servicecase in Yindle Desk kan de vraag koppelen aan de juiste order en alleen de relevante feiten tonen:
- de oorspronkelijk gekozen bezorgdag;
- de actuele planningsstatus en bron;
- de gebruikte levermethode;
- een eventuele afwijking of mislukte overdracht;
- de eerstvolgende actie en verantwoordelijke.
Daarmee verandert Desk niets aan de gerealiseerde Connect-basis. Connect laat de feiten tussen systemen stromen; Desk kan die feiten vertalen naar servicewerk met een eigenaar en terugkoppeling. De volledige, transparant afgebakende uitwerking staat in de ForaVida-use-case.
Vijf lessen voor vergelijkbare e-commerceprocessen
- Ontwerp rond het orderproces. Een lijst API’s vertelt nog niet hoe administratie en uitvoering samenwerken.
- Wijs per gegeven een bron aan. Voorkom dat webshop, ERP en planning tegelijk dezelfde waarheid proberen te beheren.
- Maak leverstromen expliciet. Afhalen, pakket en eigen bezorging vragen andere vervolgacties.
- Test uitzonderingen vroeg. Onbekende artikelen, gewijzigde adressen en tijdelijk onbereikbare systemen zeggen meer dan de perfecte testorder.
- Ontwerp herstel mee. Leg vast wie een fout ziet, welke stap opnieuw mag en hoe dubbel resultaat wordt voorkomen.
Een dergelijke aanpak levert niet automatisch een universeel platform op. Zij maakt wel zichtbaar welke regels generiek zijn en waar de unieke operatie van een organisatie bepalend blijft.
Van losse overdrachten naar één beheersbaar proces
De ForaVida-case laat zien waarom een koppeling meer is dan een technisch transportkanaal. De order moet in iedere fase dezelfde identiteit behouden, terwijl iedere toepassing alleen de context krijgt die zij nodig heeft. Juist bij wijzigingen en fouten bewijst de architectuur haar waarde: de gebeurtenis blijft traceerbaar en vervolgstappen zijn beheersbaar.
Wil je een vergelijkbare orderstroom in kaart brengen? Bespreek je e-commerceproces met Yindle en begin bij één bestelling, alle bestemmingen en de uitzonderingen die nu handwerk veroorzaken.