Prestaňte prestavovať obchod každého klienta: Opakovateľný systém onboardingu

Summary

Váš klient pošle jednoriadkovú požiadavku o 16:53 a vy ste opäť v jeho obchode a riešite rovnaký problém, ktorý ste vyriešili minulý týždeň. Tento článok mení tento chaos na opakovateľný systém onboardingu: štandardizovaný vstupný brief, maticu rozhodovania o platforme, predvolené platobné stacky, kontroly zhody, štandardy údajov o produktoch, testovací skript pre staging a spúšťaciu bránu. Systém funguje rovnako pre butiky so sviečkami aj pre dropshipperov s 300 SKU. Prestanete si vyberať nástroje zo zvyku a začnete ich vyberať na základe dôkazov. Ak vynecháte ktorýkoľvek krok, náklady sa prejavia pri prvej skutočnej objednávke. Postavte systém raz a každý budúci klient pôjde po rovnakých koľajach. Problém nie je klient – váš proces je.

Váš klient pošle jednoriadkovú požiadavku v piatok o 16:53: ‚Môžeš len pridať tlačidlo na nákup na môj Instagram?‘ Tento týždeň ste už raz prestavali jeho obchod. Prestaňte. Problém nie je klient; je to váš proces. Tento článok vám dáva opakovateľný systém onboardingu: štandardizovaný vstupný brief, maticu rozhodovania o platforme, predvolené platobné stacky, kontroly zhody, štandardy údajov o produktoch, testovací skript pre staging a spúšťaciu bránu. Postavte ho raz a každý budúci obchod pôjde po rovnakých koľajach. Prestanete riešiť rovnaký problém a začnete dodávať obchody.

1. Spustite vstup ako bránu, nie ako chat

Jeden klient predáva 12 voňavých sviečok a potrebuje spustiť pred vianočným trhom. Ďalší chce dropshipovať 300 SKU od troch rôznych dodávateľov. Klient so sviečkami sa stará o rýchlosť; dropship klient sa stará o synchronizáciu zásob a smerovanie objednávok. Ak sa oboch spýtate ‚aký máte rozpočet a akú platformu chcete‘, dostanete dve zbytočné odpovede a potom do mesiaca prestaviate jeden z tých obchodov.

Pošlite jednostránkový brief predtým, ako sa dotknete akéhokoľvek nástroja. Tieto otázky urobte povinnými:

• Koľko SKU plánujete predať za prvých 90 dní?
• Fyzický, digitálny alebo zmiešaný?
• Kto plní objednávky – vy, dodávateľ alebo tretia strana?
• Aká je priemerná hodnota objednávky?
• Predávate cez štátne alebo krajinné hranice? Kde máte daňovú prítomnosť?
• Budete ponúkať predplatné, predobjednávky alebo balíky s viac položkami?
• Aká je jediná funkcia, ktorú musí mať tento obchod v prvom mesiaci?

Nechajte klienta napísať odpovede namiesto toho, aby vám ich hovoril telefonicky. Napísané odpovede sa stanú záznamom. Slovné odpovede sa v šiestom týždni zmenia na ‚to som nikdy nepovedal‘.

Potom napíšte trojriadkový súhrn obmedzení: rozpočet, rýchlosť a nevyhnutná funkcia. Umiestnite ho na začiatok projektového súboru. Keď neskôr klient požiada o funkciu, ktorá mení architektúru, ukážte na brief a povedzte: ‚To mení platformu. Tu je, čo to stojí.‘

Prečo to záleží: výber platformy je výstupom tohto briefu. Ak ho preskočíte, vyberiete si to, čo ste použili naposledy. Výskum e-commerce platforiem sa zhoduje v jednom bode: rôzne obchodné modely potrebujú rôznu architektúru. Obchod so sviečkami s 12 SKU a dropshipper s 300 SKU sú rôzne podniky, takže s nimi zaobchádzajte rôzne. Už sme písali o prečo jedna platforma nebude vyhovovať každému klientovi; tento brief je spôsob, ako to uviesť do praxe.

