SaaS svetainės iš vidaus į išorę: kodėl kainodara ir dokumentai pirmiausia

Summary

Dauguma patarimų apie SaaS svetaines prasideda nuo pagrindinio puslapio, o kainodarą, dokumentus ir DUK palieka kaip mintis po to — todėl tie puslapiai galiausiai prieštarauja vienas kitam. Šiame straipsnyje siūloma kurti iš vidaus į išorę: pradėkite nuo kainodaros puslapio ir API dokumentacijos, kur yra tikrieji produkto apribojimai, ir iš jų išveskite visa kita. Pateikiama šešių žingsnių sistema: surinkite apribojimus, sukurkite kainodaros puslapį kaip skeletą, vertinkite API dokumentus kaip produkto paviršių, išveskite funkcijų pristatymą iš darbo eigų, surinkite DUK iš realių pokalbių ir užbaikite nuoseklumo patikra. Šis metodas skirtas agentūroms, kurioms reikia pasikartojančio proceso skirtingiems klientams. Jame taip pat aptariamos situacijos, kada sistema yra perteklinė, ir kaip valdyti klientų lūkesčius.

Dauguma patarimų, kaip kurti SaaS svetaines, yra atvirkštiniai. Jie sako pradėti nuo pagrindinio puslapio — herojaus, antraštės, produkto ekrano nuotraukos — ir vertinti kainodarą, dokumentaciją bei DUK kaip puslapius, kuriuos užpildote, kai dizainas jau patvirtintas. O po kelių savaičių tenka derinti antraštės pažadą „viskas neribota“ su kainodaros puslapyje nurodytais faktiniais naudojimo apribojimais, o funkcijų skiltis išdidžiai pristato beta versijos funkciją, kurios API dokumentuose net neminima. Tokia tvarka veikia tik tada, kai produktas yra pakankamai paprastas, kad jokio derinimo nereikia, o tai būna retai. Kas iš tikrųjų veikia — ypač kai tai darote pakartotinai visiškai skirtingiems klientams — tai svetainės kūrimas iš vidaus į išorę: pradėkite nuo labiausiai apribotų, mažiausiai patrauklių puslapių (kainodaros ir API dokumentų) ir leiskite jiems sugeneruoti pagrindinį puslapį, funkcijų pristatymą ir DUK. Štai šešių žingsnių sistema, kaip tai padaryti, ir pakeliui atkreipsiu dėmesį, kur darosi nepatogu, nes taip ir yra.

Greitas skirtumo žemėlapis, nes visas argumentas juo remiasi:

	Pirmiausia puslapis (dažniausiai)	Pirmiausia apribojimai (ši sistema)
Nuo ko pradedate	Pagrindinio puslapio herojus ir vizualai	Kainodaros puslapis ir API dokumentai
Kas lemia tekstą	Prekės ženklo istorija ir dizainas	Faktiniai produkto apribojimai ir darbo eigos
Funkcijų pristatymas	Išvardija viską, ką produktas daro	Seka realių vartotojų kelius
DUK	Rašomas paskutinis, iš spėjimų	Renkamas iš palaikymo ir pardavimų
Rezultatas paleidimo metu	Nenuoseklūs teiginiai, paslėpti konfliktai	Puslapiai skaitomi kaip vienas produktas

1 žingsnis — Perskaitykite kainodaros puslapį, kol dar neparašėte nė žodžio.

Klientas jums duoda funkcijų sąrašą, prekės ženklo pristatymą ir demonstracinę nuorodą, ir paprašo pagrindinio puslapio. Iki pirmojo pokalbio pabaigos jūs aptarinėjate herojaus tekstą ir spalvų schemas. Pabandykite tai sulėtinti. Paprašykite kainodaros puslapio ir planų apribojimų — net jei tai tik Google Doc su pastabomis — ir pamatysite, kad visas projektas pasikeičia.

Jūs ieškote esminių apribojimų: ką reiškia vieta, kaip skaičiuojamas duomenų naudojimas, kokios funkcijos yra kokiame plane, ar yra API ir ką ji iš tikrųjų gali. Šie apribojimai yra pagrindinė tiesa. Kiekvienas jūsų teiginys rinkodaroje vėliau turi atlaikyti susidūrimą su jais.

