Pārtrauciet pārbūvēt katra klienta veikalu: atkārtojama ievadīšanas sistēma

Summary

Jūsu klients sūta vienas rindiņas pieprasījumu pulksten 16:53, un jūs atkal esiet viņa veikalā, risinot to pašu problēmu, ko atrisinājāt pagājušajā nedēļā. Šis raksts pārvērš šo haosu par atkārtojamu ievadīšanas sistēmu: standartizēta sākotnējās informācijas lapa, platformas lēmumu matrica, maksājumu risinājumu noklusējumi, atbilstības pārbaudes, produktu datu standarti, testēšanas skripts priekšražošanas vidē un palaišanas vārti. Sistēma darbojas gan sveču boutiques, gan 300 SKU dropshipping uzņēmumiem. Jūs pārtrauksiet izvēlēties rīkus pēc ieraduma un sāksiet izvēlēties pēc pierādījumiem. Izlaidiet jebkuru soli, un izmaksas parādīsies pirmā īstā pasūtījuma laikā. Uzbūvējiet sistēmu vienreiz, un katrs nākamais klients sekos tiem pašiem ceļiem. Klients nav problēma — jūsu process ir.

Jūsu klients piektdienas pēcpusdienā plkst. 16:53 sūta vienas rindiņas pieprasījumu: 'Vai varat vienkārši pievienot pirkšanas pogu manam Instagram?' Jūs jau savu veikalu šonedēļ esat viņam pārbūvējis. Apstājieties. Klients nav problēma; jūsu process ir. Šis raksts sniedz atkārtojamu ievadīšanas sistēmu: standartizēta sākotnējās informācijas lapa, platformas lēmumu matrica, maksājumu risinājumu noklusējumi, atbilstības pārbaudes, produktu datu standarti, testēšanas skripts priekšražošanas vidē un palaišanas vārti. Uzbūvējiet to vienreiz, un katrs nākamais veikals sekos tiem pašiem ceļiem. Jūs pārtrauksiet risināt vienu un to pašu problēmu atkārtoti un sāksiet nodot veikalus ekspluatācijā.

1. Uztveriet ievākšanu kā vārtus, nevis sarunu

Viens klients pārdod 12 aromātiskās sveces un vēlas uzsākt darbību pirms svētku tirgus. Cits vēlas nodarboties ar dropshipping 300 SKU no trim dažādiem piegādātājiem. Sveču klientam rūp ātrums; dropshipping klientam rūp krājumu sinhronizācija un pasūtījumu maršrutēšana. Ja abiem jautāsiet 'kāds ir jūsu budžets un kādu platformu vēlaties,' jūs saņemsiet divas nederīgas atbildes, un pēc mēneša jūs pārbūvēsiet vienu no šiem veikaliem.

Nosūtiet vienas lapas sākotnējās informācijas dokumentu, pirms pieskarieties jebkuram rīkam. Padariet šos jautājumus obligātus:

• Cik SKU plānojat pārdot pirmajās 90 dienās?
• Fiziski, digitāli vai jaukti?
• Kurš izpilda pasūtījumus — jūs, piegādātājs vai trešā puse?
• Kāda ir vidējā pasūtījuma vērtība?
• Vai pārdodat pāri štata vai valsts robežām? Kur jums ir nodokļu klātbūtne?
• Vai piedāvāsiet abonementus, priekšpasūtījumus vai vairāku vienību komplektus?
• Kāda ir viena funkcija, kurai šim veikalam ir jābūt pirmajā mēnesī?

Lieciet klientam ierakstīt atbildes, nevis izstāstīt tās pa tālruni. Rakstiskas atbildes kļūst par ierakstu. Mutiskas atbildes sestajā nedēļā kļūst par 'es to nekad neteicu'.

