Pakartojamas skaitmeninių produktų pristatymo vadovas

Santrauka

Dauguma patarimų apie skaitmeninius produktus daro prielaidą, kad produktas pristatomas vieną kartą, o tai nenaudinga, kai reikia vykdyti tą pačią veiklą keliems klientams. Šiame straipsnyje teigiama, kad produktas nėra strategija – pristatymas yra strategija. Sužinosite, kaip standartizuoti pristatymo specifikaciją, automatizuoti mokėjimo momentą ir išlaikyti palaikymą bei grąžinimus žmogiškus. Taip pat aptariama, kaip atsispirti, kai klientas prašo pasirinktinio portalo, kaip nustatyti kainas pagal produkto tipą ir kurie trys skaičiai iš tikrųjų įrodo, kad procesas veikia. Tikslas – pakartojama sistema, kuri išliktų bendraujant su klientais, o ne išradingas rinkodaros piltuvas. Galiausiai tiksliai žinosite, ką daryti rytoj: parašyti specifikaciją.

Dauguma patarimų, kaip parduoti skaitmeninius produktus, yra parašyti tam, kuris tai darys tik vieną kartą. Pasirinkite platformą, įkelkite failą, pridėkite el. laišką ir pavadinkite tai paleidimu. Kai jums tenka vykdyti tą pačią operaciją antram klientui, paskui trečiam, šie patarimai žlunga. Jūs neturite prabangos kiekvienam kurti individualų sprendimą; privalote sukurti kažką pakartojamo. Pats produktas retai būna sunkiausia dalis. Sunkiausia yra pristatymas. O pristatymas yra sistemos problema, o ne kūrybinė.

Numatoma, kad skaitmeninių produktų rinka iki 2027 m. pasieks 848,5 mlrd. JAV dolerių, teigiama MVST skaitmeninių produktų verslo modelių apžvalgoje. Neįsivaizduoju, kiek tikslus šis skaičius, ir jūs taip pat. Jis egzistuoja, kad jaustumėtės pavėlavę į vakarėlį. Ignoruokite jį. Svarbu tai, kad vakarėlis pakankamai didelis, o klientai vis prašo jūsų pagalbos, o jei į kiekvieną užduotį žiūrėsite kaip į snaigę, būsite pernelyg išsekę, kad galėtumėte mėgautis darbu.

Koks didžiausias melas skaitmeninių produktų patarimuose?

Didžiausias melas yra tai, kad produktas yra strategija. Daug girdėsite apie pelningos nišos radimą, tobulo kurso plano kūrimą arba vienkartinių pirkimų ir prenumeratų pasirinkimą. Tai realūs sprendimai, tačiau tam, kuris turi pristatyti produktus keliems klientams, jie yra prieš tikrąjį kliūtį. Kliūtis yra perdavimas: kas vyksta nuo to momento, kai kas nors sumoka pinigus, iki fakto, kad jis naudoja tai, ką nusipirko. Automatizuota sistema gali sutrumpinti šį laikotarpį nuo valandų iki sekundžių – ir, kas svarbiau, gali sumažinti žmonių, kurie turi liestis prie sandorio, skaičių.

Taigi tikrasis tikslas – ne įsimylėti vieno kliento produktą. Tikslas – sukurti pristatymo architektūrą, kurią galėtumėte perkonfigūruoti be naujo dizaino. Tai kitoks raumuo nei tas, kurį lavina dauguma skaitmeninių produktų patarimų. Tai reiškia, kad galvojate produkto tipais, o ne produktais; srautais, o ne funkcijomis. Kai taip įrėminsite, kitas klausimas tampa akivaizdus.

Argi kiekvienas klientas nėra skirtingas?

Iš dalies, bet mažiau, nei jie nori, kad patikėtumėte. Kursas, šablonų rinkinys, programinės įrangos licencija ir el. knyga turi skirtingus failus, skirtingas kainas ir skirtingus klientus. Tačiau jie taip pat turi bendrą skeletą: pirkti, gauti, pasiekti, palaikyti. Jei pradėsite nuo šio skeleto, galėsite reguliuoti detales neatstatydami kaulų.