Štai tipinė situacija. Klientas yra laiko sekimo įrankis: nemokamas planas, „Pro“ planas, „Įmonės“ planas. Pardavimų pristatyme rašoma „tinka bet kuriai komandai.“ „Pro“ puslapyje rašoma „neriboti projektai.“ Tačiau palaikymo komanda patvirtina, kad „Pro“ paskyros iš tikrųjų apribotos iki 10 aktyvių projektų vienoje darbo vietoje, o API dokumentuose nurodyta, kad projekte gali būti ne daugiau kaip 50 narių. Pagrindinis puslapis nebus kuriamas, kol kas nors neišspręs šio klausimo, nes „neriboti projektai“ dabar yra teisinis klausimas, o ne teksto klausimas. Jei būtumėte pradėję nuo pagrindinio puslapio, herojuje būtumėte parašę „neriboti projektai“ ir konfliktą atradę po dviejų savaičių, kai dizainas jau būtų patvirtintas. Pradėję nuo apribojimų, konfliktą pamatysite jau pirmąją savaitę, kai jį ištaisyti nieko nekainuoja.

Ką tiksliai turėtumėte surinkti šiame žingsnyje? Planų apibrėžimus ir bet kokią funkcijų palyginimo lentelę pagal planus. API dokumentaciją arba bent sąrašą, ką API gali ir ko negali. Dažniausius palaikymo komandos klausimus (plačiau apie tai 5 žingsnyje). Pardavimų pristatymą, nepamirštant, kad pardavimų pristatymuose ir gyvena fantazija. Ir patį produktą, atidarytą taip, kad matytumėte nustatymų puslapius, kuriuose apribojimai yra taikomi — nes pats produktas yra galutinis autoritetas. Nustatymų ekranas, kuriame rašoma „Daugiausia 10 projektų“, viršija bet kokią skaičiuoklę.

Šis žingsnis nesukuria rezultato. Jis sukuria faktų sąrašą — apribojimus, apibrėžimus, išimtis — su kuriuo tikrinsite kiekvieną kitą puslapį. Agentūrai tai taip pat žingsnis, skiriantis pasikartojantį darbą nuo gaisrų gesinimo. Užrašykite apribojimus bendrame dokumente ir turėsite tiesos šaltinį, į kurį remsis kiekvienas ateities puslapio atnaujinimas.

2 žingsnis — Sukurkite kainodaros puslapį kaip visos svetainės skeletą.

Kainodaros puslapis atrodo ne kaip vieta pradėti. Tai lentelė su skaičiais ir planų pavadinimais — mažiausiai patrauklus puslapis svetainėje. Tačiau tai produkto sutartis su vartotoju, ir čia nusprendžiama visos svetainės informacijos architektūra. Jei svetainės užduotis — šviesti lankytoją, kol jis pasiruošęs užsiregistruoti, kainodaros puslapis yra ta vieta, kur tas švietimas susilieja. Kiekviena funkcija, svarbi pirkimo sprendimui, yra įvardyta; kiekvienas svarbus apribojimas yra nurodytas arba su nuoroda.

Paimkite laiko sekimo įrankį. Trys planai: „Free“, „Pro“, „Enterprise“. Lentelėje reikia stulpelių, atspindinčių, kaip produktas iš tikrųjų segmentuojamas — projektų skaičius, integracijos, ataskaitų gylis. Kiekviename langelyje turi būti teisinga vertė, o ne trokštama. Jei „Pro“ apima 10 aktyvių projektų, langelyje rašoma 10 aktyvių projektų, su nuoroda į kainodaros DUK, paaiškinančiu, ką reiškia „aktyvus“ ir kas atsitinka, kai pasiekiate limitą. Vienas iš sunkiausių sprendimų — ką pasakyti apie planą, kurį labiausiai norite, kad lankytojai pirktų. Daugelyje kainodaros puslapių pagrindinis planas yra akivaizdus — paryškintas, su ženkleliu „Populiariausias“ — ir tekstas aplink jį paaiškina, kodėl jis tinka būtent šiam lankytojui. Laiko sekimo įrankiui „Pro“ yra pagrindinis: čia prasideda integracijos ir ataskaitų gylis, todėl puslapis turėtų tai aiškiai argumentuoti, o ne tikėtis, kad lankytojas pats perskaitys lentelę ir padarys išvadą.

