Inkoopintegratie voor eCommerce: zo bestellen grote zakelijke klanten via hun eigen systeem

Je grootste afnemers bladeren niet door je webshop. Een inkoopmanager bij een bedrijf dat jaarlijks een bedrag van zes cijfers bij je uitgeeft, opent SAP Ariba of Coupa, kiest jouw naam uit de lijst met goedgekeurde leveranciers en komt in je catalogus terecht via een sessie die zijn eigen systeem heeft geopend. Hij vult een winkelwagen en stuurt die terug. Daarna wordt de bestelling een aanvraag in een goedkeuringsproces dat jij nooit te zien krijgt. Kan je webshop in die volgorde niet meedoen, dan vecht je om het deel van hun budget dat een uitzonderingsprocedure overleeft.

Dit heet punchout, en de meeste eCommerce-teams hebben het nog nooit in een projectplan opgenomen. De techniek is bekend en niet bijzonder exotisch. Wat een project opslokt, is zelden het protocol.

Wat er in een punchout-sessie echt gebeurt

Zes stappen. Lees ze op volgorde, want elke stap stelt een eis aan je webshop.

1. De inkoper kiest je uit de lijst met goedgekeurde leveranciers. Dat gebeurt in zijn eigen inkoopplatform. Niemand ontdekt je hier. Je wordt opgehaald uit een lijst waar je eerst op moest zien te komen.

2. Zijn systeem stuurt een setup-verzoek naar jouw endpoint. Daarin staat wie er aanklopt en hoe die zich identificeert: welke organisatie, welke gebruiker, soms welke kostenplaats of welk contract.

3. Jouw endpoint controleert de aanvraag en geeft een sessie terug. Het antwoord is een URL die je webshop opent in een toestand die alleen voor deze inkoper geldt.

4. De inkoper winkelt in je webshop, zonder in te loggen. Hij ziet de catalogus die jij voor deze organisatie hebt vastgesteld, tegen de prijzen die met hen zijn afgesproken, zonder extra inloggegevens.

5. De winkelwagen gaat terug naar zijn systeem, in het protocol dat zij gebruiken, regel voor regel, met de codes die hun systeem nodig heeft om hem te verwerken.

6. Goedkeuring en inkooporder gebeuren aan hun kant. Jouw bestelling komt daarna binnen, al goedgekeurd en gekoppeld aan een budget en een contract.

Kijk wat stap drie en vier van je vragen. Je webshop moet een binnenkomende machine-identiteit herleiden tot één specifieke klantrelatie. Daarna moet hij op verzoek precies de catalogus en de prijzen tonen die bij die klant horen, zonder dat er een mens inlogt. Daarin zit het hele technische vraagstuk.

Eén: de leverancierslijst bepaalt wie in beeld komt

Inkoop bestaat om eigen keuzes van medewerkers te beperken. Heeft een categorie eenmaal goedgekeurde leveranciers, dan moet elke aankoop daarbuiten verantwoord worden. Die verantwoording kost moeite, en de meeste inkopers steken die moeite niet in een leverancier die alleen maar handig is.

Dat heeft een gevolg dat je gewoon hardop moet zeggen: bij grote zakelijke klanten werkt je catalogus in hun systeem als distributiekanaal. Een leverancier met punchout is er op het moment van aankoop. Een leverancier zonder punchout wordt een handmatige uitzondering: offerte per mail, met de hand ingevoerd en beoordeeld door iemand wiens taak het is precies dat soort uitzonderingen terug te dringen.

Waar je kunt ingrijpen, is eerst commercieel en pas daarna technisch. Op de lijst komen betekent leveranciersonboarding, contractvoorwaarden en vaak een registratie in het netwerk van de klant. Het integratiewerk volgt op dat gesprek en gaat er niet aan vooraf. Daarom is punchout op de gok bouwen zelden de juiste volgorde.

Twee: de protocollen, en wat elk ervan kan

Punchout is een werkwijze, geen standaard. Twee formaten dragen het, en de verschillen daartussen bepalen wat je integratie wel en niet kan.

