Nustokite iš naujo kurti kiekvieno kliento parduotuvę: kartojama įdiegimo sistema

Summary

Jūsų klientas atsiunčia vienos eilutės užklausą 16:53, o jūs vėl esate jo parduotuvėje ir sprendžiate tą pačią problemą, kurią išsprendėte praėjusią savaitę. Šis straipsnis paverčia tą chaosą kartojama įdiegimo sistema: standartizuota informacijos rinkimo santrauka, platformų sprendimų matrica, mokėjimų numatytosios reikšmės, atitikties patikros, produktų duomenų standartai, testavimo scenarijus ir paleidimo vartai. Sistema tinka ir žvakių butikams, ir 300 SKU dropshipperiams. Nustosite rinktis įrankius iš įpročio ir pradėsite rinktis remdamiesi įrodymais. Praleiskite bet kurį žingsnį – ir kaina pasirodys per pirmąjį tikrą užsakymą. Sukurkite sistemą vieną kartą, ir kiekvienas ateities klientas eis tais pačiais bėgiais. Problema ne klientas – jūsų procesas.

Jūsų klientas penktadienį 16:53 atsiunčia vienos eilutės užklausą: „Ar gali tiesiog pridėti pirkimo mygtuką prie mano Instagram?“ Jūs jau šią savaitę vieną kartą atkūrėte jo parduotuvę. Sustokite. Problema ne klientas; jūsų procesas. Šis straipsnis suteikia jums kartojamą įdiegimo sistemą: standartizuotą informacijos rinkimo santrauką, platformų sprendimų matricą, mokėjimų numatytąsias reikšmes, atitikties patikras, produktų duomenų standartus, testavimo scenarijų ir paleidimo vartus. Sukurkite ją vieną kartą, ir kiekviena ateities parduotuvė eis tais pačiais bėgiais. Nustosite iš naujo spręsti tą pačią problemą ir pradėsite paleisti parduotuves.

1. Vykdykite informacijos rinkimą kaip vartus, o ne pokalbį

Vienas klientas parduoda 12 kvapiųjų žvakių ir jam reikia paleisti parduotuvę iki švenčių sezono. Kitas nori dropshipinti 300 SKU iš trijų skirtingų tiekėjų. Žvakių klientui rūpi greitis; dropship klientui rūpi atsargų sinchronizavimas ir užsakymų maršrutizavimas. Jei abiejų paklausite „koks jūsų biudžetas ir kokios platformos norite“, gausite du nenaudingus atsakymus, o tada per mėnesį atkursite vieną iš tų parduotuvių.

Išsiųskite vieno puslapio santrauką prieš liesdami bet kokį įrankį. Šie klausimai turi būti privalomi:

• Kiek SKU planuojate parduoti per pirmąsias 90 dienų?
• Fizinės, skaitmeninės ar mišrios?
• Kas vykdo užsakymus – jūs, tiekėjas ar trečioji šalis?
• Kokia vidutinė užsakymo vertė?
• Ar parduodate per valstijos ar šalies ribas? Kur turite mokesčių buvimą?
• Ar siūlysite prenumeratas, išankstinius užsakymus ar kelių elementų paketus?
• Kokia yra viena funkcija, kurią ši parduotuvė turi turėti pirmą mėnesį?

Paprašykite kliento atsakymus suvesti raštu, o ne pasakoti per pokalbį. Įvesti atsakymai tampa įrašu. Žodiniai atsakymai šeštą savaitę virsta „aš to nesakiau“.

Tada parašykite trijų eilučių apribojimų santrauką: biudžetas, greitis ir būtina funkcija. Įdėkite ją į projekto failo viršų. Kai klientas vėliau paprašys funkcijos, kuri pakeičia architektūrą, parodykite į santrauką ir pasakykite: „Tai keičia platformą. Štai kiek tai kainuoja.“

Kodėl tai svarbu: platformos pasirinkimas yra šios santraukos rezultatas. Jei ją praleisite, pasirinksite tą, kurią naudojote praeitą kartą. E. prekybos platformų tyrimai sutaria vienu klausimu: skirtingi verslo modeliai reikalauja skirtingos architektūros. 12 SKU žvakių parduotuvė ir 300 SKU dropshipper yra skirtingi verslai, todėl su jais elkitės skirtingai. Mes jau rašėme apie kodėl viena platforma netiks kiekvienam klientui; ši santrauka yra būdas tai įgyvendinti.

2. Kurkite platformų matricą pagal kliento profilį, o ne iš įpročio

