Hur du skapar en webbutik: vad projektet faktiskt innebär

Att skapa en webbutik är inte bara att välja en designmall. Läs hur du förbereder katalogen, betalning och leverans och ångerprocessen, och vad du ska kontrollera före lansering.

En webbutik är inte redo i det ögonblick någon kan öppna en produktsida och lägga varan i varukorgen: den är redo när köparen ser rätt pris, väljer en variant som faktiskt finns, betalar och får en begriplig bekräftelse, och när säljaren kan fullgöra ordern och vid behov ta tillbaka varan, medan designen är den mest synliga delen av projektet men inte avgör om den första ordern slutar med en leverans.

Därför måste frågan ”hur du skapar en webbutik” först preciseras: vilken säljprocess ska kunna löpa utan improvisation? Svaret börjar med en vara och en fullständig order, där datakällan, reservation av lagersaldot, betalningens utfall, skapandet av försändelsen och vad som händer vid ångerrätt är tydliga, och varje obesvarad fråga blir senare arbetsomfattning eller en manuell åtgärd: namnge den ansvariga, tiden det tar och gränsen där den manuella vägen inte längre duger, annars fortsätter en tekniskt färdig butik att vila på muntliga överenskommelser och någons minne.

I den här artikeln ligger tonvikten på att förbereda och godkänna projektet, inte på att jämföra plattformspriser, så före utveckling och lansering ska du ta fram indata, skilja butikens funktioner från företagets process och ta emot arbetet efter en riktig testorder, inte efter en skärmbild, och samma grepp duger både när du bygger butiken själv och när du ger uppdraget till en utvecklare.

Börja med en order, inte med ett plattformsnamn

Innan du väljer teknik, beskriv en vanlig order från det att varan hittas till leverans, med en konkret vara, ett pris, ett betalsätt och en adress, och skriv ner vad köparen, butiken och din medarbetare gör i varje steg; om svaret är ”det tar vi manuellt”, namnge också den ansvariga personen, tiden åtgärden tar och det orderantal där den ordningen inte längre är praktisk.

Den beskrivningen visar snabbt om du behöver en standardbutik eller mer individuell orderhantering, för en katalog, en prislogik, vanlig kortbetalning och paketautomat kräver sällan ett komplicerat system, medan priser enligt kundavtal, tillgänglighet i flera lager eller godkännande i ett annat system ändrar omfattningen redan före designen. På en funktionslista kan de två projekten se likadana ut, men i processbeskrivningen blir skillnaden entydig, och den kan göras om till ett acceptanskriterium som går att kontrollera i slutet av projektet utan gissningar om vad leverantören menade.

Plattformen ska väljas utifrån den här processen och den tillväxt du räknar med: WooCommerce kan vara ett rationellt val för standardiserad handel, medan Laravel ger mer frihet för atypisk logik och integrationer, och en bredare jämförelse finns i artikeln om när du ska välja WooCommerce eller Laravel; i det här skedet är det viktigaste att förstå att plattformens namn i sig inte säger vad som händer med din order.

Lägg också till ett undantag i processbeskrivningen och kontrollera vad som händer om betalningen misslyckas, två personer samtidigt försöker köpa den sista enheten, paketautomaten inte är tillgänglig eller kunden vill lämna tillbaka en del av ett produktpaket. Du behöver inte räkna upp varje sällsynt situation, men ett misslyckat scenario avslöjar statusar, aviseringar och medarbetarnas uppgifter långt bättre än tio gröna bockar i en offert.

Katalogen börjar med definitionen av den enhet du säljer

En Excel-fil med produkter är ännu inte en katalog, för först måste du slå fast vad som i systemet är en säljbar enhet: för en enkel bok kan det vara en produkt med ett pris och ett lagersaldo, men för kläder kan varje kombination av storlek och färg ha eget artikelnummer, bild, streckkod och saldo, och för ett produktpaket måste du dessutom veta om det är en fristående produkt eller en samling av flera lagrenheter.

