Vi har sedan en tid testat att använda automatiska rekommendationer för att tipsa besökare om andra relevanta produkter utifrån hur andra navigerat runt i butiken. Vi har valt att jobba med tre ytor och vet att det skulle gå att använda ännu fler rekommendationer, men vill ändå få en uppfattning av hur bra det fungerar.

För testerna används tjänsten nosto.com som är en tjänst som är helt molnbaserad och som tar del av informationen om hur folk rör sig p åsidorna från produktsidor, kategorisidor, kassan och varukorgen. Med data från dessa olika sidor skapas rekommendationer som passar och vi har valt att jobba med ytor för:

• Mest populära produkter på startsidan
• Mest populära i kategori
• Andra liknande produkter

Efter att ha kört några veckor visar det sig att de absolut mest effektiva ytorna är via produktsidan för att hitta andra liknande produkter. Det är också här som vi når mest ökad försäljning. Kategoriytan kommer därefter och rekommendationerna på startsidan har nästan ingen effekt alls, kanske för att den är placerad för långt ner.

Vi har testat att placera ytan med relaterade produkter under den långa beskrivningstexten, alltså måste man scrolla ganska långt ner för att hitta rekommendationer. Ändå ser vi en stor andel som klickar sig vidare och många gånger också köper produkten de klickat på via en rekommendation.

Testerna utförs under lågsäsong under sommaren. Det gör att trafikmängden är mycket mindre än i normalfallet. Vi får inte säkert liknande resultat när det är mer snurr i butiken, men det är ändå uppenbart att folk köper baserat på rekommendationer.

Nosto som rekommendationsmotor

Vi använder Kodmyrans Shop4Sale som e-handelslösning och den var mycket smidigt att integrera mot Nostos molnbaserade rekommendationer. Integrationen när vi skrev den från grunden tog några timmar och vi var igång live med rekommendationer fullt ut när tillräckligt mycket data samlats in för att börja lämna rekommendationer.

Hos Nosto betalar man inga fasta avgifter. Man betalar bara en avgift för den försäljning som uppstår till följd av rekommendationerna. Det gör att det mer eller mindre är riskfritt att testa och när man väl testat skulle det vara svårt att vara utan. Med tanke på den merförsäljning som uppstår är det prissatt så att det absolut är värt kostnaden då de beställningar vi fått via Nosto innehållit andra eller fler produkter än vi vanligtvis säljer.

Tekniken har fungerat mycket smidigt. Prestandan är god och rekommendationerna håller en hög kvalité trots att de inte har detaljkännedom om vårt sortiment.

Gränssnittet för att administrera och sätta upp på vilket sätt rekommendationer ska visas har också varit lätt att komma igång med.

Den nackdel som jag ser är att det blir så många förfrågningar externt mot en extern källa, vilket ändå i slutänden påverkar prestanda samt att mina användare skickar ut data till en extern tjänst för att få bra statistik.

Jag kan baserat på ovanstående rekommendera Nosto för den som vill testa rekommendationer.

När man ska flytta data från en nätbutik till en annan kommer man ställas inför några utmaningar på vägen. Vad man ska göra och hur man gör det beror på vilket stöd som finns i lösningen man ska flytta från och lösningen man ska flytta till. I vårt fall med Kodmyran som målplattform fanns det stora möjligheter att importera allt vi kunde behöva och så här gjorde vi upp planen för migreringen av data.

Kategorier

Basstrukturen i nätbutiken är dess kategoristruktur. Här hade vi möjligheten att importera dessa automatiskt, men då vi bara hade 130 stycken valde vi att migrera dem helt manuellt. I den nya butiken erbjuds vi möjlighet att jobba med HTML för kategoribeskrivningarna vilket gjorde att vi ändå ville gå igenom dem manuellt för att se vilka delar som skulle formatteras. Det handlade dessutom bara om en par timmars jobb att flytta över informationen.

Tack vare att man styr adressen själv på hur kategorin ska exponeras använde vi precis samma URL på kategorierna som de haft i Prestashop vilket gör att vi inte hade behov av att göra några redirects.

Vi förde en logg över de gamla identiteterna i Prestashop mot de nya i Kodmyran för att vid ett senare tillfälle kunna knyta produkter till rätt kategori.

Produkter

