.png)
Waarom standaard Shopify-kortingen vastlopen bij fashion retailers
Veel acties, nieuwe collectie en meerdere kanalen? Dit is waarom standaard kortingsapps vastlopen en wanneer maatwerk nodig wordt.
Blog
9 min leestijd
Voor veel webshops is korting een tijdelijke campagne. Voor fashion retailers kan korting een vast onderdeel van de operatie zijn. Er komt iedere week nieuwe collectie binnen, uitzonderingen veranderen per actie en dezelfde prijs moet kloppen in de webshop, de winkel, apps en advertentiefeeds.
Op dat moment is een kortingspercentage niet meer het moeilijke deel. De echte vraag is: welk systeem bepaalt de prijs, wanneer doet het dat en welke andere systemen schrijven naar hetzelfde veld?
Dat verschil merkten we bij Style Woerden, een Nederlandse fashion retailer op Shopify Plus. De winkel publiceert ongeveer 3.900 actieve varianten naar acht verkoopkanalen en draait vrijwel continu promoties. Standaard Shopify-tools en kortingsapps deden afzonderlijk wat ze moesten doen. Samen leverden ze een prijsproces op dat niet meer betrouwbaar te beheren was.
Eén promotie, acht plekken waar de prijs moet kloppen
Een fashion retailer verkoopt zelden nog via één storefront. In dit project ging dezelfde catalogus naar:
- de Shopify-webshop;
- de kassa in de winkel;
- een headless storefront;
- een mobiele app;
- Facebook en Instagram;
- TikTok;
- Google en YouTube.
Al deze kanalen verwachten een duidelijke productprijs. Een korting die alleen in de winkelwagen of in het webshopthema wordt berekend, lost daarom maar een deel van het probleem op.
Dat is vooral riskant bij advertentiefeeds. Google vergelijkt de prijs in Merchant Center met de prijs op de landingspagina. Bij een verschil kan een product worden afgekeurd. De prijs moet dus niet alleen visueel goed lijken in de webshop; hij moet in de onderliggende productdata kloppen.
Voor retailers met een fysieke winkel komt daar nog iets bij. Dezelfde promotie moet ook bij de kassa gelden. Een aparte regel per kanaal klinkt flexibel, maar maakt het steeds moeilijker om te bepalen welke prijs nu de waarheid is.
Waarom de standaardaanpak hier begon te kraken
Shopify Launchpad is gemaakt voor geplande evenementen, zoals sales, productlanceringen en voorraadreleases. Het kan aan het begin en einde van een evenement productprijzen aanpassen. Voor een korte campagne op een stabiele catalogus is dat logisch.
Deze retailer werkte precies andersom: bijna permanente korting, wekelijks nieuwe voorraad en uitzonderingen die per campagne veranderen. In de praktijk botsten drie aannames van de event-aanpak met de dagelijkse operatie.
1. Nieuwe producten vielen buiten een lopende actie
Producten die tijdens een actie werden toegevoegd, kregen niet automatisch dezelfde korting. Iedere nieuwe levering vroeg daarom om een nieuw event dat opnieuw door de catalogus ging.
Tussen 8 en 22 juli waren daar zes events voor nodig, soms met slechts zeven minuten ertussen. Wat bedoeld was als campagneplanning werd catalogusonderhoud.
2. Handmatige prijswijzigingen werden teruggedraaid
Wanneer een medewerker tijdens een lopend event een prijs wijzigde, kon de opgeslagen beginstaat die wijziging later overschrijven. Een jurk die bewust op € 12,99 was gezet, stond de volgende ochtend weer op € 7,99.
Zonder bruikbaar wijzigingslogboek moesten we via bestelregels reconstrueren wat er was gebeurd. Dat is geen werkbaar prijsproces voor een winkel die iedere dag nieuwe artikelen en afprijzingen verwerkt.
3. Uitzonderingen botsten met de collectie-indeling
Campagnes werden via tags en collecties aangestuurd. Een artikel uit de promotie halen betekende in deze inrichting ook dat het uit de navigatie kon verdwijnen.
De praktische wens was simpel: laat de winterjassen niet meedoen aan 20% korting, maar houd ze wel zichtbaar in de collectie. Binnen de bestaande inrichting waren collectie en promotielogica te sterk aan elkaar gekoppeld.
Een kortingsapp erbij maakte het probleem groter
Een tweede tool lijkt een logische uitweg wanneer de eerste te weinig flexibiliteit biedt. Maar als beide tools hetzelfde prijsveld aanpassen, ontstaat een nieuw probleem: twee schrijvers die niets van elkaar weten.
Een extra kortingsapp rekende in dit project vanaf de prijs die al door Launchpad was aangepast. Daardoor werd op 19 artikelen geen 20%, maar 36% korting toegepast. Bij het verwijderen van de app werden slechts 18 van 3.382 varianten teruggezet.
Dat is geen instelling die je met een extra vinkje repareert. Het prijsmodel zelf heeft dan geen duidelijke eigenaar meer.
Dezelfde beperking geldt voor automatische kortingen of themacode. Die kunnen de prijs aan de voorkant of in de checkout aanpassen, maar veranderen niet vanzelf de bronprijs die andere verkoopkanalen gebruiken. De webshop kan er goed uitzien terwijl de kassa of advertentiefeed nog een ander bedrag toont.
Het prijsmodel omdraaien
De maatwerkoplossing begon niet met nog een kortingstool, maar met één simpele afspraak:
De mens beheert de normale verkoopprijs. De software berekent de actieprijs.
Daarvoor kregen de twee Shopify-prijsvelden ieder één duidelijke rol:
compare_at_pricebevat de normale verkoopprijs en is het veld dat medewerkers beheren;pricebevat de actuele actieprijs en wordt door de automatisering berekend.
Omdat de berekende uitkomst in het echte Shopify-prijsveld staat, gebruiken de webshop, kassa, apps en feeds dezelfde prijs. Er is geen aparte kortingslogica per kanaal nodig.
De promotieregels staan in de Shopify-admin. De winkel kan daar zelf instellen:
- of een actie actief is;
- of de korting een percentage of vast bedrag is;
- voor welke tags de actie geldt;
- welke tags juist zijn uitgesloten.
De regels zijn opgezet als “de hele catalogus, behalve deze uitzonderingen”. Daardoor doen nieuwe producten automatisch mee. Als twee acties overlappen, wint de laagste prijs.
Voor handmatige uitzonderingen is er een noodrem: de tag PRIJS-VAST. Artikelen met die tag houdt het team zelf geprijsd. Op het moment van omzetting ging het om 170 producten, waaronder handmatige afprijzingen en artikelen die buiten een specifieke actie moesten blijven.
Klein gebouwd, groot effect
Technisch bestaat de automatisering uit een webhook, een wachtrij en een kleine functie in AWS. Bij een productwijziging stuurt Shopify een signaal. De functie berekent de juiste prijs en schrijft alleen terug als er echt iets moet veranderen.
Er is geen database, periodieke catalogusscan of permanent draaiende server nodig. Bij ongeveer 1.500 webhooks per dag blijven de infrastructuurkosten onder € 1 per maand.
Dat lage bedrag is aantrekkelijk, maar niet de belangrijkste winst. De waarde zit in een prijsmodel dat medewerkers kunnen begrijpen en vertrouwen:
- een handmatige wijziging blijft staan;
- nieuwe producten vallen automatisch onder de juiste actie;
- uitzonderingen blijven zichtbaar in de winkel;
- alle verkoopkanalen gebruiken dezelfde actuele prijs;
- de retailer kan promoties zelf aan- en uitzetten.
Van 22 minuten naar 5 minuten en 12 seconden
De omzetting was het risicovolste deel. Zodra het oude Launchpad-event stopte, sprong de catalogus terug naar het volle tarief en verdwenen de van-prijzen. Iedere minuut vertraging was zichtbaar voor klanten.
Daarom hebben we vooraf gemeten in plaats van geschat. Het uitlezen van de catalogus duurde 4,2 seconden. Het terugschrijven ging met ruim twintig producten per seconde. De terugweg werd getest door bewust één product verkeerd te zetten en daarna te herstellen.
Vervolgens is het hele proces uitgevoerd op vijf ongepubliceerde conceptproducten. Vijf van de vijf kwamen uit zoals voorspeld. Een tweede ronde schreef nul wijzigingen, waarmee ook vaststond dat de automatisering zichzelf niet in een eindeloze lus zette.
Op 3 augustus 2026 begon de echte omzetting om 14:48:22. Om 14:53:34 stond de hele catalogus weer goed. Het zichtbare venster zonder korting duurde 5 minuten en 12 seconden.
De controle achteraf gaf:
- 3.933 van 3.933 varianten correct;
- nul afwijkingen;
- nul varianten zonder van-prijs;
- tegenover 22 minuten zonder korting bij de vorige handmatige omzetting.
Het maatwerk zelf was klein. Weten wát er gebouwd moest worden, hoe de bestaande tools elkaar beïnvloedden en hoe we veilig konden omschakelen, was het echte werk.
Wat fashion retailers hiervan kunnen leren
Niet iedere fashion webshop heeft maatwerk nodig. Een standaard kortingsfunctie is vaak prima voor een tijdelijke sale met een overzichtelijke catalogus en één verkoopkanaal.
Het wordt tijd om het prijsmodel opnieuw te bekijken wanneer meerdere van deze situaties spelen:
- promoties lopen vrijwel continu;
- er komen tijdens acties nieuwe producten binnen;
- uitzonderingen verschillen per collectie of week;
- medewerkers passen prijzen ook handmatig aan;
- producten worden via webshop, POS, apps en feeds verkocht;
- meerdere apps of scripts wijzigen hetzelfde prijsveld;
- niemand kan met zekerheid aanwijzen welk systeem de uiteindelijke prijs bepaalt.
Begin dan niet met de vraag welke kortingsapp de meeste functies heeft. Begin met drie fundamentelere vragen:
- Welk systeem is eigenaar van de normale prijs?
- Welk systeem mag de actieprijs berekenen en wegschrijven?
- Hoe krijgen alle kanalen dezelfde uitkomst zonder elkaar te overschrijven?
Pas als die afspraken helder zijn, heeft het zin om een standaardapp, automatisering of maatwerkoplossing te kiezen.
En hoe zit het met Europese kortingsregels?
Voor Europese retailers komt daar de referentieprijs bij. Bij een aangekondigde prijsverlaging moet in de regel de laagste prijs van de voorafgaande dertig dagen als referentie worden gebruikt. Dat vraagt om betrouwbare prijshistorie, niet alleen om een gevuld van-prijsveld.
De oplossing uit dit project zorgt ervoor dat actuele prijzen consistent naar alle kanalen gaan. Ze bewaart geen volledige dertigdaagse prijshistorie en is daarom op zichzelf geen garantie op naleving van Europese prijsregels. Daarvoor is aanvullende registratie en juridische beoordeling nodig.
Die nuance is belangrijk. Technisch consistente prijzen en juridisch juiste referentieprijzen zijn verwant, maar niet hetzelfde probleem.
Standaard waar het kan, maatwerk wanneer het model niet meer past
Launchpad en kortingsapps zijn niet slecht omdat ze deze situatie niet oplosten. Ze zijn gebouwd vanuit andere aannames: tijdelijke campagnes, een stabiele productset en één duidelijke kortingslaag.
Fashion retailers met continue promoties, snelle collectiechanges en meerdere verkoopkanalen kunnen die aannames ontgroeien. Dan helpt nog een app meestal niet. Dan moet eerst duidelijk worden hoe de prijs door de hele organisatie stroomt.
Dat is precies waar Duxly instapt: niet om standaardsoftware opnieuw te bouwen, maar om het ontbrekende stuk te maken wanneer standaard niet meer genoeg is.
Lees ook hoe we de bredere Magento-naar-Shopify Plus-migratie van Style Woerden hebben uitgevoerd, bekijk onze aanpak voor Custom Shopify Apps of lees meer over Shopify-migraties, integraties en maatwerk.
Loopt jouw promotieproces over meerdere apps, kanalen en uitzonderingen? Plan een technische verkenning met Duxly. Dan brengen we eerst in kaart welk systeem de prijs bepaalt, voordat er nog een tool bijkomt.
Bronnen
Voor veel webshops is korting een tijdelijke campagne. Voor fashion retailers kan korting een vast onderdeel van de operatie zijn. Er komt iedere week nieuwe collectie binnen, uitzonderingen veranderen per actie en dezelfde prijs moet kloppen in de webshop, de winkel, apps en advertentiefeeds.
Op dat moment is een kortingspercentage niet meer het moeilijke deel. De echte vraag is: welk systeem bepaalt de prijs, wanneer doet het dat en welke andere systemen schrijven naar hetzelfde veld?
Dat verschil merkten we bij Style Woerden, een Nederlandse fashion retailer op Shopify Plus. De winkel publiceert ongeveer 3.900 actieve varianten naar acht verkoopkanalen en draait vrijwel continu promoties. Standaard Shopify-tools en kortingsapps deden afzonderlijk wat ze moesten doen. Samen leverden ze een prijsproces op dat niet meer betrouwbaar te beheren was.
Eén promotie, acht plekken waar de prijs moet kloppen
Een fashion retailer verkoopt zelden nog via één storefront. In dit project ging dezelfde catalogus naar:
- de Shopify-webshop;
- de kassa in de winkel;
- een headless storefront;
- een mobiele app;
- Facebook en Instagram;
- TikTok;
- Google en YouTube.
Al deze kanalen verwachten een duidelijke productprijs. Een korting die alleen in de winkelwagen of in het webshopthema wordt berekend, lost daarom maar een deel van het probleem op.
Dat is vooral riskant bij advertentiefeeds. Google vergelijkt de prijs in Merchant Center met de prijs op de landingspagina. Bij een verschil kan een product worden afgekeurd. De prijs moet dus niet alleen visueel goed lijken in de webshop; hij moet in de onderliggende productdata kloppen.
Voor retailers met een fysieke winkel komt daar nog iets bij. Dezelfde promotie moet ook bij de kassa gelden. Een aparte regel per kanaal klinkt flexibel, maar maakt het steeds moeilijker om te bepalen welke prijs nu de waarheid is.
Waarom de standaardaanpak hier begon te kraken
Shopify Launchpad is gemaakt voor geplande evenementen, zoals sales, productlanceringen en voorraadreleases. Het kan aan het begin en einde van een evenement productprijzen aanpassen. Voor een korte campagne op een stabiele catalogus is dat logisch.
Deze retailer werkte precies andersom: bijna permanente korting, wekelijks nieuwe voorraad en uitzonderingen die per campagne veranderen. In de praktijk botsten drie aannames van de event-aanpak met de dagelijkse operatie.
1. Nieuwe producten vielen buiten een lopende actie
Producten die tijdens een actie werden toegevoegd, kregen niet automatisch dezelfde korting. Iedere nieuwe levering vroeg daarom om een nieuw event dat opnieuw door de catalogus ging.
Tussen 8 en 22 juli waren daar zes events voor nodig, soms met slechts zeven minuten ertussen. Wat bedoeld was als campagneplanning werd catalogusonderhoud.
2. Handmatige prijswijzigingen werden teruggedraaid
Wanneer een medewerker tijdens een lopend event een prijs wijzigde, kon de opgeslagen beginstaat die wijziging later overschrijven. Een jurk die bewust op € 12,99 was gezet, stond de volgende ochtend weer op € 7,99.
Zonder bruikbaar wijzigingslogboek moesten we via bestelregels reconstrueren wat er was gebeurd. Dat is geen werkbaar prijsproces voor een winkel die iedere dag nieuwe artikelen en afprijzingen verwerkt.
3. Uitzonderingen botsten met de collectie-indeling
Campagnes werden via tags en collecties aangestuurd. Een artikel uit de promotie halen betekende in deze inrichting ook dat het uit de navigatie kon verdwijnen.
De praktische wens was simpel: laat de winterjassen niet meedoen aan 20% korting, maar houd ze wel zichtbaar in de collectie. Binnen de bestaande inrichting waren collectie en promotielogica te sterk aan elkaar gekoppeld.
Een kortingsapp erbij maakte het probleem groter
Een tweede tool lijkt een logische uitweg wanneer de eerste te weinig flexibiliteit biedt. Maar als beide tools hetzelfde prijsveld aanpassen, ontstaat een nieuw probleem: twee schrijvers die niets van elkaar weten.
Een extra kortingsapp rekende in dit project vanaf de prijs die al door Launchpad was aangepast. Daardoor werd op 19 artikelen geen 20%, maar 36% korting toegepast. Bij het verwijderen van de app werden slechts 18 van 3.382 varianten teruggezet.
Dat is geen instelling die je met een extra vinkje repareert. Het prijsmodel zelf heeft dan geen duidelijke eigenaar meer.
Dezelfde beperking geldt voor automatische kortingen of themacode. Die kunnen de prijs aan de voorkant of in de checkout aanpassen, maar veranderen niet vanzelf de bronprijs die andere verkoopkanalen gebruiken. De webshop kan er goed uitzien terwijl de kassa of advertentiefeed nog een ander bedrag toont.
Het prijsmodel omdraaien
De maatwerkoplossing begon niet met nog een kortingstool, maar met één simpele afspraak:
De mens beheert de normale verkoopprijs. De software berekent de actieprijs.
Daarvoor kregen de twee Shopify-prijsvelden ieder één duidelijke rol:
compare_at_pricebevat de normale verkoopprijs en is het veld dat medewerkers beheren;pricebevat de actuele actieprijs en wordt door de automatisering berekend.
Omdat de berekende uitkomst in het echte Shopify-prijsveld staat, gebruiken de webshop, kassa, apps en feeds dezelfde prijs. Er is geen aparte kortingslogica per kanaal nodig.
De promotieregels staan in de Shopify-admin. De winkel kan daar zelf instellen:
- of een actie actief is;
- of de korting een percentage of vast bedrag is;
- voor welke tags de actie geldt;
- welke tags juist zijn uitgesloten.
De regels zijn opgezet als “de hele catalogus, behalve deze uitzonderingen”. Daardoor doen nieuwe producten automatisch mee. Als twee acties overlappen, wint de laagste prijs.
Voor handmatige uitzonderingen is er een noodrem: de tag PRIJS-VAST. Artikelen met die tag houdt het team zelf geprijsd. Op het moment van omzetting ging het om 170 producten, waaronder handmatige afprijzingen en artikelen die buiten een specifieke actie moesten blijven.
Klein gebouwd, groot effect
Technisch bestaat de automatisering uit een webhook, een wachtrij en een kleine functie in AWS. Bij een productwijziging stuurt Shopify een signaal. De functie berekent de juiste prijs en schrijft alleen terug als er echt iets moet veranderen.
Er is geen database, periodieke catalogusscan of permanent draaiende server nodig. Bij ongeveer 1.500 webhooks per dag blijven de infrastructuurkosten onder € 1 per maand.
Dat lage bedrag is aantrekkelijk, maar niet de belangrijkste winst. De waarde zit in een prijsmodel dat medewerkers kunnen begrijpen en vertrouwen:
- een handmatige wijziging blijft staan;
- nieuwe producten vallen automatisch onder de juiste actie;
- uitzonderingen blijven zichtbaar in de winkel;
- alle verkoopkanalen gebruiken dezelfde actuele prijs;
- de retailer kan promoties zelf aan- en uitzetten.
Van 22 minuten naar 5 minuten en 12 seconden
De omzetting was het risicovolste deel. Zodra het oude Launchpad-event stopte, sprong de catalogus terug naar het volle tarief en verdwenen de van-prijzen. Iedere minuut vertraging was zichtbaar voor klanten.
Daarom hebben we vooraf gemeten in plaats van geschat. Het uitlezen van de catalogus duurde 4,2 seconden. Het terugschrijven ging met ruim twintig producten per seconde. De terugweg werd getest door bewust één product verkeerd te zetten en daarna te herstellen.
Vervolgens is het hele proces uitgevoerd op vijf ongepubliceerde conceptproducten. Vijf van de vijf kwamen uit zoals voorspeld. Een tweede ronde schreef nul wijzigingen, waarmee ook vaststond dat de automatisering zichzelf niet in een eindeloze lus zette.
Op 3 augustus 2026 begon de echte omzetting om 14:48:22. Om 14:53:34 stond de hele catalogus weer goed. Het zichtbare venster zonder korting duurde 5 minuten en 12 seconden.
De controle achteraf gaf:
- 3.933 van 3.933 varianten correct;
- nul afwijkingen;
- nul varianten zonder van-prijs;
- tegenover 22 minuten zonder korting bij de vorige handmatige omzetting.
Het maatwerk zelf was klein. Weten wát er gebouwd moest worden, hoe de bestaande tools elkaar beïnvloedden en hoe we veilig konden omschakelen, was het echte werk.
Wat fashion retailers hiervan kunnen leren
Niet iedere fashion webshop heeft maatwerk nodig. Een standaard kortingsfunctie is vaak prima voor een tijdelijke sale met een overzichtelijke catalogus en één verkoopkanaal.
Het wordt tijd om het prijsmodel opnieuw te bekijken wanneer meerdere van deze situaties spelen:
- promoties lopen vrijwel continu;
- er komen tijdens acties nieuwe producten binnen;
- uitzonderingen verschillen per collectie of week;
- medewerkers passen prijzen ook handmatig aan;
- producten worden via webshop, POS, apps en feeds verkocht;
- meerdere apps of scripts wijzigen hetzelfde prijsveld;
- niemand kan met zekerheid aanwijzen welk systeem de uiteindelijke prijs bepaalt.
Begin dan niet met de vraag welke kortingsapp de meeste functies heeft. Begin met drie fundamentelere vragen:
- Welk systeem is eigenaar van de normale prijs?
- Welk systeem mag de actieprijs berekenen en wegschrijven?
- Hoe krijgen alle kanalen dezelfde uitkomst zonder elkaar te overschrijven?
Pas als die afspraken helder zijn, heeft het zin om een standaardapp, automatisering of maatwerkoplossing te kiezen.
En hoe zit het met Europese kortingsregels?
Voor Europese retailers komt daar de referentieprijs bij. Bij een aangekondigde prijsverlaging moet in de regel de laagste prijs van de voorafgaande dertig dagen als referentie worden gebruikt. Dat vraagt om betrouwbare prijshistorie, niet alleen om een gevuld van-prijsveld.
De oplossing uit dit project zorgt ervoor dat actuele prijzen consistent naar alle kanalen gaan. Ze bewaart geen volledige dertigdaagse prijshistorie en is daarom op zichzelf geen garantie op naleving van Europese prijsregels. Daarvoor is aanvullende registratie en juridische beoordeling nodig.
Die nuance is belangrijk. Technisch consistente prijzen en juridisch juiste referentieprijzen zijn verwant, maar niet hetzelfde probleem.
Standaard waar het kan, maatwerk wanneer het model niet meer past
Launchpad en kortingsapps zijn niet slecht omdat ze deze situatie niet oplosten. Ze zijn gebouwd vanuit andere aannames: tijdelijke campagnes, een stabiele productset en één duidelijke kortingslaag.
Fashion retailers met continue promoties, snelle collectiechanges en meerdere verkoopkanalen kunnen die aannames ontgroeien. Dan helpt nog een app meestal niet. Dan moet eerst duidelijk worden hoe de prijs door de hele organisatie stroomt.
Dat is precies waar Duxly instapt: niet om standaardsoftware opnieuw te bouwen, maar om het ontbrekende stuk te maken wanneer standaard niet meer genoeg is.
Lees ook hoe we de bredere Magento-naar-Shopify Plus-migratie van Style Woerden hebben uitgevoerd, bekijk onze aanpak voor Custom Shopify Apps of lees meer over Shopify-migraties, integraties en maatwerk.
Loopt jouw promotieproces over meerdere apps, kanalen en uitzonderingen? Plan een technische verkenning met Duxly. Dan brengen we eerst in kaart welk systeem de prijs bepaalt, voordat er nog een tool bijkomt.
Bronnen
Stel je vraag of maak een afspraak, we praten graag persoonlijk verder!
