Blogi

Korduv mänguraamat digitaaltoodete kohaletoimetamiseks

Korduv protsess digitaaltoodete kohaletoimetamiseks mitmele kliendile ilma iga kord sama arhitektuuri ümber ehitamata.

Kokkuvõte

Enamik digitaaltoodete nõuandeid eeldab ühekordset käivitamist, mis on kasutu, kui peate sama toimingut tegema mitme kliendi jaoks. See artikkel väidab, et toode pole strateegia – kohaletoimetamine on. Õpid standardiseerima kohaletoimetamise spetsifikatsiooni, automatiseerima maksehetke ning hoidma toe ja tagasimaksed inimlikuna. See hõlmab ka seda, kuidas vastu panna, kui klient küsib kohandatud portaali, kuidas hinnastada tootetüübi järgi ja millised kolm numbrit tegelikult tõestavad, et protsess toimib. Eesmärk on korduv süsteem, mis peab vastu kliendikontaktile, mitte nutikas turundusleht. Lõpuks tead täpselt, mida homme teha: kirjuta spetsifikatsioon.

Enamik nõuandeid digitaaltoodete müümiseks on kirjutatud inimesele, kes teeb seda täpselt üks kord. Vali platvorm, laadi fail üles, lisa meiliaadress ja nimeta see käivitamiseks. Hetkel, kui pead sama toimingut tegema teise kliendi jaoks, seejärel kolmanda jaoks, see nõuanne kukub kokku. Sul pole luksust igaühe jaoks kohandatud seadistus; sul on kohustus ehitada midagi korduvat. Toode ise on harva raske osa. Kohaletoimetamine on. Ja kohaletoimetamine on süsteemiprobleem, mitte loominguline.

Digitaaltoodete turg peaks 2027. aastaks ulatuma 848,5 miljardi dollarini, vastavalt MVST ülevaatele digitaaltoodete ärimudelitest. Ma ei tea, kui täpne see number on, ja sina ka mitte. See on mõeldud selleks, et tunneksid end peole hilinenuna. Ignoreeri seda. Oluline on see, et pidu on piisavalt suur, et kliendid paluvad jätkuvalt sinult abi, ja kui suhtud igasse koostöösse nagu lumehelbesse, oled liiga kurnatud, et tööd nautida.

Mis on suurim vale digitaaltoodete nõuannetes?

Suurim vale on see, et toode on strateegia. Kuuled palju kasumliku niši leidmisest, täiusliku kursuse ülesehituse kujundamisest või ühekordsete ostude ja tellimuste vahel valimisest. Need on reaalsed otsused, kuid inimese jaoks, kes peab kohale toimetama mitme kliendini, on need tegelikust kitsaskohast ülesvoolu. Kitsaskoht on üleandmine: mis juhtub selle vahel, kui keegi raha maksab ja tegelikult ostetut kasutab. Automatiseeritud süsteem suudab seda akent tundidelt sekunditele lühendada – ja mis veelgi olulisem, see suudab vähendada inimeste arvu, kes peavad tehingut puudutama.

Seega on tegelik mäng mitte armuda ühe kliendi tootesse. See on ehitada kohaletoimetamise arhitektuur, mida saab ümber seadistada ilma ümber kujundamata. See on teistsugune lihas, kui enamik digitaaltoodete nõuandeid treenib. See tähendab, et mõtled tootetüüpides, mitte toodetes; voogudes, mitte funktsioonides. Kui sa selle nii raamid, on järgmine küsimus ilmne.

Kas iga klient pole erinev?

Osaliselt, kuid vähem kui nad tahavad, et sa usuksid. Kursusel, mallipaketil, tarkvaralitsentsil ja e-raamatul on erinevad failid, erinevad hinnad ja erinevad kliendid. Neil on ka ühine skelett: osta, saa, kasuta, toeta. Kui alustad sellest skeletist, saad detaile häälestada ilma luid ümber ehitamata.

Allolev tabel on tahtlikult umbkaudne. See pole strateegia; see on viis klientide taotluste sorteerimiseks enne kujundamise alustamist.

Kliendi olukordMis tegelikult oluline onKuhu pingutust kulutada
Üksik fail (e-raamat, PDF, mallipakett)Hetkeline, taastatav allalaadimineFailihoidla, allalaadimisleht, lihtne litsentsimärkus
Kursus moodulite või tilkumissisugaJuurdepääsukontroll, edenemise jälgimineSisselogimine, kohaletoimetamise ajakava, meeldetuletused
Tarkvara või litsentsivõtmedVõtme genereerimine ja valideerimineAutomatiseeritud võtme kohaletoimetamine, selge toetee
Liikmelisus või tellimusKorduv juurdepääs ja arveldamineMaksete integreerimine, tühistamise käsitlemine