Pēc tam uzrakstiet trīs rindiņu kopsavilkumu par ierobežojumiem: budžets, ātrums un obligāti nepieciešamā funkcija. Ievietojiet to projekta faila augšpusē. Kad klients vēlāk pieprasa funkciju, kas maina arhitektūru, norādiet uz dokumentu un sakiet: 'Tas maina platformu. Lūk, cik tas maksā.'

Kāpēc tas ir svarīgi: platformas izvēle ir šīs informācijas lapas rezultāts. Ja izlaidīsiet šo soli, jūs izvēlēsieties to, ko izmantojāt pēdējo reizi. Pētījumi par e-komercijas platformām ir vienisprātis: dažādiem uzņēmējdarbības modeļiem ir nepieciešama atšķirīga arhitektūra. 12 SKU sveču veikals un 300 SKU dropshipping uzņēmums ir atšķirīgi uzņēmumi, tāpēc izturieties pret tiem atšķirīgi. Mēs jau esam rakstījuši par kāpēc viena platforma neder katram klientam; šī informācijas lapa ir tas, kā jūs to īstenojat.

2. Veidojiet platformas matricu pēc klienta profila, nevis pēc ieraduma

Lūk, modelis, kas pastāvīgi izgāžas: jūs atverat vienu un to pašu mitināto vilkšanas un nomešanas (drag-and-drop) veidotāju katram jaunam veikalam, jo tas ir ātri. Tad klientam ar fizisku veikalu ir nepieciešams sinhronizēt krājumus ar kases aparātu. Jūsu iecienītākais veidotājs to nevar izdarīt bez trim maksas lietotnēm. Trešajā nedēļā maināt platformu, un visi zaudē laiku.

Lēmumu matrica to novērš. Tā attiecina klienta ierobežojumus uz platformas kategorijām, nevis uz zīmolu nosaukumiem. Glabājiet to koplietotā dokumentā un atjauniniet reizi ceturksnī. Sāciet ar šo darba versiju:

Klienta profils	Platformas kategorija	Kad tā uzvar
Zems SKU skaits, ātra palaišana, netehnisks īpašnieks	Mitināts vilkšanas un nomešanas veidotājs	Ātrums, lietotņu ekosistēma, iebūvēts mitināšana
Esoša satura vietne, svarīga dizaina kontrole	Atvērtā koda veikala spraudnis esošajai CMS	Saglabājiet vietni, pievienojiet komerciju
Augsts SKU skaits, sarežģīts katalogs, izaugsmes plāni	Mērogojama mitināta platforma ar spēcīgu API	Pielāgotas integrācijas, vairāku kanālu
Fizisks veikals plus tiešsaistes veikals	POS integrēts veidotājs	Krājumu sinhronizācija starp kanāliem
Ierobežots budžets, maz produktu	Viegls iebūvēts veikala vitrīna	Zemas ikmēneša izmaksas, vienkārša norēķināšanās

Šī ir kategoriju karte, nevis ranžējums. Klients, kuram nepieciešama vairāku valūtu atbalsts un abonementi, ietilpst mērogojamajā rindā neatkarīgi no tā, vai šī rinda jums patīk. Klientam ar pieciem produktiem nevajadzētu iegādāties uzņēmuma infrastruktūru.

Izmantojiet bezmaksas izmēģinājumus apzināti. Pētījumi ir viennozīmīgi: daudzas platformas piedāvā bezmaksas izmēģinājumus. Lielākā daļa cilvēku izšķiež šos izmēģinājumus, klikšķinot cauri veidnēm. Tā vietā veiciet vienu testu no klienta informācijas lapas. Importējiet 300 faktiskos SKU. Ja importēšana neizdodas, izsvītrojiet šo platformu. Pārbaudiet norēķinu posmu ar īstu testa pasūtījumu. Pārbaudiet, vai nodokļu iestatījumi aptver klienta štatu. Izmēģinājums, kas simulē jūsu faktiskos ierobežojumus, ir lēmums; izmēģinājums, kas to nedara, ir izklaide.

