Kaip sukurti el. parduotuvę: ką projektas iš tikrųjų apima

El. parduotuvės kūrimas nėra tik dizaino šablono pasirinkimas. Sužinokite, kaip parengti katalogą, atsiskaitymo ir pristatymo tvarką bei sutarties atsisakymo procesą, ir ką patikrinti prieš paleidimą.

El. parduotuvė nėra parengta tą akimirką, kai joje galima atidaryti prekės puslapį ir įdėti prekę į krepšelį. Ji parengta tada, kai pirkėjas mato teisingą kainą, pasirenka iš tikrųjų prieinamą variantą, sumoka ir gauna aiškų patvirtinimą, o pardavėjas geba užsakymą įvykdyti ir prireikus priimti prekę atgal; dizainas yra matomiausia projekto dalis, bet jis nenulemia, ar pirmasis užsakymas baigsis pristatymu.

Todėl klausimą „kaip sukurti el. parduotuvę“ pirmiausia reikia patikslinti: koks pardavimo procesas turi vykti be improvizacijos? Atsakymas prasideda nuo vienos prekės ir vieno viso užsakymo, kuriame aiškus duomenų šaltinis, likučio rezervavimas, mokėjimo rezultatas, siuntos sukūrimas ir veiksmai atsisakius sutarties. Kiekvienas neatsakytas klausimas vėliau tampa darbo apimtimi arba rankiniu veiksmu: nurodykite atsakingąjį, įvykdymo laiką ir ribą, už kurios rankinis būdas jau nebetinka. Kitaip techniškai baigta parduotuvė ir toliau remsis žodiniu susitarimu ir žmogaus atmintimi.

Šiame straipsnyje dėmesys skiriamas projekto parengimui ir priėmimui, o ne platformų kainų palyginimui; prieš kūrimą ir paleidimą Jums reikia parengti įvesties duomenis, atskirti parduotuvės funkcijas nuo įmonės proceso ir darbą priimti pagal tikrą bandomąjį užsakymą, o ne pagal ekrano nuotrauką. Toks požiūris tinka ir tada, kai parduotuvę kuriate patys, ir tada, kai darbą pavedate kūrėjui.

Pradėkite nuo vieno užsakymo, o ne nuo platformos pavadinimo

Prieš rinkdamiesi technologiją aprašykite vieną įprastą užsakymą nuo prekės radimo iki pristatymo, naudodami konkrečią prekę, kainą, mokėjimo būdą ir adresą. Užsirašykite, ką kiekviename etape daro pirkėjas, parduotuvė ir Jūsų darbuotojas. Jei atsakymas yra „tai sutvarkysime rankomis“, nurodykite ir atsakingą žmogų, veiksmui reikalingą laiką ir užsakymų skaičių, nuo kurio tokia tvarka nebebus praktiška.

Šis aprašymas greitai parodo, ar Jums reikia standartinės parduotuvės, ar individualiau tvarkomų užsakymų, nes katalogas, viena kainų logika, įprastas mokėjimas kortele ir paštomatas paprastai nereikalauja sudėtingos sistemos, o kainos pagal kliento sutartį, prieinamumas keliuose sandėliuose ar patvirtinimas kitoje sistemoje keičia apimtį dar prieš dizainą. Funkcijų sąraše abu projektai gali atrodyti panašūs, bet proceso aprašyme skirtumas tampa neabejotinas, ir jį galima paversti priėmimo kriterijumi, kurį projekto pabaigoje galima patikrinti be spėlionių, ką tiekėjas turėjo omenyje.

Platformą reikia rinktis pagal šį procesą ir numatomą augimą: WooCommerce gali būti racionalus sprendimas standartizuotai prekybai, o Laravel duoda daugiau laisvės netipinei logikai ir integracijoms; platesnis palyginimas yra straipsnyje apie tai, kada rinktis WooCommerce ar Laravel. Šiame etape svarbiausia suprasti, kad platformos pavadinimas pats savaime nesako, kas nutiks su Jūsų užsakymu.

