RoPa Workwear
Eén systeem voor RoPa Workwear, met het kledingbeheer in de kern
RoPa Workwear levert werkkleding aan bedrijven. De oude winkel draaide op WooCommerce met zeven losse plugins, waarbij elke wijziging er drie andere raakte. Het werd één applicatie, waarin het kledingbeheer van de zakelijke klant niet eromheen zit maar erin.
Over RoPa Workwear
RoPa Workwear levert werkkleding aan bedrijven. De catalogus telt circa 4.400 producten uit de leveranciersfeed, en het bedrukken en borduren gebeurt in eigen huis. Klanten zijn zelden één inkoper: het zijn bedrijven waar iedere medewerker iets nodig heeft.
De bouw deed CRM Force samen met Next Win. Next Win zit in het maatwerk en de webshops, CRM Force in de inrichting van het klant- en orderproces. Voor de klant is dat één team in plaats van twee leveranciers die naar elkaar wijzen.
De uitdaging
Wat RoPa nodig had bestond niet kant en klaar, dus was het er in de loop van de jaren omheen gebouwd: een plugin voor de productimport, een voor de branding, een voor het klantportaal, een voor de totaalpakketten. Uiteindelijk waren het er zeven. Elk stuk deed zijn werk, maar wie een categorie wilde aanpassen moest op vier plekken kijken.
Juist het deel dat een zakelijke klant nodig heeft, was het deel dat nergens kant en klaar te krijgen was. Kledingbudget per medewerker, maten die per persoon vastliggen, een aanvraag die langs de manager gaat, en een logo dat op de rug anders is dan op de borst. Dat zijn geen instellingen in een webshop.
Waarom het geen pakket werd
Het vertrekpunt wás een pakket. WooCommerce met plugins erbij is de gebruikelijke route, en die is jarenlang gevolgd. Elke nieuwe wens werd een stuk software erbij, en elk stuk moest iets weten wat een ander stuk ook al wist.
Het kledingbeheer is precies wat geen pakket meelevert. Budgetten, medewerkers, maten en goedkeuringen zijn in elk pakket maatwerk bovenop de licenties, en ze raken het bestelproces zelf. Een CRM op maat begint bij dat proces in plaats van het er achteraf omheen te vouwen.
De rekensom liep daardoor de andere kant op dan je verwacht. Doorbouwen werd duurder dan opnieuw beginnen, omdat elke aanpassing drie andere plugins raakte. Een maatwerk CRM met de webshop eraan vast was goedkoper dan nog een plugin erbij.
Lees hoe we die afweging makenDe aanpak
De winkel en het kledingmanagementsysteem zijn één applicatie. Klanten, medewerkers, bestellingen en alle uitgaande mail zitten in dezelfde database, zodat een bestelling van een medewerker gewoon een bestelling is en geen aparte stroom.
Het budget wordt geboekt bij de betaling en niet bij de goedkeuring. Tussen goedkeuren en afrekenen kan een bestelling nog veranderen, en twee boekmomenten tellen vroeg of laat dubbel.
Een kijkje in het systeem
Wat is er gebouwd?
De onderdelen die het systeem dragen:
Kledingbudget per medewerker
Elke medewerker heeft een jaarbudget. De manager ziet per persoon wat er is toegekend, wat er is besteed en wat er nog over is, zonder dat daar een spreadsheet naast loopt.
Medewerkers, maten en een eigen portaal
Shirt, broek, schoen en jas liggen per persoon vast. Medewerkers bestellen in een eigen omgeving binnen hun budget en komen niet bij de rest van het account.
Aanvraag langs de manager
Wat buiten het budget valt, gaat als aanvraag naar de manager in plaats van naar de mailbox. De bedragen worden op de server opnieuw berekend, zodat een aangepaste prijs in de browser nooit het beeld bepaalt waarop iemand akkoord geeft.
Branding met een eigen logobibliotheek
Per locatie op het kledingstuk een ander logo uit de bibliotheek die het bedrijf zelf heeft aangeleverd, met de prijs die meteen meerekent. Wat er geborduurd wordt, gaat eerst als digitaal voorbeeld naar de klant.
Klant informeren per bestelling
Tussen betaald en onderweg zitten vaak weken inkoop en borduurwerk. Vanaf de orderpagina gaat er een passende update naar de klant, met de mail live naast het formulier. Handmatig, want het moment waarop iemand iets wil horen valt zelden samen met een statuswijziging.
Automatische mails en mailings
Elke mail die het systeem verstuurt staat in één overzicht met een preview uit dezelfde renderfunctie als de echte verzending. Mailings gaan naar klanten die per stuk zijn aangevinkt, in golven, na een testmail.
Facturen naar de boekhouding
Elke betaalde bestelling stuurt de verkoopfactuur door naar het boekhoudpakket. De koppeling faalt nooit hard: een boekhouding mag een bestelling niet blokkeren.
Het resultaat
Wat er in de praktijk veranderde:
- Zeven losse plugins werden één systeem, dus een wijziging zit op één plek
- Een medewerker bestelt binnen het eigen budget; wat erbuiten valt gaat naar de manager
- Maten staan per persoon vast, dus een borduuropdracht is te herleiden naar wie hem draagt
- Tussen betaald en onderweg houdt RoPa de klant zelf op de hoogte, met de mail zichtbaar naast het formulier
- Een ontvanger kan dezelfde mailing niet twee keer krijgen; dat ligt vast in de database
- Circa 4.400 producten komen uit de leveranciersfeed en worden elke nacht bijgewerkt
Waarom CRM Force
Waar deze case laat zien hoe wij werken:
- Het zakelijke proces in de kern van de applicatie, niet als uitbreiding erop
- Bedragen worden op de server berekend, nooit overgenomen uit de browser
- Eén boekmoment voor een budget, want twee tellen vroeg of laat dubbel
- Een mail die niet te automatiseren valt, blijft een knop; raden is geen oplossing
- Gebouwd op Next.js, Supabase en Vercel, samen met Next Win
Ook een proces dat niet in een pakket past?
We kijken eerst naar wat er staat en zetten de kosten van doorbouwen naast die van opnieuw beginnen. Is doorbouwen verstandiger, dan zeggen we dat.