Toliau pateikta lentelė sąmoningai apytikslė. Tai ne strategija; tai būdas surūšiuoti klientų prašymus prieš pradedant kurti.

Kliento situacija	Kas iš tikrųjų svarbu	Kur skirti pastangas
Vienas failas (el. knyga, PDF, šablonų rinkinys)	Momentinis, atkuriamas atsisiuntimas	Failų saugykla, atsisiuntimo puslapis, paprasta licencijos pastaba
Kursas su moduliais arba nuosekliai atskleidžiamu turiniu	Prieigos kontrolė, pažangos stebėjimas	Prisijungimas, pristatymo grafikas, el. pašto priminimai
Programinė įranga arba licencijos raktai	Raktų generavimas ir patvirtinimas	Automatizuotas raktų pristatymas, aiškus palaikymo kelias
Narystė arba prenumerata	Pasikartojanti prieiga ir atsiskaitymas	Mokėjimų integracija, atšaukimo tvarkymas

Jei klientas negali pasakyti, kurioje eilutėje jis yra, jums nereikia geresnės platformos. Jums reikia geresnio pokalbio.

Ar turėčiau kiekvienam klientui pasirinkti skirtingą platformą?

Ne. Ir jei jūs linkčiate tam, leiskite man sutaupyti jums metus kančių. Numatytoji platforma, kurią puikiai pažįstate, yra geresnė nei lankstesnė, kurią turite iš naujo mokytis kiekvieną kartą. Klientui nesvarbu, kokią platformą naudojate. Jiems svarbu, kad atsisiuntimas veiktų. Pasirinkite vieną pagrindinę pardavimo aplinką, susipažinkite su jos apribojimais ir suprojektuokite savo pristatymo architektūrą atsižvelgdami į šiuos apribojimus. Kai klientas prašo to, ko numatytoji platforma negali, tada ir reikia kalbėti apie individualų sprendimą – ne anksčiau.

Tai nereiškia, kad turėtumėte ignoruoti kliento esamą sąranką. Tai reiškia, kad turėtumėte turėti nuomonę. Jei klientas sako, kad jis „jau naudoja“ kokią nors platformą ir ji veikia kitaip, jūsų darbas yra palyginti jų situaciją su jūsų numatytąja, o ne išradinėti dviratį dėl jų. Pakartojamas procesas yra procesas su numatytąja konfigūracija.

O kas, jei klientas jau turi parduotuvės sąranką?

Tada jūsų specifikacija ką tik pasikeitė. Jūs nekuriate nuo nulio; jūs audituojate esamą srautą. Kartu su jais aptarkite keturis klausimus: ką klientas gauna, kada, kaip ir kas atsitinka, jei įvyksta klaida. Dauguma esamų sąrankų nepraeina paskutiniojo klausimo. Niekas neturi atsarginio varianto „atsisiuntimo nuoroda pasibaigė“. Tai jūsų galimybė pridėti vertės neišardant visos jų parduotuvės.

Pagunda traktuoti esamą sąranką kaip šventą. Atsispirkite. Esama parduotuvė yra tik atspirties taškas. Jei pristatymo kelias yra rankinis, klientas kiekvieną dieną valandą praleidžia siųsdamas failus ranka, ir jie moka jums už sprendimą. Jūs to neištaisysite pridėdami daugiau žingsnių. Jūs tai ištaisysite perkeldami perdavimą į mokėjimo momentą.

Kaip sužinoti, ar procesas iš tikrųjų yra pakartojamas?

Užsirašykite. Jei negalite paaiškinti proceso rangovui per dešimt minučių, vadinasi, turite ne procesą, o įprotį. Pakartojamas procesas išlieka net tada, kai klientas pakeičia nuomonę proceso viduryje, ir išlieka net tada, kai jūs turite blogą dieną.