Prie proceso aprašymo pridėkite ir vieną išimtį ir patikrinkite, kas nutiks, jei mokėjimas nepavyks, paskutinį vienetą vienu metu bandys nupirkti du žmonės, paštomatas bus neprieinamas arba klientas norės grąžinti dalį komplekto. Nereikia išvardyti kiekvienos retos situacijos, tačiau vienas nesėkmingas scenarijus atskleidžia būsenas, pranešimus ir darbuotojų pareigas gerokai geriau nei dešimt žalių varnelių kainos sąmatoje.

Katalogas prasideda nuo parduodamo vieneto apibrėžties

Produktų Excel failas dar nėra katalogas, nes pirmiausia reikia susitarti, kas sistemoje yra vienas parduodamas vienetas: nesudėtingai knygai tai gali būti viena prekė su viena kaina ir likučiu, o drabužiams kiekviena dydžio ir spalvos kombinacija gali turėti savo artikulą, paveikslą, brūkšninį kodą ir likutį. Dėl komplekto savo ruožtu reikia žinoti, ar tai savarankiškas produktas, ar kelių sandėlio vienetų visuma.

Parenkite vieną visiškai užpildytą pavyzdinę prekę, kol komanda dar nepradėjo masinio importo, ir įtraukite į ją pavadinimą, trumpąjį ir visą aprašymą, kainą, mokesčio taikymą, kategoriją, variantą, artikulą, likutį, pristatymui svarbų svorį ar matmenis, paveikslus ir kitą pirkėjui svarbią informaciją. Pavyzdys leidžia pastebėti trūkstamą lauką, kol taisyti reikia tik vieną eilutę, ir kartu duoda dizaineriui tikrą turinį, o ne idealią demonstracinę kortelę.

Neribotas SKU skaičius techniniame sprendime nereiškia, kad keturiasdešimties ir keturių tūkstančių prekių parengimas reikalauja vienodo darbo, nes parduotuvės funkcijų kaina gali nesikeisti, bet didesniame kataloge auga duomenų valymas, paveikslų susiejimas, variantų patikra, vertimas ir importas. Todėl kainos sąmatoje atskirai reikia nurodyti platformos galimybę saugoti katalogą ir darbą, kurį reikia įdėti, kad Jūsų duomenys taptų tinkami naudoti; į šį darbą gali įeiti laukų susiejimas, klaidingų eilučių tvarkymas, paveikslų patikra ir galutinio importo palyginimas su šaltinio failu.

Drabužiai: dydis ir spalva nėra tik filtras

Drabužių parduotuvėje dydis ir spalva dažnai yra variantai su savo prieinamumu, o ne tik filtro reikšmės, todėl pirkėjas turi matyti, kad mėlynas M dydis baigėsi, net jei juodas M dar yra, o paveikslas turi keistis kartu su pasirinkta spalva ir į užsakymą turi patekti tiksli kombinacija. Prieš įvedant visą katalogą patikrinkite vieną produktą su bent dviem dydžiais, dviem spalvomis ir vienu neprieinamu variantu.

Katalogui reikia savininko ir po paleidimo, todėl nustatykite, kas keičia kainą, prideda variantą, taiso aprašymą ir išima prekę iš prekybos, o jei informacija ateina iš tiekėjo ar įmonės išteklių valdymo sistemos, reikia nustatyti pagrindinį duomenų šaltinį ir sinchronizavimo kryptį. Dvi vietos, kuriose darbuotojai gali taisyti tą pačią kainą, nesukuria lankstumo, o sudaro prielaidą neatitikimui. Todėl reikia susitarti dėl pakeitimų istorijos, tvirtinimo teisių ir veiksmų klaidingo importo atveju; komanda turi gebėti išsiaiškinti, kuriame šaltinyje atsirado neteisinga reikšmė ir ką ji jau paveikė.