Produkterna tillhör kärnan av det man säljer och det är viktigt att få med så bra information som möjligt. Vi skapade därför en egen exportrutin till Prestashop som exporterade i ett format som man direkt kan importera i Kodmyrans lösning. Här byggde vi en enkel CSV-export där produktdata för det som skulle konverteras fanns med. I detta steg exporteras inte produkternas attribut.

Exporten kördes sedan flera gånger där vi vid varje körning tog in fler kolumner i importen bara för att verifiera att allt fungerade bra och att allt hamnade på rätt plats. För att inte riskera att förstöra något i den “skarpa” butiken hade vi under en period kvar en demobutik att testa importera data i. Mycket användbart och smidigt för att inte råka göra fel.

Hemmakategori i Prestashop importerades via denna fil mot en kategori i den nya butiken. Här använde vi mappningstabellen från steget innan för att koppla produkten mot det nya kategori-idt.

Det knepigaste var att lyckas med att få ut HTML på rätt sätt så att den långa beskrivningen kunde importeras utan problem. På det korta beskrivningsfältet skulle vi dessutom gå från HTML till ren text. Här uppstod en del fel med vissa tecken och vi har manuellt jobbat på att rensa bort frågetecken som uppkommit i vissa texter.

När väl importen var på plats pausade vi allt utom akuta uppdateringar av produktdata för återstoden av konverteringstiden för att inte behöva underhålla data i flera system. Det var lite trist då vi hade en hel del nyheter som bara låg och väntade på att läggas ut till försäljning.

Bilder

I Prestashop ligger bilderna kopplat mot de produkter de tillhör. Dessa bilder följer dock en logik där de hamnar under img/p och sedan heter produktnummer, ett minustecken och sedan ett löpnummer. Vi exporterade dessa bilder via exportrutinen så det skulle gå att koppla på bilden mot en relativ sökväg då man i Kodmyran jobbar med filer.

Bilderna exporteras i en struktur efter varumärke/ps/produktnamn-artikelnummer.jpg så att det skulle vara enkelt att koppla upp bilden vid importtillfället. Vi hade självklart här kunnat använda bilderna i originalformat som vi lagrat dem, men för att inte riskera att göra några fel med vilken bild som är kopplad till produkterna så ansåg vi att Prestashop hade bäst data.

Exporten av bilder från Prestashop gjordes enligt följande:

1. Exportera data i CSV-formatet.
2. Öppna CSV-filen och skapa en formel i Excel för att köra “wget” på filerna så de kan laddas ner via en scriptfil.
3. Kör scriptfilen och ladda ner bilderna i originalstorlek.
4. Använd Irfanview för att tillverkare för tillverkare skala ner bilderna till 1000×1000 pixlar som maximal storlek.
5. Ladda upp filerna till bildstrukturen hos Kodmyran.

Därefter körde vi kopplingar genom import av CSV-filen med produktdata. Man kan importera kopplingar mot flera bilder samtidigt, men vi gjorde dessa kopplingar manuellt då det bara var 30 produkter som hade fler än en bild.

Den externa adressen för nästan alla produkter kunde vi behålla från Prestashop. Adresserna i Prestashop innehåller däremot EAN-koden, vilket skapar rätt långa adresser. På ett 20-tal blev adressen för lång och vi fick skapa 301-redirect för dessa specifika. Vilka som hade för lång adress räknade vi enkelt ut via en längd-formel i Excel och kunde då också generera .htaccess-rader för dessa specifika redirect.

Bloggar och texter

Här saknades det enkla importverktyg för att läsa in data på ett enkelt sätt. Därför beslutade vi även här att köra copy-paste-metoden. Det handlade om cirka 80 blogginlägg och 10 textsidor. Det var också bara frågan om en par timmars jobb, så här körde vi copy-paste och hade fixat det på några kvällar.

Det som fick hanteras manuellt här var bilder kopplade mot bloggtexter och informationstextern. Vi laddade ner dessa via en plugin till webbläsaren och laddade sedan upp den i nya butiken i en alternativ struktur med bilder i målformatet direkt. Därefter fick vi gå in på varje inlägg och koppla upp rätt bild.

Här vet vi om att det uppstått en del fel på både bilder och länkar, men prioriteringen har varit att de viktigaste texterna (ordervillkor, om oss etc) och mest besökta bloggposterna var korrekta.

