Kā izveidot interneta veikalu: ko projekts patiesībā ietver

Interneta veikala izveide nav tikai dizaina veidnes izvēle. Uzziniet, kā sagatavot katalogu, norēķinu un piegādes kārtību un atteikuma procesu, kā arī ko pārbaudīt pirms palaišanas.

Interneta veikals nav gatavs brīdī, kad tajā var atvērt preces lapu un ielikt preci grozā. Tas ir gatavs tad, kad pircējs redz pareizo cenu, izvēlas patiešām pieejamu variantu, samaksā un saņem saprotamu apstiprinājumu, bet pārdevējs spēj pasūtījumu izpildīt un vajadzības gadījumā pieņemt preci atpakaļ, savukārt dizains ir redzamākā projekta daļa, taču tas nenosaka, vai pirmais pasūtījums beigsies ar piegādi.

Tāpēc jautājums “kā izveidot interneta veikalu” vispirms jāprecizē: kādam pārdošanas procesam jānotiek bez improvizācijas? Atbilde sākas ar vienu preci un vienu pilnu pasūtījumu, kurā ir skaidrs datu avots, atlikuma rezervēšana, maksājuma rezultāts, sūtījuma izveide un rīcība atteikuma gadījumā. Katrs neatbildētais jautājums vēlāk kļūst par darba apjomu vai manuālu darbību: norādiet atbildīgo, izpildes laiku un robežu, aiz kuras manuālā pieeja vairs neder. Citādi tehniski pabeigts veikals turpinās paļauties uz mutisku vienošanos un cilvēka atmiņu.

Šajā rakstā uzmanība ir pievērsta projekta sagatavošanai un pieņemšanai, nevis platformu cenu salīdzināšanai; pirms izstrādes un palaišanas Jums jāsagatavo ievaddati, jānošķir veikala funkcijas no uzņēmuma procesa un darbs jāpieņem pēc īsta testa pasūtījuma, nevis ekrānuzņēmuma. Šāda pieeja der gan tad, ja veikalu veidojat paši, gan tad, ja uzdevumu uzticat izstrādātājam.

Sāciet ar vienu pasūtījumu, nevis platformas nosaukumu

Pirms izvēlēties tehnoloģiju, aprakstiet vienu parastu pasūtījumu no preces atrašanas līdz piegādei, izmantojot konkrētu preci, cenu, maksāšanas veidu un adresi. Pierakstiet, ko katrā posmā dara pircējs, veikals un Jūsu darbinieks. Ja atbilde ir “to sakārtosim manuāli”, norādiet arī atbildīgo cilvēku, darbībai vajadzīgo laiku un pasūtījumu skaitu, pie kura šāda kārtība vairs nebūs praktiska.

Šis apraksts ātri parāda, vai Jums vajag standarta veikalu vai individuālāku pasūtījumu apstrādi, jo katalogs, viena cenu loģika, ierasts karšu maksājums un pakomāts parasti neprasa sarežģītu sistēmu, savukārt cenas pēc klienta līguma, pieejamība vairākās noliktavās vai apstiprināšana citā sistēmā maina apjomu jau pirms dizaina. Funkciju sarakstā abi projekti var izskatīties līdzīgi, bet procesa aprakstā atšķirība kļūst nepārprotama, un to var pārvērst pieņemšanas kritērijā, kuru projekta beigās iespējams pārbaudīt bez minējumiem par to, ko piegādātājs bija domājis.

Platforma jāizvēlas pēc šī procesa un paredzamās izaugsmes: WooCommerce var būt racionāls risinājums standartizētai tirdzniecībai, bet Laravel dod vairāk brīvības netipiskai loģikai un integrācijām; plašāks salīdzinājums ir rakstā par to, kad izvēlēties WooCommerce vai Laravel. Šajā posmā svarīgākais ir saprast, ka platformas nosaukums pats par sevi nepasaka, kas notiks ar Jūsu pasūtījumu.

Procesa aprakstam pievienojiet arī vienu izņēmumu un pārbaudiet, kas notiks, ja maksājums neizdosies, pēdējo vienību vienlaikus mēģinās nopirkt divi cilvēki, pakomāts nebūs pieejams vai klients vēlēsies atdot daļu no komplekta. Nav jāuzskaita katra reta situācija, tomēr viens neveiksmīgs scenārijs atklāj statusus, paziņojumus un darbinieku pienākumus daudz labāk nekā desmit zaļi ķeksīši piedāvājumā.