Atsiskaitymo procesą reikia aprašyti būsenomis ir veiksmais

Mokėjimų integracija nėra baigta atidarius mokėjimo langą, nes projekte reikia susitarti, ką parduotuvė daro po kiekvieno rezultato: sėkmingas mokėjimas gali pakeisti užsakymo būseną, išsiųsti patvirtinimą, sumažinti prieinamą kiekį ir perduoti užduotį komplektavimui. Nesėkmingas ar nutrauktas mokėjimas negali atrodyti kaip apmokėtas užsakymas, bet neturėtų ir be galo rezervuoti prekės.

Kasdienėje kalboje „mokėjimas pavyko“ gali reikšti, kad bankas patvirtino operaciją, mokėjimo paslauga ją užregistravo arba pinigai jau įskaityti į įmonės sąskaitą, ir vykdymo procesas negali remtis tokia neaiškia formuluote, todėl nustatykite, kuri sistemos būsena leidžia pradėti komplektavimą ir kaip darbuotojas mato užsakymą, kuriam reikia patikros. Užsakymus su apmokėjimu po pristatymo ir pavedimu reikia tvarkyti atskirai, o ne kaip mokėjimo kortele proceso kopiją.

Reikia nuspręsti ir tai, kiek laiko neapmokėtas užsakymas laiko prekę rezervuotą, nes per trumpas laikotarpis gali atšaukti rezervaciją, kol pirkėjas dar baigia mokėjimą, o per ilgas laikotarpis dirbtinai sumažina prieinamą likutį. WooCommerce pagrindiniai atsargų nustatymai leidžia valdyti kiekį ir nustatyti rezervavimo laiką neapmokėtiems užsakymams, todėl standartinė parduotuvė gali kontroliuoti savo vidinį likutį be išorinės sandėlio integracijos.

Prieš paleidimą atlikite bent vieną sėkmingą mokėjimą, vieną nutrauktą mokėjimą ir vieną pinigų grąžinimą bandomuoju režimu arba su nedidele tikra suma ir patikrinkite pirkėjo ekraną, užsakymo būseną administravime, el. laiškus, likučio pokyčius ir mokėjimo paslaugos įrašą. Jei komanda yra mačiusi tik sėkmingą scenarijų, didelė atsiskaitymo proceso dalis vis dar nepatikrinta, nes realiame darbe reikia atskirti banko uždelstą pranešimą, pirkėjo nutrauktą mokėjimą ir sistemos klaidą, ir kiekvienu atveju administravime turi likti aiškus įrašas.

Pristatymas ir užsakymo vykdymas nėra viena varnelė

Pristatymo integracija gali apskaičiuoti kainą, parodyti paštomatus, sukurti siuntą ir grąžinti sekimo numerį, tačiau ne kiekvienas sprendimas atlieka visus šiuos veiksmus, todėl formuluotę „prijungti kurjerį“ reikia pakeisti konkrečiais klausimais: ar pirkėjas pasirenka paštomatą, ar kaina priklauso nuo svorio, krepšelio sumos ar šalies, ar etiketė kuriama parduotuvėje ir ar sekimo nuoroda automatiškai patenka į el. laišką?

Užsakymo vykdymas prasideda po jo priėmimo, ir darbuotojas aiškiai turi matyti apmokėtus ir komplektuotinus užsakymus, taip pat veiksmus klaidų atveju. Nustatykite, kas gali keisti būseną, ar pirkėjas gauna pranešimą ir kaip fiksuojamas sekimo numeris; mažoje parduotuvėje tai gali daryti vienas žmogus, bet didesnėje komandoje be atsakomybės pasidalijimo vieną užsakymą galima paruošti dukart, kol kitas lieka nepastebėtas.