Testas paprastas: ar galėtumėte perduoti specifikaciją kam nors kitam ir gauti tą patį rezultatą? Agentūros kontekste tai skirtumas tarp atsitiktinio darbo ir paslaugos. Paslauga turi apibrėžtą ribą, o būtent riba leidžia augti be papildomo streso. Jei procesas priklauso nuo to, kad esate kambaryje, jis nėra pakartojamas, jis tik patikimas.

Ką pirmiausia reikėtų standartizuoti?

Pradėkite nuo to, ką iš tikrųjų galite kopijuoti: pristatymo specifikacijos. Tai vieno puslapio dokumentas, kuriame kiekvienam jūsų parduodamam produkto tipui apibrėžiama, ką klientas gauna, kada gauna, kaip pasiekia ir kaip gauna pagalbą. Skamba nuobodžiai. Tai ir yra nuobodu. Būtent todėl tai veikia.

Prieš pasirinkdami platformą, parašykite specifikaciją. Tada kiekvienas klientas tampa to paties šablono variacija. „Ką klientas gauna? PDF failą ir atsisiuntimo nuorodą. Kada? Iškart. Kaip jis pasiekia? Per puslapį, kurį gali pasiekti tik jis. O jei kas nors sugenda? Bilietų forma.“ Dabar jūs žinote, ką kurti, ir galite perduoti specifikaciją kūrėjui, rangovui arba savo būsimam „aš“. Daugiau apie tai, kaip paversti tai daugkartiniu artefaktu, rašiau pristatymo specifikacijoje kiekvienam klientui, bet šiandien jums reikia tik aukščiau pateiktų keturių klausimų.

Ką iš tikrųjų reikia automatizuoti?

Automatizuokite mokėjimo momentą. Kai tik operacija įvykdoma, klientas turi gauti failą, nuorodą, licencijos raktą arba atblokavimo el. laišką. Šiame kelyje neturėtų būti jokio žmogaus. Automatizavimo vadovai mėgsta žadėti, kad tai „sumažins pristatymo laiką nuo valandų iki sekundžių“, o tai skamba kaip technologijų brošiūra, tačiau šiuo atveju technologija tikrai tai įvykdo. Klientai nenori būti sužavėti; jie nori gauti tai, ką nusipirko.

Tačiau neautomatizuokite visų klientų santykių. Galite automatizuoti perdavimą, o pokalbį palikti žmogišką. Skirtumas nėra susijęs su senamadiškumu. Tai susiję su situacijos, kai kiekvienas palaikymo prašymas gauna automatinį atsakymą, kuris neatsako į klausimą, nes klientas nenorėjo mokėti už žmogų, vengimu. Teisinga tvarka yra tokia: padarykite perdavimą nematomą, o tada suteikite žmogaus prieinamumą.

Kas turėtų likti rankiniu būdu?

Palaikymas, grąžinimai ir sprendimai. Tai užduotys, kurios atrodo, kad jas galima automatizuoti, ir tikrai neturėtų būti automatizuotos, bent jau tol, kol nematėte kelių dešimčių realių operacijų. Grąžinimo politika, paslėpta automatizuotame sraute, yra dovana klientui, kuris žino, kaip ją išnaudoti. Skundas, kuris gauna automatinį atsakymą, atrodo kaip siena.

Tai prieštaringa argumento dalis: pasaulyje, kuris liepia automatizuoti viską, jūsų konkurencinis pranašumas yra pasiekiamumas. Valanda po pirkimo yra laikas, kai pasitikėjimas kuriamas arba griaunamas, o žmogus per tą valandą gali padaryti daugiau nei bet kuri el. laiškų seką. Jei norite tai perduoti programinei įrangai, prieš tai perskaitykite valandą po pirkimo.

Klientas sako „tiesiog padėk man parduoti“ – nuo ko pradėti?