Katalogs sākas ar pārdodamās vienības definīciju

Produktu Excel fails vēl nav katalogs, jo vispirms jāvienojas, kas sistēmā ir viena pārdodama vienība: vienkāršai grāmatai tā var būt viena prece ar vienu cenu un atlikumu, bet apģērbam katrai izmēra un krāsas kombinācijai var būt savs artikuls, attēls, svītrkods un atlikums. Komplektam savukārt jāzina, vai tas ir patstāvīgs produkts vai vairāku noliktavas vienību kopums.

Sagatavojiet vienu pilnībā aizpildītu parauga preci, pirms komanda sāk masveida importu un iekļaujiet tajā nosaukumu, īso un pilno aprakstu, cenu, nodokļa piemērošanu, kategoriju, variantu, artikulu, atlikumu, piegādei būtisko svaru vai izmērus, attēlus un citu pircējam svarīgu informāciju. Paraugs ļauj pamanīt trūkstošu lauku, kamēr jālabo viena rinda, un vienlaikus dod dizaineram reālu saturu, nevis ideālu demonstrācijas kartīti.

Neierobežots SKU skaits tehniskajā risinājumā nenozīmē, ka četrdesmit un četru tūkstošu preču sagatavošana prasa vienādu darbu, jo veikala funkcijas cena var nemainīties, taču lielākā katalogā pieaug datu tīrīšana, attēlu sasaiste, variantu pārbaude, tulkošana un imports. Tāpēc piedāvājumā atsevišķi jānorāda platformas iespēja glabāt katalogu un darbs, kas jāiegulda, lai Jūsu datus sagatavotu lietošanai; šajā darbā var ietilpt lauku kartēšana, kļūdaino rindu apstrāde, attēlu pārbaude un gala importa salīdzināšana ar avota failu.

Apģērbs: izmērs un krāsa nav tikai filtrs

Apģērbu veikalā izmērs un krāsa bieži ir varianti ar savu pieejamību, nevis tikai filtra vērtības, tāpēc pircējam jāredz, ka zilais M izmērs ir beidzies, pat ja melnais M vēl ir pieejams, bet attēlam jāmainās kopā ar izvēlēto krāsu un pasūtījumā jānonāk precīzai kombinācijai. Pirms visa kataloga ievades pārbaudiet vienu produktu ar vismaz diviem izmēriem, divām krāsām un vienu nepieejamu variantu.

Katalogam ir vajadzīgs īpašnieks arī pēc palaišanas, tāpēc nosakiet, kurš maina cenu, pievieno variantu, labo aprakstu un izņem preci no tirdzniecības, bet, ja informācija ienāk no piegādātāja vai uzņēmuma resursu vadības sistēmas, jānosaka galvenais datu avots un sinhronizācijas virziens. Divas vietas, kurās darbinieki drīkst labot vienu cenu, nerada elastību, bet gan priekšnoteikumu neatbilstībai. Tāpēc jāvienojas par izmaiņu vēsturi, apstiprināšanas tiesībām un rīcību kļūdaina importa gadījumā; komandai jāspēj noskaidrot, kurā avotā radās nepareizā vērtība un ko tā jau ietekmējusi.

Norēķinu process jāapraksta ar statusiem un darbībām

Maksājumu integrācija nav pabeigta ar maksājumu loga atvēršanu, jo projektā jāvienojas, ko veikals dara pēc katra iznākuma: veiksmīgs maksājums var mainīt pasūtījuma statusu, nosūtīt apstiprinājumu, samazināt pieejamo daudzumu un nodot uzdevumu komplektēšanai. Neveiksmīgs vai pārtraukts maksājums nedrīkst izskatīties pēc apmaksāta pasūtījuma, bet tam arī nevajadzētu bezgalīgi rezervēt preci.

Ikdienas valodā “maksājums izdevās” var nozīmēt, ka banka darījumu apstiprināja, maksājumu pakalpojums to reģistrēja vai nauda jau ir ieskaitīta uzņēmuma kontā, un izpildes process nedrīkst balstīties uz tik neskaidru formulējumu, tāpēc nosakiet, kurš sistēmas statuss ļauj sākt komplektēšanu un kā darbinieks redz pasūtījumu, kuram vajadzīga pārbaude. Pēcapmaksas un pārskaitījuma pasūtījumi jāapstrādā atsevišķi, nevis kā maksājumu kartes procesa kopija.

