Nehajte obnavljati vsako trgovino stranke: Ponovljiv sistem vključevanja

Povzetek

Vaša stranka pošlje enovrstično zahtevo ob 16:53 in ste spet v njeni trgovini ter rešujete isti problem, ki ste ga rešili prejšnji teden. Ta članek spremeni ta kaos v ponovljiv sistem vključevanja: standardiziran vstopni brief, matriko odločanja o platformi, privzete nastavitve plačilnega sklada, preverjanje skladnosti, standarde podatkov o izdelkih, skripto za testiranje v pripravljalnem okolju in zagonska vrata. Sistem deluje tako za butike s svečami kot za dropshipperje s 300 SKU-ji. Ne boste več izbirali orodij po navadi, ampak na podlagi dokazov. Če preskočite kateri koli korak, se stroški pokažejo pri prvi pravi naročilu. Sistem zgradite enkrat in vsaka prihodnja stranka sledi istim tirnicam. Stranka ni problem — vaš proces je.

Vaša stranka pošlje enovrstično zahtevo ob 16:53 v petek: 'Ali mi lahko samo dodaš gumb za nakup na moj Instagram?' Njeno trgovino ste že enkrat obnovili ta teden. Nehajte. Stranka ni problem; vaš proces je. Ta članek vam ponuja ponovljiv sistem vključevanja: standardiziran vstopni brief, matriko odločanja o platformi, privzete nastavitve plačilnega sklada, preverjanje skladnosti, standarde podatkov o izdelkih, skripto za testiranje v pripravljalnem okolju in zagonska vrata. Zgradite ga enkrat in vsaka prihodnja trgovina sledi istim tirnicam. Ne boste več reševali istega problema in začeli boste pošiljati trgovine v svet.

1. Izvedite vstop kot vrata, ne kot klepet

Ena stranka prodaja 12 dišečih sveč in mora začeti prodajati pred prazničnim sejmom. Druga želi dropshipping 300 SKU-jev od treh različnih dobaviteljev. Stranki s svečami gre za hitrost; dropship stranki za sinhronizacijo zalog in usmerjanje naročil. Če obe vprašate: 'Kakšen je vaš proračun in katero platformo želite?', boste dobili dva neuporabna odgovora, nato pa boste eno od teh trgovin obnovili v enem mesecu.

Pošljite enostranski brief, preden se dotaknete katerega koli orodja. Ta vprašanja so obvezna:

• Koliko SKU-jev nameravate prodati v prvih 90 dneh?
• Fizični, digitalni ali mešani?
• Kdo izpolnjuje naročila — vi, dobavitelj ali tretja oseba?
• Kakšna je povprečna vrednost naročila?
• Ali prodajate čez državne ali mednarodne meje? Kje imate davčno prisotnost?
• Ali boste ponujali naročnine, prednaročila ali večartikelske pakete?
• Katera je tista ključna funkcija, ki jo mora ta trgovina imeti v prvem mesecu?

Naj stranka odgovore vtipka namesto da vam jih pove po telefonu. Tipkani odgovori postanejo zapis. Ustni odgovori postanejo 'tega nisem nikoli rekel' v šestem tednu.

Nato napišite trivrstični povzetek omejitev: proračun, hitrost in ključno funkcijo. Postavite ga na vrh projektne datoteke. Ko stranka pozneje zahteva funkcijo, ki spremeni arhitekturo, pokažite na brief in recite: 'To spremeni platformo. Tukaj je, koliko stane.'

Zakaj je to pomembno: izbira platforme je rezultat tega briefa. Če ga preskočite, boste izbrali tisto, kar ste uporabili nazadnje. Raziskave o e-commerce platformah se strinjajo v eni točki: različni poslovni modeli potrebujejo različno arhitekturo. Trgovina s 12 SKU-ji sveč in dropshipper s 300 SKU-ji sta različni podjetji, zato ju obravnavajte različno. Pisali smo že o tem, zakaj ena platforma ne ustreza vsaki stranki; ta brief je način, kako to uresničite.