Kai klientas jums tai pasako, atsispirkite norui iškart pereiti prie dizaino. Užduokite tris klausimus: Ką jūs parduodate, kaip norite tai perduoti ir kas turėtų atsitikti po to, kai kas nors tai nusipirks? Jei jie negali atsakyti, neparinkite jiems platformos, kol galės.

Paimkime tipišką pavyzdį: klientas turi SVG failų rinkinį rankdarbiams. Jie nori juos parduoti, bet neturi supratimo apie pristatymą. Jums nereikia narystės portalo, mobiliosios programėlės ar lašelinės kampanijos. Jums reikia atsiskaitymo puslapio, atsisiuntimo nuorodos ir mažo puslapio, kuriame nurodyta, ką pirkėjas gali daryti su failais. Sukurkite tai, tada išbandykite su tikru pirkimu. Ir viskas.

Kiekvieno kliento seka yra ta pati: apibrėžkite produkto tipą, pasirinkite paprasčiausią įvykdymo kelią, sudarykite patirties po pirkimo žemėlapį ir pridėkite vieną metriką, kuri parodo, ar kelias veikia. Visa tai galite padaryti per vieną dieną paprastam produktui. Platforma yra detalė.

O kas, jei klientas nori pasirinktinio portalo, narystės svetainės ir mobiliosios programėlės?

Čia turite būti sąžiningi, net jei tai kainuos pardavimą. Pasirinktiniai portalai yra brangūs sukurti ir sunkiai prižiūrimi. Klientas, prašantis tokio portalo, dažnai jo nereikia; jiems reikia pasiteisinimo jaustis profesionalais. Jūsų darbas yra išversti „noriu“ į „man reikia“.

Pakartojama architektūra veikia tol, kol veikia. Jei produktui iš tikrųjų reikia narystės sistemos su pažangos stebėjimu, sukurkite ją kaip atskirą produkto tipą su savo pristatymo specifikacija. Bet jei klientas prašo mobiliosios programėlės, nes jam gėda parduoti PDF, priminkite, kad joks klientas niekada nesiskundė PDF failu, kai atsisiuntimas buvo akimirksniu ir turinys buvo geras. Atsispirkite, kol neišradinėjate dviračio.

O kaip dėl kainodaros?

Kainodara nusipelno savo proceso, ir neturėtumėte leisti, kad vieno kliento keisti nuolaidų įpročiai užterštų jūsų pristatymo architektūrą. Tačiau jūsų pristatymo specifikacija iš tikrųjų formuoja kainodaros pokalbį. Jei žinote, ką klientas gauna, kada gauna ir koks yra atsarginis variantas, galite nustatyti kainą užtikrintai – ir paaiškinti kainą klientui neišgalvodami istorijos apie „prekės ženklo vertę“.

Lengviausias būdas išlaikyti kainodarą protingą visiems klientams – susieti kainą su produkto tipu, o ne su kliento entuziazmu. Vieno failo šablonų rinkinys turi kitokį kainų intervalą nei pilnas kursas, o jūsų specifikacija padaro šį palyginimą natūralų. Norėdami sužinoti daugiau, skaitykite skaitmeninių produktų kainodarą maksimaliam pelnui.

O kaip dėl srauto ir rinkodaros?

Štai čia dauguma patarimų virsta „kelkite įrašus socialiniuose tinkluose ir tikėkitės“. Galite padaryti geriau, vertindami rinkodarą kaip dar vieną pakartojamą sistemą: produkto aprašymą, kuris paaiškina rezultatą, pavyzdį ar anonsą ir paprastą būdą rinkti el. pašto adresus prieš paleidimą. Jums nereikia virusinio piltuvo. Jums reikia nuspėjamo piltuvo.

Spąstai – leisti kiekvieno kliento „prekės ženklo balsui“ pateisinti visiškai naują rinkodaros procesą. Galite pakoreguoti toną nekeisdami žingsnių. Žingsniai tokie: parodykite problemą, parodykite sprendimą, parodykite įrodymus, paprašykite parduoti. Tai veikia el. knygai, kursui ir SVG failų rinkiniui. Tai nediplomatiška, ir tai išlieka bendraujant su klientu, kuris neįsivaizduoja, kaip turėtų skambėti jų prekės ženklas.