Kad klients jautā, kāpēc izvēlējāties šo platformu, parādiet matricu un informācijas lapu. Tā jūs pieņemat aizstāvamu platformas lēmumu klienta priekšnieka, klienta grāmatveža vai savas komandas priekšā.

3. Nosakiet maksājumu risinājumu komplektu pēc naudas plūsmas, nevis pēc tā, kas ir pazīstams

Diviem klientiem ir divas naudas plūsmas realitātes. Viens pārdod 40 dolāru sveces un var gaidīt nedēļu uz maksājumiem. Cits pārdod 800 dolāru mēbeles un viņam ir nepieciešama nauda kontā dažu dienu laikā, lai iegādātos materiālus nākamajam pasūtījumam. Ja konfigurēsiet tos ar vienu un to pašu maksājumu vārteju, jūs vienu no viņiem nostādīsit neveiksmes priekšā. Maksājumu apstrādes ceļveži konsekventi norāda uz trim darbības svirām: maksājumu saņemšanas ātrums, cenu pārredzamība un atbalsta kvalitāte. Sāciet ar tām.

Ievērojiet šo secību:

1. Jautājiet, kāds ir klienta naudas aprites cikls. Vai maksājumi tiek veikti katru nedēļu vai katru dienu? Daži apstrādātāji norēķinās ātrāk, un daži tur līdzekļus ilgāk noteiktiem uzņēmējdarbības veidiem.
2. Pārbaudiet vārtejas integrāciju ar izvēlēto platformas kategoriju. Vai tā atbalsta abonementus, ja to prasa informācijas lapa? Vai tā atbalsta valstis, kas norādītas jūsu informācijas lapā?
3. Pirms izstrādes pārbaudiet klienta produktu kategoriju pret apstrādātāja ierobežoto sarakstu. Augsta riska kategorijas saņem iesaldētus kontus, nevis brīdinājuma e-pastus.
4. Ja klientam jau ir maksājumu metode, kurai viņu klienti uzticas — piemēram, plaši atzīts maksājumu maks — iekļaujiet to pat tad, ja tā palielina maksu. Uzticēšanās pārvērš pārdošanā labāk nekā maksas atšķirība.
5. Dokumentējiet, kuru vārteju, kuru kontu un kuru izmaksas grafiku klients apstiprināja. Ievietojiet to projekta failā ar datumu.

Konkrēts piemērs: mēbeļu klientam nepieciešami ātri maksājumi un atbalsts lielām pasūtījuma vērtībām. Sveču klientam nepieciešama vienkārša norēķināšanās un zemas pieskaitāmās izmaksas. Jūs, iespējams, pirmajam izvēlēsieties API-pirmo apstrādātāju, bet otrajam — iesācējiem draudzīgu apstrādātāju. To izlemj matrica. Jūsu ieradums to neizlemj.

Ja to izlaidīsit, problēma parādīsies otrajā nedēļā pēc palaišanas, kad klients zvanīs un teiks, ka viņu nauda ir iestrēgusi. Maksājumu pārstrāde skar norēķinu posmu, čekus, nodokļu atskaites un klienta uzticību. Tā ir visdārgākā lieta, ko varat pārbūvēt.

4. Veiciet atbilstības pārbaudes pirms dizaina

Jūs uzņematies klientu, kurš pārdod uztura bagātinātāju, kas ir legāls visur. Jūs izveidojat tīru veikalu, pieslēdzat maksājumu apstrādātāju un palaižat to. Pēc sešām nedēļām apstrādātājs iesaldē kontu, jo produktu kategorijai ir nepieciešama licence un atbilstības pārskatīšana. Jūsu dizains nekad nav bijis problēma. Trūkstošā dokumentācija bija.

Atbilstība ir palaišanas vārti, nevis administrēšana. Pirms jebkāda dizaina darba pārliecinieties:

• Uzņēmuma reģistrācija atbilst klienta faktiskajai juridiskajai personai.
• Pārdošanas nodokļa reģistrācijas pastāv katrā štatā, kur klientam ir saistība (nexus).
• Produktu kategoriju atļauj maksājumu apstrādātājs, kuru plānojat pieslēgt.
• Klientam ir licences vai atļaujas, ko prasa produktu veids.
• Lietošanas noteikumi, konfidencialitātes politika, atgriešanas politika un piegādes politika ir uzrakstīti un atbilst tam, ko veikals faktiski dara.

Veiciet to kā kontrolsarakstu ar atzīmējamām rūtiņām, nevis kā sarunu. Kad klients saka 'mans jurists to nokārtos,' nosakiet termiņu. Ja termiņš paiet, palaišanas datums tiek pārcelts. Tas nav jūsu spītīgums; tā ir jūsu palaišanas aizsardzība.

Ierasts padoms tiešsaistes veikaliem ir 'sāciet maz un attīstiet.' Tas darbojas produktu izvēlē un mārketingā. Tas nedarbojas atbilstības jomā. Veikala pārbūve tāpēc, ka apstrādātājs iesaldēja kontu, nav attīstība; tā ir izšķērdība. Ātra juridiskās sagatavošanas darba veikšana sākumā maksā mazāk nekā viens iesaldēts maksājums. Izlaidiet šo soli, un labākajā gadījumā jūs steidzīgi meklēsiet dokumentus. Sliktākajā gadījumā klients domās, ka izpostījāt viņa biznesu.

5. Standartizējiet produktu datu līgumu

Klients nosūta izklājlapu ar 300 produktiem. Katrā rindā ir nosaukums un cena. Nevienā rindā nav svara, izmēru, izcelsmes valsts vai piegādātāja koda. Jūs pieprasāt trūkstošos laukus. Klients nesaprot, kāpēc tas ir svarīgi. Projekts apstājas uz nedēļu. Pēc tam jūs palaižat veikalu ar piegādi 'bezmaksas', jo nevarējāt aprēķināt tarifus, un klients maksā par šo kļūdu.

Pārtrauciet pieņemt produktu datus jebkādā formā. Definējiet produktu datu līgumu. Katram produktam jāiekļauj vismaz:

• Iekšējais SKU un svītrkods
• Produkta nosaukums un apraksts, kas tiks publicēts vietnē
• Cena un salīdzināšanas cena (compare-at price)
• Svars un izmēri piegādei
• Izcelsmes valsts un, ja starptautisks, harmonizētās sistēmas kods
• Piegādātājs un izpildes laiks
• Piegādes profils (pārvadātāja klase un zonas)
• Produkta fotoattēla faila nosaukums un alternatīvais teksts
• Nodokļu kategorija

Izskatiet tos pašus divus klientus. Sveču klients sniedz 12 SKU. Jūs iestatāt laukus stundas laikā. Dropshipping klients sniedz 300 SKU. Jūs pieprasāt CSV eksportu no katra piegādātāja un kartējat šīs kolonnas ar līgumu. Ja piegādātājs nesniedz kādu lauku, tā ir iepirkuma problēma, kas klientam jāatrisina, nevis datu problēma, par kuru jums jāmin.

Standartizēti produktu dati ir viena lieta, kas padara platformas migrāciju lētu. Ja katalogs ir pareizi strukturēts, klienta pārcelšana uz citu platformu ir imports, nevis pārbūve. Ja tā nav, jūs pārrakstīsit 300 rindas un kļūdīsities. Varat arī izmantot šos strukturētos datus, lai izveidotu produktu sludinājumus, kas pārdod, jo teksti un alternatīvais teksts jau ir līgumā.

6. Izpildiet vienu un to pašu priekšprodukcijas testa skriptu katrā veikalā

Jūsu klients sūta ekrānuzņēmumu pulksten 9:00: 'Tas man iekasēja piegādi divreiz.' Jūs piesakāties un atrodat nepareizas valsts nodokļa likmi un atlaižu kodu, kas konfliktē ar piegādes loģiku. To salabot prasa divdesmit minūtes. Bet klients tikko zaudēja uzticību, un uzticība ir viss bizness.