Jāizlemj arī tas, cik ilgi neapmaksāts pasūtījums tur preci rezervētu, jo pārāk īss periods var atbrīvot preci, kamēr pircējs vēl pabeidz maksājumu, bet pārāk garš periods mākslīgi samazina pieejamo atlikumu. WooCommerce pamata krājumu iestatījumi ļauj pārvaldīt daudzumu un noteikt rezervācijas laiku neapmaksātiem pasūtījumiem, tāpēc standarta veikals var kontrolēt savu iekšējo atlikumu bez ārējas noliktavas integrācijas.

Pirms palaišanas veiciet vismaz vienu veiksmīgu maksājumu, vienu pārtrauktu maksājumu un vienu atmaksu testa vai nelielas reālas summas režīmā un pārbaudiet pircēja ekrānu, pasūtījuma statusu administrācijā, e-pastus, atlikuma izmaiņas un maksājumu pakalpojuma ierakstu. Ja komanda ir redzējusi tikai veiksmīgo scenāriju, liela daļa norēķinu procesa joprojām nav pārbaudīta, jo reālajā darbā jāspēj atšķirt bankas aizkavētu paziņojumu, pircēja pārtrauktu maksājumu un sistēmas kļūdu, un katram gadījumam administrācijā jāatstāj saprotams ieraksts.

Piegāde un pasūtījuma izpilde nav viens ķeksītis

Piegādes integrācija var aprēķināt cenu, parādīt pakomātus, izveidot sūtījumu un atgriezt izsekošanas numuru, taču ne katrs risinājums veic visas šīs darbības, tāpēc formulējums “pieslēgt kurjeru” jāaizstāj ar konkrētiem jautājumiem: vai pircējs izvēlas pakomātu, vai cena atkarīga no svara, groza summas vai valsts, vai uzlīme top veikalā un vai izsekošanas saite automātiski nonāk e-pastā?

Pasūtījuma izpilde sākas pēc tā pieņemšanas, un darbiniekam skaidri jāredz apmaksātie un komplektējamie pasūtījumi, kā arī rīcība kļūdu gadījumā. Nosakiet, kurš drīkst mainīt statusu, vai pircējs saņem paziņojumu un kā tiek fiksēts izsekošanas numurs; mazā veikalā to var darīt viens cilvēks, bet lielākā komandā bez atbildības sadalījuma vienu pasūtījumu var sagatavot divreiz, kamēr cits paliek nepamanīts.

Piegādes cenu pārbaudiet ar galējiem piemēriem, ne tikai ar vienu vidēju grozu un izmēģiniet lētāko un dārgāko preci, bezmaksas piegādes slieksni, adresi ārpus atļautās teritorijas un preci, kuru nevar ievietot pakomātā. Ja aprēķinā izmanto svaru, viena prece bez svara var izjaukt visu rezultātu. Fiksētas cenas gadījumā jāzina, kurš sedz starpību nestandarta sūtījumam; jāpārbauda arī vairāku paku piegādi un to, vai metode paliek pieejama grozam ar atšķirīga izmēra precēm.

Arī saņemšana birojā vai veikalā ir piegādes metode ar saviem noteikumiem, tāpēc pircējam jāzina adrese, laiks un brīdis, kad pasūtījums ir gatavs saņemšanai, bet noliktavas darbiniekam par šo izvēli jāuzzina laikus. Labs tests beidzas nevis ar uzrakstu “pasūtījums saņemts”, bet ar paku vai izsniegšanai sagatavotu preci un pircējam nosūtītu precīzu paziņojumu.

Pasūtījuma un atteikuma prasības jāievieš konkrētās darbībās

Distances līgumu var noslēgt tīmekļvietnē, e-pastā, ziņapmaiņā vai citā attālinātā saziņā, tāpēc pārdevēja pienākumi nepazūd, ja pasūtījumu pieņem sociālajā tīklā un rēķinu nosūta vēlāk, savukārt elektroniskajā pasūtīšanas procesā pogai vai līdzvērtīgai darbībai nepārprotami jānorāda, ka pasūtījums rada pienākumu maksāt. Prasības attiecas uz pašu pasūtīšanas secību, ne tikai uz noteikumu lapu vietnes kājenē.