Pristatymo kainą tikrinkite kraštutiniais pavyzdžiais, ne tik vienu vidutiniu krepšeliu, ir išbandykite pigiausią ir brangiausią prekę, nemokamo pristatymo slenkstį, adresą už leidžiamos teritorijos ir prekę, kurios negalima įdėti į paštomatą. Jei skaičiavime naudojamas svoris, viena prekė be svorio gali sujaukti visą rezultatą. Fiksuotos kainos atveju reikia žinoti, kas padengia skirtumą nestandartinei siuntai; reikia patikrinti ir kelių siuntinių pristatymą ir tai, ar būdas lieka prieinamas krepšeliui su skirtingo dydžio prekėmis.

Atsiėmimas biure ar parduotuvėje taip pat yra pristatymo būdas su savomis taisyklėmis, todėl pirkėjas turi žinoti adresą, darbo laiką ir akimirką, kada užsakymas paruoštas atsiimti, o sandėlio darbuotojas apie šį pasirinkimą turi sužinoti laiku. Geras testas baigiasi ne užrašu „užsakymas gautas“, o siunta ar atsiėmimui paruošta preke ir pirkėjui išsiųstu tiksliu pranešimu.

Užsakymo ir sutarties atsisakymo reikalavimus reikia įgyvendinti konkrečiais veiksmais

Nuotolinę sutartį galima sudaryti svetainėje, el. paštu, žinutėmis ar kitomis nuotolinio ryšio priemonėmis, todėl pardavėjo pareigos nedingsta, jei užsakymas priimamas socialiniame tinkle, o sąskaita išsiunčiama vėliau, o elektroniniame užsakymo procese mygtukas ar lygiavertis veiksmas turi nedviprasmiškai nurodyti, kad užsakymas sukuria prievolę sumokėti. Reikalavimai taikomi pačiai užsakymo eigai, o ne tik taisyklių puslapiui svetainės poraštėje.

Civilinio kodekso 6.228⁸ straipsnis numato, kad tiesiai prieš elektroninį užsakymą pirkėjui, be kita ko, turi būti parodyta nustatyta esminė informacija, galutinė kaina ir papildomos išlaidos; Vartotojų teisių apsaugos įstatymo 5 straipsnis reikalauja, kad mokėjimo būdai ir pristatymo apribojimai būtų nurodyti ne vėliau kaip užsakymo teikimo pradžioje. Kadangi reikalavimų sudėtis gali keistis, prieš paleidimą reikia patikrinti tą dieną galiojančią redakciją ir parduotuvės ekranus palyginti su konkrečiomis normomis.

Užsakymo patvirtinime turi būti pačių sutarties sąlygų kopija ar kitas dokumentas, kurį pirkėjas gali išsaugoti nepakeistą; vien nuorodos į pardavėjo vienašališkai keičiamą puslapį nepakanka, todėl patikrinkite, ar patvirtinime yra užsakytos prekės, kaina, pristatymas, prekiautojo duomenys ir reikiama ikisutartinė informacija. Tikslių dokumentų rinkinį ir formuluotes suderinkite su teisininku pagal savo pardavimo modelį. Išsaugokite naudotą versiją kartu su užsakymo data, kad ginčo atveju būtų galima parodyti ne tik dabartinį taisyklių puslapį, bet ir pirkėjui faktiškai suteiktą informaciją.

VVTAT paaiškina, kad vartotojas prekėms paprastai turi keturiolikos dienų teisę atsisakyti sutarties, kuri skaičiuojama nuo prekės gavimo, o teisės aktuose yra nurodytos konkrečios išimtys. Projekte reikia numatyti ne tik atsisakymo tekstą, bet ir formą ar kontaktą, pranešimo datos registravimą, prekės patikrą, pinigų grąžinimą ir likučio atkūrimą; jei šie veiksmai gyvena vieno darbuotojo atmintyje, parduotuvė veikia tik tol, kol šis žmogus yra pasiekiamas.

Parduotuvė be savo sandėlio vis tiek yra pardavėjo procesas