Kui klient ei oska öelda, millises reas nad on, pole sul vaja paremat platvormi. Sul on vaja paremat vestlust.

Kas peaksin iga kliendi jaoks valima erineva platvormi?

Ei. Ja kui sa sellele kaasa noogutad, siis las ma säästan su aasta kannatusi. Vaikimisi platvorm, mida tunned läbi ja lõhki, lööb paindlikuma, mida pead iga koostöö puhul uuesti õppima. Klienti ei huvita, millist platvormi kasutad. Neid huvitab, et allalaadimine töötab. Vali üks peamine müügikeskkond, õpi tundma selle piiranguid ja kujunda oma kohaletoimetamise arhitektuur nende piirangute ümber. Kui klient küsib midagi, mida vaikimisi ei oska, on see hetk rääkida kohandatud ehitusest – mitte varem.

See ei tähenda, et peaksid ignoreerima kliendi olemasolevat seadistust. See tähendab, et sul peaks olema arvamus. Kui klient ütleb, et nad on „juba“ mõnel platvormil ja see teeb asju teisiti, on sinu ülesanne võrrelda nende olukorda oma vaikimisvalikuga, mitte leiutada nende pärast ratast uuesti. Korduv protsess on protsess vaikimisvalikuga.

Mis siis, kui kliendil on juba poe seadistus?

Siis on su spetsifikatsioon lihtsalt muutunud. Sa ei kujunda nullist; sa auditid olemasolevat voogu. Käi nendega läbi neli küsimust: mida klient saab, millal, kuidas ja mis juhtub ebaõnnestumisel. Enamik olemasolevaid seadistusi kukub viimases küsimuses läbi. Kellelgi pole varulahendust lingi aegumiseks. See on sinu võimalus väärtust lisada ilma kogu poodi välja kiskumata.

Kiusatus on kohelda olemasolevat seadistust pühana. Pane vastu. Olemasolev pood on vaid lähtepunkt. Kui kohaletoimetamise tee on manuaalne, kulutab klient tund päevas faile käsitsi saates ja maksab sulle paranduse eest. Sa ei paranda seda rohkemate sammude lisamisega. Sa parandad selle, viies üleandmise maksehetke.

Kuidas ma tean, et protsess on tegelikult korratav?

Kirjuta see üles. Kui sa ei suuda protsessi töövõtjale kümne minutiga selgitada, pole sul protsessi, vaid harjumus. Korratav protsess peab vastu kliendile, kes muudab poole pealt meelt, ja peab vastu ka sinuga halval päeval.

Test on lihtne: kas saaksid spetsifikatsiooni kellelegi teisele üle anda ja saada sama väljundi? Agentuuri kontekstis on see vahe ühekordse töö ja teenuse vahel. Teenusel on määratletud piir ja piir on see, mis võimaldab skaleerida ilma stressi lisamata. Kui protsess sõltub sellest, et oled ruumis, pole see korratav, see on lihtsalt usaldusväärne.

Mida peaksin kõigepealt standardiseerima?

Alusta asjast, mida sa tegelikult kopeerida saad: kohaletoimetamise spetsifikatsioonist. See on üheleheküljeline dokument, mis määratleb iga müüdava tootetüübi puhul, mida klient saab, millal ta selle saab, kuidas ta sellele juurde pääseb ja kuidas ta abi saab. See kõlab igavalt. See ongi igav. Just sellepärast see töötabki.

Enne kui platvormi valid, kirjuta spetsifikatsioon. Siis saab igast kliendist sama malli variatsioon. „Mida klient saab? PDF-i ja allalaadimislingi. Millal? Kohe. Kuidas ta sellele juurde pääseb? Lehe kaudu, millele pääseb ligi ainult tema. Mis siis, kui see katki läheb? Piletivorm.“ Nüüd tead, mida ehitada, ja saad spetsifikatsiooni üle anda arendajale, töövõtjale või oma tulevasele minale. Olen kirjutanud rohkem selle kohta, kuidas muuta see korduvkasutatavaks artefaktiks kohaletoimetamise spetsifikatsioon igale kliendile, kuid versioon, mida täna vajad, on lihtsalt ülaltoodud neli küsimust.

Mida tegelikult automatiseerida tuleb?