Ministru kabineta noteikumi Nr. 255 paredz, ka tieši pirms elektroniska pasūtījuma pircējam cita starpā jāparāda noteikta būtiskā informācija, galīgā cena un papildu izmaksas, bet maksāšanas veidi un piegādes ierobežojumi jānorāda ne vēlāk kā pasūtījuma veikšanas sākumā. Tā kā prasību sastāvs var mainīties, pirms palaišanas jāpārbauda tajā dienā spēkā esošā redakcija un veikala ekrāni jāsalīdzina ar konkrētajām normām.

Pasūtījuma apstiprinājumā jāiekļauj pašu līguma noteikumu kopija vai cits dokuments, kuru pircējs var saglabāt nemainītā veidā; ar saiti uz pārdevēja vienpusēji maināmu lapu vien nepietiek, tāpēc pārbaudiet, vai apstiprinājumā ir pasūtītās preces, cena, piegāde, tirgotāja dati un vajadzīgā pirmslīguma informācija. Precīzo dokumentu kopumu un formulējumus saskaņojiet ar juristu atbilstoši savam pārdošanas modelim. Saglabājiet izmantoto versiju kopā ar pasūtījuma datumu, lai strīda gadījumā varētu parādīt ne tikai pašreizējo noteikumu lapu, bet arī pircējam faktiski sniegto informāciju.

PTAC skaidro, ka patērētājam precēm parasti ir četrpadsmit dienu atteikuma tiesības, kuras skaita no preces saņemšanas, un noteikumos ir nosaukti konkrēti izņēmumi. Projektā jāparedz ne tikai atteikuma teksts, bet arī veidlapa vai kontakts, paziņojuma datuma reģistrēšana, preces pārbaude, atmaksa un atlikuma atjaunošana; ja šīs darbības glabājas viena darbinieka atmiņā, veikals darbojas tikai tik ilgi, kamēr šis cilvēks ir pieejams.

Veikals bez savas noliktavas joprojām ir pārdevēja process

Veikalu var darbināt bez savas fiziskas noliktavas, piemēram, piegādājot preci no izplatītāja vai ražotāja, tādējādi samazinot vajadzību glabāt krājumus, bet neatceļ pārdevēja atbildību pret pircēju. Ja līgums noslēgts ar Jūsu uzņēmumu, par tā izpildi pircējam joprojām atbild Jūsu uzņēmums, nevis piegādātājs.

Šādā modelī kritiska ir informācija par pieejamību, un, ja piegādātājs nodrošina datu plūsmu vai lietojumprogrammas saskarni, jāvienojas par atjaunošanas biežumu, kļūdu apstrādi un rīcību savienojuma pārtraukuma gadījumā. Piecu minūšu aizkave ātri tirgotai pēdējai vienībai var būt būtiska, bet katalogam ar lēnu krājumu apriti tā var būt pieņemama. Sinhronizācijas biežums jānosaka pēc krājumu kustības un uzņēmuma riska, un jāvienojas arī par to, vai savienojuma kļūdas laikā preci paslēpj, atstāj pārdošanā vai nodod manuālai pārbaudei.

Svarīgi atšķirt veikala iekšējo krājumu uzskaiti no noliktavas moduļa vai ārējas integrācijas: WooCommerce pamata iespējas var glabāt daudzumu katrai precei un variantam, samazināt to pēc pasūtījuma un liegt pasūtīt preci bez atlikuma, un ar to var pietikt vienam katalogam, kuru uztur pašā veikalā. Noliktavas modulis kļūst vajadzīgs, ja galvenais atlikums ir citā sistēmā, ir vairākas glabāšanas vietas vai jāsinhronizē vairāki pārdošanas kanāli.

Pirms palaišanas izspēlējiet situāciju, kurā piegādātājs nevar izpildīt pasūtījumu, lai gan prece veikala ekrānā vēl ir pieejama, un nosakiet, kurš saņem paziņojumu, cik ātri sazinās ar pircēju, vai piedāvā alternatīvu un kā veic atmaksu. Šis scenārijs nepadara modeli sliktu, bet negaidītu sarežģījumu pārvērš pārvaldāmā riskā.

Vai interneta veikalu var izveidot bez maksas?

Bezmaksas interneta veikala izveide var nozīmēt vairākas atšķirīgas lietas, piemēram, bezmaksas dizaina veidni, atvērtā pirmkoda programmatūru, izmēģinājuma plānu vai sociālā tīkla vitrīnu. Šie rīki var samazināt sākotnējo licences maksu un palīdzēt pārbaudīt, vai cilvēki interesējas par piedāvājumu, tomēr tie neatceļ darbu ar preču datiem, maksājumiem, piegādi, noteikumiem, drošību un ikdienas administrēšanu.