2. Postavte maticu platforiem podľa profilu klienta, nie podľa zvyku

Tu je vzor, ktorý sa stále láme: pre každý nový obchod otvoríte rovnaký hostovaný drag-and-drop nástroj, pretože je rýchly. Potom klient s fyzickým obchodom potrebuje, aby sa zásoby synchronizovali s pokladnicou. Váš obľúbený nástroj to nedokáže bez troch platených aplikácií. V treťom týždni zmeníte platformu a všetci stratia čas.

Matica rozhodovania to rieši. Mapuje obmedzenia klienta na kategórie platforiem, nie na značky. Uchovávajte ju v zdieľanom dokumente a aktualizujte štvrťročne. Začnite s touto pracovnou verziou:

Profil klienta	Kategória platformy	Kedy vyhráva
Nízky počet SKU, rýchle spustenie, ne-technický vlastník	Hostovaný drag-and-drop nástroj	Rýchlosť, ekosystém aplikácií, vstavaný hosting
Existujúci obsahový web, záleží na dizajne	Open-source plugin pre obchod pre aktuálny CMS	Zachovajte web, pridajte obchod
Vysoký počet SKU, komplexný katalóg, plány rastu	Škálovateľná hostovaná platforma so silným API	Vlastné integrácie, multi-channel
Fyzický obchod plus online obchod	Nástroj s integrovanou pokladňou (POS)	Synchronizácia zásob naprieč kanálmi
Napätý rozpočet, málo produktov	Odľahčený vstavaný obchod	Nízke mesačné náklady, jednoduchý checkout

Toto je mapa kategórií, nie rebríček. Klient, ktorý potrebuje multi-menu a predplatné, patrí do škálovateľného riadku, či sa vám ten riadok páči alebo nie. Klient s piatimi produktmi by si nemal kupovať podnikovú infraštruktúru.

Používajte bezplatné skúšobné verzie zámerne. Výskum je konzistentný: mnoho platforiem ponúka bezplatné skúšobné verzie. Väčšina ľudí premrhá tieto skúšobné verzie preklikávaním šablón. Namiesto toho spustite jeden test z klientovho briefu. Importujte 300 skutočných SKU. Ak import zlyhá, túto platformu škrtnite. Otestujte checkout skutočnou testovacou objednávkou. Skontrolujte, či daňové nastavenia pokrývajú štát klienta. Skúšobná verzia, ktorá simuluje vaše skutočné obmedzenia, je rozhodnutie; tá, ktorá to nerobí, je zábava.

Keď sa klient opýta, prečo ste vybrali túto platformu, ukážte maticu a brief. Takto urobíte rozhodnutie o platforme, ktoré môžete obhájiť pred šéfom klienta, účtovníkom klienta alebo pred vlastným tímom.

3. Nastavte platobný stack podľa cash flow, nie podľa toho, čo je známe

Dvaja klienti, dve reality cash flow. Jeden predáva sviečky za 40 dolárov a môže čakať týždeň na vklady. Ďalší predáva nábytok za 800 dolárov a potrebuje peniaze späť na účte v priebehu niekoľkých dní, aby mohol nakúpiť materiál na ďalšiu objednávku. Ak ich nastavíte s rovnakou bránou, jedného z nich pripravíte na zlyhanie. Sprievodcovia platobným spracovaním konzistentne poukazujú na tri prevádzkové páky: rýchlosť vkladov, transparentnosť cien a kvalitu podpory. Začnite s nimi.

Dodržiavajte toto poradie:

1. Opýtajte sa, aký je hotovostný cyklus klienta. Týždenné alebo denné vklady? Niektorí spracovatelia vyrovnávajú rýchlejšie a niektorí držia finančné prostriedky dlhšie pre určité typy podnikov.
2. Skontrolujte integráciu brány s kategóriou platformy, ktorú ste si vybrali. Podporuje predplatné, ak to brief vyžaduje? Podporuje krajiny z vášho briefu?
3. Skontrolujte kategóriu produktov klienta proti obmedzenému zoznamu spracovateľa pred vytvorením. Vysoko rizikové kategórie dostávajú zmrazené účty, nie varovné e-maily.
4. Ak už klient má platobnú metódu, ktorej jeho zákazníci dôverujú – napríklad všeobecne uznávanú peňaženku – zahrňte ju, aj keď pridá poplatok. Dôvera konvertuje lepšie ako rozdiel v poplatku.
5. Zdokumentujte, ktorú bránu, ktorý účet a ktorý harmonogram výplat klient schválil. Uložte to do projektového súboru s dátumom.