Ta fram en helt ifylld exempelvara innan teamet börjar med massimport, och ta med namn, kort och lång beskrivning, pris, hur moms ska tillämpas, kategori, variant, artikelnummer, lagersaldo, vikt eller mått som spelar roll för leveransen, bilder och annan information som betyder något för köparen. Exemplet gör att ett saknat fält syns medan bara en rad behöver rättas, och ger samtidigt designern verkligt innehåll i stället för ett idealt demonstrationskort.

Ett obegränsat antal SKU i den tekniska lösningen betyder inte att det tar samma arbete att förbereda fyrtio varor som fyra tusen, för priset på butikens funktioner kan vara oförändrat, men i en större katalog växer datastädning, bildkoppling, kontroll av varianter, översättning och import. Därför ska offerten särredovisa plattformens förmåga att lagra en katalog och det arbete som krävs för att dina data ska bli användbara; i det arbetet kan det ingå mappning av fält, hantering av felaktiga rader, kontroll av bilder och jämförelse av den slutliga importen mot källfilen.

Kläder: storlek och färg är inte bara ett filter

I en klädbutik är storlek och färg ofta varianter med egen tillgänglighet, inte bara filtervärden, så köparen ska se att den blå M är slutsåld även om den svarta M fortfarande finns, bilden ska bytas med den valda färgen och den exakta kombinationen ska hamna i ordern, och innan hela katalogen matas in ska du testa en produkt med minst två storlekar, två färger och en otillgänglig variant.

Katalogen behöver en ägare också efter lansering, så bestäm vem som ändrar pris, lägger till en variant, rättar en beskrivning och tar bort en vara från försäljning, och om informationen kommer från en leverantör eller ett affärssystem ska du slå fast den huvudsakliga datakällan och synkroniseringens riktning. Två ställen där medarbetare får rätta samma pris skapar inte flexibilitet, utan förutsättningen för en avvikelse, därför måste det finnas en överenskommelse om ändringshistorik, godkännanderätt och vad som händer vid en felaktig import, och teamet ska kunna ta reda på i vilken källa det felaktiga värdet uppstod och vad det redan har påverkat.

Betalningsprocessen ska beskrivas med statusar och åtgärder

En betalningsintegration är inte klar när ett betalningsfönster öppnas, för i projektet måste det slås fast vad butiken gör efter varje utfall: en lyckad betalning kan byta orderstatus, skicka en bekräftelse, minska tillgängligt antal och lämna över en uppgift till plockning, medan en misslyckad eller avbruten betalning inte får se ut som en betald order men inte heller ska reservera varan i oändlighet.

I vardagsspråk kan ”betalningen lyckades” betyda att banken bekräftade transaktionen, att betaltjänsten registrerade den eller att pengarna redan är bokförda på företagets konto, och orderhanteringen får inte vila på en så vag formulering, så bestäm vilken systemstatus som tillåter att plockningen börjar och hur en medarbetare ser en order som behöver kontrolleras; ordrar med efterkrav eller banköverföring ska hanteras för sig, inte som en kopia av kortbetalningsprocessen.

Du måste också besluta hur länge en obetald order håller varan reserverad, för en för kort tid kan släppa varan medan köparen fortfarande slutför betalningen, och en för lång tid minskar det tillgängliga lagersaldot på konstgjord väg. WooCommerces grundinställningar för lager gör det möjligt att hantera antal och sätta en reservationstid för obetalda ordrar, så en standardbutik kan styra sitt interna lagersaldo utan en extern lagerintegration.

Före lansering, gör minst en lyckad betalning, en avbruten betalning och en återbetalning i testläge eller med ett litet verkligt belopp, och kontrollera köparens skärm, orderstatusen i administrationen, e-postmeddelandena, lagersaldots förändring och betaltjänstens post. Om teamet bara har sett det lyckade scenariot är en stor del av betalningsprocessen fortfarande oprövad, för i det dagliga arbetet måste du kunna skilja en försenad bankavisering, en betalning som köparen avbrutit och ett systemfel, och i varje fall ska det lämnas en begriplig post i administrationen.

Leverans och orderhantering är inte en bock