Parduotuvę galima turėti be savo fizinio sandėlio, pavyzdžiui, pristatant prekę iš platintojo ar gamintojo, taip sumažinant poreikį laikyti atsargas, bet tai nepanaikina pardavėjo atsakomybės pirkėjui. Jei sutartis sudaryta su Jūsų įmone, už jos įvykdymą pirkėjui vis tiek atsako Jūsų įmonė, o ne tiekėjas.

Tokiame modelyje ypač svarbi yra informacija apie prieinamumą, ir jei tiekėjas teikia duomenų srautą ar programų sąsają, reikia susitarti dėl atnaujinimo dažnio, klaidų tvarkymo ir veiksmų ryšio nutrūkimo atveju. Penkių minučių vėlavimas greitai parduodamam paskutiniam vienetui gali būti esminis, o katalogui su lėta atsargų apyvarta — priimtinas. Sinchronizavimo dažnį reikia nustatyti pagal atsargų judėjimą ir įmonės riziką, ir susitarti ir dėl to, ar ryšio klaidos metu prekė paslepiama, paliekama prekyboje, ar perduodama rankinei patikrai.

Svarbu skirti parduotuvės vidinę atsargų apskaitą nuo sandėlio modulio ar išorinės integracijos: WooCommerce pagrindinės galimybės gali saugoti kiekį kiekvienai prekei ir variantui, sumažinti jį po užsakymo ir neleisti užsakyti prekės be likučio, ir to gali pakakti vienam katalogui, kuris tvarkomas pačioje parduotuvėje. Sandėlio modulis tampa reikalingas, jei pagrindinis likutis yra kitoje sistemoje, yra kelios saugojimo vietos arba reikia sinchronizuoti kelis pardavimo kanalus.

Prieš paleidimą pereikite situaciją, kurioje tiekėjas negali įvykdyti užsakymo, nors prekė parduotuvės ekrane dar yra prieinama, ir nustatykite, kas gauna pranešimą, kaip greitai susisiekiama su pirkėju, ar siūloma alternatyva ir kaip atliekamas pinigų grąžinimas. Šis scenarijus nedaro modelio blogo, bet netikėtą komplikaciją paverčia valdoma rizika.

Ar el. parduotuvę galima sukurti nemokamai?

Nemokamas el. parduotuvės kūrimas gali reikšti kelis skirtingus dalykus, pavyzdžiui, nemokamą dizaino šabloną, atvirojo kodo programinę įrangą, bandomąjį planą ar socialinio tinklo vitriną. Šie įrankiai gali sumažinti pradinį licencijos mokestį ir padėti patikrinti, ar žmonės domisi pasiūlymu, tačiau jie nepanaikina darbo su prekių duomenimis, mokėjimais, pristatymu, taisyklėmis, saugumu ir kasdieniu administravimu.

Jei parduotuvę kuriate patys, pradėkite nuo mažiausio proceso, kurį įmanoma korektiškai įvykdyti, nes viena kalba, nedidelis katalogas, vienas mokėjimo būdas ir vienas pristatymo būdas leidžia patikrinti paklausą neprisiimant sudėtingų integracijų priežiūros. Ir tokioje versijoje pirkėjas turi matyti teisingą kainą ir pristatymo sąlygas, užsakymas turi patekti į administravimą, o Jūs turite gebėti prekę išsiųsti ir tvarkyti sutarties atsisakymą.

Išlaidos paprastai atsiranda ten, kur nemokamas įrankis baigiasi: domene ir talpinime, mokėjimų komisiniuose, mokamuose įskiepiuose, duomenų importe, dizaino pritaikyme, priežiūroje ir Jūsų pačių laiku, todėl lyginkite ne tik mėnesio prenumeratą, bet ir valandas, kurių prireiks katalogui, klaidų šalinimui ir atnaujinimams. Jau bandomajame etape užsirašykite pasikartojančius darbus, nes nemokamas įrankis gali būti ekonomiškas būtent tol, kol rankinis aptarnavimas nesuėda sutaupytos licencijos kainos. Jei vieną rankinį veiksmą atliekate penkiems užsakymams, tai gali būti pagrįsta; penkiems šimtams užsakymų tai jau išmatuojama sąnaudų eilutė.