Konkrétny príklad: klient s nábytkom potrebuje rýchle vklady a podporu pre veľké hodnoty objednávok. Klient so sviečkami potrebuje jednoduchý checkout a nízke réžie. Môžete skončiť s procesorom zameraným na API pre prvého a s procesorom vhodným pre začiatočníkov pre druhého. Rozhoduje matica. Nie váš zvyk.

Ak to preskočíte, problém sa objaví v druhom týždni po spustení, keď klient zavolá a povie, že ich peniaze sú zaseknuté. Oprava platieb sa dotýka checkoutu, účteniek, daňových hlásení a dôvery klienta. Je to najdrahšia vec, ktorú môžete prestavať.

4. Vykonajte kontroly zhody pred návrhom

Vezmete si klienta, ktorý predáva doplnok stravy, ktorý je legálny všade. Postavíte čistý obchod, pripojíte platobný procesor, spustíte. O šesť týždňov neskôr procesor pozastaví účet, pretože kategória produktov vyžaduje licenciu a kontrolu zhody. Váš návrh nikdy nebol problém. Chýbajúca papierovačka bola.

Zhoda je spúšťacia brána, nie administratíva. Pred akoukoľvek návrhárskou prácou potvrďte:

• Registrácia podniku sa zhoduje so skutočnou právnickou osobou klienta.
• Registrácie dane z obratu existujú pre každý štát, kde má klient nexus.
• Kategória produktov je povolená platobným procesorom, ktorý sa chystáte pripojiť.
• Klient vlastní licencie alebo povolenia, ktoré si typ produktu vyžaduje.
• Obchodné podmienky, zásady ochrany osobných údajov, zásady vrátenia tovaru a zásady dopravy sú napísané a zodpovedajú tomu, čo obchod skutočne robí.

Spustite to ako kontrolný zoznam so zaškrtávacími políčkami, nie ako konverzáciu. Keď klient povie ‚môj právnik to vybaví‘, stanovte termín. Ak termín uplynie, dátum spustenia sa posunie. To nie je vaša nepružnosť; to je ochrana spustenia.

Bežná rada pre online obchody je ‚začnite v malom a iterujte.‘ To funguje pre výber produktov a marketing. Neplatí to pre zhodu. Prestavba obchodu, pretože procesor zmrazil účet, nie je iterácia; je to plytvanie. Rýchly prechod právnym nastavením vopred stojí menej ako jedna zmrazená výplata. Preskočte tento krok a najlepší prípad je zháňanie dokumentov. Najhorší prípad je klient, ktorý si myslí, že ste mu zničili podnikanie.

5. Štandardizujte zmluvu o údajoch o produktoch

Klient pošle tabuľku s 300 produktmi. Každý riadok má názov a cenu. Žiadny riadok nemá hmotnosť, rozmery, krajinu pôvodu ani kód dodávateľa. Požiadate o chýbajúce polia. Klient nevidí, prečo to záleží. Projekt sa zastaví na týždeň. Potom spustíte s dopravou nastavenou na ‚zadarmo‘, pretože ste nevedeli vypočítať sadzby, a klient zaplatí za chybu.

Prestaňte prijímať údaje o produktoch v akejkoľvek podobe prídu. Definujte zmluvu o údajoch o produktoch. Každý produkt musí zahŕňať minimálne:

• Interné SKU a čiarový kód
• Názov produktu a popis, ktorý bude na webe
• Cena a porovnávacia cena (compare-at)
• Hmotnosť a rozmery pre dopravu
• Krajina pôvodu a, ak je medzinárodný, harmonizovaný systémový kód
• Dodávateľ a dodacia lehota
• Profil dopravy (trieda prepravcu a zóny)
• Názov súboru fotografie produktu a alternatívny text
• Daňová kategória

