Toistettava pelikirja digitaalisten tuotteiden toimittamiseen

Yhteenveto

Useimmat digitaalisia tuotteita koskevat neuvot olettavat kertaluonteisen lanseerauksen, joka on hyödytön, kun sama operaatio on toistettava useille asiakkaille. Tämä artikkeli väittää, että tuote ei ole strategia – toimitus on. Opit standardoimaan toimitusmäärittelyn, automatisoimaan maksuhetken ja pitämään tuen ja hyvitykset inhimillisinä. Se käsittelee myös sitä, miten vastustaa asiakkaan pyyntöä mukautetusta portaalista, miten hinnoitella tuotetyypin mukaan ja mitkä kolme lukua todistavat prosessin toimivan. Tavoitteena on toistettava järjestelmä, joka kestää kontaktin asiakkaisiin, ei nokkelasti suunniteltu markkinointisuppilo. Lopussa tiedät tarkalleen, mitä tehdä huomenna: kirjoita määrittely.

Useimmat neuvot digitaalisten tuotteiden myymisestä on kirjoitettu henkilölle, joka tekee tämän vain kerran. Valitse alusta, lataa tiedosto, lisää sähköposti ja kutsu sitä lanseeraukseksi. Heti kun sinun on ajettava sama operaatio toiselle asiakkaalle ja sitten kolmannelle, nämä neuvot romahtavat. Sinulla ei ole ylellisyyttä räätälöidä asetuksia jokaiselle; sinulla on velvollisuus rakentaa jotain toistettavaa. Itse tuote on harvoin vaikea osuus. Toimitus on. Ja toimitus on järjestelmäongelma, ei luova ongelma.

Digitaalisten tuotteiden markkinoiden ennustetaan saavuttavan 848,5 miljardia dollaria vuoteen 2027 mennessä MVST:n katsauksen mukaan digitaalisten tuotteiden liiketoimintamalleista. Minulla ei ole aavistustakaan, kuinka tarkka tuo luku on, eikä sinullakaan. Se on olemassa saadakseen sinut tuntemaan, että olet myöhässä juhlista. Jätä se huomiotta. Tärkeää on, että juhlat ovat tarpeeksi suuret, jotta asiakkaat pyytävät sinulta apua, ja jos suhtaudut jokaiseen toimeksiantoon kuin lumihiutaleeseen, olet liian uupunut nauttiaksesi työstä.

Mikä on suurin valhe digitaalisia tuotteita koskevissa neuvoissa?

Suurin valhe on, että tuote on strategia. Kuulet paljon kannattavan markkinaraon löytämisestä, täydellisen kurssirungon suunnittelusta tai kertamaksujen ja tilausten välillä valitsemisesta. Nämä ovat todellisia päätöksiä, mutta henkilölle, jonka on toimitettava useille asiakkaille, ne ovat varsinaisen pullonkaulan yläpuolella. Pullonkaula on luovutus: mitä tapahtuu maksun ja ostetun tuotteen käytön välillä. Automaattinen järjestelmä voi kutistaa tämän ikkunan tunneista sekunteihin – ja mikä tärkeintä, se voi vähentää niiden ihmisten määrää, joiden on koskettava tapahtumaa.

Joten todellinen temppu ei ole rakastua yhden asiakkaan tuotteeseen. Se on toimitusarkkitehtuurin rakentaminen, jonka voit konfiguroida uudelleen ilman uudelleensuunnittelua. Se on erilainen lihas kuin mihin useimmat digitaalisia tuotteita koskevat neuvot harjoittavat. Se tarkoittaa, että ajattelet tuotetyyppeinä, et tuotteina; virtoina, et ominaisuuksina. Kun kehystät sen näin, seuraava kysymys on ilmeinen.

Eikö jokainen asiakas ole erilainen?

Osittain, mutta vähemmän kuin he haluavat sinun uskovan. Kurssilla, mallipakkauksella, ohjelmistolisenssillä ja e-kirjalla on erilaiset tiedostot, eri hinnat ja erilaiset asiakkaat. Niillä on myös yhteinen runko: osta, vastaanota, käytä, tue. Jos aloitat tästä rungosta, voit hienosäätää yksityiskohtia ilman, että rakennat luita uudelleen.