Tai taip pat vieta, kur nusprendžiate, kurie terminai bus kanoniški visoje svetainėje. Jei produktas kainodaros puslapyje grupes vadina „darbo erdvėmis“, o rinkodaros tekstas sako „komandos“, kiekvienas paskesnis puslapis paveldi nenuoseklumą. Rašydami kainodaros puslapį pirmiausia, esate priversti pasirinkti žodyną, ir turėtumėte pasirinkti tą, kurį naudoja pats produktas — nes produktas ir dokumentai turi atitikti jį, o rinkodaros svetainė yra ta, kuri gali prisitaikyti.

Kainodaros puslapiui taip pat reikia savo DUK. Klausimai, kurie ten priklauso, yra susiję su konkrečia planų mechanika: kas laikoma vieta, kas atsitinka, kai sumažinate planą, ar atsiskaitymas vyksta kasmet ar kas mėnesį, ką reiškia „aktyvus“ projektui. Yra gerai išplėtota praktika, kaip struktūruoti kainodaros puslapius konversijoms, ir ta mechanika verta pasidomėti. Tačiau šioje sistemoje kainodaros puslapio užduotis — ne tik konvertuoti, bet ir užfiksuoti faktinius sprendimus, kurių laikysis kiekvienas kitas puslapis. Jei norite gilesnės mechanikos, šis vadovas, kaip taisyti SaaS kainodaros puslapius, išsamiai tai aptaria.

3 žingsnis — Vertinkite API dokumentaciją kaip produkto paviršių, o ne kaip vadovą.

Programuotojas vertina laiko sekimo įrankį. Jų įmonei reikia automatiškai perkelti darbo laiko apskaitos žiniaraščius į darbo užmokesčio sistemą. Dokumentai yra suskirstyti abėcėlės tvarka pagal galinius taškus: /projects, /reports, /timesheets, /users. Programuotojas nežino, nuo kurio skambučio pradėti, o skiltis „Autentifikavimas“ daro prielaidą, kad jis turi žinių, kurių neturi — dokumentuose niekada nepaaiškinama, kad API raktą reikia sukurti nustatymų puslapyje po „Integracijos“. Programuotojas uždaro skirtuką, įsitikinęs, kad produktas švariai nesintegruosis. Tačiau visa būtina informacija buvo dokumentuose; ji tiesiog buvo išdėstyta tokia tvarka, kokia naudotųsi informacinis vadovas, o ne žmogus.

Dokumentacija, suskirstyta pagal darbo eigą, būtų pakeitusi tą rezultatą: „Greitas startas“, „Autentifikuokite“, „Atsisiųskite darbo laiko apskaitą“, „Sukurkite projektą“, „Webhooks ir sinchronizavimas.“ Kiekviena skiltis pradedama nuo užduoties, tada rodomas galinis taškas. Greitas startas gali užtrukti penkias minutes ir sėkmingai atlikti API užklausą — tai dokumentacijos ekvivalentas nemokamos bandomosios versijos. Produktui, orientuotam į kūrėjus, tai yra įtikinamiausias puslapis svetainėje.

Bet kuriai SaaS, turinčiai API, dokumentacija yra jūsų svetainės puslapis, ar planavote ją taip, ar ne. Pramonės etalonas — nustatytas tokių įmonių kaip Stripe, GitHub ir Twilio — yra dokumentacija, kuri skaitoma kaip produktas: ji paaiškina užduotį, kurią programuotojas bando atlikti, o ne tik galinius taškus. Principas toks: API dokumentai yra produkto patirties dalis ir turėtų laikytis tos pačios logikos iš vidaus į išorę kaip ir likusi svetainės dalis: pradėkite nuo užduočių, kurias programuotojas gali atlikti, tada atskleiskite mechaniką.

Agentūrai papildomas privalumas yra tai, kad toks dokumentų rašymas iškelia apribojimų sąrašą į paviršių — ką API iš tikrųjų gali, kur yra užklausų limitai, kurių galinių taškų trūksta — ir šiuos konfliktus pastebėsite, kol jie dar nepasirodė rinkodaros puslapyje. Jei API dokumentacija yra didelė šio kliento svetainės dalis, yra išsamesnis vadovas, kaip rašyti dokumentus, kuriuos programuotojai iš tikrųjų naudoja.