2. Zgradite matriko platform glede na profil stranke, ne po navadi

Tukaj je vzorec, ki se vedno znova lomi: za vsako novo trgovino odprete isti gostujoči graditelj s povleci-in-spusti, ker je hiter. Potem stranka s fizično trgovino potrebuje sinhronizacijo zalog z registrsko blagajno. Vaš najljubši graditelj tega ne zmore brez treh plačljivih aplikacij. V tretjem tednu zamenjate platformo in vsi izgubijo čas.

Matrika odločanja to reši. Preslika omejitve stranke v kategorije platform, ne v blagovne znamke. Hranite jo v skupnem dokumentu in jo posodabljajte četrtletno. Začnite s to delovno različico:

Profil stranke	Kategorija platforme	Kdaj zmaga
Nizko število SKU-jev, hiter zagon, netehnični lastnik	Gostujoči graditelj s povleci-in-spusti	Hitrost, ekosistem aplikacij, vgrajeno gostovanje
Obstoječe vsebinsko spletišče, pomemben nadzor nad obliko	Vtičnik za odprtokodno trgovino za trenutni CMS	Ohranite spletišče, dodajte trgovino
Visoko število SKU-jev, kompleksen katalog, načrti rasti	Prilagodljiva gostujoča platforma z zmogljivim API-jem	Po meri narejene integracije, večkanalnost
Fizična trgovina plus spletna trgovina	Graditelj z integrirano blagajno (POS)	Sinhronizacija zalog med kanali
Ozek proračun, malo izdelkov	Lahka vgrajena trgovina	Nizki mesečni stroški, preprosta blagajna

To je zemljevid kategorij, ne lestvica. Stranka, ki potrebuje večvalutnost in naročnine, sodi v prilagodljivo vrstico, ne glede na to, ali vam je všeč ali ne. Stranka s petimi izdelki ne bi smela kupiti infrastrukture za podjetja.

Prosta preskušanja uporabljajte premišljeno. Raziskave so dosledne: veliko platform ponuja brezplačne preizkuse. Večina ljudi te preizkuse zapravi s klikom po predlogah. Namesto tega izvedite en test iz straninega briefa. Uvozite 300 dejanskih SKU-jev. Če uvoz ne uspe, platformo prečrtajte. Preizkusite blagajno z resničnim testnim naročilom. Preverite, ali davčne nastavitve pokrivajo stranino državo. Preizkus, ki simulira vaše dejanske omejitve, je odločitev; preizkus, ki jih ne, je zabava.

Ko stranka vpraša, zakaj ste izbrali to platformo, pokažite matriko in brief. Tako sprejmete odločitev o platformi, ki jo lahko zagovarjate pred šefom stranke, računovodjo stranke ali vašo lastno ekipo.

3. Privzeto nastavite plačilni sklad glede na denarni tok, ne glede na to, kar je znano

Dve stranki, dve realnosti denarnega toka. Ena prodaja sveče za 40 $ in lahko teden dni čaka na pologe. Druga prodaja pohištvo za 800 $ in potrebuje denar nazaj na računu v nekaj dneh, da kupi material za naslednje naročilo. Če ju nastavite z istim plačilnim prehodom, enega od njiju pripravite do neuspeha. Vodniki za obdelavo plačil dosledno kažejo na tri operativne vzvode: hitrost pologov, preglednost cen in kakovost podpore. Začnite s temi.

Upoštevajte ta vrstni red:

1. Vprašajte, kakšen je denarni cikel stranke. Tedenski ali dnevni pologi? Nekateri procesorji poravnavajo hitreje, nekateri dlje zadržujejo sredstva za določene vrste podjetij.
2. Preverite integracijo prehoda s kategorijo platforme, ki ste jo izbrali. Ali podpira naročnine, če jih brief zahteva? Ali podpira države iz vašega briefa?
3. Pred gradnjo preverite kategorijo izdelkov stranke glede na seznam omejitev procesorja. Kategorije z visokim tveganjem dobijo zamrznjene račune, ne opozorilna e-poštna sporočila.
4. Če ima stranka že plačilno metodo, ki ji stranke zaupajo — na primer splošno priznano denarnico — jo vključite, tudi če doda provizijo. Zaupanje pretvarja bolje kot razlika v proviziji.
5. Dokumentirajte, kateri prehod, kateri račun in kateri načrt izplačil je stranka odobrila. To dajte v projektno datoteko z datumom.