Wie dit vaker heeft gedaan, geeft steeds hetzelfde advies: begin met cXML. Moderne inkoopplatforms ondersteunen het, en het loopt na de punchout-sessie door in de documenten die daarop volgen. Bouw OCI pas als een specifieke klant met SAP erom vraagt. In sommige Europese handelssectoren kom je nog een derde formaat tegen, IDS Connect. Goed om te weten dat het bestaat, maar geen reden om je planning erop af te stemmen.

Binnen cXML zit één onderscheid dat je inschatting verandert. Level 1 dekt de punchout-sessie en het terugsturen van de winkelwagen. Level 2 voegt diepere interactie met de catalogus toe, en of de klant dat ondersteunt, moet je vragen in plaats van aannemen. Stel vóór het inschatten vast welk level en welke documenten een klant echt nodig heeft. Dat haalt de meest voorkomende oorzaak van dubbel werk weg.

Drie: het echte werk zit in wie wat mag zien

Alles hierboven is transport. Wat inkoopintegratie tot een project maakt in plaats van een plug-in, is dat je commercesysteem voor een anonieme binnenkomende sessie een reeks vragen moet beantwoorden die de meeste webshops nooit krijgen.

Welke organisatie is dit, als je alleen een machinecredential hebt en geen login? Welk contract geldt er? Welke SKU’s mag deze organisatie zien? Raamovereenkomsten dekken vaak maar een deel van je assortiment. Welke prijs geldt er, per SKU en per organisatie, mogelijk per staffel en per contractperiode? Welke van hun gebruikers mag wat bestellen, en tot welk bedrag? En welke codes verwacht hun systeem op de teruggestuurde winkelwagen? Het inkoopsysteem van een klant heeft vaak de eigen artikelnummers van die klant nodig, niet de jouwe.

Elk van die vragen gaat over je datamodel. Of je platform legt per bedrijf vast wie wat mag zien en tegen welke prijs, of de punchout-laag moet dat rechtenmodel nabouwen. In dat nabouwen verdwijnt het budget.

De vraag over artikelnummers verdient extra aandacht. Je mist hem makkelijk bij het inschatten en ontdekt hem duur tijdens het testen. Het systeem van een grote klant werkt misschien met een eigen intern materiaalnummer. Kan je catalogus geen klantspecifiek artikelnummer per SKU per organisatie opslaan, dan sluit de teruggestuurde winkelwagen aan hun kant niet aan. De integratie is dan technisch af en commercieel onbruikbaar.

Het knelpunt is je datamodel, niet het protocol

Hier komen oorzaak en gevolg samen. De protocollen zijn gedocumenteerd, stabiel en al door veel leveranciers vóór jou gebouwd. Of een integratie zes weken duurt of twee kwartalen, hangt af van één vraag: legt je commerceplatform bedrijfsaccounts, contractprijzen, klantspecifieke catalogi en klanteigen artikelnummers al vast als volwaardige data?

Ondersteunt een platform B2B-structuren op bedrijfsniveau zelf, dan wordt punchout een vertaallaag over iets wat al bestaat. Doet het dat niet, dan groeit de punchout-laag uit tot een tweede commercesysteem in de schaduw, waarin het rechtenmodel leeft. Elke prijswijziging moet je dan voortaan op twee plekken doorvoeren. Dat tweede scenario wil je al in het ontwerp uitsluiten, want het maakt van eenmalige integratiekosten blijvende operationele kosten.

Dit hangt direct samen met het grotere integratieplaatje. Contractprijzen ontstaan meestal in een ERP en niet in de webshop. Productcodes komen meestal uit een PIM. Onze gidsen over Shopify koppelen aan ERP of PIM en over API-documentatie voor ERP-integratie behandelen de laag daaronder. Daar speelt dezelfde vraag: welk systeem is leidend voor welke data? Punchout dwingt je die vraag hardop te beantwoorden.

Waar punchout vastloopt

Het mechanisme zelf is stabiel. De verrassingen komen voort uit de volgorde van de stappen, en ze zijn allemaal goedkoper om vooraf in te plannen dan om tijdens de acceptatietest te ontdekken.