Alla oleva taulukko on tarkoituksella karkea. Se ei ole strategia; se on tapa lajitella asiakkaiden pyyntöjä ennen suunnittelun aloittamista.

Asiakkaan tilanne	Mikä oikeasti merkitsee	Mihin panostaa
Yksi tiedosto (e-kirja, PDF, mallipaketti)	Välitön, palautettavissa oleva lataus	Tiedostojen tallennus, lataussivu, yksinkertainen lisenssimaininta
Kurssi moduuleilla tai porrastetulla sisällöllä	Pääsynhallinta, edistymisen seuranta	Kirjautuminen, toimitusaikataulu, sähköpostimuistutukset
Ohjelmisto tai lisenssiavaimet	Avainten luonti ja validointi	Automaattinen avainten toimitus, selkeä tukipolku
Jäsenyys tai tilaus	Toistuva pääsy ja laskutus	Maksuintegraatio, peruutusten käsittely

Jos asiakas ei osaa kertoa, millä rivillä he ovat, et tarvitse parempaa alustaa. Tarvitset paremman keskustelun.

Pitäisikö minun valita eri alusta jokaiselle asiakkaalle?

Ei. Ja jos nyökkäät tälle, säästän sinut vuoden kivulta. Oletusalusta, jonka tunnet kuin omat taskusi, voittaa joustavamman, joka on opittava uudelleen joka toimeksiannossa. Asiakasta ei kiinnosta, mitä alustaa käytät. Heitä kiinnostaa, että lataus toimii. Valitse yksi ensisijainen myyntiympäristö, opi sen rajoitukset ja suunnittele toimitusarkkitehtuurisi näiden rajoitusten ympärille. Kun asiakas pyytää jotain, jota oletusarvo ei voi tehdä, silloin on aika puhua mukautetusta rakennuksesta – ei aikaisemmin.

Tämä ei tarkoita, että sinun pitäisi jättää huomiotta asiakkaan olemassa oleva asennus. Se tarkoittaa, että sinulla pitäisi olla mielipide. Jos asiakas sanoo olevansa “jo jollain” alustalla ja se toimii eri tavalla, tehtäväsi on verrata heidän tilannettaan oletusarvoosi, ei keksiä pyörää uudelleen heidän vuokseen. Toistettava prosessi on prosessi, jolla on oletusarvo.

Entä jos asiakkaalla on jo kauppa pystyssä?

Sitten määrittelysi on juuri muuttunut. Et suunnittele tyhjästä; auditoit olemassa olevaa virtaa. Käy heidän kanssaan läpi neljä kysymystä: mitä asiakas saa, milloin, miten ja mitä tapahtuu epäonnistuessa. Useimmat olemassa olevat asetukset epäonnistuvat viimeisessä kysymyksessä. Kenelläkään ei ole varasuunnitelmaa “latauslinkki on vanhentunut” -tilanteeseen. Se on mahdollisuutesi tuottaa lisäarvoa repimättä heidän koko kauppaansa irti.

Kiusaus on kohdella olemassa olevaa asennusta pyhänä. Vastusta sitä. Olemassa oleva kauppa on vain lähtökohta. Jos toimituspolku on manuaalinen, asiakas käyttää tunnin päivässä lähettääkseen tiedostoja käsin, ja he maksavat sinulle korjauksesta. Et korjaa sitä lisäämällä vaiheita. Korjaat sen siirtämällä luovutuksen maksuhetkeen.

Mistä tiedän, että prosessi on oikeasti toistettava?

Kirjoita se ylös. Jos et pysty selittämään prosessia urakoitsijalle kymmenessä minuutissa, sinulla ei ole prosessia, sinulla on tapa. Toistettava prosessi kestää kontaktin asiakkaaseen, joka muuttaa mieltään kesken kaiken, ja se kestää kontaktin sinuun huonona päivänä.