Adresserna på bloggposterna fick bli desamma som tidigare.

Det som inte var klockrent att migrera var bloggkategorier och en förstasida för bloggen, då både kategoriverktyg och taggning saknades. Här blev det en halvmanuell sida där man kan lyfta fram blogginlägg att visa upp och en lista över samtliga blogginlägg längre ner som en rak lista. Inte helt optimalt, men det får rättas längre fram.

För bloggen saknades funktionalitet för att koppla produkter till blogginlägg, men detta kunde med lite klurande och några rader programkod i mallen implementeras av oss själva. Mycket smidigt!

Kopplingar mellan kategori och produkt

Vi har några olika alternativa strukturer för att navigera fram till samma produkt från några olika vyer. Dessutom har vi kategorier för toppsäljare och fyndhörnan som behövde fyllas med data.

Här gjorde vi en enkel SQL där vi exportera produktnummer och kategori-id för alla kategorier där produkten ingår. Kategori-id var den nya butikens identitet och en enkel excelformel användes för att översätta från gamla identiteter till nya via mappningstabellen från kategoriskaparsteget.

Kunder

Att importera kunder var något vi gjorde natten innan det var dags att gå live med den nya butiken. Från Prestashop kombinerade vi exporten av kunddata som kundregister och adressregister med den senast skapade leveransadressen.  Flagga med prenumeration på nyhetsbrev ingick också i exporten.

Order och orderrader

Dessa går också att importera i den nya lösningen, men det har vi ännu inte konverterat. Hade tänkt göra det och vi får se om det blir gjort, eller om orderhistoriken helt enkelt får ligga kvar i det gamla systemet.

Hur gick det då?

All form av migrering är klurigt att lyckas bra med. Vi lyckades väl inte perfekt, men det gick på det hela sett fantastiskt smidigt att migrera till Kodmyran. Det märks verkligen att de jobbat med att göra det smidigt. För dem som kanske inte har en lika stor verktyglåda som jag att klippa och klistra ihop kod med, har de några paket där de hjälper till att flytta data.

Nästa avsnitt

I nästa avsnitt tänkte jag berätta lite kring hur vi tänkte med mallarna för butiken och varför vi valde att inte gå all-in med en professionell design. Stay tuned!

…efter en hel del utvärderande, funderande och verifiering mot kravspecifikationen blev den lösning vi fastnade för allra mest lösningen från Kodmyran. Länge stod vi och vände och vred de olika alternativen mot varandra och de alternativ vi in i det sista stod mellan var:

• Att köra vidare med open source och gå in med Magento.
• Att investera tid och kraft i att uppgradera vår Prestashop mot senaste versionen
• Att välja Wikinggruppen för att man får en lösning som tilltalar plånboken och det ingår en professionell design
• Att välja den lösning från Kodmyran som är vi under utvärderingen fastnade för då den förutom alla butiksfunktioner även har ett bra stöd för inköpshantering

Varför gillade vi då Kodmyrans lösning bäst?

Det kanske tyngsta argumentet är att den kändes rätt från början. Magkänslan är viktig för hur väl man kommer trivas med lösningen och med en god ingångskänsla finns bra förutsättningar för att lyckas väl i genomförandet av projektet.

Det som också väger otroligt tungt är svaren från supporten. Vi testade som jag skrev i tidigare inlägg att skicka frågor till supporten. Av Kodmyran fick vi alltid förstklassiga svar som innehöll mycket erfarenhet och med en känsla av att de kom med motförslag om de frågor jag skickade hade en erfarenhetsmässigt bättre implementationsteknik.

På backendsidan för den som ska hantera sin butik fanns det några saker som utmärkte sig:

• Import och export av data är enormt smidigt. Exportera – efterbehandla – importera. Supersnyggt!
• Flera olika textfält för att beskriva sina produkter. Vi kan t.ex. automatisera produktspecifikationerna via vår masterkatalog för artikelregistret där alla egenskaper redan finns.
• Enkelt att skapa nya produkter. Bara några fåtal obligatoriska fält och så är man igång. Fylla på senare.
• Flödet för att packa och skicka är mycket bra. Integrationen med Klarna funkar finfint för aktivering av fakturor.
• SEO-taggning tydlig och möjlig att fylla på med standardvärden om man inte fyllt i något.
• Bra möjlighet att ha massvis med information i butiken med olika paneler som kan användas som information om t.ex. specifika typer av produkter.
• Snygga och prydliga utskrifter.
• Ekonomisk rapportering med dagsavslut och all information som behövs för att bokföra.
• Enkelt att sälja på Fyndiq och Tradera direkt i gränssnittet utan att riskera att man har fel lagersaldo någonstans.
• Att vi kommer kunna behålla samma adresser till nästan alla sidor och därmed inte tar lika stor risk som om vi fått bygga redirects på att sidorna flyttat.

