- Detta ämne har 13 svar, 8 deltagare, och uppdaterades senast för 11 år, 8 månader sedan av
.
-
Inlägg
-
Det här med returer… Att gå igenom en säck med returer måste vara det tråkigaste man kan göra som e-handlare, snäppet värre än bokföring och inventering.
Vi hanterar ca 15 returer/garantiärenden i veckan så det är inte så mycket men medräknat kontakt med kunden, dokumentation och hantering av leverantörsreturen så blir det en hel del tid som läggs på detta. Samtidigt är returhanteringen viktig för kundupplevelsen, inget irriterar en kund så mycket som långsam eller felaktig returhantering. Alltså – vi behöver ett schysst systemstöd för detta som minimerar det administrativa.
Idag hanterar vi alla ärenden i Excel där vi registrerar ordernummer, artnr, serienummer (behövs när vi ska claima leverantören) och typ (garanti eller ångrat köp). Mailen hanteras i en gemensam mailbox i Google Apps och i affärssystemet (Specter) hanterar vi krediteringar och utbytesordrar.
Målet är att slopa Excelfilen och hantera mail och ärenden i ett och samma system. Jag vill ha kontroll på öppna ärenden, statistik på artikelnummernivå och hantering av leverantörsreturer. Jag har tittat på Zendesk och Kayako men de verkar inte ha stöd för detta. Nån som har tips?
Även i stora och dyra affärssystem så är sannerligen inte stödet för returer och reklamationer något att jubla över. Jag vet datagrossister i Sverige med miljardomsättning som gör ungefär som du gör idag, där Excel och manuell koll är det som får det att fungera.
Jag har själv tittat på det där, och en del av komplexiteten är att returer beror på en massa olika saker, och att det som returneras sedan skall behandlas på olika sätt. En del skall tillbaka till leverantören, en del skall kastas, en del skall till hyllan och säljas igen. En skall kanske först kontrolleras om det verkligen är fel. Kunden skall ha pengarna tillbaka, en ny produkt eller en annan produkt. En del returer känner man till, andra bara dyker upp. En del returer är exemplariskt märkta, andra är inte så exemplariskt märka. En del varor som kommer tillbaka är i prima skick, andra varor saknar förpackning, och/eller en del av innehållet.
Nästan oavsett vilket system man än har, så kommer man få lägga tid på returerna, och jag har för länge sedan gett upp mina tankar om att hitta den perfekta lösningen på problemet, utan det handlar mer om att lära av returerna och försöka undvika att de händer igen.
Håller helt med Berra.
Det system som jag anser funkar bra är faktiskt Kodmyrans plattform som hanterar returer på ett helt okej sätt.
Men sen vill man såklart att man ska kunna göra returer i plattformen med återbetalning till t.ex. Payson, Auriga, PayPal, Svea, Klarna osv. Detta finns i andra system men då faller dessa andra plattformar på att dom har ett kasst retursystem:p:rolleyes::o
@Jimmy Öström 50688 wrote:
Men sen vill man såklart att man ska kunna göra returer i plattformen med återbetalning till t.ex. Payson, Auriga, PayPal, Svea, Klarna osv. Detta finns i andra system men då faller dessa andra plattformar på att dom har ett kasst retursystem:p:rolleyes::o
Det borde inte vara så svårt för Kodmyran att implementera. De flesta betalleverantörer har ju fina API:n med funktioner för t.ex krediteringar av returer.
@Joel 50690 wrote:
Det borde inte vara så svårt för Kodmyran att implementera. De flesta betalleverantörer har ju fina API:n med funktioner för t.ex krediteringar av returer.
Det är inte svårt, men det tar mkt tid eftersom vi har lite fler än när man bara har en butik. Sedan ska det ju underhållas också. Finns även ett antal som ej har stöd, då är frågan ska vi stödja de som har eller göra lika för alla? Det finns inget lätt svar på den. Vi kommer troligen framöver att minska stödet för alla omöjliga kombinationer och välja ut de vi vill samarbeta närmare med och integrera mer mot dem och låta andra kopplingar leva vidare men ej utveckla, för underhålla så många som vi gör i dag blir omöjligt till slut. Det händer en del hos våra betalväxlar även om det inte alltid syns utåt.
@Kodmyran 50691 wrote:
Det är inte svårt, men det tar mkt tid eftersom vi har lite fler än när man bara har en butik. Sedan ska det ju underhållas också. Finns även ett antal som ej har stöd, då är frågan ska vi stödja de som har eller göra lika för alla? Det finns inget lätt svar på den. Vi kommer troligen framöver att minska stödet för alla omöjliga kombinationer och välja ut de vi vill samarbeta närmare med och integrera mer mot dem och låta andra kopplingar leva vidare men ej utveckla, för underhålla så många som vi gör i dag blir omöjligt till slut. Det händer en del hos våra betalväxlar även om det inte alltid syns utåt.
Jag förstår att det är jobbigt att bygga stöd för alla men ta de 3 vanligaste så borde det hjälpa rätt många. T.ex Klarna, Svea och Payson.
Ang. förändringar i API:n så är det inte något vi har märkt av faktiskt. Innan vi bytte plattform i våras så körde vi samma API till Klarna och Payer i 2 år utan någon ändring i koden. En bra systemleverantör bör vara bakåtkomptibel med sina API:er
De flesta kortleverantörer har väl inte ens API för detta?
Har payson det?
Vi är fullintegrerade mot Klarna, men allt annat är manuellt arbete vilket är trist.
Kortleverantörerna (PSP) har nog oftast API för refund och cancel, men för andra betalsätt kan det vara lite si och så. När det gäller bankbetalningar så kan det också finnas begränsningar i bankens tjänst som gör att kreditering inte funkar fullt ut.
Man får vara lite försiktig med att automatisera krediteringar, så att man inte råkar kreditera av misstag. Krediteringar går inte att ångra. Det blir bara en massa extra jobb att försöka få kunden att betala sen. Själv kör vi manuella krediteringar än så länge. Det är nog knappt en per vecka, så inte särskilt betungande.
@Dan 50698 wrote:
De flesta kortleverantörer har väl inte ens API för detta?
Har payson det?
Vi är fullintegrerade mot Klarna, men allt annat är manuellt arbete vilket är trist.
Nu kanske jag tog det för givet men Payer som vi kör med har ett API för det i alla fall.
@GregerA 50701 wrote:
Kortleverantörerna (PSP) har nog oftast API för refund och cancel, men för andra betalsätt kan det vara lite si och så. När det gäller bankbetalningar så kan det också finnas begränsningar i bankens tjänst som gör att kreditering inte funkar fullt ut.
Man får vara lite försiktig med att automatisera krediteringar, så att man inte råkar kreditera av misstag. Krediteringar går inte att ångra. Det blir bara en massa extra jobb att försöka få kunden att betala sen. Själv kör vi manuella krediteringar än så länge. Det är nog knappt en per vecka, så inte särskilt betungande.
Det stämmer, direktbetalning går inte att återbetala för oss som kör Payer vilket leder till en hel del merjobb med att lägga in mottagare och återbetalningar direkt hos Swedbank…
Vi har normalt 4-5 återbetalningar per dag (och x 10 så många under högsäsong per dag) så för oss blir det lite betungande tyvärr
@Joel 50693 wrote:
Jag förstår att det är jobbigt att bygga stöd för alla men ta de 3 vanligaste så borde det hjälpa rätt många. T.ex Klarna, Svea och Payson.
Ang. förändringar i API:n så är det inte något vi har märkt av faktiskt. Innan vi bytte plattform i våras så körde vi samma API till Klarna och Payer i 2 år utan någon ändring i koden. En bra systemleverantör bör vara bakåtkomptibel med sina API:er
bör ja, men de är det inte. Klarna tillhör de bra i den kategorin, men långt ifrån alla är det.
Payson tror jag inte har stöd, många betalväxlar har inte stöd för återbetalning av direktbetalningar, och många har inte stöd för retur av del av order, exvis om bara en vara returneras, vilket gör det rätt krångligt.
Men som sagt med tiden spår jag att vi kommer att integrera närmare vissa leverantörer, och låta andra vara som de är, dock är det också rätt svårt att göra på ett schysst sätt, för hur säger du till din kund att tyvärr vi kommer inte att satsa på just den betalleverantör du föredrar.
- Du måste vara inloggad för att svara på detta ämne.