Automatiseeri maksehetk. Teine pärast seda, kui tehing on kinnitatud, peaks klient saama faili, lingi, litsentsivõtme või avamismeili. Ükski inimene ei tohiks sellel teel olla. Automatiseerimise juhendid armastavad lubada, et see „lühendab kohaletoimetamise aja tundidelt sekunditele“, mis kõlab nagu tehniline brošüür, kuid sel juhul tehnoloogia tõesti tarnib. Kliendid ei taha olla muljet avaldatud; nad tahavad oma ostu.

Kuid ära automatiseeri kogu kliendisuhet. Saad automatiseerida üleandmise ja seejärel hoida vestluse inimlikuna. Eristus pole selles, et oleksid vanamoodne. See on selle vältimine, et iga toetaotlus saab automaatvastuse, mis ei vasta küsimusele, sest klient ei tahtnud inimese eest maksta. Õige järjekord on: muuda üleandmine nähtamatuks, seejärel tee inimene kättesaadavaks.

Mis peaks jääma käsitsi tehtavaks?

Tugi, tagasimaksed ja otsustusvõime. Need on ülesanded, mis näevad välja automatiseeritavad ja mida kindlasti ei tohiks automatiseerida, vähemalt mitte enne, kui oled näinud mõnda tosinat reaalset tehingut. Automaatvoogu peidetud tagasimaksmise poliitika on kingitus kliendile, kes oskab seda ära kasutada. Kaebus, mis saab automaatvastuse, tundub seinana.

See on argumendi vastupidine osa: maailmas, mis ütleb sulle kõik automatiseerida, on sinu konkurentsieelis kättesaadav olemine. Ostujärgne tund on koht, kus usaldus luuakse või hävitatakse, ja inimene suudab selle tunni jooksul rohkem kui ükski meilijada. Kui sul on kiusatus see tarkvarale üle anda, loe enne ostujärgset tundi.

Klient ütleb „lihtsalt aita mul müüma hakata“ – kust alustan?

Kui klient sulle selle lause ütleb, pane vastu kiusatusele kohe kujundama hüpata. Küsi kolm küsimust: mida sa müüd, kuidas sa tahad selle üle anda ja mis peaks juhtuma pärast seda, kui keegi selle ostab? Kui nad ei oska vastata, ära vali neile platvormi enne, kui nad oskavad.

Võtame tüüpilise näite: kliendil on komplekt SVG-faile käsitöötegijatele. Nad tahavad neid müüa, aga neil pole aimugi kohaletoimetamisest. Sul pole vaja liikmelisuse portaali, mobiilirakendust ega tilkumiskampaaniat. Sul on vaja kassalehte, allalaadimislinki ja väikest lehte, mis ütleb, mida ostja failidega teha saab. Ehita see, siis testi seda reaalse ostuga. Kõik.

Järjekord on iga kliendi puhul sama: määratle tootetüüp, vali kõige lihtsam täitmistee, kaardista ostujärgne kogemus ja lisa üks mõõdik, mis ütleb, kas tee töötab. Kõike seda saad lihtsa toote puhul teha ühe päevaga. Platvorm on detail.

Mis siis, kui klient soovib kohandatud portaali, liikmelisuse veebisaiti ja mobiilirakendust?

Siin pead olema aus, isegi kui see maksab sulle müügi. Kohandatud portaalide ehitamine on kallis ja nende hooldamine on valulik. Klient, kes seda küsib, ei vaja seda sageli; nad vajavad vabandust, et end professionaalsena tunda. Sinu ülesanne on tõlkida „tahan seda“ ümber „vajan seda“.

Korratav arhitektuur töötab seni, kuni ta ei tööta. Kui toode tõesti nõuab liikmelisuse süsteemi koos edenemise jälgimisega, ehita see eraldi tootetüübina oma kohaletoimetamise spetsifikatsiooniga. Aga kui klient küsib mobiilirakendust, sest tal on piinlik PDF-i müüa, tuleta talle meelde, et ükski klient pole kunagi PDF-i üle kurtnud, kui allalaadimine oli hetkeline ja sisu hea. Pane vastu enne, kui ratast uuesti leiutad.

Aga hinnastamine?

Hinnastamine väärib oma protsessi ja sa ei tohiks lasta ühe kliendi imelikel allahindlusharjumustel oma kohaletoimetamise arhitektuuri saastata. Kuid sinu kohaletoimetamise spetsifikatsioon kujundab tegelikult hinnavestlust. Kui tead, mida klient saab, millal ta selle saab ja mis on varulahendus, saad hinnata enesekindlalt – ja saad hinda kliendile selgitada ilma lugu välja mõtlemata „brändikapitalist“.