Konkreten primer: stranka s pohištvom potrebuje hitre pologe in podporo za velike vrednosti naročil. Stranka s svečami potrebuje preprosto blagajno in nizke režijske stroške. Morda boste za prvo izbrali procesor, ki je najprej API, za drugo pa procesor, prijazen za začetnike. Matrika odloča. Vaša navada ne.

Če to preskočite, se težava pojavi v drugem tednu po zagonu, ko stranka pokliče in reče, da je njen denar obtičal. Predelava plačil se dotakne blagajne, računov, davčnih poročil in zaupanja stranke. To je najdražja stvar, ki jo lahko obnovite.

4. Pred oblikovanjem izvedite preverjanja skladnosti

Prevzamete stranko, ki prodaja prehransko dopolnilo, ki je legalno povsod. Zgradite čisto trgovino, povežete plačilni procesor, greste v živo. Šest tednov pozneje procesor zamrzne račun, ker kategorija izdelka potrebuje licenco in pregled skladnosti. Vaše oblikovanje nikoli ni bilo problem. Manjkala je dokumentacija.

Skladnost so zagonska vrata, ne administracija. Pred kakršnim koli oblikovalskim delom potrdite:

• Poslovna registracija se ujema z dejanskim subjektom stranke.
• Registracije za prometni davek obstajajo za vsako državo, kjer ima stranka davčno prisotnost.
• Kategorijo izdelka dovoljuje plačilni procesor, na katerega se boste povezali.
• Stranka ima licence ali dovoljenja, ki jih zahteva vrsta izdelka.
• Pogoji uporabe, politika zasebnosti, politika vračil in politika pošiljanja so napisani in se ujemajo s tem, kar trgovina dejansko počne.

To izvedite kot kontrolni seznam s potrditvenimi polji, ne kot pogovor. Ko stranka reče 'moj odvetnik bo to uredil,' določite rok. Če rok preteče, se datum zagona premakne. To ni vaša trma; to je vaše varovanje zagona.

Običajen nasvet za spletne trgovine je 'začnite na majhno in iterirajte.' To deluje pri izbiri izdelkov in marketingu. Pri skladnosti ne deluje. Obnova trgovine, ker je procesor zamrznil račun, ni iteracija; je izguba. Hiter pregled pravne priprave vnaprej stane manj kot eno zamrznjeno izplačilo. Če ta korak preskočite, je najboljši scenarij hitenje za dokumenti. Najslabši scenarij je stranka, ki misli, da ste uničili njeno podjetje.

5. Standardizirajte pogodbo o podatkih o izdelkih

Stranka pošlje preglednico s 300 izdelki. Vsaka vrstica ima ime in ceno. Nobena vrstica nima teže, dimenzij, države izvora ali dobaviteljeve kode. Zahtevate manjkajoča polja. Stranka ne razume, zakaj je to pomembno. Projekt se za teden dni ustavi. Nato zaženete trgovino s poštnino nastavljeno na 'brezplačno', ker niste mogli izračunati cen, in stranka plača za napako.

Nehajte sprejemati podatke o izdelkih v kakršni koli obliki že pridejo. Določite pogodbo o podatkih o izdelkih. Vsak izdelek mora vključevati vsaj:

• Interno SKU in črtno kodo
• Ime izdelka in opis, ki bo na spletišču
• Ceno in primerjalno ceno (compare-at)
• Težo in dimenzije za pošiljanje
• Državo izvora in, če gre za mednarodno, harmonizirano oznako sistema (HS kodo)
• Dobavitelja in dobavni rok
• Pošiljni profil (razred prevoznika in območja)
• Ime datoteke fotografije izdelka in alt besedilo
• Davčno kategorijo