Prejdite si rovnakých dvoch klientov. Klient so sviečkami vám dá 12 SKU. Polia nastavíte za hodinu. Dropshipper vám dá 300 SKU. Vyžadujete CSV export od každého dodávateľa a mapujete stĺpce na zmluvu. Ak dodávateľ neposkytne pole, to je problém zdrojovania, ktorý musí vyriešiť klient, nie dátový problém, ktorý máte hádať.

Štandardizované údaje o produktoch sú jediná vec, vďaka ktorej je migrácia platformy lacná. Ak je katalóg správne štruktúrovaný, presun klienta na inú platformu je import, nie prestavba. Ak nie, prepíšete 300 riadkov a pomýlite sa. Tieto štruktúrované údaje môžete tiež použiť na vytvorenie zoznamov produktov, ktoré predávajú, pretože texty a alt texty sú už v zmluve.

6. Spustite rovnaký testovací skript na každom obchode

Váš klient pošle screenshot o 9:00: ‚Nabodovalo mi to dopravu dvakrát.‘ Prihlásite sa a nájdete daňovú sadzbu z nesprávnej krajiny a zľavový kód v konflikte s logikou dopravy. Oprava trvá dvadsať minút. Ale klient práve stratil dôveru a dôvera je celý biznis.

Potrebujete testovací skript. Rovnaké poradie, rovnaké kroky, každý klient:

1. Uskutočnite skutočnú testovaciu objednávku s testovacou platobnou metódou.
2. Potvrďte, že potvrdzovací e-mail dorazí zákazníkovi.
3. Spracujte refundáciu a potvrďte, že ju klient vidí.
4. Použite zľavový kód a skontrolujte výpočet.
5. Skontrolujte checkout pre hostí a prihlásených zvlášť.
6. Pridajte produkt do košíka z mobilného telefónu, nielen z desktopovej ukážky.
7. Otestujte medzinárodnú adresu dopravy, ak klient posiela do zahraničia.
8. Skontrolujte výpočet dane pre domovský štát klienta a jeden ďalší štát.
9. Spustite zamietnutú platbu a overte chybové hlásenie.
10. Potvrďte, že zásoby sa znížia pri predaji.

Použite testovací produkt s nízkou cenou v staging alebo konceptovom režime. Mnoho platforiem ponúka bezplatné skúšobné režimy; použite ich na toto, nie na prehliadanie šablón. Obmedzte test na pol hodinu na obchod. Opakovateľný testovací skript je rýchlejší ako prístup ‚všetko je pravdepodobne v poriadku‘, pretože nikdy netušíte, čo ste zabudli.

Ak to preskočíte, neodošlete rozbitý obchod úmyselne. Odošlete obchod s jednou netestovanou cestou a prvý skutočný zákazník ju nájde.

7. Prestaňte nechať platformu byť prvým rozhodnutím

Klient sa pripojí na onboardovací hovor a povie: ‚Chceme populárny hostovaný nástroj, pretože ho niekto z marketingu raz použil.‘ Strávite dva dni mapovaním ich požiadaviek do tohto nástroja a zistíte, že nedokáže urobiť multi-menový checkout, ktorý brief vyžaduje. Teraz máte dve možnosti: oznámiť to a naštvať klienta, alebo postaviť nesprávnu vec.

Platforma je výstup, nie vstup. Váš brief definuje prácu. Matica rozhodovania vyberie kategóriu. Až potom si vyberiete konkrétny nástroj. Táto disciplína sa zdá spätná, pretože marketing platformy chce, aby ste si nástroj vybrali ako prvý. Odolajte tomu.