På frontendsidan finns det också några saker vi gillar:

• Mallhanteringen är enkel att jobba med för den som är van att jobba med en butiksplattform. Ingen editor som döljer inställningar utan äkta HTML-mallar. Man kan ha flera parallella mallar och alltså arbeta fram den kommande designen helt utan att störa det som rullar i drift.
• Smidigt flöde för betalningar. Här har man också själv möjlighet att bygga en riktigt bra kassa, något vi kommer titta på men ej fixa absolut från början.
• Hastigheten. Butikerna är snabba och smidiga.
• Möjligheter att direkt hantera nyheter, kategorier, varumärken, bästsäljare, relaterade produkter, tillbehör och sådant som andra köpte.

För programmeraren och den som ska integrera gillar vi:

• Att det finns ett API som innehåller det mesta man kan behöva för att integrera övriga applikationer med nätbutiken.
• Att det finns bra funktioner att ta ut XML-filer direkt i webbgränssnittet som kan laddas in i andra system.
• Att man själv kan påverka hur mallarna fungerar och inte är styrd exakt efter hur det ser ut i standardmallarna.

Vad var det som inte var lika bra?

Allt är givetvis inte alltid bra med en lösning. Hade vi funnit en lösning som inte hade några brister hade vi ju inte behövt tveka. Därför tänkte jag också presentera några av de saker som andra leverantörer hade bättre möjligheter till.

• Att design inte ingår. Här får man möjligheter genom att köpa ett färdigt tema till en opensourcelösning eller välja en leverantör som innehåller en del designarbete och detta var ett av de områden där andra var starkare. Man får dock med ett helt gäng olika standardmallar att utgå ifrån när man bygger sin egen lösning hos Kodmyran.
• Vi har vant oss vid ganska standardiserade funktioner för sökning och filtrering av produkter via kategoriträd. Hos Kodmyran får man enklare träfflistor där man vid avancerad sökning får artikelnummer, benämning, lagersaldo och pris. När man jobbar med nya produkter är det aldrig fel med en bild.
• Bildhanteringen känns lite begränsande i och med att man får lägga upp koppling mot bilder en och en i gränssnittet där det krånglar en del med katalogstrukturer och förhandsgranskning. Finns dock goda möjligheter att köra in dessa via import i stället.
• Att sökningen inte hanterar sökning under tiden man skriver med Ajax som är standard för de flesta andra lösningar.
• Att vissa funktioner kräver enterpriseversionen och att det då gärna drar iväg i kostnad. Nu beslutade vi oss för att köra utan attributhanteringen och sköta detta via specifikationsfältet och genom att bygga alternativa kategoristrukturer.

Implementationstiden

Då vi som alltid är sent ute och är mitt inne i vår del av året när försäljningen är rätt starkt så är det en jättestor risk att byta nätbutik mitt uppe i pågående försäljning. Planen var då att innan den 15:e november vara igång med den nya nätbutiken och alltså klarar implementationen på motsvarande 45 dagar. För den som inte gjort ett IT-projekt kan man tycka att detta låter som eoner av tid, men för den som varit inblandad i ett liknande projekt vet att det är en mycket kort projekttid.

I verkligheten så driftsatte vi butiken den 4:e november, alltså 10 dagar före tidplan och det är bloggen som inte hunnit bli skriven i takt med projektet.

Nästa avsnitt

I nästa avsnitt kommer jag att skriva hur vi tänkte med att flytta över informationen från vår Prestashop till Kodmyran och vilka val som gjordes kring automatisk eller manuell hantering.

Att styra sin teknik är att ha kontroll. Det är också att ha ett ansvar för att se till att hålla sin programvara uppdaterad och fräsch. Man ska gärna hänga med trender och då och då införa nya funktioner som gör det smidigare för besökarna att bli till kunder. Handlaren ska dessutom fokusera på att sälja mer och ta hand om de besökare som väljer att bli kunder. Detta på sin fritid som ska delas med familjen.