Preidimo skozi isti dve stranki. Stranka s svečami vam da 12 SKU-jev. Polja nastavite v eni uri. Dropshipper vam da 300 SKU-jev. Od vsakega dobavitelja zahtevate izvoz CSV in preslikate te stolpce v pogodbo. Če dobavitelj ne zagotovi polja, je to problem nabave, ki ga mora rešiti stranka, ne podatkovni problem, ki bi ga vi ugibali.

Standardizirani podatki o izdelkih so edina stvar, zaradi katere je selitev platforme poceni. Če je katalog pravilno strukturiran, je premik stranke na drugo platformo uvoz, ne obnova. Če ni, boste ponovno vnesli 300 vrstic in jih naredili narobe. Te strukturirane podatke lahko uporabite tudi za oblikovanje prodajnih seznamov izdelkov, saj so besedila in alt besedila že v pogodbi.

6. V vsaki trgovini izvedite enako skripto za testiranje v pripravljalnem okolju

Vaša stranka ob 9. uri zjutraj pošlje posnetek zaslona: 'Zaračunali so mi poštnino dvakrat.' Prijavite se in najdete davčno stopnjo iz napačne države ter kodo za popust, ki je v konfliktu z logiko pošiljanja. Popravilo traja dvajset minut. Toda stranka je pravkar izgubila zaupanje, zaupanje pa je celotno poslovanje.

Potrebujete testno skripto. Ista naročila, isti koraki, vsaka stranka:

1. Izvedite pravo testno naročilo s testno plačilno metodo.
2. Potrdite, da potrditveno e-poštno sporočilo doseže stranko.
3. Izvedite vračilo in potrdite, da ga stranka vidi.
4. Uporabite kodo za popust in preverite izračun.
5. Ločeno preverite blagajno za goste in blagajno za prijavljene uporabnike.
6. Dodajte izdelek v košarico z mobilnega telefona, ne samo s predogledom na namizju.
7. Testirajte mednarodni poštni naslov, če stranka pošilja v tujino.
8. Preverite izračun davka za domačo državo stranke in eno drugo državo.
9. Sprožite zavrnjeno plačilo in preverite sporočilo o napaki.
10. Potrdite, da se zaloga zmanjša, ko je prodaja opravljena.

Uporabite poceni testni izdelek v pripravljalnem okolju ali načinu osnutka. Veliko platform ponuja brezplačne preskusne načine; uporabite jih za to, ne za brskanje po predlogah. Časovno omejite test na pol ure na trgovino. Ponovljiva testna skripta je hitrejša od pristopa 'verjetno je vse v redu', ker nikoli ne ugibate, kaj ste pozabili.

Če to preskočite, ne boste namerno poslali pokvarjene trgovine. Poslali boste trgovino z eno nepreizkušeno potjo in prva prava stranka jo bo našla.

7. Nehajte dovoliti, da je platforma prva odločitev

Stranka se pridruži klicu za vključitev in reče: 'Želimo priljubljen gostujoči graditelj, ker ga je nekdo iz marketinga enkrat uporabil.' Dva dni porabite za preslikavo njunih zahtev v to orodje in odkrijete, da ne podpira večvalutne blagajne, ki jo zahteva brief. Zdaj imate dve možnosti: sporočiti slabo novico in razjeziti stranko ali zgraditi napačno stvar.

Platforma je rezultat, ne vnos. Vaš brief opredeljuje nalogo. Matrika odločanja izbere kategorijo. Šele nato izberete določeno orodje. Ta disciplina se zdi nazadnjaška, ker vas trženje platform spodbuja, da orodje izberete najprej. Uprite se temu.