Ja veikalu veidojat paši, sāciet ar mazāko procesu, kuru iespējams korekti izpildīt, jo viena valoda, neliels katalogs, viens maksāšanas veids un viena piegādes metode ļauj pārbaudīt pieprasījumu, neuzņemoties sarežģītu integrāciju uzturēšanu. Arī šādā versijā pircējam jāredz pareiza cena un piegādes nosacījumi, pasūtījumam jānonāk administrācijā, bet Jums jāspēj preci nosūtīt un apstrādāt atteikumu.

Izmaksas parasti parādās vietās, kur bezmaksas rīks beidzas: domēnā un mitināšanā, maksājumu komisijās, maksas papildinājumos, datu importā, dizaina pielāgošanā, uzturēšanā un Jūsu pašu laikā, tāpēc salīdziniet ne tikai mēneša abonementu, bet arī stundas, kuras vajadzēs katalogam, kļūdu novēršanai un atjauninājumiem. Jau izmēģinājuma posmā pierakstiet atkārtotos darbus, jo bezmaksas rīks var būt ekonomisks tieši tik ilgi, kamēr manuālā apkalpošana neapēd ietaupīto licences maksu. Ja vienu manuālu darbību veicat pieciem pasūtījumiem, tā var būt pamatota; piecsimt pasūtījumiem tā jau ir izmērāma izmaksu pozīcija.

Profesionāla palīdzība kļūst racionāla tad, kad kļūda maksā vairāk par ieviešanu vai process vairs neietilpst viena cilvēka darba dienā, un par šādu robežu var liecināt nesakrītoši atlikumi, vairākas valodas un cenu grupas, atkārtotas manuālas datu pārbaudes vai integrācijas ar grāmatvedību un piegādātājiem. Pašu spēkiem izveidots veikals nav neveiksme un izstrādātāja piesaiste nav obligāts nākamais solis; lēmumu nosaka procesa sarežģītība un uzņēmuma spēja to uzturēt. Komandā vajadzīgs cilvēks, kurš regulāri pārbauda atjauninājumus, rezerves kopijas, drošības paziņojumus un kļūdu žurnālus, kā arī jāspēj atjaunot pirkšanas procesu pēc papildinājumu atjaunināšanas un dokumentēt risinājumu tā, lai veikals nepaliktu atkarīgs no viena darbinieka brīvā laika.

Neatkarīgi no izpildītāja domēna, mitināšanas, maksājumu pakalpojuma un piegādes kontiem jābūt uzņēmuma kontrolē, nevis piesaistītiem viena darbinieka vai ārēja speciālista personīgajai adresei; pierakstiet, kur glabā piekļuves, kurš drīkst apstiprināt maksājumus un kā atjauno piekļuvi atbildīgā cilvēka prombūtnē. Pašu spēkiem veidotā projektā šī kārtība ir tikpat svarīga kā ārpakalpojumā, jo platformas administrēšanas tiesības vēl nenozīmē kontroli pār domēnu, serveri un ārējo pakalpojumu līgumiem.

Saturs un migrācija jāsagatavo pirms izstrādes noslēguma

Veikala projektu bieži aizkavē nevis kods, bet trūkstoši preču dati, attēli un lēmumi, tāpēc nosakiet, kurš uzņēmumā piegādā saturu, kurš to apstiprina un kādi lauki ir obligāti, turklāt katram starprezultātam vajadzīgs datums. Izstrādātājs var izveidot lauku aprakstam, bet nevar uzņēmuma vietā izlemt, ko drīkst solīt par preci.

Attēliem vajag vienotu proporciju, pietiekamu izšķirtspēju un lietošanas tiesības; pārbaudiet failu nosaukumus, alternatīvos tekstus un to, kura bilde pieder konkrētam variantam. Ja piegādātājs maina attēlu adreses bez brīdinājuma, ārējā saite var pazust, tāpēc drošāks process parasti ir kontrolēti importēt un optimizēt attēlus veikala vidē, saglabājot saikni ar produkta identifikatoru.

