WooCommerce is een plugin bovenop WordPress, geen eigen winkelplatform. Producten, variaties en orders leven in dezelfde tabellen als berichten en pagina's, plus een berg metadata. Voor een catalogus, winkelwagen, iDEAL via Mollie en verzending naar een paar zones is dat genoeg. De grens verschijnt pas als jouw verkoopproces extra stappen eist die de plugin niet als kern heeft: staffels per klantgroep, een offerte vóór de order, een kredietlimiet, of voorraad die in een ander systeem leidend is.
Plugins dichten één gat en maken er drie
Een B2B-plugin zet groothandelsprijzen op het product. Een quote-plugin zet daarnaast een knop voor een offerte. Een PDF-plugin maakt de pakbon. Een connector duwt de order naar de boekhouding. Elk stukje lijkt los te koop, tot een WordPress-update of een overstap naar eigen ordertabellen één van die stukken laat vallen. Dan zoek je niet naar een shopfout. Je zoekt welk van de twaalf plugins de prijs-HTML overschrijft.
HPOS, High Performance Order Storage, legt orders in eigen tabellen in plaats van in de berichtenlijst van WordPress. Nieuwe Woo-installaties hebben dat als standaard sinds versie 8.2. Bestaande shops blijven op de oude post-tabellen tot je migreert. Oude maatwerkcode die orderdata uit post-metadata las, ziet na die overstap ineens lege velden. Plugins die HPOS-compatible beloven, botsen alsnog met een thema dat de checkout overschrijft, of met een taalplugin die variaties in het admin-scherm niet laat uitklappen. Woo-shops groeien zo: extra plugin, extra haak in de code, extra kans dat twee partijen dezelfde prijsfilter claimen.
Licenties lijken goedkoop. Losse B2B- of PDF-plugins zitten vaak tussen de tachtig en driehonderd euro per jaar. Stapel je groothandelsprijzen, offertes, facturen, cache en een boekhoudconnector, dan tel je al snel 25 tot 100 euro per maand bij elkaar. Daarbij komt hosting die de queries aankan, 20 tot 80 euro. De echte rekening is developer-tijd bij elke Woo- of PHP-update, grofweg 8 tot 20 uur per jaar. Bij 85 euro exclusief btw is dat 680 tot 1.700 euro onderhoud, zonder dat je een nieuwe verkoopregel hebt gekocht.
Beveiligingspatches voor WordPress, Woo en plugins komen in golven binnen. Eén verouderde checkout-plugin is een gat naar orders en klantgegevens. Maatwerk heeft ook updates, maar jij bepaalt de oppervlakte: geen winkelwagen-extensie van een onbekende auteur naast je betaalflow.
Catalogus en variaties lopen vast in het WordPress-datamodel
Variaties zijn kindberichten. Honderd SKU's met kleur en maat worden al snel duizenden rijen, elk met eigen meta. Filters, voorraad per magazijn of een prijs per ingelogde klant trekken die meta keer op keer. Extra prijsvelden in de productweergave maken van een pagina van drie seconden zomaar een van zes. Dat voelt de bezoeker als een trage shop. Jij voelt het als conversie die wegzakt terwijl de server nog lang niet vol zit.
Import vanuit een spreadsheet of een leveranciersfeed is het tweede knelpunt. Woo heeft CSV-import, plus extra plugins die nachtelijke bestanden inlezen. Een bestand met tienduizend regels haalt PHP-geheugenlimieten en timeouts. Batchen kan, maar de shop blijft tijdens de import traag of toont halve prijzen. In een maatwerk-shop zet ik de feed in een wachtrij, per batch, met een rapport welke SKU's faalden. Woo kan dat nadoen als je er een extra job omheen bouwt. Dan onderhoud je twee systemen: de shop en de importlaag.
Zoekfilters, facetten en gerelateerde producten komen vaak uit nog een plugin. Elke extra query op metadata is een gok of de index het haalt. Bij een paar honderd producten merkt niemand het. Bij een groothandelscatalogus met staffels, afmetingen en voorraadstatus wel. Laravel legt producten in eigen tabellen met kolommen die jij indexeert. Woo vraagt je om hetzelfde in meta-sleutels te proppen omdat het product een WordPress-bericht is.
De checkout is gebouwd om nu te betalen
De standaardcheckout verwacht gast of account, adres, verzending, betalen, bedankt. Op rekening leveren, een inkoper die een mandje klaarzet en een chef die accordeert, of een offerte-PDF die later een order wordt: dat hangt eraan met plugins. Die plugins schrijven extra velden in de order. De kernflow blijft consument. Zodra je deelleveringen, restorders of een kredietcheck voor acceptatie wilt, zit je buiten wat de checkout als staat kent.
Offerte-voor-order is het scherpste voorbeeld. De klant vraagt een prijs, jij stuurt een PDF, iemand intern keurt goed, daarna mag er pas een echte order ontstaan. Woo kent die tussentijdse status niet als kern. Quote-plugins bootsen hem na met een extra posttype of een orderstatus die de rest van je plugins niet begrijpt. Zet je de offerte om naar een order, dan verdwijnen notities, staffels of een geldigheidsdatum die alleen in de plugin leefden. Dat is geen instelling. Dat is een tweede verkoopproces naast de winkelwagen.
Prijsafspraken per debiteur horen in jouw ERP of in een prijstabel die jij bezit. In Woo leeft de prijs op het product, plus een overlay van groepsregels. Twee kortingsplugins tegelijk geven catalogusprijzen die niet matchen met de winkelwagen. Variabele producten zijn daar extra gevoelig voor, omdat de range op de overzichtspagina gecached wordt en de cart de regel opnieuw rekent. Dan heb je twee bronnen van waarheid, en één klant die belt waarom de bevestiging anders is dan het scherm.
Excel blijft dan alsnog in beeld. Orders gaan naar een sheet omdat de shop de uitzondering niet aankan, of omdat de binnendienst de prijs nog even aanpast. De vraag of je Excel ontgroeid bent, is hier letterlijk: je hebt een shop én een spreadsheet. Maatwerk is hier geen mooier thema. Order, prijs en voorraad horen in één datamodel, met een admin waarin jij uitzonderingen zet zonder CSV-rondjes.
Woo laten staan of overstappen
Blijf op Woo als je assortiment in de standaardcatalogus past, je checkout betalen-nu is, en je plugins op één hand te tellen zijn. Content en shop in hetzelfde WordPress is dan een plus, niet een last. Hosting, updates en een staging-omgeving moet je wél serieus nemen. Anders koop je de limiet op termijn, niet op dag één.
Betaalmethoden zijn zelden de reden om Woo te verlaten. iDEAL en creditcard via Mollie koppel je in een maatwerk-shop net zo. De reden zit in de orderregel, niet in de betaalknop. Wie alleen een andere checkout-kleur of een extra betaalmethode zoekt, is goedkoper uit met een thema of een gateway-plugin.
Stap over als drie of meer van deze punten waar zijn. Staffels of klantprijzen die niet in één plugin blijven, een offerte of goedkeuring voor de order, een koppeling met voorraad of boekhouding die twee kanten op moet, een catalogus die de admin traag maakt, of een binnendienst die orders in Excel afmaakt: dat zijn de signalen. Eén knelpunt kun je nog met gerichte code of een hybride stuk dichten. Drie knelpunten tegelijk is een keten.
Hybride bestaat. De shop blijft Woo voor de catalogus die werkt, en een klein Laravel-stuk pakt de uitzondering: een orderportaal, een prijs-API, een importwachtrij. Dat is goedkoper dan alles in één keer slopen, duurder dan nóg een plugin. Eigenaarschap moet dan scherp zijn: wie pakt de telefoon als Woo een haak hernoemt en jouw brug stilvalt.
Migratie is geen exportknop. Producten, klanten, orders, redirects van oude URL's en de betaalhistorie moeten mee, of bewust achterblijven. Reken voor een gerichte herbouw van catalogus plus checkout plus admin grofweg 80 tot 160 uur, dus 6.800 tot 13.600 euro bij 85 euro exclusief btw. B2B-regels, een magazijnkoppeling of een configurator tillen dat naar 15.000 tot 25.000 of hoger. Woo nog een jaar rekken met plugins is goedkoper in maand één. Over drie jaar tel je de uren, de downtime bij updates en de migratie alsnog.
Lokaal maakt de plugin niet slimmer. Een groothandel in Oss of Veghel met staffels heeft dezelfde Woo-limiet als een landelijke shop. Wat wél telt is of jouw binnendienst de order in het admin-scherm herkent zonder een extra sheet ernaast.
Lezen van een bestaande Woo-installatie doe ik wél: pluginlijst, checkout-stappen, en of de binnendienst nog een sheet ernaast houdt. Soms is het antwoord een wachtrij en minder plugins. Soms is het een maatwerk-webshop in Laravel omdat jouw proces de shop is, niet andersom.
Webshops van dit kaliber horen bij het werk onder webshops en e-commerce. Op https://pimvdmolen.nl/diensten/webshops-e-commerce lees je hoe ik catalogus, checkout en koppelingen aanpak, op uurbasis of in fases. Schets via https://pimvdmolen.nl/contact welke plugins je nu draait, waar Excel nog tussen zit, en welke orderregel de shop niet aankan. Dan krijg je een eerlijk ja of nee op Woo, zonder dat ik een thema verkoop dat je niet nodig hebt.