Jums ir nepieciešams testa skripts. Tāda pati secība, tie paši soļi katram klientam:

1. Veiciet reālu testa pasūtījumu ar testa maksājuma metodi.
2. Apstipriniet, ka apstiprinājuma e-pasts sasniedz klientu.
3. Veiciet atmaksu un pārliecinieties, ka klients to redz.
4. Pielietojiet atlaižu kodu un pārbaudiet aprēķinu.
5. Pārbaudiet viesu norēķinu un autorizētā lietotāja norēķinu atsevišķi.
6. Pievienojiet produktu grozam no mobilā tālruņa, ne tikai datora priekšskatījumā.
7. Pārbaudiet starptautisku piegādes adresi, ja klients piegādā starptautiski.
8. Pārbaudiet nodokļa aprēķinu klienta mītnes štatam un vienam citam štatam.
9. Izraisiet noraidītu maksājumu un pārbaudiet kļūdas ziņojumu.
10. Apstipriniet, ka krājumi samazinās, kad tiek veikta pārdošana.

Izmantojiet zemu cenu testa produktu priekšprodukcijas vai melnraksta režīmā. Daudzas platformas piedāvā bezmaksas izmēģinājuma režīmus; izmantojiet tos šim nolūkam, nevis veidņu pārlūkošanai. Ierobežojiet testa laiku līdz pusstundai katram veikalam. Atkārtojams testa skripts ir ātrāks nekā pieeja 'viss droši vien ir kārtībā', jo jūs nekad nedomājat, ko esat aizmirsis.

Izlaidiet šo soli, un jūs apzināti nenosūtīsit salauztu veikalu. Jūs nosūtīsit veikalu ar vienu netestētu ceļu, un pirmais īstais klients to atradīs.

7. Pārtrauciet ļaut platformai būt pirmajam lēmumam

Klients pieslēdzas ievadīšanas zvanam un saka: 'Mēs vēlamies populāro mitināto veidotāju, jo kāds mārketingā to kādreiz izmantoja.' Jūs pavadāt divas dienas, kartējot viņu prasības šajā rīkā, un atklājat, ka tas nevar veikt vairāku valūtu norēķinus, ko prasa informācijas lapa. Tagad jums ir divas iespējas: paziņot sliktās ziņas un nokaitināt klientu vai izveidot nepareizo lietu.

Platforma ir rezultāts, nevis ievaddati. Jūsu informācijas lapa nosaka uzdevumu. Lēmumu matrica izvēlas kategoriju. Tikai tad jūs izvēlaties konkrētu rīku. Šī disciplīna šķiet pretēja, jo platformu mārketings vēlas, lai jūs izvēlētos rīku vispirms. Pretojieties tam.

Lūk, reālais kompromiss, ko vairums rakstu izlaiž: dažkārt klienta ierobežojums ir pamatots. Ja klientam jau ir izstrādātājs, kurš pārzina konkrētu platformu, vai noliktavas sistēma, kas integrējas tikai ar noteiktu ekosistēmu, šis ierobežojums ir jāiekļauj matricā. Ierakstiet to informācijas lapā kā 'jāintegrējas ar esošo X.' Pēc tam izvēlieties kategoriju, kas to atbalsta. Ja ierobežojums ir tikai zīmola izvēle, jautājiet klientam, kādu darbu viņi sagaida no šīs platformas. Tas, ko viņi patiesībā vēlas, parasti ir funkcija, un jūs varat nodrošināt šo funkciju, nemainot arhitektūru.

Brīdinājums ir reāls: nepārbūvējiet nākotnes vajadzībām, kuras nevarat redzēt. Sveču klientam nav nepieciešama vairāku piegādātāju integrācija. Dropshipping klientam ir. Atbilstiet informācijas lapai, nevis iedomātai nākotnei. Ja klients saka: 'mēs plānojam paplašināties starptautiski pēc 18 mēnešiem,' atzīmējiet to un izvēlieties kategoriju, kas to nebloķēs. Ja viņi saka: 'mēs tikai vēlamies to izmēģināt,' izvēlieties ātrāko variantu un plānojiet vēlāk mainīt platformu. Veidojiet saskaņā ar informācijas lapu.