Migrācijā atsevišķi jāuzskaita produkti, kategorijas, klienti, pasūtījumu vēsture, kuponi, saturs un faili, jo ne visu drīkst vai vajag pārnest, turklāt vēsturiskie klientu dati jāvērtē arī no datu aizsardzības un glabāšanas termiņu viedokļa. Pirms pilnās migrācijas veiciet izmēģinājumu ar nelielu datu kopu, salīdziniet ierakstu skaitu un laukus un tikai tad nosakiet brīdi, kad vecajā sistēmā vairs neveic izmaiņas; pēc gala importa sagatavojiet pārskatu par trūkstošiem ierakstiem, dublikātiem un vērtībām, kuras jaunā sistēma interpretējusi citādi.

Mainot vietni, sagatavojiet veco un jauno adrešu karti, jo adrese bez pāradresācijas aizved lietotāju un meklētāju uz neesošu lapu, un pāradresācija pati par sevi negarantē iepriekšējās pozīcijas, tomēr tā palīdz saglabāt loģisku ceļu un nodot signālus atbilstošajai jaunajai lapai. Pēc palaišanas pārbaudiet svarīgākās produktu un kategoriju adreses, nevis tikai sākumlapu.

Pirms palaišanas izpildiet pilnu pieņemšanas testu

Pieņemšanas testā izmantojiet reālistisku pircēja scenāriju ar konkrētu preci: atveriet veikalu telefonā, atrodiet preci ar meklēšanu vai kategoriju, izvēlieties variantu, ielieciet to grozā un mainiet daudzumu, pēc tam pārbaudiet cenu ar nodokļiem, paredzēto atlaidi un piegādi. Turpiniet līdz pasūtījuma noformēšanai, samaksājiet un izlasiet visus ekrānus un e-pastus.

Turpiniet testu administrācijā: pārbaudiet pasūtījuma statusu, atlikuma samazinājumu tieši izvēlētajam variantam, adresi, pakomātu un pircēja piezīmi, izveidojiet sūtījumu, nosūtiet izsekošanas informāciju un pabeidziet pasūtījumu. Visbeidzot noformējiet atteikumu un atmaksu, jo pilns cikls bieži atklāj, ka katra funkcija atsevišķi strādā, bet informācija netiek nodota no vienas funkcijas citai.

Atkārtojiet īsāku testu ar kļūdām: nederīgu kuponu, nepieejamu variantu, pārtrauktu maksājumu, adresi ārpus piegādes zonas un pēdējo preces vienību, turklāt kļūdas paziņojumam jāpaskaidro nākamais solis, un sistēma nedrīkst atstāt nepareizu rezervāciju. Testa rezultātā vajadzīgs ne tikai kļūdu saraksts, bet arī lēmums par to, kuras kļūdas bloķē palaišanu. Katram labojumam norādiet atbildīgo, atkārtotās pārbaudes datumu un pieņemšanas pierādījumu, pēc tam pārliecinieties, ka kļūda vairs neatkārtojas ne telefonā, ne datora pārlūkā.

Pārbaudiet arī privātuma un analītikas iestatījumus, jo neobligāti analītikas, reklāmas vai citi izsekošanas skripti, kuru darbībai vajadzīga piekrišana, nedrīkst sākt darbu pirms attiecīgās izvēles, un pārbaude jāveic arī pēc atteikuma un piekrišanas atsaukšanas. Pasūtījumam nepieciešamās tehniskās darbības savukārt nedrīkst pārstāt darboties, ja pircējs atsakās no analītikas.

Palaišanas laikā norīkojiet atbildīgos un sagatavojiet rīcības plānu neveiksmes gadījumam, nosakot, kurš pārbauda maksājumus, piegādi un saturu, kam ziņot par kritisku kļūdu un kā rīkoties, ja maksājumus nevar pieņemt vai cenas ir nepareizas. Dažkārt drošākais lēmums ir uz laiku apturēt pasūtīšanu, nevis vākt pasūtījumus, kurus nevar izpildīt. Palaišanas pārbaudē salīdziniet testa un publiskās vides konfigurāciju, maksājumu atslēgas, piegādes kontus, nodokļu iestatījumus un e-pasta sūtītāju, jo veiksmīgs tests citā vidē vēl nepierāda, ka tādi paši nosacījumi darbojas pircējam pieejamajā veikalā.

Administrēšana un uzturēšana sākas pirms palaišanas