Štai modelis, kuris nuolat lūžta: kiekvienai naujai parduotuvei atidarote tą patį talpinamą „drag-and-drop“ konstruktorių, nes tai greita. Tada klientui, turinčiam fizinę parduotuvę, reikia, kad atsargos sinchronizuotųsi su kasos aparatu. Jūsų mėgstamiausias konstruktorius to negali padaryti be trijų mokamų programėlių. Trečią savaitę pakeičiate platformą ir visi praranda laiką.

Sprendimų matrica tai išsprendžia. Ji susieja kliento apribojimus su platformų kategorijomis, o ne su prekės ženklais. Laikykite ją bendrame dokumente ir atnaujinkite kas ketvirtį. Pradėkite nuo šios veikiančios versijos:

Kliento profilis	Platformos kategorija	Kada laimi
Mažas SKU skaičius, greitas paleidimas, netechninis savininkas	Talpinamas „drag-and-drop“ konstruktorius	Greitis, programėlių ekosistema, įmontuotas talpinimas
Esama turinio svetainė, svarbi dizaino kontrolė	Atvirojo kodo parduotuvės įskiepis esamai CMS	Išlaikykite svetainę, pridėkite prekybą
Didelis SKU skaičius, sudėtingas katalogas, augimo planai	Talpinama platforma su stipriu API, galinti skalėti	Individualios integracijos, daugiakanalis
Fizinė parduotuvė ir internetinė parduotuvė	Su POS integruotas konstruktorius	Atsargų sinchronizavimas per kanalus
Mažas biudžetas, nedaug produktų	Lengvas įterptas parduotuvės vitrinas	Maža mėnesinė kaina, paprasta atsiskaitymas

Tai kategorijų žemėlapis, o ne reitingas. Klientas, kuriam reikia kelių valiutų ir prenumeratų, priklauso skalėjimo eilutei, nesvarbu, ar jums ta eilutė patinka. Klientas, turintis penkis produktus, neturėtų pirkti įmonės infrastruktūros.

Naudokite nemokamus bandomuosius laikotarpius sąmoningai. Tyrimai nuoseklūs: daugelis platformų siūlo nemokamus bandomuosius laikotarpius. Dauguma žmonių šiuos bandomuosius laikotarpius švaisto spustelėdami šablonus. Vietoj to, atlikite vieną testą pagal kliento santrauką. Importuokite 300 tikrų SKU. Jei importas nepavyksta, išbraukite tą platformą. Išbandykite atsiskaitymą su tikru bandomuoju užsakymu. Patikrinkite, ar mokesčių nustatymai apima kliento valstiją. Bandomasis laikotarpis, kuris imituoja jūsų tikrus apribojimus, yra sprendimas; bandomasis laikotarpis, kuris to nedaro, yra pramoga.

Kai klientas paklausia, kodėl pasirinkote šią platformą, parodykite matricą ir santrauką. Taip priimsite platformos sprendimą, kurį galite apginti prieš kliento viršininką, kliento buhalterį ar savo komandą.

3. Nustatykite mokėjimų sistemą pagal pinigų srautus, o ne pagal tai, kas pažįstama

Du klientai, dvi pinigų srautų realybės. Vienas parduoda 40 USD vertės žvakes ir gali palaukti savaitę iki lėšų įskaitymo. Kitas parduoda 800 USD vertės baldus ir jam reikia pinigų sąskaitoje per kelias dienas, kad galėtų įsigyti medžiagų kitam užsakymui. Jei abiems nustatysite tą patį mokėjimo kanalą, vieną iš jų pasmerksite nesėkmei. Mokėjimų apdorojimo vadovai nuosekliai nurodo tris veiklos svertus: lėšų įskaitymo greitį, kainodaros skaidrumą ir palaikymo kokybę. Pradėkite nuo jų.

Laikykitės šios tvarkos:

1. Paklauskite, koks kliento pinigų ciklas. Savaitiniai ar dienos įskaitymai? Kai kurie apdorotojai atsiskaito greičiau, o kai kurie ilgiau laiko lėšas tam tikroms verslo rūšims.
2. Patikrinkite mokėjimo kanalo integraciją su pasirinkta platformos kategorija. Ar jis palaiko prenumeratas, jei santrauka to reikalauja? Ar jis palaiko jūsų santraukoje nurodytas šalis?
3. Prieš kurdami patikrinkite kliento produktų kategoriją apdorotojo ribotų sąraše. Didelės rizikos kategorijos užšaldo sąskaitas, o ne įspėja el. laiškais.
4. Jei klientas jau turi mokėjimo būdą, kuriuo pasitiki jo klientai — pavyzdžiui, plačiai pripažįstamą piniginę — įtraukite jį, net jei tai prideda mokestį. Pasitikėjimas konvertuoja geriau nei mokesčio skirtumas.
5. Dokumentuokite, kurį mokėjimo kanalą, kurią sąskaitą ir kurį išmokėjimo grafiką patvirtino klientas. Įdėkite tai į projekto failą su data.