En leveransintegration kan räkna ut ett pris, visa paketautomater, skapa en försändelse och returnera ett spårningsnummer, men inte varje lösning gör allt det, så formuleringen ”koppla in en budfirma” ska bytas mot konkreta frågor: väljer köparen paketautomat, beror priset på vikt, varukorgssumma eller land, skapas etiketten i butiken och kommer spårningslänken automatiskt i e-posten?

Orderhanteringen börjar efter att ordern har tagits emot, och medarbetaren ska tydligt se vilka ordrar som är betalda och redo att plockas, och hur man agerar vid fel, så bestäm vem som får byta status, om köparen får en avisering och hur spårningsnumret registreras; i en liten butik kan en person göra det, men i ett större team kan en order utan ansvarsfördelning plockas två gånger medan en annan blir osedd.

Kontrollera leveranspriserna med extrema exempel, inte bara med en genomsnittlig varukorg, och prova den billigaste och den dyraste varan, tröskeln för fri frakt, en adress utanför det tillåtna området och en vara som inte ryms i en paketautomat; om beräkningen använder vikt kan en vara utan vikt slå sönder hela resultatet, och vid fast pris måste det vara klart vem som står för mellanskillnaden vid en icke-standardförsändelse, liksom om leverans i flera paket fungerar och om metoden förblir tillgänglig för en varukorg med varor av olika storlek.

Även avhämtning på kontoret eller i butiken är ett leveranssätt med egna regler, så köparen ska veta adress, tider och ögonblicket när ordern är redo att hämtas, och lagermedarbetaren ska få veta det valet i tid. Ett bra test slutar inte med texten ”order mottagen”, utan med ett paket eller en vara som är förberedd för utlämning och en exakt avisering till köparen.

Kraven på order och ångerrätt ska bli konkreta åtgärder

Ett distansavtal kan ingås på en webbplats, i e-post, i meddelanden eller via annat distanskommunikationsmedel, så säljarens skyldigheter försvinner inte för att ordern tas emot i sociala medier och fakturan skickas senare, medan knappen eller en likvärdig åtgärd i en elektronisk beställningsprocess otvetydigt ska visa att beställningen medför en betalningsförpliktelse; kraven gäller själva beställningsföljden, inte bara en villkorssida i webbplatsens sidfot.

Lagen om distansavtal och avtal utanför affärslokaler kräver att köparen, när avtalet ingås på en webbplats, bland annat ska göras särskilt uppmärksam på viss väsentlig information, det slutliga priset och tillkommande kostnader, och att betalningssätt och leveransbegränsningar ska anges senast i början av beställningsprocessen. Eftersom kravens innehåll kan ändras ska du före lansering kontrollera den lydelse som gäller den dagen och jämföra butikens skärmar med de konkreta bestämmelserna.

I orderbekräftelsen ska det ingå en kopia av själva avtalsvillkoren eller ett annat dokument som köparen kan behålla i läsbar och varaktig form, och en länk till en sida som säljaren ensidigt kan ändra räcker inte, så kontrollera att bekräftelsen innehåller de beställda varorna, priset, leveransen, näringsidkarens uppgifter och den förhandsinformation som krävs. Stäm av den exakta dokumentuppsättningen och formuleringarna med en jurist utifrån din säljmodell, och spara den använda versionen tillsammans med orderdatumet, så att du vid en tvist kan visa inte bara den aktuella villkorssidan, utan den information som faktiskt lämnades till köparen.

Konsumentverket förklarar att konsumenten för varor vanligtvis har fjorton dagars ångerrätt, räknat från det att varan kommit i konsumentens besittning, och att lagen namnger specifika undantag. I projektet ska du inte bara ha en text om ångerrätten, utan också ett formulär eller en kontaktväg, registrering av meddelandets datum, kontroll av varan, återbetalning och återställning av lagersaldot, för om de åtgärderna bara finns i en medarbetares minne fungerar butiken bara så länge den personen är tillgänglig.

En butik utan eget lager är fortfarande säljarens process

En butik kan drivas utan ett eget fysiskt lager, till exempel genom att varan skickas från en distributör eller tillverkare, och det minskar behovet av att hålla lager, men det tar inte bort säljarens ansvar mot köparen: om avtalet är ingånget med ditt företag är det fortfarande ditt företag som svarar mot köparen för fullgörandet, inte leverantören.