Lihtsaim viis hinnastamine mõistlikuna hoida erinevate klientide lõikes on siduda hind tootetüübiga, mitte kliendi entusiasmiga. Ühe faili mallipakkumisel on erinev hinnaklass kui täiskursusel ja sinu spetsifikatsioon muudab selle võrdluse loomulikuks. Süvitsi minekuks vaata digitaaltoodete hinnastamist maksimaalse kasumi jaoks.

Aga liiklus ja turundus?

Siin mandub enamik nõuandeid „postita sotsiaalmeediasse ja looda“. Sa saad paremini hakkama, kui kohtled turundust teise korratava süsteemina: tootekirjeldus, mis selgitab tulemust, näidis või teaser ja lihtne viis meiliaadresside kogumiseks enne käivitamist. Sul pole vaja viiruslehtrit. Sul on vaja prognoositavat.

Lõks on lasta igal kliendi „brändihäälel“ õigustada tervet uut turundusprotsessi. Saad tooni kohandada ilma samme muutmata. Sammud on: näita probleemi, näita lahendust, näita tõestust, küsi müüki. See töötab e-raamatu, kursuse ja SVG-failide komplekti puhul. See on ebadramaatiline ja peab vastu kliendile, kellel pole aimugi, milline nende bränd kõlama peaks.

Kuidas seda kliendile esitleda ilma konsultandina kõlamata?

Ära esitle protsessi protsessina. Esitle seda sellena, mida nad saavad: poelett, mis annab toote kliendile automaatselt üle, toetee, mis ei söö sinu kliendi nädalavahetust, ja käivitamine, mis ei vaja arendajat. Kui alustad „kohaletoimetamise spetsifikatsioonist“, kaotad nad. Kui alustad „teie kliendid saavad kohe selle, mille eest maksid“, siis ei kaota.

Boonus on see, et korratav protsess annab sulle kaitstava ulatuse. Kui klient küsib midagi spetsifikatsioonist väljaspool, saad öelda „see on eraldi tootetüüp“ selle asemel, et „see on palju lisatööd“. Teine kõlab vabandusena. Esimene kõlab professionaalse piirina. Mõlemad ütlevad ei; üks hoiab suhte puutumatuna.

Mis siis, kui kliendil pole veel toodet?

Siis ei tee sa kohaletoimetamise projekti, vaid tootearenduse projekti. Ole erinevuse osas selge enne alustamist. On ahvatlev öelda „ehitan sulle kursuse“, aga kui klient ei oska öelda, millise tulemuse ostja saab, ehitad platvormi sisule, mida pole olemas.

Sel juhul on esimene samm ikkagi spetsifikatsioon – kuid spetsifikatsioon kirjeldab toodet, mitte ainult kohaletoimetamist. Kes on ostja? Mis probleem neil on? Mida nad saaksid pärast ostmist teha? Kui need vastused on olemas, on kohaletoimetamise arhitektuur sama mis igal teisel tootetüübil. Ära lase toote puudumisel saada vabanduseks kohaletoimetamise üle keeruliseks muutmiseks.

Mida peaksin mõõtma?

Mõõda üleandmist. Täpsemalt mõõda aega makse ja selle vahel, kui klient saab midagi kasulikku, ostude ja edukate allalaadimiste suhet ning tagasimaksetaotluste osakaalu. Need kolm numbrit ütlevad, kas kohaletoimetamise süsteem on terve. Ära lase end segada lehevaadetest, näitamistest ega „kaasatusest“, kui sulle ei maksta aruannete tootmise eest, mida keegi ei loe.

Kui üleandmise aeg on järjekindlalt lühike, märkad, et tagasimaksed vähenevad ja toetuspiletid muutuvad vähem veidraks. See pole hunnik statistikat; see on lihtsalt see, mis juhtub, kui inimesed saavad selle, mille eest maksid. Sul pole selleks armatuurlauda vaja. Sa pead jälgima üleandmist.

Mis on see üks asi, mida sa homme tegema peaksid?

Kirjuta kohaletoimetamise spetsifikatsioon. Mitte homme – täna pärastlõunal. Võta tootetüüp, mida kõige tõenäolisemalt järgmisena müüd, ava tühi dokument ja vasta neljale küsimusele: mis, millal, kuidas ja mis siis, kui see katki läheb. See üksik artefakt on väärtuslikum kui ükski uus platvormifunktsioon.

Kõik muu digitaaltoodete nõuannetes on enamasti müra. Turg on suur, hüpe on vali ja tööriistad muudavad nimesid iga kvartal. See, mis ellu jääb, on protsess, mis muudab „klient X tahab müüa asja“ korratavaks vastuseks, mille oled juba läbi mõelnud. Ehita see üks kord ja lõpetad oma aja müümise. Hakkad müüma süsteemi.

Sources (5)