Konkretus pavyzdys: baldų klientui reikia greitų įskaitymų ir didelių užsakymų verčių palaikymo. Žvakių klientui reikia paprasto atsiskaitymo ir mažų sąnaudų. Galite baigti su API-pirmojo apdorotoju pirmam ir pradedančiųjų apdorotoju antram. Matrica nusprendžia. Jūsų įprotis ne.

Jei tai praleisite, problema išryškės antrą savaitę po paleidimo, kai klientas paskambins ir pasakys, kad jų pinigai įstrigo. Mokėjimų perdarymas liečia atsiskaitymą, kvitus, mokesčių ataskaitas ir kliento pasitikėjimą. Tai brangiausias dalykas, kurį galite atkurti.

4. Atlikite atitikties patikras prieš kurdami

Priimate klientą, kuris parduoda maisto papildą, teisėtą visur. Sukuriate švarią parduotuvę, prijungiate mokėjimų apdorotoją, paleidžiate. Po šešių savaičių apdorotojas užšaldo sąskaitą, nes produktų kategorijai reikia licencijos ir atitikties peržiūros. Jūsų dizainas niekada nebuvo problema. Trūko dokumentų.

Atitiktis yra paleidimo vartai, o ne administravimas. Prieš bet kokį dizaino darbą patvirtinkite:

• Verslo registracija atitinka tikrąjį kliento subjektą.
• Pardavimo mokesčio registracijos yra kiekvienoje valstijoje, kurioje klientas turi ryšį.
• Produktų kategoriją leidžia mokėjimų apdorotojas, kurį ketinate prijungti.
• Klientas turi licencijas ar leidimus, kurių reikalauja produkto tipas.
• Paslaugų teikimo sąlygos, privatumo politika, grąžinimo politika ir siuntimo politika yra parašytos ir atitinka tai, ką parduotuvė iš tikrųjų daro.

Atlikite tai kaip kontrolinį sąrašą su žymimaisiais langeliais, o ne kaip pokalbį. Kai klientas sako „mano advokatas tai sutvarkys“, nustatykite terminą. Jei terminas praeina, paleidimo data nukeliama. Tai ne jūsų sunkumas; tai jūs saugote paleidimą.

Dažnas patarimas internetinėms parduotuvėms yra „pradėkite mažai ir tobulinkite“. Tai veikia produktų atrankai ir rinkodarai. Tai neveikia atitikčiai. Atkurti parduotuvę, nes apdorotojas užšaldė sąskaitą, nėra tobulinimas; tai švaistymas. Greita teisinės sąrangos darbų peržiūra iš anksto kainuoja mažiau nei vienas užšaldytas mokėjimas. Praleiskite šį žingsnį, ir geriausiu atveju skubėsite ieškoti dokumentų. Blogiausiu atveju klientas manys, kad sugadinote jo verslą.

5. Standartizuokite produktų duomenų sutartį

Klientas atsiunčia skaičiuoklę su 300 produktų. Kiekviena eilutė turi pavadinimą ir kainą. Nėra eilučių su svoriu, matmenimis, kilmės šalimi ar tiekėjo kodu. Paprašote trūkstamų laukų. Klientas nemato, kodėl tai svarbu. Projektas sustoja savaitei. Tada paleidžiate su siuntimu nustatytu „nemokamai“, nes negalėjote apskaičiuoti tarifų, ir klientas sumoka už klaidą.

Nustokite priimti produktų duomenis tokia forma, kokia jie ateina. Apibrėžkite produktų duomenų sutartį. Kiekvienas produktas turi apimti bent:

• Vidinis SKU ir brūkšninis kodas
• Produkto pavadinimas ir aprašymas, kuris bus svetainėje
• Kaina ir palyginamoji kaina
• Svoris ir matmenys siuntimui
• Kilmės šalis ir, jei tarptautinis, harmonizuotos sistemos kodas
• Tiekėjas ir pristatymo laikas
• Siuntimo profilis (vežėjo klasė ir zonos)
• Produkto nuotraukos failo pavadinimas ir alt tekstas
• Mokesčių kategorija