Kaip tai pristatyti klientui, kad neskambėtumėte kaip konsultantas?

Ne pristatykite procesą kaip procesą. Pristatykite jį kaip tai, ką jie gauna: vitriną, kuri automatiškai perduoda produktą klientui, palaikymo kelią, kuris nesuvalgo jūsų kliento savaitgalio, ir paleidimą, kuriam nereikia kūrėjo. Jei pradėsite nuo „pristatymo specifikacijos“, juos prarasite. Jei pradėsite nuo „jūsų klientai iškart gaus tai, už ką sumokėjo“, neprarasite.

Premija yra tai, kad pakartojamas procesas suteikia jums apginamą apimtį. Kai klientas prašo kažko, kas neįeina į specifikaciją, galite pasakyti „tai atskiras produkto tipas“ užuot sakę „tai daug papildomo darbo“. Antrasis skamba kaip pasiteisinimas. Pirmasis skamba kaip profesionali riba. Abu reiškia „ne“; vienas išlaiko santykius.

O kas, jei klientas dar neturi produkto?

Tada jūs dirbate ne pristatymo projektą, o produkto kūrimo projektą. Prieš pradėdami aiškiai supraskite skirtumą. Pagunda pasakyti „sukursiu jums kursą“, bet jei klientas negali pasakyti, kokį rezultatą gauna pirkėjas, kūrėte platformą turiniui, kurio nėra.

Tokiu atveju pirmas žingsnis vis tiek yra specifikacija – bet specifikacija apibūdina produktą, o ne tik pristatymą. Kas yra pirkėjas? Kokia problema jie turi? Ką jie galėtų daryti po pirkimo? Kai šie atsakymai egzistuoja, pristatymo architektūra yra tokia pati kaip ir bet kurio kito produkto tipo. Neleiskite, kad produkto nebuvimas taptų pasiteisinimu pernelyg sudėtingam pristatymui.

Ką turėčiau matuoti?

Matuokite perdavimą. Tiksliau, matuokite laiką nuo mokėjimo iki momento, kai klientas turi ką nors naudingo, pirkimų ir sėkmingų atsisiuntimų santykį bei grąžinimo prašymų dalį. Šie trys skaičiai parodo, ar pristatymo sistema yra sveika. Neleiskite atitraukti dėmesio puslapio peržiūroms, parodymams ar „įsitraukimui“, nebent esate apmokami už ataskaitas, kurių niekas neskaito.

Kai perdavimo laikas nuolat trumpas, pastebėsite, kad grąžinimų mažėja, o palaikymo bilietai tampa mažiau keisti. Tai ne krūva statistikos; tai tiesiog tai, kas atsitinka, kai žmonės gauna tai, už ką sumokėjo. Jums tam nereikia skydelio. Jums reikia stebėti perdavimą.

Ką vieną dalyką turėtumėte padaryti rytoj?

Parašykite pristatymo specifikaciją. Ne rytoj – šią popietę. Paimkite produkto tipą, kurį greičiausiai parduosite kitą, atidarykite tuščią dokumentą ir atsakykite į keturis klausimus: ką, kada, kaip ir kas atsitinka, jei kas nors sugenda. Šis vienas artefaktas yra vertingesnis nei bet kuri nauja platformos funkcija.

Visa kita skaitmeninių produktų patarimuose dažniausiai yra triukšmas. Rinka didelė, ažiotažas garsus, o įrankiai keičia pavadinimus kas ketvirtį. Išlieka procesas, kuris paverčia „klientas X nori parduoti daiktą“ į pakartojamą atsakymą, kurį jau apgalvojote. Sukurkite tai vieną kartą ir nustosite pardavinėti savo laiką. Pradedate pardavinėti sistemą.