4 žingsnis — Išveskite funkcijų pristatymą iš darbo eigų, o ne iš funkcijų sąrašo.

Klientas atsiunčia jums skaičiuoklę su 40 funkcijų ir prašo funkcijų puslapio. Lengviausias atsakymas — tinklelis: 40 elementų, kiekvienas su piktograma ir antrašte. Rezultatas atrodo išsamus, bet skaitomas kaip triukšmas, nes tinklelis neturi istorijos. Niekas neina į SaaS svetainę, kad sužinotų visas funkcijas; jie ateina sužinoti, ar šis produktas atlieka būtent tą darbą, dėl kurio jie atėjo. Todėl pristatymas turėtų būti kuriamas iš darbo eigų, o ne iš funkcijų sąrašo.

Išnagrinėkime pavyzdį. Dažniausias laiko sekimo įrankio sėkmės kelias, pasak kliento palaikymo komandos, yra komandos vadovas, kuris užsiregistruoja, pakviečia tris kolegas, sukuria projektą ir savaitės pabaigoje paleidžia ataskaitą. Tai ir yra darbo eiga. Funkcijų pristatymas turėtų sekti ja: skiltis apie komandos pakvietimą (apimanti vietas ir vaidmenis), skiltis apie projekto sukūrimą (apimanti šablonus ir projekto nustatymus), skiltis apie ataskaitų skydelį (apimanti diagramas ir eksportavimo parinktis). Kiekvienoje skiltyje rodoma ekrano nuotrauka iš tos konkrečios produkto akimirkos, o ne apkarpyta retai naudojamo nustatymų skydelio nuotrauka. Lankytojas mato savo kelią, o funkcijos, kurias jis mato pakeliui, yra tos, kurios jam svarbios.

Tolesnė darbo eiga, skirta šiek tiek kitokiam lankytojui, yra vadovas, kuris pats niekada nenaudoja įrankio: jis tvirtina darbo laiko apskaitą ir peržiūri savaitės ataskaitą. Pristatymas gali pridėti skiltį tam lankytojui pabaigoje — „Vadovams“ — nesulaužydamas pasakojimo. Paprastai pradžiai užtenka dviejų darbo eigų; nereikia po vieną kiekvienai asmenybei.

Įspėjimas — realus — yra tas, kad pristatymas, pagrįstas darbo eigomis, reikalauja žinoti, kokios yra dažniausios darbo eigos. Tam reikia kalbėtis su palaikymo ir pardavimų komandomis, o ne tik su produkto vadybininku. Jei klientas negali pasakyti, kokie yra trys pagrindiniai būdai, kaip žmonės naudoja produktą, tai pirmas dalykas, kurį reikia išspręsti, nes kitaip svetainė spėlios. Šis žingsnis dažnai atskleidžia, kad produktas neturi aiškios pagrindinės darbo eigos — tai produkto problema, o ne svetainės. Pasakykite tai sąžiningai; svetainė negali sukurti darbo eigos, kurios nėra. Norėdami sistemingai išdėstyti šias darbo eigas, šis straipsnis apie funkcijų pristatymo struktūrą konversijoms paaiškina sprendimų seką.

5 žingsnis — Rinkite DUK iš palaikymo ir pardavimų, o ne iš savo vaizduotės.

Iki svetainės paleidimo liko dvi dienos, o DUK vis dar tuščias. Instinktas yra per popietę parašyti dešimt klausimų — paprastai tuos, į kuriuos norėtumėte, kad produktas atsakytų, o ne tuos, kuriuos užduoda tikri klientai. Tai atvirkščia. DUK turi konkrečią užduotį: pašalinti paskutines abejones tarp lankytojo ir registracijos. Veiksmingi DUK puslapiai, kaip matote iš HubSpot, Slack ir Zendesk, veikia todėl, kad yra organizuoti pagal realias užklausas, yra ieškomi ir glausti. Jie yra klausymosi, o ne išradimo rezultatas.