Pereikime per tuos pačius du klientus. Žvakių klientas jums duoda 12 SKU. Laukus nustatote per valandą. Dropshipper duoda 300 SKU. Reikalaujate CSV eksporto iš kiekvieno tiekėjo ir susiejate tas stulpelius su sutartimi. Jei tiekėjas nepateikia lauko, tai yra tiekimo problema, kurią klientas turi išspręsti, o ne duomenų problema, kurią jūs turite spėti.

Standartizuoti produktų duomenys yra vienintelis dalykas, dėl kurio platformos migracija yra pigi. Jei katalogas struktūrizuotas teisingai, kliento perkėlimas į kitą platformą yra importas, o ne atkūrimas. Jei ne, teks perrašyti 300 eilučių ir jos bus klaidingos. Taip pat galite naudoti tuos struktūrizuotus duomenis kurdami produktų sąrašus, kurie parduoda, nes tekstai ir alt tekstai jau yra sutartyje.

6. Atlikite tą patį testavimo scenarijų kiekvienoje parduotuvėje

Jūsų klientas atsiunčia ekrano nuotrauką 9:00: „Man du kartus nuskaičiavo siuntimą.“ Prisijungiate ir randate neteisingos šalies mokesčio tarifą ir nuolaidos kodą, konfliktuojantį su siuntimo logika. Sutaisyti užtrunka dvidešimt minučių. Bet klientas ką tik prarado pasitikėjimą, o pasitikėjimas yra visas verslas.

Jums reikia testo scenarijaus. Ta pati tvarka, tie patys veiksmai, kiekvienam klientui:

1. Atlikite tikrą bandomąjį užsakymą su bandomuoju mokėjimo metodu.
2. Patvirtinkite, kad patvirtinimo el. laiškas pasiekia klientą.
3. Atlikite grąžinimą ir patvirtinkite, kad klientas jį mato.
4. Pritaikykite nuolaidos kodą ir patikrinkite skaičiavimus.
5. Patikrinkite svečio atsiskaitymą ir prisijungusio atsiskaitymą atskirai.
6. Įdėkite produktą į krepšelį iš mobiliojo telefono, ne tik iš darbalaukio peržiūros.
7. Išbandykite tarptautinį siuntimo adresą, jei klientas siunčia tarptautiniu mastu.
8. Patikrinkite mokesčių apskaičiavimą kliento gimtojoje valstijoje ir vienoje kitoje valstijoje.
9. Sukelkite atmestą mokėjimą ir patikrinkite klaidos pranešimą.
10. Patvirtinkite, kad atsargos mažėja, kai pardavimas įvyksta.

Naudokite mažos kainos bandomąjį produktą testavimo ar juodraščio režimu. Daugelis platformų siūlo nemokamus bandomuosius režimus; naudokite juos šiam tikslui, o ne šablonų naršymui. Testui skirkite pusvalandį vienai parduotuvei. Kartojamas testavimo scenarijus yra greitesnis nei „viskas tikriausiai gerai“ metodas, nes jums nereikia spėlioti, ką pamiršote.

Praleiskite tai ir sąmoningai neišleisite sugedusios parduotuvės. Išleisite parduotuvę su vienu neišbandytu keliu, ir pirmasis tikras klientas jį ras.

7. Nustokite leisti platformai būti pirmuoju sprendimu

Klientas prisijungia prie įdiegimo skambučio ir sako: „Norime populiaraus talpinamo konstruktoriaus, nes kažkas rinkodaroje jį kadaise naudojo.“ Dvi dienas praleidžiate susiedami jų reikalavimus su tuo įrankiu ir sužinote, kad jis negali atlikti kelių valiutų atsiskaitymo, kurio reikalauja santrauka. Dabar turite du pasirinkimus: pranešti naujieną ir suerzinti klientą arba sukurti netinkamą dalyką.

Platforma yra rezultatas, o ne įvestis. Jūsų santrauka apibrėžia darbą. Sprendimų matrica pasirenka kategoriją. Tik tada pasirenkate konkretų įrankį. Ši disciplina atrodo atvirkštinė, nes platformų rinkodara nori, kad pirmiausia pasirinktumėte įrankį. Priešinkitės.