När projektet med att driva näthandel börjar ta lite fart på allvar handlar det inte längre om att sitta vid e-posten och vänta på att det ska plinga in ett mail med uppgifter om att en order ska packas. Det kan faktiskt innebära en hel del arbete att ta hand om de som väljer att bli kunder och handla av butiken. Alla de där fina orden man skrev när det trillade in någon order per vecka och det inte var ett problem att det tog 15-20 minuter att göra i ordning ett enda paket. När saker börjar rulla är det inte riktigt lika enkelt att låta en order ta 20 minuter att behandla om man dessutom ska hinna utveckla butiken på sin dyrbara fritid.

Det har skrivits många kloka ord kring att vara näthandlare inte handlar om att vara tekniker med förmågan att bemästra tekniken. Det handlar i stället om att vara bäst på de produkter man säljer och bäst på att sälja just dessa produkter. Jag är inte e-handlare generellt bara, jag är lamphandlare. För att bli bäst på att sälja lampor måste jag fokusera just på hur man säljer lampor på bästa sätt.

Förlorar försäljning på grund av teknik

Vi har under en period slitit med många köp som misslyckats via t.ex. Klarna där vi vet att det beror på ett fel i integrationen i den tilläggsmodul till Prestashop som gör det möjligt att handla med Klarna. Det går att fixa felet – jag har till och med ganska noga felsökt just vad som gått fel – men tiden för att rätta till det finns inte. Det är dessutom så att flödet för de olika betallösningarna inte riktigt är så smidigt som det skulle kunna vara.

Det handlar också om trovärdighet. Kunder handlar gärna av en butik där tekniken fungerar.  Vi vill att våra kunder ska känna sig trygga med att det går att betala på ett säkert sätt. Om vi inte tar tag i problemen kanske man inte anser att det är ok att behöva betala med kort för att det krånglar med betalning via faktura?

Ta del av andras erfarenhet

Väljer man att jobba med Prestashop, Magento, Opencart eller någon av de andra lösningarna för att driva sin nätbutik via Open Source får man ta del av utvecklingen av plattformarna. Det är lösningar med hundratals eller tusentals tillägg som enkelt kan installeras för att forma butiken precis hur som helst. Har man tid och kunskap är det nog perfekt att bygga ihop en lösning baserat på dessa tillägg. Funkar fint ända fram till det är dags att uppgradera och tilläggen visar sig vara i osynk.

Man kan också välja en enklare väg. Välja en lösning där man inte helt säkert får tillgång till alla möjliga sätt att göra saker på utan blir styrd in i ett mer kontrollerat sätt. Ett sätt som är anpassat till den marknad man verkar på och där kunderna känner igen sättet att presentera produkter på, genomföra köp och hur man följer sin order tills den når brevlådan. Här finns det ett flertal leverantörer och vi har tittat på ett urval av dem via demobutiker och referenser.

• Nordisk e-handel
• Textalk
• Talex
• Kodmyran
• Wikinggruppen
• Askås
• C4Media
• Jetshop

Det man slås av är hur tillräckligt de flesta lösningar verkar kunna presentera upplevelsen för besökaren. Man kan skapa sin unika design idag och var och en av dem har riktigt fina referenser. Flera butiker har lyckats riktigt bra på vägen med respektive plattform.

Att arbeta med sin produktinformation

Bortsett från att produkterna ska kunna presenteras på ett bra sätt för besökaren måste jag som handlare också kunna underhålla den på ett bra sätt. För mig är det superviktigt att kunna hantera informationen via ett import och exportförfarande där jag kan arbeta fram visst material utanför själva nätbutiken. Det innebär att det måste finnas ett bra sätt att få in och ut informationen i butikskanalen som möjligt. Här har alla leverantörerna vi testat haft färdiga lösningar som fungerat hyggligt.

Vi jobbar med vårt artikelregister utanför e-handelssystemet just för att vi har en lagerbutik och ett behov av att planera sortimentet utifrån våra leverantörers artiklar. Det vill vi kunna göra i lugn och ro helt utan att lägga in uppgifterna i nätbutiken. Det ska tilldelas artikelnummer, upprättas dokumentation och ordnas med en hel del pappersarbete innan en artikel är klar att säljas på nätet. Hela den processen med att ta fram och testa av nyheter och leveranser från nya leverantörer sker utanför nätbutiken.