Tukaj je prava menjava, ki jo večina člankov izpusti: včasih je omejitev stranke legitimna. Če ima stranka že razvijalca, ki pozna določeno platformo, ali skladiščni sistem, ki se integrira samo z določenim ekosistemom, ta omejitev sodi v matriko. Zapišite jo v brief kot 'se mora povezati z obstoječim X.' Nato izberite kategorijo, ki to omogoča. Če je omejitev le preferenca do blagovne znamke, vprašajte stranko, kakšno nalogo pričakuje od te platforme. Kar si dejansko želijo, je običajno funkcija, to funkcijo pa lahko zagotovite brez menjave arhitekture.

Opozorilo je resnično: ne pretiravajte s tehnično dovršenostjo za prihodnje potrebe, ki jih ne vidite. Stranka s svečami ne potrebuje integracije več dobaviteljev. Dropshipper jo potrebuje. Ujemite se z briefom, ne z namišljeno prihodnostjo. Če stranka reče 'načrtujemo širitev na mednarodni trg čez 18 mesecev,' to zabeležite in izberite kategorijo, ki tega ne bo blokirala. Če rečejo 'samo želimo preizkusiti to,' izberite najhitrejšo možnost in načrtujte poznejšo zamenjavo platforme. Gradite za brief.

8. Pogoj za zagon naj bo minimalno sprejemljiv katalog

Stranki je spletišče všeč. Samo še nimajo fotografij izdelkov. 'Naslednji teden,' rečejo. Tri tedne pozneje je trgovina še vedno za ogrado 'kmalu na voljo'. Vaša ekipa začne dodajati dodatne funkcije, da zapolni čas, ker nihče noče stranki povedati, da je projekt zastal na njihovi strani. Potem se obseg dela razširi in vi plačate ure.

Postavite zagonska vrata. Določite minimalno sprejemljiv katalog, preden se projekt začne. Vključevati mora dovolj izdelkov, da trgovina deluje resnično v svoji niši — ducat trdnih izdelkov je pogosto dovolj za butik, medtem ko dropshipper morda potrebuje izbran nabor najboljših prodajalcev in ne vseh 300. Vsak izdelek v tem naboru mora imeti fotografijo, ceno, opis, težo in dimenzije ter potrjenega dobavitelja. Brez strani izdelkov s 'kmalu na voljo'. Brez nadomestnega besedila.

Pogoj za zagon so te zahteve, vse so binarne:

• Vstopni brief je izpolnjen in odobren.
• Datoteka s pogodbo o podatkih o izdelkih je popolna za vsak izdelek ob zagonu.
• Plačilni sklad je odobren in testno naročilo je uspešno.
• Kontrolni seznam skladnosti je popoln.
• Testna skripta v pripravljalnem okolju je uspešno opravljena.

Ko stranka vpraša: 'Ali lahko preprosto zaženemo z izdelki, ki so pripravljeni?' je odgovor da, če ti izdelki izpolnjujejo celotno pogodbo. To ni perfekcionizem; to je ponovljivost. Vrata obstajajo, da nikoli ne zaženete trgovine s skrito odvisnostjo.

Če vrata preskočite, boste prevzeli stranino manjkajoče delo. Urejali boste zamegljene fotografije, izmišljali teže pošiljk in ugibali davčne kategorije. Ti ugibi postanejo vračila, povračila in negativne ocene. Zagonska vrata so meja med vašim delom in delom stranke.

Sklep: vaš proces je izdelek

Ne prodajate spletišč. Prodate predvidljivo pot od 'želim trgovino' do 'trgovina je v živo in obdeluje naročila.' Ta pot potrebuje privzete nastavitve, ne improvizacijo.

Naslednjič, ko stranka piše ob 16:53 v petek, vam ni treba znova reševati ničesar. Izvedete brief, preverite matriko, pregledate plačilni sklad, izvedete seznam skladnosti, potrdite podatke o izdelkih in izvedete testno skripto. Nato na e-pošto odgovorite z načrtom namesto z ugibanjem.

Začnite sistem na majhno. Ta teden dodajte eno stranko v vstopni brief. Zgradite matriko v skupnem dokumentu. Testno skripto napišite enkrat in jo ponovno uporabite. Vsak korak, ki ga zdaj standardizirate, je napaka, ki je ne boste ponovili za naslednjih pet strank.