Štai tikrasis kompromisas, kurį dauguma straipsnių praleidžia: kartais kliento apribojimas yra teisėtas. Jei klientas jau turi programuotoją, kuris išmano konkrečią platformą, arba sandėlio sistemą, kuri integruojasi tik su konkrečia ekosistema, tas apribojimas turi būti matricoje. Įrašykite jį į santrauką kaip „turi integruotis su esama X“. Tada pasirinkite kategoriją, kuri tai pritaiko. Jei apribojimas yra tik prekės ženklo pasirinkimas, paklauskite kliento, kokio darbo jie tikisi iš tos platformos. Tai, ko jie iš tikrųjų nori, paprastai yra funkcija, ir jūs galite suteikti tą funkciją nekeisdami architektūros.

Atsargumas realus: neperprojektuokite ateities poreikiams, kurių nematote. Žvakių klientui nereikia kelių tiekėjų integracijos. Dropshipperiui reikia. Derinkite su santrauka, o ne su įsivaizduojama ateitimi. Jei klientas sako „planuojame plėstis tarptautiniu mastu per 18 mėnesių“, pažymėkite tai ir pasirinkite kategoriją, kuri to neblokuos. Jei jie sako „mes tik norime tai išbandyti“, pasirinkite greičiausią variantą ir planuokite vėliau pakeisti platformą. Kurkite pagal santrauką.

8. Saugokite paleidimą minimaliu gyvytingu katalogu

Klientui svetainė patinka. Jie tiesiog neturi produktų nuotraukų. „Kitą savaitę“, – sako jie. Po trijų savaičių parduotuvė vis dar stovi už „Netrukus“ vietos žymeklio. Jūsų komanda pradeda pridėti papildomų funkcijų, kad užpildytų laiką, nes niekas nenori pasakyti klientui, kad projektas užstrigo dėl jų. Tada apimtis išauga ir jūs praryjate valandas.

Nustatykite paleidimo vartus. Apibrėžkite minimalų gyvybingą katalogą prieš pradedant projektą. Jis turėtų apimti pakankamai produktų, kad parduotuvė atrodytų tikra toje nišoje — tuzinas tvirtų prekių dažnai pakanka butikui, o dropshipperiui gali prireikti kuruojamo rinkinio iš geriausiai parduodamų, o ne visų 300. Kiekvienas to rinkinio produktas turi turėti nuotrauką, kainą, aprašymą, svorį ir matmenis bei patvirtintą tiekėją. Jokių „netrukus“ produktų puslapių. Jokių vietos žymeklio tekstų.

Saugokite paleidimą šiomis sąlygomis, visomis dvejetainėmis:

• Informacijos rinkimo santrauka užpildyta ir patvirtinta.
• Produktų duomenų sutarties failas yra išsamus kiekvienam paleidimo produktui.
• Mokėjimų sistema patvirtinta ir bandomasis užsakymas atliktas sėkmingai.
• Atitikties kontrolinis sąrašas baigtas.
• Testavimo scenarijus atliktas sėkmingai.

Kai klientas klausia: „Ar galime tiesiog paleisti su produktais, kurie yra paruošti?“, atsakymas yra taip, jei tie produktai atitinka visą sutartį. Tai ne perfekcionizmas; tai pakartojamumas. Vartai egzistuoja, kad niekada neišleistumėte parduotuvės su nematoma priklausomybe.

Jei praleisite vartus, perimsite kliento trūkstamą darbą. Redaguosite neryškias nuotraukas, išgalvosite siuntimo svorius ir spėsite mokesčių kategorijas. Tie spėjimai virsta grąžinimais, atsisakymais ir neigiamais atsiliepimais. Paleidimo vartai yra riba tarp jūsų darbo ir kliento.

Išvada: jūsų procesas yra produktas

Jūs neparduodate svetainių. Jūs parduodate nuspėjamą kelią nuo „noriu parduotuvės“ iki „parduotuvė veikia ir apdoroja užsakymus“. Tam keliui reikia numatytųjų reikšmių, o ne improvizacijos.

Kai kitą kartą klientas parašys penktadienį 16:53, jums nereikės nieko iš naujo spręsti. Atlikite santrauką, patikrinkite matricą, peržiūrėkite mokėjimų sistemą, atlikite atitikties sąrašą, patvirtinkite produktų duomenis ir įvykdykite testavimo scenarijų. Tada atsakysite į el. laišką su planu, o ne spėjimu.

Pradėkite sistemą mažai. Šią savaitę pridėkite vieną klientą prie informacijos rinkimo santraukos. Sukurkite matricą bendrame dokumente. Parašykite testavimo scenarijų vieną kartą ir naudokite jį pakartotinai. Kiekvienas žingsnis, kurį standartizuosite dabar, yra klaida, kurios nekartosite su kitais penkiais klientais.