I den här modellen är tillgänglighetsinformationen kritisk, och om leverantören tillhandahåller ett dataflöde eller ett API måste det slås fast hur ofta det uppdateras, hur fel hanteras och vad som händer om anslutningen bryts. En fördröjning på fem minuter kan vara avgörande för en sista enhet som säljs snabbt, men för en katalog med långsam lageromsättning kan den vara acceptabel, så synkroniseringsfrekvensen ska sättas efter lagerrörelsen och företagets risk, och det måste också vara klart om varan vid ett anslutningsfel döljs, lämnas till försäljning eller lämnas till manuell kontroll.

Skilj butikens interna lagerbokföring från en lagermodul eller en extern integration: WooCommerces grundfunktioner kan lagra ett antal per vara och variant, minska det efter en order och hindra att en vara utan saldo beställs, och det kan räcka för en katalog som sköts i själva butiken. En lagermodul blir nödvändig när det huvudsakliga lagersaldot ligger i ett annat system, det finns flera lagringsplatser eller flera säljkanaler ska hållas i synk.

Före lansering, spela igenom en situation där leverantören inte kan fullgöra ordern även om varan fortfarande syns som tillgänglig på butikens skärm, och bestäm vem som får aviseringen, hur snabbt köparen kontaktas, om ett alternativ erbjuds och hur återbetalningen görs; det scenariot gör inte modellen dålig, men det gör en oväntad komplikation till en risk du kan styra.

Kan du skapa en webbutik gratis?

Att skapa en webbutik gratis kan betyda flera olika saker, till exempel en gratis designmall, programvara med öppen källkod, en provperiod eller ett skyltfönster i sociala medier. De verktygen kan sänka den inledande licensavgiften och hjälpa dig att se om människor är intresserade av erbjudandet, men de tar inte bort arbetet med varudata, betalningar, leverans, villkor, säkerhet och den dagliga administrationen.

Om du bygger butiken själv, börja med den minsta process du kan genomföra korrekt, för ett språk, en liten katalog, ett betalsätt och ett leveranssätt låter dig pröva efterfrågan utan att ta på dig underhållet av komplicerade integrationer. Också i den versionen ska köparen se rätt pris och leveransvillkor, ordern ska nå administrationen, och du ska kunna skicka varan och hantera en retur.

Kostnaderna dyker vanligtvis upp där det gratis verktyget tar slut: för domän och hosting, betalningsprovisioner, betalda tillägg, dataimport, anpassning av designen, förvaltning och din egen tid, så jämför inte bara månadsabonnemanget, utan också de timmar som går till katalogen, felrättning och uppdateringar. Redan i provperioden, skriv ner de återkommande uppgifterna, för ett gratisverktyg kan vara ekonomiskt precis så länge den manuella hanteringen inte äter upp den licensavgift du sparade: om du gör en manuell åtgärd för fem ordrar kan den vara motiverad, men för femhundra ordrar är den redan en mätbar kostnadspost.

Professionell hjälp blir rationell när ett fel kostar mer än införandet, eller när processen inte längre ryms i en persons arbetsdag, och tecken på den gränsen kan vara lagersaldon som inte stämmer, flera språk och prisgrupper, upprepade manuella datakontroller eller integrationer mot bokföring och leverantörer. En butik byggd med egna krafter är inte ett misslyckande, och att ta in en utvecklare är inte ett obligatoriskt nästa steg; beslutet styrs av processens komplexitet och av företagets förmåga att hålla den vid liv, så i teamet behövs någon som regelbundet kontrollerar uppdateringar, säkerhetskopior, säkerhetsaviseringar och felloggar, och du ska kunna återställa köpprocessen efter att tillägg har uppdaterats och dokumentera lösningen så att butiken inte hänger på en medarbetares fritid.