De tijd tussen winkelwagen en inkooporder. De goedkeuring gebeurt nadat de winkelwagen je webshop heeft verlaten, en dat kan dagen duren. Zijn je prijzen, voorraad of acties in die tijd veranderd, dan klopt de inkooporder die binnenkomt niet met wat de klant heeft goedgekeurd. Bepaal vooraf of een teruggestuurde winkelwagen een prijs een vaste periode vasthoudt. Maak die regel duidelijk aan de klant, zodat je het verschil niet pas ontdekt via een afgewezen order.

Btw en verzendkosten. Veel inkoopsystemen berekenen na het terugsturen van de winkelwagen hun eigen btw en vracht. De totalen in je webshop kunnen dus afwijken van wat het systeem van de klant vastlegt. Spreek vroeg af welke kant leidend is voor welk bedrag. Een verschil van een paar procent op het totaal is genoeg om een order in de beoordeling te laten hangen.

Orderregels die het systeem van de klant weigert. Een teruggestuurde winkelwagen wordt getoetst aan hun catalogusregels, budgetcodes en verwachte artikelnummers. Een regel zonder artikelnummer, met een onbekende eenheid of met een categorie die hun systeem niet accepteert, kan ongemerkt wegvallen. De inkoper ziet een onvolledige aanvraag en meldt dat als jouw probleem.

Verlopen sessies en opnieuw instappen. Punchout-sessies verlopen, en inkopers lopen vaak halverwege weg. Of een verlopen sessie verdergaat, leeg opnieuw begint of een foutmelding geeft, is een ontwerpkeuze. Leeg opnieuw beginnen bij een aanvraag van honderd regels: dat is de versie die inkopers onthouden.

Artikelen buiten de catalogus en configureerbare producten. Inkopers willen geregeld iets wat niet in hun catalogus staat, of een product waarvan de prijs afhangt van gekozen opties. Voor allebei heb je een vaste route nodig. Zonder die route kan zo’n artikel helemaal niet via de integratie besteld worden en wordt het weer een handmatige uitzondering. Precies wat de integratie moest wegnemen.

Klanten met meerdere entiteiten. Eén klant kan vanuit verschillende juridische entiteiten binnenkomen, elk met een eigen contract, valuta, leveringsvoorwaarden en goedkeuringsketen. Zit de entiteit niet in je rechtenmodel, dan merk je dat zodra de tweede entiteit zich meldt.

Geen van deze punten is een protocolprobleem. Het zijn commerciële regels die ergens moeten bestaan, en punchout laat vaak zien dat ze er nooit waren.

Een inkoopintegratie afbakenen

Zes beslissingen, het liefst genomen voordat de ontwikkeling begint.

Welke klant, welk platform, welk protocol. Baken af op basis van een klant met een naam en een concrete eis. Punchout die generiek wordt gebouwd, wordt meestal opnieuw gebouwd zodra de eerste echte klant zich meldt.

Welke documenten erbij horen. Punchout-sessie en winkelwagen terugsturen is het minimum. Inkooporders, orderbevestigingen, verzendaankondigingen en facturen voegen elk integratiewerk toe, en elk ervan is een apart gesprek met het team van de klant.

Waar het rechtenmodel ligt. Bepaal of bedrijfsaccounts, contractprijzen en het klantspecifieke assortiment in je commerceplatform staan of in de middleware. Deze ene beslissing verklaart het grootste deel van het kostenverschil tussen implementaties.

Hoe artikelnummers op elkaar aansluiten. Stel vast of de klant zijn eigen artikelnummers op de teruggestuurde winkelwagen nodig heeft, en waar die koppeling wordt opgeslagen en bijgehouden.

Wat je platform echt kan. Sommige commerceplatforms hebben punchout standaard aan boord. Andere hebben er middleware of een app voor nodig. Shopify heeft geen ingebouwde punchout. Leveranciers regelen het met connector-apps of een eigen middlewarelaag. De openbare prijzen van punchout-connectors in de Shopify App Store lopen op tot enkele honderden dollars per maand per koppeling, en extra koppelingen en documenttypes kosten apart. De lopende kosten groeien dus mee met het aantal grote zakelijke klanten en blijven niet gelijk.