Profesionali pagalba tampa racionali tada, kai klaida kainuoja daugiau nei įdiegimas arba procesas nebetelpa į vieno žmogaus darbo dieną, ir tokią ribą gali rodyti nesutampantys likučiai, kelios kalbos ir kainų grupės, pasikartojančios rankinės duomenų patikros ar integracijos su apskaita ir tiekėjais. Savomis jėgomis sukurta parduotuvė nėra nesėkmė ir kūrėjo pasitelkimas nėra privalomas kitas žingsnis; sprendimą lemia proceso sudėtingumas ir įmonės gebėjimas jį prižiūrėti. Komandoje reikia žmogaus, kuris reguliariai tikrina atnaujinimus, atsargines kopijas, saugumo pranešimus ir klaidų žurnalus, taip pat reikia gebėti atkurti pirkimo procesą po įskiepių atnaujinimo ir dokumentuoti sprendimą taip, kad parduotuvė neliktų priklausoma nuo vieno darbuotojo laisvo laiko.

Nepriklausomai nuo vykdytojo, domenas, talpinimas, mokėjimo paslaugos ir pristatymo paskyros turi būti įmonės kontrolėje, o ne pririštos prie vieno darbuotojo ar išorinio specialisto asmeninio adreso; užsirašykite, kur saugomos prieigos, kas gali patvirtinti mokėjimus ir kaip atkuriama prieiga atsakingam žmogui nesant. Savomis jėgomis kuriamame projekte ši tvarka yra lygiai tokia pat svarbi kaip ir išorinėje paslaugoje, nes platformos administravimo teisės dar nereiškia kontrolės domenui, serveriui ir išorinių paslaugų sutartims.

Turinį ir migraciją reikia parengti prieš kūrimo pabaigą

Parduotuvės projektą dažnai vilkina ne kodas, o trūkstami prekių duomenys, paveikslai ir sprendimai, todėl nustatykite, kas įmonėje teikia turinį, kas jį tvirtina ir kurie laukai privalomi, be to, kiekvienam tarpiniam rezultatui reikia datos. Kūrėjas gali sukurti lauką aprašymui, bet negali įmonės vietoje nuspręsti, ką leidžiama žadėti apie prekę.

Paveikslams reikia vienodos proporcijos, pakankamos raiškos ir naudojimo teisių; patikrinkite failų pavadinimus, alternatyviuosius tekstus ir tai, kuris paveikslas priklauso konkrečiam variantui. Jei tiekėjas keičia paveikslų adresus be įspėjimo, išorinė nuoroda gali dingti, todėl saugesnis procesas paprastai yra kontroliuojamai importuoti ir optimizuoti paveikslus parduotuvės aplinkoje, išlaikant ryšį su prekės identifikatoriumi.

Migracijoje atskirai reikia išvardyti produktus, kategorijas, klientus, užsakymų istoriją, kuponus, turinį ir failus, nes ne viską leidžiama ar reikia perkelti, be to, istorinius klientų duomenis reikia vertinti ir duomenų apsaugos bei saugojimo laikotarpių požiūriu. Prieš visą migraciją atlikite bandymą su nedideliu duomenų rinkiniu, palyginkite įrašų skaičių ir laukus ir tik tada nustatykite akimirką, nuo kurios senoji sistema nebėra keičiama; po galutinio importo parenkite apžvalgą apie trūkstamus įrašus, dublikatus ir reikšmes, kurias naujoji sistema interpretavo kitaip.

Keičiant svetainę parenkite senų ir naujų adresų žemėlapį, nes adresas be peradresavimo nuveda naudotoją ir paieškos sistemą į neegzistuojantį puslapį, o peradresavimas pats savaime negarantuoja ankstesnių pozicijų paieškos sistemose, tačiau padeda išlaikyti loginį kelią ir perduoti signalus atitinkamam naujam puslapiui. Po paleidimo patikrinkite svarbiausius produktų ir kategorijų adresus, o ne tik pradžios puslapį.