Bilder är också något som ska gå att använda i flera kanaler som t.ex. reklamblad eller den tryckta katalogen (som vi ännu inte lyckats producera på grund av tidsbrist).

Vissa av leverantörerna utmärkte sig direkt genom att ha mycket väl utvecklade rutiner för att kombinera information inne i systemet med information som man läser in från externa filer.

Supporten jätteviktig

Om man tar steget att lägga tekniken i knä hos en annan leverantör gäller det att det finns en bra support som kan svara på lätta och svåra frågor och gör detta ganska snabbt. Vi körde denna del i testet ganska fort och ställde frågor till supporten både om sådant som finns i manualerna och sådant som inte gick att räkna ut. Vi tog med exempel på saker som uppenbart inte gick att göra. Turligt nog gjorde det att listan på tänkbara leverantörer nu var nere på två.

• Kodmyran
• Wikinggruppen

Nästa steg blev en rejäl genomkörare i respektive butiks demobutiker och ett surfande på massvis av butiker som använder respektive system. Skulle tro att de som använder sin Google Analytics lär ha haft en minst sagt angelägen besökare som tittat på varenda beståndsdel i butikslösningen för att utvärdera hur en färdig lösning kan se ut.

I nästa bloggpost ska jag berätta lite mer om vår kravbild och hur vi testade demonstrationsbutikerna.

Det självklara valet för en IT-konsult som vill hitta en lösning som går att växa i är många gånger självklart i valet av Magento. Det är en plattform som kan användas för allt från att vara CMS för att driva en webbplats, en nätbutik som säljer ett fåtal produkter eller en hel farm av olika utkanaler med innehållet per butik olika fast med samma administrativa gränssnitt. 

Detta är den andra artikeln i serien om när vi ska ta nästa steg med plattformen för butiken pålyset.se som vi kör i en äldre version av Prestashop som är i behöv av förnyelse.

Att välja Magento är ett steg i teknik som kräver några saker av den e-handlare som väljer plattformen:

• Driftmiljön bör ske på en egen server, en VPS som man lämpligtvis hyr hos någon driftleverantör.
• Magento ger dig möjlighet att konfigurera väldigt mycket och det gäller att man vet vad man vill.
• Det behövs några tilläggsmoduler för att fungera smidigt med en lösning i Sverige om man ska sköta en hel del av orderhanteringen inne i Magento.
• Det finns en hel uppsjö mallar att välja bland men då Magento är väldigt generisk blir det väldigt mycket kod i mallarna och sidorna blir rätt stora.
• Man får ett arv av den stora lösningen även för den lilla handlaren.

Sökning och filtrering via attribut

I och med att Magento är en kraftfull plattform har den också stöd för att kunna bygga avancerade funktioner för att navigera med sökningar där man kombinerar flera sätt att finna informationen. Det här är något vi absolut vill ha möjlighet att jobba med och som är ett krav när man har väldigt många produkter där det ska vara möjligt att jämföra via produkters egenskaper.

Detta går att göra i både Prestashop, Magento och flertalet av de svenska e-handelslösningarna men hamnar ofta i segmentet med enterpriselicenser.

Vi har i vårt val av plattform ändå valt att detta ska komma i ett senare steg av butiken och eftersom vi inte har det idag kan vi klara oss utan det ett tag framöver också, just för att den typ av produkter som behöver filtreringen inte tillhör majoriteten av dem vi säljer. Om det sedan beror på att vi saknar filtrering idag återstår väl att upptäcka när vi får den aktiverad i framtiden.

Orderhanteringen

De system som är gjorda att fungera i hela världen med multibutikens alla möjligheter gör att orderhanteringen i Magento är rätt kompetent. Man kan på ett utmärkt sätt integrera denna orderhantering via ett affärssystem dit order och kunder skickas. Ska man däremot hantera sina order direkt i plattforman bör man skaffa några plugins för att hantera t.ex.

• Plocklistor
• Utskrift av flera fakturor/kvitton samtidigt
• Moduler för att direkt hantera sålda fakturor i gränssnittet
• Modul för att hantera återkoppling av frakt