Wie het test. Inkoopintegraties worden getest in het systeem van de klant, volgens hun planning, door hun team. Regel testtoegang dus vroeg. Een leverancier die klaar is om te testen tegenover een klant zonder testvenster: zo loopt het vaak vast.

Het maatwerkteam van Flatline bakent inkoopintegraties af als onderdeel van enterprise commerce-trajecten. Het patroon dat steeds terugkomt, is het patroon hierboven: het protocolwerk is voorspelbaar, het rechtenmodel bepaalt de doorlooptijd.

Veelgestelde vragen

Wat is het verschil tussen punchout en EDI? 

Punchout gaat over het moment van winkelen: de inkoper bekijkt je catalogus vanuit zijn eigen inkoopsysteem en stuurt een winkelwagen terug. EDI gaat over de gestructureerde uitwisseling van documenten tussen systemen, meestal inkooporders, bevestigingen, verzendaankondigingen en facturen. Vaak bestaan ze naast elkaar: punchout regelt de keuze, een documentlaag regelt alles na de goedkeuring. cXML kan beide delen dragen, en dat is een reden waarom het meestal het betere startpunt is.

Ondersteunt Shopify punchout? 

Niet standaard. Leveranciers op Shopify bouwen punchout met connector-apps of maatwerk-middleware. Die handelt het setup-verzoek, de authenticatie van de sessie en het terugsturen van de winkelwagen af, terwijl de webshop de klantspecifieke catalogus toont. Het kan dus wel, maar de kosten zijn doorlopend en niet eenmalig. Dat hoort in je businesscase.

Hoe lang duurt een punchout-integratie? 

Het protocolwerk is het voorspelbare deel, vaak een kwestie van weken. De onbekende is of je platform bedrijfsaccounts, contractprijzen en klantspecifieke catalogi al kent. Is dat zo, dan reken je in weken. Moet de punchout-laag dat rechtenmodel nabouwen, reken dan op kwartalen, en op blijvend onderhoud in twee systemen.

Loont het om punchout te bouwen voordat een klant erom vraagt? 

Meestal niet. De eisen hangen af van het platform, het protocol, de documenten en de artikelnummering van die ene klant, en een generieke implementatie wordt meestal omgebouwd zodra de eerste echte eis binnenkomt. Wat vooraf wel loont, is het datafundament: bedrijfsaccounts, contractprijzen en schone productcodes. Die heb je hoe dan ook nodig, welk inkoopplatform zich ook als eerste meldt.

De belangrijkste punten

• Via punchout komen grote zakelijke klanten bij je catalogus: gekozen uit een lijst met goedgekeurde leveranciers, als sessie geopend door hun inkoopsysteem, doorzocht zonder login en als winkelwagen teruggestuurd naar hun goedkeuringsproces.

• Twee protocollen dragen het. cXML is het bredere startpunt en loopt door in inkooporders, bevestigingen, verzendaankondigingen en facturen. OCI is het SAP-formaat dat je bouwt als een specifieke klant erom vraagt.

• Het protocol is niet het moeilijke deel. Het echte werk is een machine-identiteit herleiden tot een organisatie, een contract, een klantspecifiek assortiment, contractprijzen en klanteigen artikelnummers. Dat is een vraag over je datamodel.

• Kent een platform B2B-structuren op bedrijfsniveau zelf, dan is punchout een vertaallaag. Kent het die niet, dan wordt de connector een tweede commercesysteem met eigen prijslogica, en worden de kosten blijvend in plaats van eenmalig.

Inkoopintegratie leest als een technisch onderwerp, maar gedraagt zich als een commercieel onderwerp. De leverancier die op het moment van aankoop in het systeem van de klant verschijnt, doet mee in een proces dat is ontworpen om inkoop binnen een korte lijst te houden. Op die lijst staan is meer waard dan de meeste webshopoptimalisatie die je voor hetzelfde budget kunt kopen.