Testi on yksinkertainen: voisitko antaa määrittelyn jollekin toiselle ja saada saman lopputuloksen? Toimistokontekstissa se on ero keikan ja palvelun välillä. Palvelulla on määritelty raja, ja raja on se, mikä mahdollistaa skaalaamisen ilman stressin lisäämistä. Jos prosessi riippuu siitä, että olet itse paikalla, se ei ole toistettava, se on vain luotettava.

Mitä minun pitäisi standardoida ensin?

Aloita asiasta, jonka voit oikeasti kopioida: toimitusmäärittelystä. Tämä on yksisivuinen asiakirja, joka määrittelee jokaiselle myymällesi tuotetyypille, mitä asiakas saa, milloin hän saa sen, miten hän käyttää sitä ja miten hän saa apua. Se kuulostaa tylsältä. Se on tylsää. Juuri siksi se toimii.

Kirjoita määrittely ennen kuin valitset alustan. Sitten jokainen asiakas muuttuu muunnelmaksi samasta mallista. “Mitä asiakas saa? PDF:n ja latauslinkin. Milloin? Välittömästi. Miten hän pääsee siihen? Sivun kautta, johon vain hän pääsee. Mitä jos se rikkoontuu? Tikettilomake.” Nyt tiedät, mitä rakentaa, ja voit antaa määrittelyn kehittäjälle, urakoitsijalle tai tulevalle itsellesi. Olen kirjoittanut lisää tämän muuttamisesta uudelleenkäytettäväksi artefaktiksi toimitusmäärittely jokaiselle asiakkaalle, mutta versio, jota tarvitset tänään, on vain yllä olevat neljä kysymystä.

Mikä oikeastaan pitää automatisoida?

Automatisoi maksuhetki. Heti kun tapahtuma vahvistuu, asiakkaan pitäisi saada tiedosto, linkki, lisenssiavain tai avaussähköposti. Ihmisen ei pitäisi olla tämän polun keskellä. Automaatio-oppaat lupaavat mielellään, että tämä “lyhentää toimitusajan tunneista sekunteihin”, mikä kuulostaa tekniseltä esitteeltä, mutta tässä tapauksessa tekniikka todella toimittaa. Asiakkaat eivät halua olla vaikuttuneita; he haluavat ostoksensa.

Älä kuitenkaan automatisoi koko asiakassuhdetta. Voit automatisoida luovutuksen ja pitää sitten keskustelun inhimillisenä. Ero ei ole vanhanaikaisuudesta. Se on sen välttämistä, että jokainen tukipyyntö saa automaattisen vastauksen, joka ei vastaa kysymykseen, koska asiakas ei halunnut maksaa ihmisestä. Oikea järjestys on: tee luovutuksesta näkymätön ja aseta sitten ihminen saataville.

Minkä pitäisi pysyä manuaalisena?

Tuki, hyvitykset ja harkinta. Nämä ovat tehtäviä, jotka näyttävät automatisoitavilta, mutta joita ei todellakaan pitäisi automatisoida, ainakaan ennen kuin olet nähnyt muutaman tusinan todellisia tapahtumia. Automaattiseen virtaan haudattu hyvityskäytäntö on lahja asiakkaalle, joka osaa hyödyntää sitä. Valitus, joka saa automaattisen vastauksen, tuntuu seinältä.

Tämä on väitteen vastakkaisin osa: maailmassa, joka kehottaa automatisoimaan kaiken, kilpailuetusi on tavoitettavuus. Oston jälkeinen tunti on se, missä luottamus rakentuu tai tuhoutuu, ja ihminen voi tehdä sillä tunnilla enemmän kuin mikään sähköpostisarja. Jos sinua houkuttaa luovuttaa se ohjelmistolle, lue oston jälkeinen tunti ennen kuin teet niin.

Asiakas sanoo “saat minut vain myymään” – mistä aloitan?

Kun asiakas heittää tuon lauseen, vastusta halua hypätä suoraan suunnitteluun. Kysy kolme kysymystä: Mitä myyt, miten haluat luovuttaa sen ja mitä pitäisi tapahtua sen jälkeen, kun joku ostaa sen? Jos he eivät osaa vastata, älä valitse alustaa heille ennen kuin osaavat.