Realistiškas scenarijus: esate kainodaros puslapyje ir žinote, kad didžiausia laiko sekimo įrankio kliūtis yra integracija: „Ar tai veikia su QuickBooks?“ Palaikymo žurnalų peržiūra rodo, kad tai dažniausias ikipardaviminis klausimas. Tas klausimas su atsakymu priklauso kainodaros puslapio DUK. Antras pagal dažnumą iš pardavimų skambučių: „Kas atsitiks mano darbo laiko apskaitai, jei atšauksiu?“ Jis taip pat ten priklauso. Kiekvienas atsakymas sutrumpina pardavimo ciklą ir sumažina palaikymo apkrovą, nes lankytojas, matantis atsakymą raštu, labiau pasitiki produktu nei tas, kuris turi klausti.

Agentūros taisyklė: nerašykite nė vieno DUK atsakymo, kol neperžiūrėjote palaikymo bilietų, pardavimų skambučių užrašų ir įtraukimo el. laiškų. Kokie klausimai iš tikrųjų kartojasi? Tie ir įtraukiami. Visa kita eina į funkcijų puslapį arba niekur. O svetainei vystantis, grįžkite prie DUK — kiekvienas kainodaros pakeitimas ar funkcijos pristatymas sukuria naujų klausimų, o DUK yra pigiausia vieta juos užfiksuoti.

Taip pat yra pagrindo pagalvoti apie DUK struktūrą, o ne tik turinį. Ilgą, slenkantį klausimų sąrašą sunku skenuoti; grupavimas pagal kategorijas (Atsiskaitymas, Integracijos, Paskyros valdymas) su turiniu viršuje daro jį tikrai naudojamą. Paieškos funkcija padeda, kai sąrašas išauga virš tam tikro dydžio — tai ta puslapio dalis, kur dizainas yra toks pat svarbus kaip tekstas, nes neieškomas DUK yra neskaitomas DUK.

Dar vienas dalykas, kuris yra nemalonus: DUK dažnai yra pats nuoširdžiausias svetainės puslapis, nes tai vienintelis puslapis, kuriame atsakote į klausimą, kurio lankytojas bijo paklausti. Jei į klausimą atsakyti nepatogu — „Ar tikrai galiu atšaukti bet kada?“ „Ar nemokamas planas rodo reklamas?“ — tas nepatogumas yra įrodymas, kad jis ten priklauso, o ne priežastis jį išmesti. Lankytojas turi tą klausimą, nesvarbu, ar atsakote, ar ne; jei neatsakote, jis sugalvos atsakymą, ir tas sugalvotas atsakymas bus blogesnis už tiesą.

6 žingsnis — Suvienodinkite ir atlikite kokybės užtikrinimą visuose puslapiuose, prieš rodydami klientui.

Jūs ketinate parodyti klientui užbaigtą svetainę. Prieš tai atidarykite kainodaros puslapį ir funkcijų puslapį greta. Patikrinkite kiekvieną funkcijos pavadinimą: ar jie sutampa? Patikrinkite kiekvieną skaičių: ar kainodaros puslapyje rašoma „10 projektų“, funkcijų puslapyje „iki 10 projektų“, o API nuorodoje „daugiausia 10“ — ar viskas vienoda? Patikrinkite kiekvieną pažadą: ar „neriboti projektai“ yra kur nors svetainėje, ir jei taip, ar tai tiesa? Tada ieškokite produkto žodyno: ar visur rašoma „darbo erdvės“, ar paslysta į „komandos“? Čia pastebėsite, kad pagrindinis puslapis sako „kreditinės kortelės nereikia“, o registracijos srautas iš tikrųjų prašo kreditinės kortelės nemokamai bandomajai versijai — būtent tokia nenuoseklumo klasė, kuri žudo pasitikėjimą.

Čia pasiteisina iš vidaus į išorę tvarka. Kadangi kiekvienas puslapis buvo išvestas iš tų pačių apribojimų, nuoseklumo darbas yra patikrinimas, o ne gelbėjimo misija. Tačiau nepraleiskite jo. Išliekantys prieštaravimai yra subtilūs — funkcija vadinama „patvirtinimai“ kainodaros puslapyje, bet „peržiūros srautai“ API dokumentuose, ekrano nuotrauka pagrindiniame puslapyje, rodanti tamsųjį režimą, kurio produktas neturi, teiginys, kad produktu „pasitiki nuotolinės komandos“, kilęs iš prekės ženklo pristatymo ir neatitinkantis tikrojo kliento klientų sąrašo.

