Website of webshop? Wanneer heb je welk type platform nodig?
Niet ieder bedrijf dat producten aanbiedt heeft een webshop nodig. Het verschil zit vooral in het proces: informeren en aanvragen ontvangen versus zelfstandig bestellen, betalen en afhandelen.

Niet ieder bedrijf dat producten verkoopt heeft een webshop nodig. Dat klinkt tegendraads in een markt waarin online verkopen als vanzelfsprekend geldt, maar een webshop is wezenlijk iets anders dan een website met productpagina's en prijzen erop. Zodra bezoekers zelfstandig moeten kunnen bestellen, betalen en hun order verwerkt moeten zien worden, ontstaat een transactieketen die veel verder reikt dan de pagina die ze zien: voorraad, orderstatus, facturatie, verzending en retouren worden er allemaal onderdeel van.
Een gewone bedrijfswebsite heeft meestal een ander doel. Die informeert, bouwt vertrouwen op en eindigt bij een aanvraag, waarna een medewerker het overneemt en de commerciële transactie buiten de website wordt afgerond. Een webshop neemt juist dat laatste stuk over van de mens, en wordt daarmee onderdeel van het operationele verkoopproces. De juiste keuze hangt daarom minder af van de vraag of je producten hebt, en veel meer van de vraag welke stap de klant zelfstandig online moet kunnen afronden.
Soms is een reguliere website voldoende. Soms past een catalogus met offerteaanvraag beter. Soms is een volledige webshop logisch. En in B2B ontstaan vaak tussenvormen die geen van beide labels helemaal dekken.
Het verschil zit in het proces, niet in het uiterlijk
Een website en een webshop kunnen visueel sterk op elkaar lijken. Beide kunnen productpagina's hebben, categorieën, een zoekfunctie, formulieren, klantcases en zelfs accountfunctionaliteit. Wie alleen naar screenshots kijkt, ziet het verschil vaak niet.
Dat verschil wordt pas zichtbaar zodra je kijkt naar wat er ná de productpagina gebeurt. Bij een bedrijfswebsite bekijkt de bezoeker het aanbod, leest hij de informatie, vraagt hij een offerte aan en neemt een medewerker contact op. De website levert een gekwalificeerde aanvraag af en houdt daar op. Bij een webshop kiest de bezoeker een product en een variant, ziet hij de definitieve prijs, rekent hij af, wordt de order geregistreerd en volgen voorraad en fulfilment automatisch. Vanaf het moment dat er wordt afgerekend is de website geen etalage meer maar een schakel in de bedrijfsvoering, en dat is technisch én organisatorisch een andere categorie.
Die tweedeling verklaart waarom twee projecten met dezelfde omvang zo verschillend kunnen uitpakken. Een informatieve site die faalt levert een gemiste lead op. Een webshop die faalt levert een order op die wel is betaald maar niet verwerkt, of voorraad die niet klopt.
Wanneer een bedrijfswebsite volstaat
Een website zonder online checkout is vaak de beste keuze wanneer de verkoop veel menselijke afstemming vraagt. Dat is het geval als iedere offerte maatwerk is, als de prijs afhangt van projectdetails, als advies noodzakelijk is voordat iemand kan bestellen, als beschikbaarheid handmatig wordt gecontroleerd, of als de uiteindelijke order pas na overleg ontstaat. Je ziet dit patroon terug bij bouwbedrijven, zakelijke dienstverleners, machinebouwers, maatwerkinterieurbouw en complexe B2B-leveranciers.
In zulke situaties kan het digitale proces prima eindigen bij informatie, een configuratie of aanvraag, en daarna sales. De website doet dan precies wat hij moet doen: hij zorgt dat de aanvraag compleet en gekwalificeerd binnenkomt. Een checkout toevoegen omdat iedereen tegenwoordig online verkoopt, sluit in die gevallen juist slecht aan op het echte bedrijfsproces — en levert een winkelwagen op die niemand gebruikt.
Wanneer een webshop zichzelf terugverdient
Een webshop wordt sterker naarmate de klant zelfstandiger tot een order kan komen. Dat vraagt dat producten voldoende gestandaardiseerd zijn, dat prijzen vooraf bekend zijn, dat voorraad of levertijd digitaal beschikbaar is, dat betaalmethoden duidelijk zijn en dat orderverwerking grotendeels voorspelbaar verloopt. Zijn die vijf voorwaarden aanwezig, dan voegt een online transactie echt waarde toe, simpelweg omdat de klant niet voor iedere bestelling een medewerker nodig heeft.
Stel dat een leverancier van bevestigingsmaterialen een webshop laat bouwen met een volledige checkout. De producten zijn gestandaardiseerd, de prijzen staan vast, en tot en met de betaling verloopt alles zoals bedoeld. Daarna blijkt de voorraad alleen in het ERP te bestaan en nergens automatisch naar de webshop te komen. Iedere order wordt met de hand overgenomen, en bij iedere drukke week loopt de getoonde beschikbaarheid achter op de werkelijkheid. De winkelwagen werkt; de keten eromheen niet.
Wat organisaties daarbij stelselmatig onderschatten, is hoeveel proces er achter "online bestellen" schuilgaat. Een serieuze webshop moet omgaan met een productcatalogus, categorieën, varianten, prijzen, kortingen, belastingen, voorraad, winkelmand, checkout, betaalprovider, orderstatus, bevestigingsmail, fulfilment, verzending, retouren, terugbetalingen, facturatie, klantaccounts en vaak een ERP- of boekhoudkoppeling. Niet iedere webshop heeft dat allemaal nodig, maar het verschil met een informatieve website zit precies in deze operationele laag. Die laag verdwijnt niet als je hem negeert; hij verhuist dan naar de mailbox van je binnendienst.
De tussenvormen die in B2B het vaakst passen
Tussen "website" en "webshop" zit meer ruimte dan de twee woorden suggereren, en juist in B2B liggen de bruikbaarste vormen daar. De eerste is de online catalogus: de site toont producten met alle specificaties, maar laat bezoekers niet direct afrekenen. Dat is sterk wanneer prijzen projectafhankelijk zijn, minimumafnames gelden, transportkosten variëren, advies nodig is of contractvoorwaarden per klant verschillen.
De tweede is de offerteflow, die veel rijker kan zijn dan een contactformulier. In plaats van een leeg tekstvak kiest de klant een product, geeft een hoeveelheid en variant op, vult projectgegevens in en voegt eventueel een bestand toe. Hij krijgt zo een gestructureerde digitale ervaring, terwijl de uiteindelijke prijs of order nog door een medewerker wordt beoordeeld. Commercieel is dat vaak efficiënter dan de keuze tussen een kaal formulier en een te rigide webshop.
B2C-webshops draaien meestal om transparante prijzen, snelle checkout, directe betaling en eenvoudige retouren. B2B stelt andere eisen: klant-specifieke prijzen, bestellen op rekening, staffelprijzen, minimumafnames, meerdere gebruikers binnen één account, goedkeuringsflows, herhaalorders, orderhistorie en offertefunctionaliteit. Daarom is "we hebben een webshop nodig" bij B2B nog steeds een te algemene uitspraak; de echte vraag is welk bestelproces digitaal ondersteund moet worden. Sommige bedrijven willen bijvoorbeeld dat alleen ingelogde klanten prijzen zien, met een publieke catalogus ervoor en eigen prijzen erachter. Dat kan uitstekend werken, maar het verschuift de oplossing richting een B2B-portaal of een maatwerk commerce-omgeving, en de complexiteit stijgt navenant.
De keuze hoeft bovendien niet binair te zijn. Een hybride flow waarin standaardproducten direct besteld kunnen worden en maatwerkproducten via een offerteaanvraag lopen, ondersteunt meerdere commerciële routes zonder alles in één rigide proces te dwingen. Hetzelfde geldt voor een splitsing op ordergrootte: kleine orders via checkout, grote orders via sales.
Wat je productcatalogus technisch met je doet
Zodra producten digitaal worden beheerd, bepaalt de opbouw van je productdata een groot deel van de technische scope. Een product is dan niet alleen een titel met een prijs, maar een record met omschrijving, categorie, afbeeldingen, SKU, voorraad en varianten. De complexiteit groeit zodra er veel varianten zijn, samengestelde producten, technische eigenschappen, dynamische prijzen of verschillende klantgroepen. Een webshop met twintig simpele producten kan daardoor technisch eenvoudiger zijn dan een catalogus met vijf producten die honderden configureerbare combinaties kennen.
Varianten verdienen daarbij aparte aandacht. Een product dat varieert op maat, kleur, uitvoering en materiaal dwingt de webshop om te bepalen welke combinaties geldig zijn, welke prijs bij iedere variant hoort, welke voorraad geldt en welke SKU wordt gebruikt. Dat raakt niet alleen de gebruikerservaring maar ook de data en de orderverwerking. Voorraad kent een vergelijkbaar vraagstuk: er moet één systeem leidend zijn. Beheert het ERP de voorraad en toont de webshop alleen beschikbaarheid, dan is de verhouding helder. Passen meerdere systemen voorraad onafhankelijk aan, dan ontstaan overselling en afwijkingen die je pas merkt als een klant belt.
Checkout, betaling en alles wat daarna komt
Een betaalflow is geen knop maar een statusmachine. Een order wordt aangemaakt, een betaling gestart, de betaling slaagt en de order wordt definitief — of de betaling mislukt en de order blijft open of vervalt. Welke implementatie past hangt af van platform en betaalprovider, maar het uitgangspunt is steeds dat betaling onderdeel is van de orderstatus en niet een los element ernaast.
De checkout zelf bestaat meestal uit klantgegevens, verzendadres, factuuradres, verzendmethode, betaalmethode en een ordercontrole. Iedere extra stap kan nodig zijn en voegt tegelijk frictie toe, dus het uitgangspunt blijft: vraag alleen wat nodig is om de order correct af te ronden. Een verplichte accountregistratie is bijvoorbeeld onnodig als de klant maar één keer bestelt; een gastcheckout past daar beter. Een account wordt pas relevant wanneer de klant er zelf voordeel bij heeft, door orderhistorie, herhaalbestellingen, opgeslagen adressen, klantprijzen of abonnementen.
Na de betaling begint de operationele afhandeling, en daar wordt een webshop pas echt een bedrijfssysteem. De order gaat naar het magazijn, wordt gepickt, verzonden en voorzien van tracking. Dat kan intern gebeuren of via een koppeling met ERP, WMS, een fulfilmentpartner of een verzendprovider — en hoe meer systemen erbij betrokken zijn, hoe belangrijker een eenduidige orderstatus wordt. Retouren worden in de eerste scope vaak vergeten terwijl ze onmiskenbaar bij commerce horen: een retouraanvraag, een beoordeling, een retourlabel, de ontvangst en de terugbetaling. Bij lage volumes kan dat deels handmatig; bij groei loont automatisering.
Dat alles maakt de keuze ook een beheerkeuze. Een webshop vraagt structureel meer operationeel werk dan een bedrijfswebsite: productdata, voorraad, prijzen, acties, orders, betalingen en retouren moeten door iemand worden bijgehouden. Een technisch uitstekende webshop zonder intern beheerproces veroudert opvallend snel.
Standaardplatform, maatwerk of headless
Niet iedere webshop hoeft custom gebouwd te worden. Hosted platforms en bestaande e-commerceoplossingen zijn sterk wanneer het proces grotendeels standaard is: een gebruikelijke checkout, een eenvoudig productmodel, beschikbare integraties en apps die voldoende functionaliteit bieden. Maatwerk wordt pas interessant wanneer de B2B-logica uniek is, klantprijzen complex zijn, de orderflow afwijkt, configuratie centraal staat, specifieke integraties nodig zijn of het standaardplatform structureel workarounds vraagt.
Die keuze volgt uit procesfit, niet uit een voorkeur voor technologie. Een custom webshop kan exact aansluiten, onnodige code vermijden en een specifieke gebruikerservaring ondersteunen, maar je neemt er ook meer verantwoordelijkheid mee voor security, onderhoud, hosting, updates, integraties en testwerk. Er moet dus een concrete reden zijn waarom een bestaand platform onvoldoende is.
Headless commerce verdient dezelfde nuchterheid. Een headless architectuur is nuttig als dezelfde commercebackend meerdere kanalen bedient — website, app, kiosk — maar voegt ook een extra technische laag toe. Is één gewone webshop het enige kanaal, dan is een traditionele architectuur vaak eenvoudiger en onderhoudbaarder. Headless is een middel, geen upgrade.
SEO en performance verschillen wezenlijk
Een informatieve website heeft doorgaans een beperkte URL-structuur. Een webshop kan duizenden URL-combinaties krijgen door categorieën, producten, varianten, filters, sortering en pagination, en daarmee wordt technische SEO een serieus onderdeel van het project in plaats van een afrondende handeling. De checklist voor een launch-ready website loopt de technische punten langs die daarbij horen.
Categoriepagina's helpen gebruikers én zoekmachines begrijpen hoe je assortiment is georganiseerd, mits ze een echte navigatiefunctie hebben en niet alleen bestaan om te ranken. Productpagina's moeten correcte en actuele informatie tonen — naam, prijs, beschikbaarheid, variant, afbeeldingen en beschrijving — en met Product- en Offer-markup kun je die eigenschappen expliciet maken voor zoekmachines. Dat garandeert geen rich result, maar het helpt wel bij de interpretatie. Filters en facets zijn het lastigste onderdeel: een combinatie van kleur, maat en merk genereert razendsnel enorme aantallen URL's, en lang niet iedere combinatie hoort indexeerbaar te zijn. Daar hoort vooraf een crawl- en indexatiestrategie bij.
Performance weegt bij webshops eveneens zwaarder. Reviews, zoekfunctie, filters, personalisatie, checkout, tracking en aanbevelingswidgets stapelen zich op, en daar komen doorgaans veel productafbeeldingen bij. Iedere externe app of widget heeft bovendien invloed op laadtijd, privacy, security en betrouwbaarheid. Dat is geen argument om third-party tools te mijden, wel om per toevoeging een duidelijke zakelijke functie te eisen. Hetzelfde geldt voor privacy: webshops gebruiken vaker analytics, advertenties, chat, reviews en personalisatie, en niet-noodzakelijke tracking hoort niet te laden voordat aan de geldende toestemmingsvereisten is voldaan. Toegankelijkheid ten slotte is sinds de invoering van Europese regels voor bepaalde diensten extra relevant, maar los van de wettelijke vraag geldt gewoon dat een checkout die voor een deel van je bezoekers onbruikbaar is, geen sterke checkout is.
Wanneer je verder moet kijken dan een webshop
Sommige bedrijven hebben eigenlijk geen klassieke webshop nodig maar een bestelportaal. Dat speelt wanneer klanten vaste contractprijzen hebben, herhaalorders plaatsen, op rekening betalen, met meerdere gebruikers werken of goedkeuringsflows nodig hebben. De oplossing verschuift dan richting een klantportaal met commercefunctionaliteit, waarin de relatie belangrijker is dan de transactie.
Bij configureerbare producten loopt een klassieke webshop tegen een andere grens aan. Maatwerkafmetingen, technische opties, onderlinge afhankelijkheden en dynamische prijsberekening passen slecht in een variantenmodel. Dan kan een productconfigurator onderdeel worden van het bestel- of offertetraject, waarbij de webshop verantwoordelijk blijft voor order en betaling en de configuratielogica in een aparte laag zit.
Een beslisboom in vijf vragen
De keuze laat zich in de praktijk terugbrengen tot een korte reeks vragen, die je het beste in volgorde beantwoordt:
- Kan de klant zelfstandig de definitieve prijs bepalen? Zo niet, dan is een website of catalogus met offerteflow meestal sterker.
- Kan de klant bestellen zonder menselijke beoordeling? Zo niet, dan blijft een aanvraagflow de logische vorm.
- Is directe betaling onderdeel van het proces? Zo ja, dan wordt een webshop logisch; zo nee, dan past een B2B-bestelportaal of orderflow beter.
- Zijn prijzen, voorraad en orderlogica standaard? Zo ja, onderzoek dan serieus een bestaand commerceplatform; zo nee, dan komen maatwerk of een hybride architectuur in beeld.
- Bestaan er klant-specifieke rechten of prijzen? Dan hoort portaalfunctionaliteit vanaf het begin in de scope.
Vergelijking
| Vraag | Bedrijfswebsite | Webshop | B2B-portaal / hybride |
|---|---|---|---|
| Primair doel | Informeren / leads | Direct verkopen | Terugkerende zakelijke transacties |
| Productcatalogus | Optioneel | Meestal | Vaak |
| Definitieve prijzen | Niet noodzakelijk | Meestal | Vaak klantafhankelijk |
| Checkout | Nee | Ja | Afhankelijk |
| Online betaling | Optioneel | Meestal | Soms op rekening |
| Voorraad | Vaak niet | Vaak relevant | Afhankelijk |
| Klantaccounts | Optioneel | Optioneel | Vaak essentieel |
| Orderhistorie | Nee | Vaak | Vaak |
| Approvalflows | Zelden | Zelden | Regelmatig |
| Integraties | CRM/formulieren | Payment/ERP/fulfilment | CRM/ERP/boekhouding |
Kies op basis van het verkoopproces
De meest gemaakte fout is starten vanuit het label. "We moeten een webshop hebben" is geen requirement maar een conclusie, en meestal een die te vroeg is getrokken. De bruikbare vraag is hoe klanten je aanbod willen ontdekken, kiezen, bestellen en betalen — daaruit volgt de digitale vorm vanzelf.
Voor het ene bedrijf eindigt dat bij een website met een sterke aanvraagflow. Voor het andere bij een catalogus met account en zakelijke orders. Voor weer een ander bij een volledige webshop met checkout, betaling en fulfilment. De professionele keuze is steeds de kleinste digitale oplossing die het commerciële proces betrouwbaar ondersteunt. Praktisch splitst dat zich bij ons in een bedrijfswebsite of een webshop.
Draait de vraag bij jou eigenlijk om een site die er al staat, dan komt er een stap vóór: bepalen of die opnieuw gebouwd moet worden of alleen bijgewerkt.
Bronnen
Dit artikel is opgesteld op basis van het onderzoeksdossier over websites en webshops voor Nederlandse bedrijven. Belangrijkste bronnen daaruit:
- Google Search Central — Product structured data
- Google Search Central — documentatie over crawlbaarheid, canonicals en structured data
- Nielsen Norman Group — mobile checkout en formulier-UX
- W3C/WAI — toegankelijkheidsrichtlijnen
- Europese toegankelijkheidswetgeving en Nederlandse toelichting
- officiële documentatie en praktijkbronnen over CMS-, webshop- en platformkeuze
Commerciële bronnen uit het dossier zijn alleen gebruikt voor markt- en praktijkobservaties; technische en SEO-claims zijn waar mogelijk gebaseerd op officiële documentatie.