8. Nosakiet palaišanas vārtus ar minimāli dzīvotspējīgu katalogu

Klientam vietne patīk. Viņiem vienkārši nav produktu fotoattēlu. 'Nākamnedēļ,' viņi saka. Pēc trim nedēļām veikals joprojām atrodas aiz 'Drīzumā' viettura. Jūsu komanda sāk pievienot papildu funkcijas, lai aizpildītu laiku, jo neviens nevēlas teikt klientam, ka projekts ir iesprūdis viņu pusē. Tad darba apjoms pieaug, un jūs zaudējat stundas.

Nosakiet palaišanas vārtus. Pirms projekta sākuma definējiet minimāli dzīvotspējīgu katalogu. Tajā jābūt pietiekami daudz produktu, lai veikals justos reāls šajā nišā — duci labu produktu bieži vien pietiek boutique, savukārt dropshipping uzņēmumam var būt nepieciešams atlasīts labāko produktu komplekts, nevis visi 300. Katram šī komplekta produktam jābūt fotoattēlam, cenai, aprakstam, svaram un izmēriem, kā arī apstiprinātam piegādātājam. Bez 'drīzumā' produktu lapām. Bez viettura tekstiem.

Nosakiet palaišanas vārtus, pamatojoties uz šiem nosacījumiem, visi no tiem ir bināri:

• Sākotnējās informācijas lapa ir aizpildīta un apstiprināta.
• Produktu datu līguma fails ir pilnīgs katram palaišanas produktam.
• Maksājumu risinājumu komplekts ir apstiprināts un testa pasūtījums ir izturēts.
• Atbilstības kontrolsaraksts ir pilnīgs.
• Priekšprodukcijas testa skripts ir izturēts.

Kad klients jautā: 'Vai mēs varam vienkārši palaist veikalu ar produktiem, kas ir gatavi?' atbilde ir jā, ja vien šie produkti atbilst pilnam līgumam. Tas nav perfekcionisms; tā ir atkārtojamība. Vārti pastāv, lai jūs nekad nepalaistu veikalu ar neredzamu atkarību.

Ja izlaidīsit vārtus, jūs uzņemsities klienta trūkstošo darbu. Jūs rediģēsiet izplūdušus fotoattēlus, izdomāsiet piegādes svarus un minēsiet nodokļu kategorijas. Šie minējumi kļūs par atmaksām, atprasījumiem un negatīvām atsauksmēm. Palaišanas vārti ir robeža starp jūsu un klienta darbu.

Secinājums: jūsu process ir produkts

Jūs nepārdodat vietnes. Jūs pārdodat paredzamu ceļu no 'es gribu veikalu' līdz 'veikals ir tiešsaistē un apstrādā pasūtījumus.' Šim ceļam ir nepieciešami noklusējumi, nevis improvizācija.

Nākamreiz, kad klients raksta piektdien plkst. 16:53, jums nekas nav jārisina no jauna. Jūs izmantojat informācijas lapu, pārbaudāt matricu, pārskatāt maksājumu risinājumu komplektu, izpildāt atbilstības sarakstu, apstiprināt produktu datus un izpildāt testa skriptu. Pēc tam jūs atbildat uz e-pastu ar plānu, nevis minējumu.

Sāciet sistēmu mazā mērogā. Šonedēļ pievienojiet vienu klientu sākotnējās informācijas lapai. Izveidojiet matricu koplietotā dokumentā. Uzrakstiet testa skriptu vienreiz un izmantojiet to atkārtoti. Katrs solis, ko tagad standartizējat, ir kļūda, ko neatkārtosiet nākamajiem pieciem klientiem.