Oavsett vem som utför arbetet ska kontona för domän, hosting, betaltjänst och leverans ligga under företagets kontroll, inte kopplas till en medarbetares eller en extern specialists personliga adress, så skriv ner var åtkomsten förvaras, vem som får godkänna betalningar och hur åtkomsten återställs när den ansvariga är borta. I ett projekt du bygger själv är den ordningen lika viktig som vid ett uppdrag, för administrationsrättigheter i plattformen betyder ännu inte kontroll över domän, server och avtalen med de externa tjänsterna.

Innehåll och migrering ska vara förberedda innan utvecklingen tar slut

Ett butiksprojekt försenas ofta inte av koden, utan av saknade varudata, bilder och beslut, så slå fast vem i företaget som levererar innehåll, vem som godkänner det och vilka fält som är obligatoriska, och varje delresultat behöver ett datum. En utvecklare kan skapa ett fält för en beskrivning, men kan inte i företagets ställe besluta vad du får lova om en vara.

Bilderna behöver en enhetlig proportion, tillräcklig upplösning och rätt att användas, så kontrollera filnamn, alternativa texter och vilken bild som hör till en viss variant. Om leverantören byter bildadresser utan förvarning kan en extern länk försvinna, så den säkrare processen är vanligtvis att importera och optimera bilderna kontrollerat i butiksmiljön, med kopplingen till produktens identitet bevarad.

I en migrering ska produkter, kategorier, kunder, orderhistorik, kuponger, innehåll och filer räknas upp var för sig, för allt får eller bör inte flyttas, och historiska kunduppgifter ska också bedömas utifrån dataskydd och lagringstider. Före den fullständiga migreringen, gör ett försök med en liten datamängd, jämför antal poster och fält, och slå först därefter fast tidpunkten från vilken det gamla systemet inte längre ändras; efter den slutliga importen, ta fram en översikt över saknade poster, dubbletter och värden som det nya systemet har tolkat annorlunda.

När du byter webbplats, ta fram en karta över gamla och nya adresser, för en adress utan omdirigering leder användaren och sökmotorn till en sida som inte finns, och en omdirigering i sig garanterar inte tidigare placeringar i sökresultaten, men den hjälper till att behålla en logisk väg och föra över signaler till den motsvarande nya sidan, så efter lansering ska du kontrollera de viktigaste produkt- och kategoriadresserna, inte bara startsidan.

Kör ett fullständigt acceptanstest före lansering

I acceptanstestet, använd ett realistiskt köparscenario med en konkret vara: öppna butiken i telefonen, hitta varan via sök eller kategori, välj variant, lägg den i varukorgen och ändra antal, kontrollera sedan priset med skatter, den avsedda rabatten och leveransen, fortsätt till kassan, betala och läs alla skärmar och e-postmeddelanden.

Fortsätt testet i administrationen: kontrollera orderstatus, att lagersaldot minskat just för den valda varianten, adressen, paketautomaten och köparens notering, skapa försändelsen, skicka spårningsinformationen och slutför ordern, och hantera till sist en retur och en återbetalning, för en hel cykel visar ofta att varje funktion fungerar för sig, men att informationen inte förs över från en funktion till en annan.

Upprepa ett kortare test med fel: en ogiltig kupong, en otillgänglig variant, en avbruten betalning, en adress utanför leveranszonen och varans sista enhet, där felmeddelandet ska förklara nästa steg och systemet inte får lämna kvar en felaktig reservation. Testets resultat ska inte bara vara en fellista, utan ett beslut om vilka fel som blockerar lanseringen, så för varje rättning namnge den ansvariga, datumet för omtestet och beviset på godkännande, och förvissa dig sedan om att felet inte längre uppträder i telefonen eller i datorns webbläsare.

Kontrollera också inställningarna för integritet och analys, för icke-nödvändiga analys-, reklam- eller andra spårningsskript som kräver samtycke får inte starta före det aktuella valet, och kontrollen ska göras även efter ett avslag och efter återkallelse av samtycke, medan de tekniska åtgärder som ordern behöver inte får sluta fungera om köparen avstår från analys.