Prieš paleidimą atlikite visą priėmimo testą

Priėmimo teste naudokite realistišką pirkėjo scenarijų su konkrečia preke: atidarykite parduotuvę telefone, raskite prekę paieška ar kategorija, pasirinkite variantą, įdėkite jį į krepšelį ir pakeiskite kiekį, tada patikrinkite kainą su mokesčiais, numatytą nuolaidą ir pristatymą. Tęskite iki užsakymo įforminimo, sumokėkite ir perskaitykite visus ekranus ir el. laiškus.

Tęskite testą administravime: patikrinkite užsakymo būseną, likučio sumažėjimą būtent pasirinktam variantui, adresą, paštomatą ir pirkėjo pastabą, sukurkite siuntą, išsiųskite sekimo informaciją ir užbaikite užsakymą. Galiausiai įforminkite sutarties atsisakymą ir pinigų grąžinimą, nes visas ciklas dažnai atskleidžia, kad kiekviena funkcija atskirai veikia, bet informacija neperduodama iš vienos funkcijos į kitą.

Pakartokite trumpesnį testą su klaidomis: negaliojančiu kuponu, neprieinamu variantu, nutrauktu mokėjimu, adresu už pristatymo zonos ir paskutiniu prekės vienetu, be to, klaidos pranešimas turi paaiškinti kitą žingsnį, o sistema negali palikti neteisingos rezervacijos. Testo rezultate reikia ne tik klaidų sąrašo, bet ir sprendimo, kurios klaidos blokuoja paleidimą. Kiekvienam taisymui nurodykite atsakingąjį, pakartotinės patikros datą ir priėmimo įrodymą, tada įsitikinkite, kad klaida nebesikartoja nei telefone, nei kompiuterio naršyklėje.

Patikrinkite ir privatumo bei analitikos nustatymus, nes neprivalomi analitikos, reklamos ar kiti sekimo skriptai, kuriems reikia sutikimo, negali pradėti veikti prieš atitinkamą pasirinkimą, o patikrą reikia atlikti ir po atsisakymo, ir po sutikimo atšaukimo. Užsakymui reikalingi techniniai veiksmai savo ruožtu neturi nustoti veikti, jei pirkėjas atsisako analitikos.

Paleidimo metu paskirkite atsakinguosius ir parenkite veiksmų planą nesėkmės atvejui, nustatydami, kas tikrina mokėjimus, pristatymą ir turinį, kam pranešti apie kritinę klaidą ir kaip elgtis, jei mokėjimų negalima priimti arba kainos yra neteisingos. Kartais saugesnis sprendimas yra laikinai sustabdyti užsakymus, o ne rinkti užsakymus, kurių negalima įvykdyti. Paleidimo patikroje palyginkite bandomosios ir viešosios aplinkos konfigūraciją, mokėjimų raktus, pristatymo paskyras, mokesčių nustatymus ir el. laiško siuntėją, nes sėkmingas testas kitoje aplinkoje dar neįrodo, kad tokios pačios sąlygos veikia pirkėjui prieinamoje parduotuvėje.

Administravimas ir priežiūra prasideda prieš paleidimą

Parduotuvės administratorius nėra abstraktus vaidmuo, kuris suteikiamas po projekto perdavimo, todėl prieš paleidimą nustatykite, kas turi teisę keisti kainas, skelbti produktus, atlikti pinigų grąžinimą ir matyti klientų duomenis, nes kiekvienam žmogui nereikia visų teisių. Turinio redaktoriui paprastai nereikia keisti mokėjimų nustatymų, o sandėlio darbuotojui nereikia matyti daugiau klientų informacijos, nei reikia siuntai paruošti.

