Alles wat u wilt weten voordat u installeert.
Een gedetailleerde blik op hoe DataFirefly Product Return Manager: Productretouren met QR-scan, Analytics en ChatGPT-vertaling voor PrestaShop 8 werkt, waarom we het zo gebouwd hebben en de gedachte achter de bovenstaande functies.
Waarom de native functie tekortschiet
PrestaShop 8 biedt van huis uit alleen het met de hand aanmaken van creditnota's en tegoedbonnen in de backoffice. Meer niet. Geen aanvraag door de klant zelf, geen pdf-etiket, geen validatie bij ontvangst, geen analyse van de retourredenen, geen automatische vertaling, en vooral geen enkel traject voor klanten die als gast hebben besteld. Het gevolg: uw klantenservice zit aan de telefoon om retouren met de hand vast te leggen, uw magazijnmedewerkers controleren met de hand retournummers die op een briefje zijn gekrabbeld, en u hebt geen zicht op wat uw klanten terugsturen of waarom. Bij een winkel met een retourpercentage van 5% en 1.000 bestellingen per maand gaat dat om meerdere mensdagen per maand aan puur invoerwerk.
Het volledige traject, van klant tot analyse
De klant gaat naar zijn account, kiest zijn bestelling en klikt op Retour aanvragen. Hij kiest de producten die hij wil terugsturen en het aantal, kiest een redencategorie (probleem met het product, probleem met de bezorging, van gedachten veranderd) en daarna een specifieke reden (verkeerde maat, kwaliteitsgebrek, levering duurde te lang en zo verder), voegt eventueel een opmerking toe en bevestigt. Meteen daarna krijgt hij per e-mail een pdf-retouretiket met uw adres, het retournummer, de betrokken producten en een unieke QR-code. Komt het pakket binnen, dan scant uw medewerker die QR-code met zijn telefoon en opent er een beveiligde beheerpagina met alle details van het retour. Met één klik keurt hij goed of af, waarmee het volgende in gang wordt gezet: de bestelstatus verandert (met instelbare statussen voor gedeeltelijke of volledige terugbetaling), de tegoedbon of de terugbetaling wordt aangemaakt, de klant krijgt bericht, en de hook actionOrderSlipAdd gaat naar externe modules (Fastmag ERP en andere). Allemaal zonder ook maar iets over te typen.
De QR-code: wat er in het magazijn verandert
Zonder QR-code ontvangt uw magazijnmedewerker een pakket, leest het gekrabbelde retournummer, gaat naar de PrestaShop-backoffice, zoekt het retour op in een lange lijst, opent het en vergelijkt de inhoud met wat er in het pakket zit. Met een QR-code: hij scant, het retour opent meteen, hij keurt goed. De winst zit niet alleen in tijd (van ongeveer 2 minuten naar 10 seconden per retour), maar vooral in het verdwijnen van tikfouten in het retournummer, en daarmee van de gevallen waarin het verkeerde retour wordt goedgekeurd. De validatiepagina is beveiligd (er is een ingelogde beheerder nodig) en het QR-token is per retour uniek, dus onterechte goedkeuring is uitgesloten.
De analyse, het echte verschil
Het dashboard biedt 13 invalshoeken. De algemene kerncijfers: het aantal retouren over de periode, het retourpercentage, de teruggestuurde waarde in euro's en het aandeel tegoedbonnen dat wordt ingewisseld. Per redencategorie: ziet u bijvoorbeeld dat het merendeel van de retouren een productprobleem is, dan weet u waar u moet zoeken. Per reden: blijkt binnen die productproblemen vooral de verkeerde maat te spelen, dan hebt u waarschijnlijk een probleem met uw maattabel. Per product: concentreren enkele referenties een groot deel van de retouren, dan hebt u de miskopen te pakken. Per land: ligt het retourpercentage in één land veel hoger, dan wijst dat op een bezorger in dat land of op een product dat er niet aanslaat. De klanten die het vaakst terugsturen: een kleine groep die een groot deel van de retouren veroorzaakt, en die u kunt bijhouden of uitsluiten. De maandtrend over 12 maanden: een piek na de feestdagen, een dal in de zomer. En de gemiddelde verwerkingstijd: duurt die bij uw klantenservice dagen, dan gaan klanten klagen. Alles is als CSV te exporteren voor verdere analyse of voor uw datawarehouse.
De ChatGPT-koppeling voor de vertaling
U legt uw redenen in het Frans vast, en juist het meertalig maken is doorgaans het punt waar het contentteam een dag of twee op blijft hangen. De module automatiseert dat via OpenAI: u levert uw ChatGPT-sleutel aan, klikt op Vertalen, en binnen enkele seconden staan uw redenen in EN, ES, IT, PT en DE (en in alle andere actieve talen), met woordkeuze die bij e-commerce past. U kunt elke vertaling daarna nalezen en aanpassen. Voegt u een nieuwe reden toe, dan volstaat dezelfde klik. Bij een winkel met 6 talen en 30 redenen scheelt dat 180 vertalingen, ofwel ongeveer een tot twee mensdagen.
De koppeling met Fastmag ERP
Gebruikt u Fastmag (of een ander ERP), dan is het synchroniseren van retouren doorgaans een wrijvingspunt: het retour wordt in PrestaShop vastgelegd en daarna met de hand opnieuw in het ERP ingevoerd. De module vuurt bij elk goedgekeurd retour de hook actionOrderSlipAdd af, die door de Fastmag-module van DataFirefly (of door elke andere module die naar die hook luistert) wordt opgepikt. Zo krijgt u synchronisatie in real time. Met de knop om eerdere retouren opnieuw te synchroniseren kunt u de hook bovendien alsnog afvuren op retouren uit het verleden, handig als Fastmag pas na deze module is geïnstalleerd of als de synchronisatie is weggevallen.
Typische gebruikssituaties
Mode en textiel: retourpercentages die vaak op 15% of hoger liggen, met de verkeerde maat als voornaamste reden, waarbij de module laat zien bij welke producten de maattabel moet worden bijgesteld. Consumentenelektronica: een gematigd retourpercentage maar hoge bedragen, waarbij de QR-code kostbare validatiefouten uitsluit en de analyse per leverancier de merken met twijfelachtige kwaliteit aanwijst. Cosmetica: een laag retourpercentage maar een wettelijk verplichte afhandeling, waarbij de module de naleving regelt zonder de klantenservice te overbelasten. Zakelijke verkoop: zeldzame retouren maar grote bedragen, waarbij de tegoedbon de klant bindt en het officiële pdf-etiket de boekhouding van de klant vergemakkelijkt.
Nieuw in 1.6: het handmatige retour door de beheerder
De module is nu ook bruikbaar als coulance-instrument voor de klantenservice. In de kop van de retourlijst in de backoffice verschijnt een knop om een handmatig retour aan te maken. De werkwijze verloopt in twee schermen: eerst vult u de referentie of het ID van de bestelling in, daarna vinkt u de producten aan die worden teruggestuurd, met hun aantallen, hun reden, het soort terugbetaling (tegoedbon of creditnota) en een per regel aanpasbaar terugbetaalbedrag. De ingestelde retourtermijn (DF_RETURN_DAYS) en het filter op bestelstatussen worden volledig genegeerd, dus de beheerder kan ook een retour aanmaken voor een bestelling uit 2022, of voor een geannuleerde bestelling of een concept. Bij bevestiging wordt het retour meteen verwerkt: de tegoedbon of creditnota wordt ter plekke aangemaakt, de voorraad wordt teruggeboekt, de bestelstatus wordt bijgewerkt en de Fastmag-hook wordt afgevuurd. Met een vakje om de klant te melden (standaard uit) stuurt u zo nodig alsnog de gewone bevestigingsmail.
Het per regel aanpasbare terugbetaalbedrag (1.7)
Bij het handmatige retour door de beheerder heeft elke productregel nu een bewerkbaar veld voor het terugbetaalbedrag. De standaardwaarde is de stukprijs maal het aantal, en een script berekent die standaard automatisch opnieuw wanneer het aantal verandert, tot het moment dat de beheerder zelf een bedrag invult, waarna zijn waarde wordt gerespecteerd. De evenredige kortingsverhouding van de bestelling, die bij gewone klantretouren automatisch wordt toegepast om de werkelijk betaalde prijs te weerspiegelen, wordt bij handmatige retouren uitgeschakeld: het ingevoerde bedrag is precies wat er wordt terugbetaald, niet meer en niet minder. Juist daardoor is de functie bruikbaar voor gedeeltelijke terugbetalingen (bijvoorbeeld een beschadigd product dat voor de helft wordt vergoed), voor coulanceregelingen en voor correcties met terugwerkende kracht. De aangemaakte creditnota houdt de verdeling tussen bedrag exclusief en inclusief btw evenredig aan het btw-tarief van de oorspronkelijke regel.
Nieuw in 1.7: het traject voor gasten
Klanten die als gast hebben besteld (dus zonder een account aan te maken) komen nu via dezelfde URL bij de retouren als ingelogde klanten. Belandt een niet-ingelogde bezoeker op de retourpagina, dan toont de module een formulier voor het bestelnummer en het e-mailadres in plaats van de pagina Mijn bestellingen. De controle gebeurt aan serverzijde: de combinatie van referentie en e-mailadres moet precies overeenkomen met een bestaande bestelling (waarbij het e-mailadres hoofdletterongevoelig wordt vergeleken). Mislukt dat, dan is de foutmelding bewust algemeen gehouden (geen bestelling gevonden bij deze referentie en dit e-mailadres), zodat niet valt af te leiden welke referenties in de database bestaan, als bescherming tegen aftasten. Is de controle geslaagd, dan worden het bestel-ID en het klant-ID in de PrestaShop-sessiecookie bewaard en komt de bezoeker in het gewone retourproces terecht, alleen voor die ene bestelling. Het pdf-etiket wordt normaal aangemaakt en blijft zonder inloggen bereikbaar via de link in de e-mail, beveiligd met een willekeurig token van 64 tekens dat per retour uniek is. Met een balk om een andere bestelling te kiezen kan de bezoeker zijn sessie terugzetten en naar een andere bestelling overstappen.
Er zijn nog geen beoordelingen.