Tu je skutočný kompromis, ktorý väčšina článkov vynecháva: niekedy je obmedzenie klienta legitímne. Ak už klient má vývojára, ktorý pozná konkrétnu platformu, alebo skladový systém, ktorý sa integruje len s konkrétnym ekosystémom, to obmedzenie patrí do matice. Napíšte ho do briefu ako ‚musí sa integrovať s existujúcim X.‘ Potom vyberte kategóriu, ktorá to umožní. Ak je obmedzenie len preferencia značky, opýtajte sa klienta, akú prácu od platformy očakáva. To, čo vlastne chcú, je zvyčajne funkcia, a tú funkciu môžete dodať bez zmeny architektúry.

Výhrada je reálna: neprestavajte pre budúce potreby, ktoré nevidíte. Klient so sviečkami nepotrebuje integráciu viacerých dodávateľov. Dropshipper áno. Prispôsobte sa briefu, nie imaginárnej budúcnosti. Ak klient povie ‚plánujeme expandovať medzinárodne o 18 mesiacov‘, poznačte si to a vyberte kategóriu, ktorá to nezablokuje. Ak povie ‚chceme to len vyskúšať‘, vyberte najrýchlejšiu možnosť a plánujte neskoršiu zmenu platformy. Stavajte pre brief.

8. Podmiente spustenie minimálnym životaschopným katalógom

Klient miluje web. Len nemá fotky produktov. ‚Budúci týždeň,‘ povedia. O tri týždne neskôr je obchod stále za zástupným textom ‚Čoskoro‘. Váš tím začne pridávať extra funkcie, aby vyplnil čas, pretože nikto nechce klientovi povedať, že projekt je zablokovaný na ich strane. Potom sa rozsah rozlezie a vy miniete hodiny.

Stanovte spúšťaciu bránu. Definujte minimálny životaschopný katalóg pred začiatkom projektu. Mal by obsahovať dostatok produktov, aby obchod pôsobil v tejto nike skutočne – tucet solídnych položiek je často dosť pre butik, zatiaľ čo dropshipper môže potrebovať vybranú zostavu najlepšie predávajúcich namiesto všetkých 300. Každý produkt v tejto zostave musí mať fotografiu, cenu, popis, hmotnosť a rozmery a potvrdeného dodávateľa. Žiadne stránky produktov s ‚Čoskoro‘. Žiadny zástupný text.

Podmiente spustenie týmito podmienkami, všetky sú binárne:

• Vstupný brief je vyplnený a schválený.
• Súbor zmluvy o údajoch o produktoch je úplný pre každý produkt pri spustení.
• Platobný stack je schválený a testovacia objednávka prešla.
• Kontrolný zoznam zhody je úplný.
• Testovací skript pre staging prešiel.

Keď sa klient opýta: ‚Môžeme spustiť len s produktmi, ktoré sú pripravené?‘ odpoveď je áno, pokiaľ tieto produkty spĺňajú plnú zmluvu. To nie je perfekcionizmus; je to opakovateľnosť. Brána existuje, aby ste nikdy nespustili obchod s neviditeľnou závislosťou.

Ak bránu preskočíte, absorbujete chýbajúcu prácu klienta. Budete upravovať rozmazané fotografie, vymýšľať hmotnosti dopravy a hádať daňové kategórie. Tieto odhady sa stanú refundáciami, chargebackmi a negatívnymi recenziami. Spúšťacia brána je hranicou medzi vašou prácou a prácou klienta.

Záver: váš proces je produkt

Nepredávate webové stránky. Predávate predvídateľnú cestu od ‚chcem obchod‘ po ‚obchod je živý a spracúva objednávky‘. Táto cesta potrebuje predvolené nastavenia, nie improvizáciu.

Nabudúce, keď klient napíše v piatok o 16:53, nemusíte nič znovu riešiť. Spustíte brief, skontrolujete maticu, prejdete platobný stack, prejdete zoznam zhody, potvrdíte údaje o produktoch a vykonáte testovací skript. Potom odpoviete na e-mail s plánom namiesto hádania.

Začnite so systémom v malom. Pridajte tento týždeň jedného klienta do vstupného briefu. Postavte maticu v zdieľanom dokumente. Napíšte testovací skript raz a používajte ho znova. Každý krok, ktorý teraz štandardizujete, je chyba, ktorú nezopakujete pre ďalších päť klientov.