Veikala administrators nav abstrakta loma, kuru piešķir pēc projekta nodošanas, tāpēc pirms palaišanas nosakiet, kam ir tiesības mainīt cenas, publicēt produktus, veikt atmaksu un redzēt klientu datus, jo katram cilvēkam nav vajadzīgas visas tiesības. Satura redaktoram parasti nav jāmaina maksājumu iestatījumi, bet noliktavas darbiniekam nav jāredz vairāk klientu informācijas, nekā vajadzīgs sūtījuma sagatavošanai.

Vienojieties, kā tiek uzstādīti sistēmas, spraudņu un integrāciju atjauninājumi, kuri nedrīkst pirmoreiz nonākt publiski pieejamajā veikalā piektdienas pēcpusdienā tikai tāpēc, ka administrācijas panelī parādījies paziņojums. Vajadzīga rezerves kopija, pārbaudes vide un cilvēks, kurš pēc izmaiņām izpilda īsu pirkuma testu, jo atjauninājums var skart ne tikai izskatu, bet arī norēķinu, piegādes un e-pasta integrācijas.

Nosakiet, kurš pamana, ka maksājumu paziņojumi vairs nenonāk veikalā, sūtījumu saskarne atbild ar kļūdu vai strauji pieaug neveiksmīgu pasūtījumu skaits. Pircēja zvans nedrīkst būt pirmais signāls par kļūdu. Vismaz kritiskām integrācijām vajag kļūdu žurnālu un paziņojumu atbildīgajam, bet komandai — incidentu apstrādes kārtību, kurā jānorāda, kur glabā lēmumu par pagaidu risinājumu un pēc kāda kritērija pārbauda pakalpojuma atjaunošanu.

Pirmajās nedēļās mērījumiem jāatbild uz procesa jautājumiem, ne tikai jāskaita apmeklējumi, tāpēc salīdziniet uzsāktos un pabeigtos pirkumus, maksājumu kļūdas, piegādes izvēles un klientu atbalsta iemeslus. Ja daudz cilvēku apstājas vienā posmā, vispirms pārbaudiet tehnisku vai satura šķērsli, pirms secināt, ka tirgū nav pieprasījuma.

Ko sagatavot pirms sarunas ar izstrādātāju

Lai pirmā saruna būtu produktīva, sagatavojiet vienu parauga preci, vienu pilnu pasūtījuma scenāriju un vienu izņēmuma situāciju un pievienojiet aptuveno preču un variantu skaitu, valodas, valstis, maksāšanas un piegādes veidus. Ja ir esoša vietne, norādiet, ko vēlaties migrēt un ar kurām sistēmām veikalam jāapmainās ar datiem; tehniskais risinājums Jums nav jāzina, bet uzņēmuma darbs ir jāspēj parādīt.

Atsevišķi nosauciet prasības, kurām jābūt pirmajā palaišanā, un idejas, kuras drīkst atlikt: maksājuma un piegādes pamatprocess parasti ir palaišanas prasība, savukārt sarežģīta lojalitātes programma var būt nākamais posms, ja bez tās iespējams korekti pieņemt un izpildīt pasūtījumu. Šis dalījums pasargā budžetu labāk nekā patvaļīga funkciju svītrošana, jo katram atliktajam darbam paliek nosaukts iemesls, atkarība un brīdis, kad pie lēmuma jāatgriežas pēc reāliem pasūtījumu datiem.

Ar parauga preci, pasūtījuma scenāriju un izņēmuma situāciju pietiek, lai interneta veikala projekta izpētē noteiktu skaidru un pārbaudāmu darba apjomu, kā arī termiņu un cenu. Piedāvājumā prasiet ne tikai funkciju nosaukumus, bet arī robežas: kas sagatavo datus, kas konfigurē ārējo pakalpojumu un pēc kāda testa darbs ir pieņemts.

Ja Jums jau ir katalogs vai procesa skice, nākamais solis ir to izskatīt kopā ar cilvēku, kurš var novērtēt tehniskās atkarības, bet, ja skices vēl nav, varam sākt ar tās izveidi un pateikt, ko pirmajā versijā nevajag būvēt. Pieteikt interneta veikala projekta izpēti ir vērtīgi pirms platformas izvēles, jo tad cenu nosaka skaidri definēts darba apjoms, nevis pieņēmumi par to, ko vajadzētu ietvert vārdam “veikals”. Abām pusēm jau pirms izstrādes vienādi jāsaprot, kāds pārbaudāms rezultāts apliecinās projekta pabeigšanu.