Otetaan tyypillinen esimerkki: asiakkaalla on joukko SVG-tiedostoja käsityöläisille. He haluavat myydä niitä, mutta heillä ei ole aavistustakaan toimituksesta. Et tarvitse jäsenyysportaalia, mobiilisovellusta tai tiputuskampanjaa. Tarvitset kassasivun, latauslinkin ja pienen sivun, jossa kerrotaan, mitä ostaja voi tiedostoilla tehdä. Rakenna se ja testaa sitten oikealla ostolla. Siinä kaikki.

Sekvenssi on sama jokaiselle asiakkaalle: määrittele tuotetyyppi, valitse yksinkertaisin toteutuspolku, kartoita oston jälkeinen kokemus ja lisää yksi mittari, joka kertoo, toimiiko polku. Voit tehdä kaiken tämän päivässä yksinkertaiselle tuotteelle. Alusta on yksityiskohta.

Entä jos asiakas haluaa mukautetun portaalin, jäsenyyssivuston ja mobiilisovelluksen?

Tässä sinun on oltava rehellinen, vaikka se maksaisi sinulle kaupan. Mukautetut portaalit ovat kalliita rakentaa ja tuskallisia ylläpitää. Asiakas, joka pyytää sellaista, ei usein tarvitse sitä; he tarvitsevat tekosyyn tunteakseen itsensä ammattilaiseksi. Tehtäväsi on kääntää “haluan sen” muotoon “tarvitsen sen”.

Toistettava arkkitehtuuri toimii, kunnes se ei toimi. Jos tuote aidosti vaatii jäsenyysjärjestelmän edistymisen seurannalla, rakenna se erillisenä tuotetyyppinä omalla toimitusmäärittelyllään. Mutta jos asiakas pyytää mobiilisovellusta, koska hävettää myydä PDF, muistuta heitä siitä, ettei yksikään asiakas ole koskaan valittanut PDF:stä, kun lataus oli välitön ja sisältö hyvä. Vastusta ennen kuin keksit pyörän uudelleen.

Entä hinnoittelu?

Hinnoittelu ansaitsee oman prosessin, etkä saa antaa yhden asiakkaan outojen alennustottumusten saastuttaa toimitusarkkitehtuuriasi. Mutta toimitusmäärittelysi itse asiassa muokkaa hinnoittelukeskustelua. Jos tiedät, mitä asiakas saa, milloin hän saa sen ja mikä varajärjestelmä on, voit hinnoitella luottavaisesti – ja voit selittää hinnan asiakkaalle keksimättä tarinaa “brändipääomasta”.

Helpoin tapa pitää hinnoittelu järkevänä eri asiakkailla on sitoa hinta tuotetyyppiin, ei asiakkaan innostukseen. Yksittäisen tiedoston mallipaketilla on eri hintahaarukka kuin täydellä kurssilla, ja määrittelysi tekee vertailusta luontevaa. Jos haluat syvällisemmän katsauksen, katso digitaalisten tuotteiden hinnoittelu maksimaalisen voiton saavuttamiseksi.

Entä liikenne ja markkinointi?

Tässä useimmat neuvot vesittyvät muotoon “julkaise sosiaalisessa mediassa ja toivo”. Voit tehdä paremmin kohtelemalla markkinointia toisena toistettavana järjestelmänä: tuotekuvaus, joka selittää lopputuloksen, näyte tai teaser sekä yksinkertainen tapa kerätä sähköpostiosoitteita ennen lanseerausta. Et tarvitse viraalia suppiloa. Tarvitset ennustettavan.

Loukku on antaa jokaisen asiakkaan “brändiäänen” oikeuttaa aivan uusi markkinointiprosessi. Voit säätää sävyä muuttamatta vaiheita. Vaiheet ovat: näytä ongelma, näytä ratkaisu, näytä todiste, pyydä kauppaa. Se toimii e-kirjalle, kurssille ja joukolle SVG-tiedostoja. Se on dramatiikaton, ja se kestää kontaktin asiakkaaseen, jolla ei ole aavistustakaan, miltä he haluavat brändinsä kuulostavan.

