E-handel och lagerhantering

E-handel och lagerhantering i en applikation

Säljer du både på nätet och på plats arbetar du troligen med minst två applikationer. Den ena är e-butiken — WooCommerce, någon e-handelsplattform eller något annat. Den andra är ett lagerprogram, en kassa eller helt enkelt Excel, där du håller koll på vad som faktiskt står på hyllan. Och i slutet av månaden räknas siffrorna ihop på ett tredje ställe.

Varje applikation gör sitt jobb bra. Problemet ligger mellan dem.

Vad som går sönder när applikationerna är två

Lagersaldot stämmer inte. Butiken säljer den sista varan över disk, men e-butiken vet inget om det. Ett par dagar senare köper någon samma vara på nätet, och då visar det sig att hyllan är tom. Det följer ett ursäktande mejl och en återbetalning. Samma sak händer i cykelbutiken med den sista hjälmen, i blomsterbutiken med den sista vasen och i verkstaden med det sista filtret.

Antal förs över för hand. Leverantörens kartong kommer, varorna läses in i lagerprogrammet — och sedan måste samma antal föras in i e-butiken separat. Eller så gör en integration det på natten, när den råkar fungera. Varje integration är ett ställe där något hamnar ur synk.

Två månadsavgifter, två inloggningar, två produktkataloger. En ny produkt måste skapas på två ställen, en prisändring göras två gånger. Om samma produkt har lite olika namn på de två ställena hittar integrationen dem inte längre.

Kunden finns på flera ställen. I e-butiken finns hens beställningar, i kassan hens presentkort, i kalendern hens bokning. Ingen ser helheten.

Du behöver inte köpa två applikationer

Jag byggde NUNDINAE för att täppa till det glappet. E-butiken och lagerhanteringen är inte två integrerade program, utan en applikation med en databas:

  • En katalog för varor och tjänster. Produkten du säljer i e-butiken är samma produkt som du säljer i kassan och skannar in ur leverantörens kartong.
  • Ett lagersaldo. En beställning i e-butiken, en kassaförsäljning och en inleverans ändrar samma siffra i samma ögonblick. Det finns ingen synkronisering, eftersom det inte finns något att synkronisera.
  • Ett kundregister för e-butikens konton och kunderna på plats. E-post är inte obligatoriskt — ett telefonnummer räcker.
  • En rapport. Omsättningen per dag omfattar e-butiken, kassan och bokningarnas fakturor tillsammans.

När en produkt köps i e-butiken reserveras den direkt; blir betalningen aldrig gjord frigörs varan av sig själv. När den sista biten säljs i kassan går den inte längre att köpa på nätet i samma ögonblick.

Lagret sköts med streckkodsläsare

Lagerhantering betyder inte en tabell där du skriver in siffror för hand. Vid inleverans trycker du på ”Ta emot varor” och skannar varje produkt — varje skanning lägger till en styck och varan är direkt till salu även i e-butiken. Svaret på ”hur många har vi i lager?” får du genom att skanna produkten på valfri adminsida.

Alla USB- eller Bluetooth-streckkodsläsare som fungerar som tangentbord duger; ingen separat programvara behövs. I telefon och surfplatta kan du använda kameran. Mer om inleverans, inventering och beställningslistan till leverantören skrev jag i artikeln lagerhantering med streckkodsläsare.

Moduler: du använder bara det du behöver

Alla behöver inte allt. E-butik, bokningar, kundkort, kassa, presentkort, automatiska meddelanden, sms och rapporter är moduler som du slår på och av själv. En butik som inte säljer tjänster på tid stänger av bokningarna och ser dem inte i menyn. En verkstad eller studio som säljer både tjänster och produkter låter dem vara på — då ligger även bokningens faktura och de använda reservdelarna i samma lager. Att stänga av en modul raderar inga data.

Så flyttar du från ditt gamla system

Den största rädslan inför ett byte är befogad: produkter, kunder och flera års historik får inte försvinna.

Produkter från den gamla e-butiken (till exempel WooCommerce) flyttas över med varianter — storlek, färg, volym. Produktinformation som ”Användning” eller ”Ingredienser” blir i det nya systemet en egenskap som butiken visar på produktsidan med egen rubrik.

Lagersaldot kommer från en inventerings-CSV (SKU;antal eller EAN;antal). EAN-koder kan läggas till i bulk från leverantörens prislista.

Kunder och historik kommer från CSV med kolumnmatchning — både en export från det gamla programmet och en Excel-tabell fungerar. En ny import kompletterar befintliga uppgifter i stället för att skapa dubbletter.

Gamla adresser är där de flesta flyttar tappar sina placeringar i Google. Varje gammal produkt- och kategoriadress måste omdirigeras till den nya — hur man gör det rätt skrev jag om i artikeln ny webbplats utan att tappa SEO. I NUNDINAE:s admin finns dessutom vyn ”Trasiga länkar”: där ser du gamla adresser som ger 404 och omdirigerar dem med en knapp.

Flytten gör jag: jag kartlägger dina gamla data, för över dem och kontrollerar resultatet.

Är en applikation alltid bättre?

Nej. Säljer du bara på nätet, har du inget eget lager och kommer varorna direkt från leverantören kan en vanlig e-butik vara enklare — titta i så fall på sidan om e-handel. En applikation ger mest när du har ett fysiskt lager och försäljning i flera kanaler — just då hamnar mest handpåläggning mellan två program. Hur det ser ut i en vanlig butik skrev jag om i artikeln e-handel och lager för butiken.

Är det din situation, beställ NUNDINAE eller be om en visning. Jag tittar på vad du arbetar med i dag och säger ärligt om flytten lönar sig.

Läs vidare

Relaterade tjänster

E-butik och lager i en applikation?

NUNDINAE är plattformen jag byggde just för det. Jag visar den utifrån ditt företag.

Se NUNDINAE