Vid lanseringen, utse ansvariga och ta fram en handlingsplan för fel, där det framgår vem som kontrollerar betalningar, leverans och innehåll, vem som ska meddelas om ett kritiskt fel och hur du agerar om betalningar inte kan tas emot eller priserna är fel; ibland är det säkraste beslutet att tillfälligt stoppa beställningar, hellre än att samla ordrar som inte kan fullgöras. I lanseringskontrollen, jämför konfigurationen i test- och produktionsmiljön, betalningsnycklar, leveranskonton, momsinställningar och e-postavsändare, för ett lyckat test i en annan miljö bevisar ännu inte att samma villkor gäller i den butik köparen når.

Administration och förvaltning börjar före lansering

Butikens administratör är inte en abstrakt roll som delas ut efter att projektet har lämnats över, så före lansering ska du slå fast vem som har rätt att ändra priser, publicera produkter, göra återbetalningar och se kunduppgifter, för varje person behöver inte alla rättigheter. En innehållsredaktör ska vanligtvis inte ändra betalningsinställningar, och en lagermedarbetare ska inte se mer kundinformation än som behövs för att förbereda en försändelse.

Kom överens om hur uppdateringar av systemet, tilläggen och integrationerna installeras, för de får inte för första gången nå den publika butiken en fredagseftermiddag bara för att ett meddelande har dykt upp i administrationspanelen. Det behövs en säkerhetskopia, en testmiljö och en person som efter ändringen kör ett kort köptest, för en uppdatering kan röra inte bara utseendet, utan också integrationerna för betalning, leverans och e-post.

Bestäm vem som märker att betalningsaviseringar inte längre når butiken, att försändelsegränssnittet svarar med fel eller att antalet misslyckade ordrar stiger brant, för ett samtal från köparen får inte vara den första signalen om ett fel. Åtminstone de kritiska integrationerna behöver en fellogg och en avisering till den ansvariga, och teamet behöver en ordning för incidenthantering som anger var beslutet om en tillfällig lösning förvaras och efter vilket kriterium återställningen av tjänsten kontrolleras.

De första veckorna ska mätningarna svara på processfrågor, inte bara räkna besök, så jämför påbörjade och avslutade köp, betalningsfel, leveransval och orsakerna till kundsupport, och om många stannar i ett steg, kontrollera först ett tekniskt eller innehållsligt hinder innan du drar slutsatsen att marknaden saknar efterfrågan.

Vad du ska förbereda före samtalet med en utvecklare

För att det första samtalet ska bli produktivt, ta fram en exempelvara, ett fullständigt orderscenario och en undantagssituation, och lägg till ungefärligt antal varor och varianter, språk, länder samt betal- och leveranssätt. Om det redan finns en webbplats, ange vad du vill migrera och vilka system butiken ska utbyta data med; du behöver inte kunna den tekniska lösningen, men du måste kunna visa företagets arbete.

Namnge separat de krav som måste finnas i den första lanseringen, och de idéer som får vänta: den grundläggande betal- och leveransprocessen är vanligtvis ett lanseringskrav, medan ett komplicerat lojalitetsprogram kan vara nästa steg om en order kan tas emot och fullgöras korrekt utan det. Den uppdelningen skyddar budgeten bättre än att stryka funktioner på måfå, för varje uppskjutet arbete behåller ett namngivet skäl, ett beroende och en tidpunkt då beslutet ska tas upp igen efter verkliga orderdata.

En exempelvara, ett orderscenario och en undantagssituation räcker för att förstudien av ett webbutiksprojekt ska kunna sätta en tydlig och kontrollerbar omfattning, liksom tidplan och pris. I offerten, begär inte bara funktionsnamn, utan också gränser: vem som tar fram data, vem som konfigurerar den externa tjänsten och efter vilket test arbetet är godkänt.

Om du redan har en katalog eller en skiss av processen är nästa steg att gå igenom den med någon som kan bedöma de tekniska beroendena, och om det inte finns någon skiss ännu kan vi börja med att ta fram en och säga vad du inte behöver bygga i den första versionen. Att ansöka om förstudie av ett webbutiksprojekt är värdefullt redan före plattformsvalet, för då sätts priset av en tydligt definierad omfattning, inte av antaganden om vad ordet ”butik” borde rymma, och båda parter måste redan före utvecklingen förstå på samma sätt vilket kontrollerbart resultat som visar att projektet är avslutat.