Miten esitän tämän asiakkaalle kuulostamatta konsultilta?

Älä esitä prosessia prosessina. Esitä se siinä muodossa, mitä he saavat: kauppapaikka, joka luovuttaa tuotteen asiakkaalle automaattisesti, tukipolku, joka ei vie asiakkaasi viikonloppua, ja lanseeraus, joka ei vaadi kehittäjää. Jos alat puhua “toimitusmäärittelystä”, menetät heidät. Jos alat puhua “asiakkaasi saavat maksamansa välittömästi”, et menetä.

Bonuksena toistettava prosessi antaa sinulle puolustettavan laajuuden. Kun asiakas pyytää jotain määrittelyn ulkopuolelta, voit sanoa “se on erillinen tuotetyyppi” sen sijaan, että sanoisit “se on paljon ylimääräistä työtä”. Jälkimmäinen kuulostaa tekosyyltä. Ensimmäinen kuulostaa ammattimaiselta rajalta. Molemmat sanovat ei; toinen pitää suhteen ennallaan.

Entä jos asiakkaalla ei ole vielä tuotetta?

Silloin et tee toimitusprojektia, vaan tuotekehitysprojektin. Ole selkeä erosta ennen aloittamista. On houkuttelevaa sanoa “rakennan sinulle kurssin”, mutta jos asiakas ei osaa kertoa, minkä lopputuloksen ostaja saa, rakennat alustaa sisällölle, jota ei ole olemassa.

Siinä tapauksessa ensimmäinen askel on silti määrittely – mutta määrittely kuvaa tuotteen, ei pelkästään toimitusta. Kuka on ostaja? Mikä ongelma heillä on? Mitä he pystyisivät tekemään ostamisen jälkeen? Kun nämä vastaukset ovat olemassa, toimitusarkkitehtuuri on sama kuin millä tahansa muulla tuotetyypillä. Älä anna tuotteen puuttumisen tulla tekosyyksi monimutkaistaa toimitusta.

Mitä minun pitäisi mitata?

Mittaa luovutus. Mittaa erityisesti aika maksun ja sen välillä, että asiakkaalla on jotain hyödyllistä, ostosten ja onnistuneiden latausten suhde sekä hyvityspyyntöjen osuus. Nämä kolme lukua kertovat, onko toimitusjärjestelmä terve. Älä anna sivunäyttöjen, näyttökertojen tai “sitoutumisen” häiritä, ellet saa palkkaa sellaisten raporttien tuottamisesta, joita kukaan ei lue.

Kun luovutusaika on jatkuvasti lyhyt, huomaat, että hyvitykset vähenevät ja tukipyynnöt muuttuvat vähemmän kummallisiksi. Se ei ole tilastokasa; se on vain sitä, mitä tapahtuu, kun ihmiset saavat maksamansa. Et tarvitse kojelautaa siihen. Sinun on tarkkailtava luovutusta.

Mikä on se yksi asia, joka sinun pitäisi tehdä huomenna?

Kirjoita toimitusmäärittely. Ei huomenna – tänä iltapäivänä. Ota todennäköisin seuraavaksi myytävä tuotetyyppi, avaa tyhjä asiakirja ja vastaa neljään kysymykseen: mitä, milloin, miten ja mitä jos se rikkoontuu. Tämä yksittäinen artefakti on arvokkaampi kuin mikään uusi alustaominaisuus.

Kaikki muu digitaalisia tuotteita koskevissa neuvoissa on enimmäkseen kohinaa. Markkinat ovat suuret, hype on kova ja työkalut vaihtavat nimeään joka neljännes. Se, mikä selviää, on prosessi, joka muuttaa “asiakas X haluaa myydä jutun” toistettavaksi vastaukseksi, jonka olet jo miettinyt läpi. Rakenna se kerran, niin lopetat aikasi myymisen. Ala myydä järjestelmää.