Praktinė technika: padarykite apribojimų sąrašą kokybės užtikrinimo scenarijumi. Pereikite per kiekvieną puslapį ir patikrinkite kiekvieną faktą pagal sąrašą. Tai veikia, nes apribojimų sąrašas buvo parašytas pirmąją savaitę, prieš atsirandant puslapiams, todėl tai tikrai nepriklausomas šaltinis. Jei kokybės užtikrinimą pradėsite nuo dizaino arba iš atminties, praleisite faktus, kurie pasikeitė, kol kūrėte.

Šiuo metu priežastis, kodėl darbą reikia išdėstyti nuosekliai, tampa akivaizdi. Kai puslapiai kuriami lygiagrečiai iš skirtingų šaltinių, šis kokybės užtikrinimas kaskart randa konfliktų, o kiekvienas konfliktas reiškia perdarymą jau baigtame atrodančiame puslapyje. Kai puslapiai kuriami nuosekliai pagal vieną apribojimų sąrašą, kokybės užtikrinimas randa rašybos klaidas. Tai skirtumas tarp pasikartojančio proceso ir nuolatinės krizės. Kad visa svetainė po paleidimo pasakotų vieną istoriją — naujos funkcijos, naujos komandos, nauji tekstų autoriai — jums reikia tos pačios disciplinos priežiūros versijos, o sistema, skirta suvienodinti SaaS svetainės istoriją puslapiuose, yra natūralus kitas žingsnis.

Įspėjimai, kurie išlaiko tai sąžininga.

Trys dalykai, kurių ši sistema neteigia. Pirma, labai ankstyvos stadijos SaaS be API, su vienu planu ir vienu akivaizdžiu naudojimo atveju, tvarka turi daug mažesnę reikšmę; tą svetainę galėtumėte kurti bet kokia tvarka, o derinimo darbas būtų nereikšmingas. Sistema atsiperka, kai yra realus sudėtingumas — keli planai, API, daug funkcijų, kelios auditorijos. Netaikykite jos kaip dogmos produktui, kuris iš esmės yra nukreipimo puslapis su registracijos mygtuku.

Antra, kuriant iš vidaus į išorę, pradžioje matoma pažanga yra lėta. Klientas paprašė pagrindinio puslapio, o jūs pristatote kainodaros lentelę ir apribojimų dokumentą. Jie priešinsis, nes pagrindinis puslapis yra tai, ką jie gali parodyti investuotojams ir savo komandai. Tų lūkesčių valdymas — parodant jiems, kaip kainodaros puslapio sprendimai formuoja viską, kas toliau, — yra darbo dalis, o ne jo nesėkmė. Vienas būdų išlaikyti pagreitį — anksti sukurti apytikrį pagrindinio puslapio maketą, aiškiai pažymėtą kaip konteinerį, laukiantį turinio, kad klientas matytų tikslą, kol kuriate skeletą.

Trečia, apribojimų sąrašas keičiasi. Kainodara keičiasi, API plečiasi, planų daugėja. Sistema daro prielaidą, kad po paleidimo nuolat atnaujinsite apribojimų dokumentą, nes svetainė pradės nykti tą akimirką, kai nustos atspindėti realius produkto apribojimus. Tai iš vidaus į išorę metodo priežiūros kaina: tiesos šaltinis yra teisingas tik tada, jei kažkas jį valdo.

Išvada.

Dažniausia SaaS svetainių projektų nesėkmė nėra silpnas tekstas ar blogas dizainas — tai puslapiai, kurie nesutaria vienas su kitu, nes buvo sukurti neteisinga tvarka. Pradėkite nuo kainodaros puslapio ir API dokumentacijos, kur yra tikrieji produkto apribojimai; išveskite funkcijų pristatymą iš realių darbo eigų; surinkite DUK iš realių pokalbių; ir užbaikite nuoseklumo patikra, kuri patvirtina, o ne gelbsti. Atlikite tai keliems skirtingiems klientams ir pastebėsite, kad tai mažiau kūrybinis procesas, o labiau surinkimo linija — o agentūrai būtent to ir reikia. Kūrybinis darbas vis dar yra; jis tiesiog pritaikomas ten, kur turi didžiausią svertą.