Det blir rätt många steg att klicka runt på varje order för att leverera den och hanteringstiden vi har idag per order ligger på i snitt 8 minuter. Målet för oss är att komma ner i 4 minuter. Ett av de stora problemen för oss med vår orderhantering är att det är väldigt trångt på lagret. Man måste flytta på saker för att komma åt produkterna och därför är det en fördel att kunna ha ett papper med allt som ska plockas när man väl ger sig ut för att ta fram allt. Med dagens lösning och ett papper per order får man ibland öppna samma låda flera gånger.

Här finns det några fina moduler man kan köpa som löser just detta problem.

Reservering av produkter på lagret

En av nackdelarna med Magento är just hur flödet ser ut när man bekräftat men ej betalt en order. Det handlar om att en order skapas i samband med att kunden bekräftar ordern men före betalning är genomförd. Det händer ibland att kunder misslyckas med betalningen och behöver backa tillbaka för att ändra något och då finns en stor risk att ordern går “förlorad” och kunden får börja om med risken för att någon produkt kanske tagit slut på lagret.  Vi är ju en rätt liten butik och har man ibland bara 5-10 produkter i lager av sådant som är populärt kan det lätt bli så att man missar en order för att det bara fanns ett fåtal exemplar kvar.

För att komma tillrätta med problemet finns det moduler man kan skaffa som automatiskt ordnar med att ångra dessa order och placera tillbaka kundens varor i kundvagnen när man återvänder efter misslyckad betalning. Allt går alltså utmärkt att lösa.

Mallar och grafik

Vi har tittat på att få en smidigare HTML-kod i butiken för att den ska ladda snabbare och att texten kommer högre upp i koden för att sökmotorerna ska gilla oss bättre. I och med Magento och  de mallar man kan köpa verkar många ha byggt enorma mallsystem där man kan konfigurera och anpassa mallarna så att varje butik blir unik nästan helt utan att själv ändra i mallarna.

Vi köpte några mallar för att testa och resultatet blev mest lite trist eftersom det blir enormt mycket HTML-kod och Javascript. Alternativet med att koda egna mallar kvarstod och jag gjorde några försök som egentligen gick rätt bra, bortsett från att man då kommer få göra alla testerna mot alla webbläsare själv igen för att dessutom matcha alla taggar så att moduler som man skaffar ska fungera. Det är egentligen ett väldigt smart och genomtänkt med mallhierarkier, men för den lilla butiken får detta lätt konsekvensen att man måste in i väldigt många filer för att göra en enklare mall och då har man förstört det fina med just mallhanteringens grundtanke att bara ändra sådant som ska ändras.

Hantera produkter i Magento

Här ligger nog det mest kraftfulla med Magento. Man skapar olika attributset för sina produkter och lägger in egenskaperna på produktkortet. Det går att hantera kopplingar och relationer till andra produkter och bildhanteringen är kraftfull där man kan välja vilken bild som ska användas till respektive syfte.

Det är enkelt att styra i vilka kategorier produkterna ingår och man kan på ett kraftfullt sätt lägga till fler värden i de attribut som jobbar med värdelistor. Man styr också över till vilka butiker produkter finns och det är inga problem att jobba med ett “dolt” sortiment under tiden man tar fram all produktinformation över kommande produkter.

Man kan styra inställningar för lager på varje produkt och lägga varianter på produkter på ett smidigt sätt med vilka egenskaper som skiljer de olika varianterna åt.

Via administrativa gränssnittet går det även att styra ordning och flik för de fält som ska fyllas i. Man väljer vilka attribut som ska ingå i den facetterade sökningen och vilka som ska vara ren information. Tack vare attributset får man bara med de attribut som är aktuella för den typ av produkt man jobbar med för varje produkt och behöver alltså inte fylla i “längd på anslutningskabel” för ett värmeljus.

Vi har länge övervägt Magento som nästa steg

Man kan nog i princip göra allt vi tänker oss göra idag och i morgon likväl som nästa år med Magento. Det är en oerhört kraftfull lösning. Det enda den inte löser är att möjligheterna är så stora att vi aldrig kommer ta oss till en butik som är smidigare utan rätt mycket arbetstid som investeras. Man vill ju inte ta nästa steg med en  så kraftfull lösning utan att utnyttja den?