Susitarkite, kaip diegiami sistemos, įskiepių ir integracijų atnaujinimai, kurie pirmą kartą negali patekti į viešai prieinamą parduotuvę penktadienio popietę tik todėl, kad administravimo skydelyje pasirodė pranešimas. Reikia atsarginės kopijos, bandymo aplinkos ir žmogaus, kuris po pakeitimų atlieka trumpą pirkimo testą, nes atnaujinimas gali paliesti ne tik išvaizdą, bet ir atsiskaitymo, pristatymo ir el. pašto integracijas.

Nustatykite, kas pastebi, kad mokėjimų pranešimai nebepatenka į parduotuvę, siuntų sąsaja grąžina klaidą arba staiga auga nesėkmingų užsakymų skaičius. Pirkėjo skambutis negali būti pirmasis klaidos signalas. Bent kritinėms integracijoms reikia klaidų žurnalo ir pranešimo atsakingajam, o komandai — incidentų tvarkymo tvarkos, kurioje nurodyta, kur saugomas sprendimas dėl laikino sprendimo ir pagal kokį kriterijų tikrinamas paslaugos atkūrimas.

Pirmosiomis savaitėmis matavimai turi atsakyti į proceso klausimus, o ne tik skaičiuoti apsilankymus, todėl palyginkite pradėtus ir užbaigtus pirkimus, mokėjimų klaidas, pristatymo pasirinkimus ir klientų aptarnavimo priežastis. Jei daug žmonių sustoja viename etape, pirmiausia patikrinkite techninę ar turinio kliūtį, prieš darydami išvadą, kad rinkoje nėra paklausos.

Ką parengti prieš pokalbį su kūrėju

Kad pirmasis pokalbis būtų naudingas, parenkite vieną pavyzdinę prekę, vieną visą užsakymo scenarijų ir vieną išimties situaciją ir pridėkite apytikslį prekių ir variantų skaičių, kalbas, šalis, mokėjimo ir pristatymo būdus. Jei yra esama svetainė, nurodykite, ką norite migruoti ir su kuriomis sistemomis parduotuvė turi keistis duomenimis; techninio sprendimo Jums žinoti nereikia, bet įmonės darbą reikia gebėti parodyti.

Atskirai įvardykite reikalavimus, kurie turi būti pirmajame paleidime, ir idėjas, kurias galima atidėti: mokėjimo ir pristatymo pagrindinis procesas paprastai yra paleidimo reikalavimas, o sudėtinga lojalumo programa gali būti kitas etapas, jei be jos įmanoma korektiškai priimti ir įvykdyti užsakymą. Šis skirstymas saugo biudžetą geriau nei savavališkas funkcijų braukymas, nes kiekvienam atidėtam darbui lieka įvardyta priežastis, priklausomybė ir akimirka, kada prie sprendimo reikia grįžti pagal tikrus užsakymų duomenis.

Pavyzdinės prekės, užsakymo scenarijaus ir išimties situacijos pakanka, kad el. parduotuvės projekto tyrime būtų nustatyta aiški ir patikrinama darbo apimtis, taip pat terminas ir kaina. Kainos sąmatoje prašykite ne tik funkcijų pavadinimų, bet ir ribų: kas rengia duomenis, kas konfigūruoja išorinę paslaugą ir po kokio testo darbas yra priimtas.

Jei Jūs jau turite katalogą ar proceso eskizą, kitas žingsnis yra jį peržiūrėti kartu su žmogumi, kuris gali įvertinti technines priklausomybes, o jei eskizo dar nėra, galime pradėti nuo jo parengimo ir pasakyti, ko pirmoje versijoje nereikia statyti. Užsakyti el. parduotuvės projekto tyrimą verta prieš platformos pasirinkimą, nes tada kainą lemia aiškiai apibrėžta darbo apimtis, o ne prielaidos apie tai, ką turėtų apimti žodis „parduotuvė“. Abiem pusėms jau prieš kūrimą vienodai reikia suprasti, koks patikrinamas rezultatas patvirtins projekto pabaigą.