Retouren verwerken automatiseren: de 14-dagenklok

Een retour lijkt één handeling, maar bestaat uit een rij losse stappen die elk apart mis kunnen gaan: de klant meldt de retour (vaak via een formulier of los e-mailadres), er wordt een retourlabel aangemaakt, het pakket komt terug op het magazijn, iemand controleert of het product compleet en onbeschadigd is, de voorraad wordt bijgewerkt, en pas dan volgt de terugbetaling.

Bij een paar retouren per week doe je dat met een schriftje en een Excel-tabblad. Bij enkele tientallen per week raakt dat handmatige traject zoek: een retour die een week blijft liggen op het magazijn omdat niemand hem heeft afgemeld bij de klantenservice, een terugbetaling die twee keer wordt gedaan omdat twee medewerkers hem allebei hebben verwerkt, of een product dat terug de voorraad in gaat zonder dat het systeem dat ooit heeft geregistreerd.

Automatiseren betekent hier vooral: één retourmelding die automatisch een label genereert, een status bijhoudt (aangemeld, onderweg, ontvangen, gecontroleerd, terugbetaald) en die status koppelt aan zowel de boekhouding als de voorraad. Het gaat niet om het wegnemen van de controle op het product zelf — dat blijft mensenwerk — maar om het wegnemen van de administratieve stappen ertussen.

Bij een retour van een consumentenaankoop geldt het herroepingsrecht: de klant mag binnen 14 dagen na ontvangst van het product de aankoop ongedaan maken. Voor jou als webwinkel is vooral de terugbetalingstermijn die daarna volgt relevant. Volgens de Autoriteit Consument & Markt (ACM) moet de consument zijn geld terug krijgen binnen 14 dagen na ontvangst van de retourzending — je mag als webwinkel dus wachten met terugbetalen tot het product daadwerkelijk bij je binnen is.

Dat is precies waar een geautomatiseerd proces winst oplevert, maar ook waar het risico zit. De klok gaat lopen op het moment van ontvangst, niet op het moment van melden. Als je retourproces niet automatisch vastlegt wanneer een pakket is binnengekomen — bijvoorbeeld omdat scanning op het magazijn en registratie in de boekhouding twee losse stappen zijn die niet gelijk lopen — dan weet niemand meer zeker of dag 1 van de termijn drie dagen geleden begon of vandaag.

Een gemiste termijn is geen theoretisch risico: consumenten kunnen een melding doen bij ACM Consuwijzer, en bij herhaalde klachten over te late terugbetaling grijpt de ACM in. Zorg dus dat het moment van ontvangst, niet het moment van verwerken, de teller start.

Bron: ACM, over de terugbetaaltermijn aan consumenten.

De meeste problemen met retouren ontstaan niet bij het terugbetalen zelf, maar bij de voorraad erna. Een teruggestuurd product moet pas weer verkoopbaar zijn zodra iemand het heeft gecontroleerd op schade of volledigheid — automatisch de voorraad verhogen zodra een pakket wordt gescand bij binnenkomst, zonder die controleslag, leidt tot verkoop van producten die eigenlijk niet meer compleet zijn.

Het omgekeerde probleem komt net zo vaak voor: de controle gebeurt wel, maar de voorraadmutatie verdwijnt in de wachtrij omdat niemand tijd heeft om het los in te boeken. Het resultaat is een voorraadstand die structureel lager is dan de werkelijkheid, met als gevolg dat je onterecht nee verkoopt aan nieuwe klanten of onnodig bijbestelt.

Een werkende koppeling behandelt de voorraadmutatie als onderdeel van dezelfde statusovergang die ook de terugbetaling triggert: zodra een retour de status "gecontroleerd, akkoord" krijgt, lopen voorraad en terugbetaling tegelijk mee, uit hetzelfde systeem. Twee losse acties door twee verschillende mensen in twee verschillende systemen is de situatie waarin dit stuk loopt, hoe goed de losse onderdelen ook zijn.

Een klant die drie producten bestelt en er één terugstuurt, is lastiger te automatiseren dan een volledige retour. De terugbetaling moet een creditnota opleveren die precies het teruggestuurde product en het bijbehorende btw-bedrag dekt, niet de hele oorspronkelijke factuur. Een sjabloon dat standaard het volledige factuurbedrag crediteert, corrigeert zichzelf niet — dat moet iemand of iets actief uitrekenen op basis van wat er werkelijk is teruggekomen.

Daar komt bij dat verzendkosten bij een deelretour niet automatisch volledig meetellen: als de klant het grootste deel van de bestelling houdt, is het gangbaar dat de oorspronkelijke verzendkosten niet (volledig) worden terugbetaald, omdat die kosten ook zonder het retourartikel gemaakt zouden zijn. Een automatisch proces dat domweg een vast percentage terugrekent zonder naar de samenstelling van de bestelling te kijken, betaalt dus structureel te veel of te weinig terug.

De creditnota die hieruit volgt, moet bovendien gewoon in je doorlopende factuurnummering passen — een creditnota is voor de administratie een factuur met een negatief bedrag, geen apart document buiten de reeks. Richt je automatisering daarom in op het niveau van de productregel, niet op het niveau van de hele bestelling.

Bij een handvol retouren per week is een gekoppeld systeem vaak meer werk om in te richten dan het oplevert. Het uitzoeken welke statussen je nodig hebt, hoe de koppeling met de boekhouding werkt en hoe je omgaat met uitzonderingen (beschadigde producten, deelretouren, producten die buiten het herroepingsrecht vallen) kost tijd die je bij een laag aantal retouren sneller terugverdient door het gewoon handmatig te blijven doen, met een vast wekelijks moment waarop iemand alle openstaande retouren naloopt.

De knop om op te letten is niet het aantal retouren op zich, maar het moment waarop je de 14-dagentermijn begint te missen of waarop voorraadfouten leiden tot nee-verkopen aan klanten. Zodra dat structureel gebeurt — niet incidenteel, maar elke week een paar keer — is de handmatige aanpak niet meer de bottleneck die je kunt negeren, en is een koppeling tussen retourmelding, voorraad en boekhouding de stap die het probleem daadwerkelijk wegneemt in plaats van het te verschuiven naar een andere medewerker.