Ända fram till målsnöret stod Magento som ett av de starkaste alternativen, men vi valde ändå för vår huvudbutik att inte gå vidare med Magento just för att den inte kommer minska vår administration jämfört med vad vi har idag. Magento kommer absolut användas för någon satellitbutik eller för tester av koncept, men inte där ett av de största kraven är att få ner hanteringstiden på en order till ett minium.

Som jag tidigare skrivit så har vi nu kört vår nätbutik med ungefär samma utseende rätt länge. Man lär sig saker hela tiden och det börjar vara dags att ta tag i en förnyelse av vissa funktioner i butiken. Vi passar då även på att se över om vi kör på rätt plattform eftersom det har visat sig vara ett rätt omfattande arbete att uppgradera den vi kör idag.

Information overload

Något man lärt sig på vägen är att besökare inte kan läsa eller ta till sig information rent generellt. Vi har hela tiden försökt vara en butik där man kan skaffa sig information, men i många fall blir all information mer överflödig och ett störande moment i stället för att vara till stöd och hjälp. Nästa version av butiken ska alltså bli betydligt mer rensad och man ska få informationen först när man efterfrågar den.

Kassan måste vara smidigare

På senare tid har det här med flödet för att betala blivit allt viktigare för att få dem som ändå skapat en kundvagn att ta sig genom kassan och slutföra köpet. Det har nog bland annat att göra på att Klarna med sin Klarna Checkout förändrat sättet på hur enkelt man beställer och betalar via nätet. Vi har ännu inte riktigt kommit fram till att uppskatta lösningen då det t.ex. inte går att handla via Klarna Checkout som företag. Många andra har passat på att göra sina krångliga kassor enklare och vår kassa som när vi lanserade butiken ändå var rätt enkel kan nu betraktas som lite omständig med alla sina val.

Det som skrämmer många besökare är alla uppgifter man ska fylla i nu när man vant sig vid att hämta uppgifterna via sitt personnummer och kanske någon ytterligare uppgift som postnummer. Ska erkänna att jag själv ibland hellre beställer från en butik som kan hämta uppgifterna via personnummer i stället för att knappa in dem flera gånger.

Vi tror dessutom att en del problem med felstavade adresser och postnummer kan lösas den vägen. Bara kunderna förstår att det är en frivillig uppgift.

E-handelsplattformen

Vi kör idag Prestashop och har lite fastnat i problemen man lätt hamnar i med Open Source som IT-konsult. Jag kan ju fixa allt själv och det är ju bra, men idag ägnar jag rätt mycket tid åt packandet, plockandet och skickandet så att det av den lilla fritid man har om kvällarna inte blir så mycket tid kvar alls åt att programmera om och uppgradera sin e-handelslösning.

Det visar sig att varje order tar i genomsnitt 8 minuter att hantera. Det gör att vi bara hinner packa 8 order på en timme. Inte mycket tid kvar för att kolla på TV om kvällarna då. Det handlar mycket om ren pappershantering för att få ut alla dokument och ändra status på varje order i flödet. Det gick ju bra när man bara skulle skicka en eller två order på en dag men nu kan det bli lite jäktigt.

Något annat som har fått allt större betydelse är möjligheten att skapa bra tillbehörslistor och relaterade produkter, då många av våra produkter gärna handlas med tillbehör eller som färdiga paket som består av flera olika produkter. Här har vi haft en del problem med att delar som ingår i ett paket sålt slut medan paketet legat kvar i lager trots att det inte går att leverera för att t.ex. en dimmer tillfälligt tagit slut.

Börjar man titta på flödet så finns det en hel del moment som är onödigt krångliga och där man i stället skulle kunna hitta en enklare lösning även om det innebär att man kompromissar på möjligheten att göra precis vad man vill.

Det jag gjorde som nästa steg var att börja inventera några olika lösningar som skulle kunna matcha min kravbild.  Jag ska i de följande bloggarna gå igenom lite av det som fått mig att överväga att hyra butikslösningen i stället för att köra den i egen regi. Stay tuned!

Följ hela butiksuppgraderingen

Jag kommer blogga om hela flödet vad det innebär att uppgradera nätbutiken och ni kommer så småningom även få veta vilken leverantör jag valt och hur jag kommer gå vidare med arbetet, men en sak i taget…