SaaS vietnes no iekšpuses uz āru: kāpēc cenas un dokumentācija ir pirmie

Kopsavilkums

Lielākā daļa padomu par SaaS vietnēm sākas ar sākumlapu un atstāj cenas, dokumentāciju un FAQ kā vēlākas domas — tāpēc šīs lapas galu galā nonāk pretrunā viena ar otru. Šis raksts iestājas par veidošanu no iekšpuses uz āru: sāciet ar cenu lapu un API dokumentāciju, kur dzīvo produkta reālie ierobežojumi, un no tiem atvasiniet visu pārējo. Tajā ir sešu soļu sistēma: apkopojiet ierobežojumus, izveidojiet cenu lapu kā skeletu, uztveriet API dokumentāciju kā produkta virsmu, atvasiniet funkciju demonstrāciju no darbplūsmām, iegūstiet FAQ no reālām sarunām un beidziet ar konsekvences pārbaudi. Šī pieeja ir veidota aģentūrām, kurām nepieciešams atkārtojams process dažādiem klientiem. Tajā ir arī piezīmes par to, kad šī sistēma ir pārmērīga un kā pārvaldīt klientu cerības.

Lielākā daļa padomu par SaaS vietņu veidošanu ir nepareizi. Tie saka sākt ar sākumlapu — varoni, virsrakstu, produkta ekrānuzņēmumu — un uztvert cenas, dokumentāciju un FAQ kā lapas, ko aizpildāt pēc dizaina apstiprināšanas. Tad nedēļas vēlāk jūs saskaņojat virsraksta solījumu "viss neierobežots" ar cenu lapas faktiskajiem lietošanas ierobežojumiem, un funkciju sadaļa lepni demonstrē beta funkciju, kuru API dokumentācija pat nemin. Šī secība darbojas tikai tad, ja produkts ir pietiekami vienkāršs, lai saskaņošana nebūtu nepieciešama, kas notiek reti. Kas patiešām darbojas — īpaši, ja to darāt atkārtoti pilnīgi dažādiem klientiem — ir veidot vietni no iekšpuses uz āru: sāciet ar visvairāk ierobežotajām, vismazāk glamūrīgajām lapām (cenām un API dokumentāciju) un ļaujiet tām ģenerēt sākumlapu, funkciju demonstrāciju un FAQ. Šeit ir sešu soļu sistēma, kā to izdarīt, un pa ceļam es atzīmēšu, kur tas kļūst neērti, jo tas tā notiek.

Ātra atšķirības karte, jo viss arguments uz tās balstās:

	Lapa pirmā (visbiežāk)	Ierobežojumi pirmie (šī sistēma)
Kur sākt	Sākumlapas varonis un vizuālie materiāli	Cenu lapa un API dokumentācija
Kas virza tekstu	Zīmola stāsts un dizains	Produkta faktiskie ierobežojumi un darbplūsmas
Funkciju demonstrācija	Uzskaita visu, ko produkts dara	Seko reālu lietotāju ceļiem
FAQ	Rakstīts pēdējais, no minējumiem	Iegūts no atbalsta un pārdošanas
Rezultāts palaišanas brīdī	Nekonsekventi apgalvojumi, slēpti konflikti	Lapas lasāmas kā viens produkts

1. solis — izlasiet cenu lapu, pirms rakstāt kaut vienu vārdu.

Klients iedod jums funkciju sarakstu, zīmola prezentāciju un demo saiti, un lūdz sākumlapu. Līdz pirmā zvana beigām jūs jau apspriežat varoņa tekstu un krāsu shēmas. Mēģiniet to palēnināt. Pieprasiet cenu lapu un plāna ierobežojumus — pat ja tie ir tikai Google dokuments ar piezīmēm — un jūs atklāsiet, ka viss projekts mainās.

Jūs meklējat stingros ierobežojumus: ko nozīmē viena vieta, kā tiek skaitīts datu lietojums, kuras funkcijas pastāv kādā plāna līmenī, vai ir API un ko tā patiešām spēj. Šie ierobežojumi ir pamata patiesība. Katram mārketinga apgalvojumam, ko veiksit vēlāk, ir jāiztur saskare ar tiem.

Lūk, tipisks scenārijs. Klients ir laika izsekošanas rīks: bezmaksas plāns, Pro plāns, Enterprise plāns. Pārdošanas prezentācijā teikts "mērogojas uz jebkuru komandu." Pro lapā teikts "neierobežoti projekti." Bet atbalsta komanda apstiprina, ka Pro kontiem faktiski ir ierobežojums — 10 aktīvi projekti vienā darbvietā, un API dokumentācijā teikts, ka projektam var būt ne vairāk kā 50 dalībnieki. Sākumlapa netiek rakstīta, kamēr kāds to neatrisina, jo "neierobežoti projekti" tagad ir juridisks jautājums, nevis teksta jautājums. Ja jūs būtu sākuši ar sākumlapu, jūs būtu uzrakstījuši "neierobežoti projekti" varoņa sadaļā un atklājuši konfliktu divas nedēļas vēlāk, pēc dizaina apstiprināšanas. Sākot ar ierobežojumiem, konflikts parādās pirmajā nedēļā, kad tā novēršana neko nemaksā.

Ko tieši jums vajadzētu apkopot šajā solī? Plānu definīcijas un jebkuru funkciju salīdzināšanas tabulu pa plāniem. API dokumentāciju vai vismaz sarakstu par to, ko API var un nevar darīt. Atbalsta komandas biežākos jautājumus (vairāk par to 5. solī). Pārdošanas prezentāciju, ar piezīmi, ka pārdošanas prezentācijas ir vieta, kur dzīvo fantāzija. Un pašu produktu, atvērtu tā, lai jūs redzētu iestatījumu lapas, kur tiek piemēroti ierobežojumi — jo produkts pats ir galīgā autoritāte. Iestatījumu ekrāns, kurā teikts "Maksimāli 10 projekti", atsver jebkuru izklājlapu.

Šis solis nerada piegādājamo rezultātu. Tas rada faktu sarakstu — ierobežojumus, definīcijas, izņēmumus — pret kuriem pārbaudīsiet katru nākamo lapu. Aģentūrai šis ir arī solis, kas atdala atkārtojamu darbu no ugunsgrēku dzēšanas. Uzrakstiet ierobežojumus koplietotā dokumentā, un jūs esat izveidojuši patiesības avotu, uz kuru atsauksies katrs nākamais lapas atjauninājums.

2. solis — izveidojiet cenu lapu kā visas vietnes skeletu.

Cenu lapa nešķiet vieta, ar ko sākt. Tā ir tabula ar skaitļiem un plānu nosaukumiem — vismazāk glamūrīgā lapa vietnē. Bet tā ir produkta līgums ar lietotāju, un tieši tur tiek izlemta visas vietnes informācijas arhitektūra. Ja vietnes uzdevums ir izglītot apmeklētāju, līdz viņš ir gatavs reģistrēties, tad cenu lapa ir vieta, kur šī izglītošana saplūst. Katra funkcija, kas ir svarīga pirkuma lēmumam, tur ir nosaukta; katrs svarīgais ierobežojums ir norādīts vai uz to ir saite.

Ņemiet laika izsekošanas rīku. Trīs plāni: Free, Pro, Enterprise. Tabulā ir vajadzīgas kolonnas, kas atspoguļo to, kā produkts patiešām segmentējas — projektu skaits, integrācijas, atskaišu dziļums. Katrā šūnā ir vajadzīga godīga vērtība, nevis vēlamā. Ja Pro ietver 10 aktīvus projektus, šūnā jābūt rakstītam "10 aktīvi projekti", ar saiti uz cenu FAQ, kur paskaidrots, ko nozīmē "aktīvs" un kas notiek, kad sasniedzat ierobežojumu. Viens no grūtākajiem lēmumiem šeit ir tas, ko teikt par plānu, kuru visvairāk vēlaties, lai apmeklētāji pērk. Daudzas cenu lapas padara enkura plānu acīmredzamu — izceltu, ar nozīmīti "Vispopulārākais" — un teksts ap to izskaidro, kāpēc tas ir piemērots tieši šim apmeklētājam. Laika izsekošanas rīkam Pro ir enkurs: tieši tur patiesībā sākas integrācijas un atskaišu dziļums, tāpēc lapai tas būtu jāpaskaidro tieši, nevis jāpieņem, ka apmeklētājs izlasīs tabulu un pats izdarīs secinājumu.

Šajā vietā jūs arī izlemjat, kuri termini būs kanoniski visā vietnē. Ja produkts grupas cenu lapā sauc par "darbvietām", bet mārketinga teksts saka "komandas", katra nākamā lapa pārmanto šo nekonsekvenci. Rakstot cenu lapu vispirms, jūs esat spiests izvēlēties vārdnīcu, un jums vajadzētu izvēlēties to, ko produkts pats lieto — jo produktam un dokumentācijai ir jāatbilst tai, un mārketinga vietne ir tā, kas var locīties.

Cenu lapai ir nepieciešams arī savs FAQ. Jautājumi, kas tur pieder, ir saistīti ar konkrēto plānu mehāniku: kas tiek uzskatīts par vietu, kas notiek, kad pazemināt plānu, vai norēķini ir gada vai mēneša, ko nozīmē "aktīvs" projektam. Ir labi attīstīta prakse par cenu lapu strukturēšanu konversijai, un šo mehāniku ir vērts izpētīt. Bet šīs sistēmas ietvaros cenu lapas uzdevums nav tikai konvertēt — tas ir nostiprināt faktiskos lēmumus, kuriem pakļausies katra cita lapa. Ja vēlaties dziļāku mehāniku, šis ceļvedis par SaaS cenu lapu labošanu to visu sīki apraksta.

3. solis — uztveriet API dokumentāciju kā produkta virsmu, nevis rokasgrāmatu.

Izstrādātājs vērtē laika izsekošanas rīku. Viņa uzņēmumam ir nepieciešams automātiski iegūt laika uzskaites lapas algu sistēmā. Dokumentācija ir sakārtota alfabētiski pēc galapunktiem: /projects, /reports, /timesheets, /users. Izstrādātājam nav ne jausmas, ar kuru zvanu sākt, un sadaļa "Autentifikācija" paredz zināšanas, kuru viņam nav — dokumentācijā nekad nav paskaidrots, ka API atslēga tiek izveidota iestatījumu lapā sadaļā "Integrācijas". Izstrādātājs aizver cilni, pārliecināts, ka produkts tīri neintegrēsies. Tomēr visa nepieciešamā informācija bija dokumentācijā; tā vienkārši bija sakārtota tādā secībā, kādu izmantotu rokasgrāmata, nevis tādā, kādu izmantotu cilvēks.

Dokumentācija, kas sakārtota pēc darbplūsmām, būtu mainījusi šo iznākumu: "Ātrā starts", "Autentifikācija", "Laika uzskaites iegūšana", "Projekta izveide", "Tīmekļa āķi un sinhronizācija". Katra sadaļa sākas ar uzdevumu, tad parāda galapunktu. Ātrā starts varētu aizņemt piecas minūtes un radīt veiksmīgu API zvanu — tas ir dokumentācijas ekvivalents bezmaksas izmēģinājumam. Izstrādātājiem paredzētam produktam šī ir vispārliecinošākā lapa vietnē.

Jebkuram SaaS, kam ir API, dokumentācija ir jūsu vietnes lapa neatkarīgi no tā, vai to plānojāt. Nozares etalons — ko noteikuši tādi uzņēmumi kā Stripe, GitHub un Twilio — ir dokumentācija, kas lasās kā produkts: tā izskaidro darbu, ko izstrādātājs mēģina paveikt, ne tikai pieejamos galapunktus. Princips ir tāds, ka API dokumentācija ir daļa no produkta pieredzes, un tai jāseko tai pašai no iekšpuses uz āru loģikai kā pārējai vietnei: sāciet ar darbiem, ko izstrādātājs var paveikt, tad atklājiet mehāniku.

Aģentūrai bonuss ir tas, ka šāda dokumentācijas rakstīšana izvirza ierobežojumu sarakstu uz virsmu — ko API patiešām var, kur ir ātruma ierobežojumi, kuru galapunktu trūkst — un jūs noķersit šos konfliktus, pirms tie parādās mārketinga lapā. Ja API dokumentācija ir nozīmīga šī klienta vietnes daļa, ir dziļāks ceļvedis par dokumentācijas rakstīšanu, ko izstrādātāji patiešām izmanto.

4. solis — atvasiniet funkciju demonstrāciju no darbplūsmām, nevis no funkciju saraksta.

Klients jums atsūta izklājlapu ar 40 funkcijām un lūdz funkciju lapu. Vienkāršākā atbilde ir režģis: 40 elementi, katrs ar ikonu un parakstu. Rezultāts šķiet rūpīgs, bet lasās kā troksnis, jo režģim nav stāsta. Neviens neapmeklē SaaS vietni, lai uzzinātu katru funkciju; viņi apmeklē, lai uzzinātu, vai šis produkts veic to vienu darbu, kura dēļ viņi atnāca. Tāpēc demonstrācija jāveido no darbplūsmām, nevis no funkciju saraksta.

Izstrādājiet piemēru līdz galam. Laika izsekošanas rīka visizplatītākais veiksmes ceļš, saskaņā ar klienta atbalsta komandu, ir komandas vadītājs, kurš reģistrējas, uzaicina trīs kolēģus, izveido projektu un nedēļas beigās sagatavo atskaiti. Tā ir darbplūsma. Funkciju demonstrācijai tai jāseko: sadaļa par komandas uzaicināšanu (ietverot vietas un lomas), sadaļa par projekta izveidi (ietverot veidnes un projekta iestatījumus), sadaļa par atskaišu paneli (ietverot diagrammas un eksporta iespējas). Katra sadaļa rāda ekrānuzņēmumu tieši no šī konkrētā produkta brīža, nevis apgrieztu ekrānuzņēmumu no reti izmantota iestatījumu paneļa. Apmeklētājs redz savu ceļu, un funkcijas, ko viņš redz pa ceļam, ir tās, kas viņam ir svarīgas.

Nākamā darbplūsma, nedaudz citam apmeklētājam, ir vadītājs, kurš pats nekad neizmanto rīku: viņš apstiprina laika uzskaites un pārskata nedēļas atskaiti. Demonstrācija var pievienot sadaļu šim apmeklētājam beigās — "Vadītājiem" — nepārkāpjot naratīvu. Divas darbplūsmas parasti ir pietiekami, lai sāktu; jums nav vajadzīga viena katrai personai.

Piezīme — patiesa — ir tā, ka uz darbplūsmām balstītai demonstrācijai ir nepieciešams zināt, kādas patiesībā ir izplatītākās darbplūsmas. Tas prasa sarunas ar atbalstu un pārdošanu, ne tikai ar produktu vadītāju. Ja klients nevar pateikt trīs galvenos veidus, kā cilvēki lieto produktu, tas ir pirmais, kas jālabo, jo pretējā gadījumā vietne minēs. Šis solis bieži atklāj, ka produktam nav skaidras primārās darbplūsmas — tā ir produkta, nevis vietnes problēma. Atzīmējiet to godīgi; vietne nevar izgatavot darbplūsmu, kuras nav. Lai sistemātiski sakārtotu šīs darbplūsmas, šis raksts par funkciju demonstrācijas strukturēšanu konversijai izskata lēmumu secību.

5. solis — iegūstiet FAQ no atbalsta un pārdošanas, nevis no savas iztēles.

Jums ir divas dienas līdz vietnes palaišanai, un FAQ joprojām ir tukšs. Instinkts ir uzrakstīt desmit jautājumus vienā pēcpusdienā — parasti tādus, uz kuriem jūs vēlētos, lai produkts atbild, nevis tos, kurus jautā īsti klienti. Tas ir nepareizi. FAQ ir konkrēts uzdevums: noņemt pēdējās šaubas starp apmeklētāju un reģistrēšanos. Efektīvas FAQ lapas, piemēram, tās, ko redzat no HubSpot, Slack un Zendesk, darbojas tāpēc, ka tās ir organizētas ap reāliem vaicājumiem, meklējamas un kodolīgas. Tās ir klausīšanās, nevis izgudrošanas produkts.

Reālistisks scenārijs: jūs atrodaties cenu lapā, un zināt, ka lielākais šķērslis laika izsekošanas rīkam ir integrācija: "Vai tas darbojas ar QuickBooks?" Atbalsta žurnāla pārskats parāda, ka tas ir biežākais jautājums pirms pārdošanas. Šis jautājums ar atbildi pieder cenu lapas FAQ. Otrs biežākais, no pārdošanas zvaniem, ir "Kas notiek ar manām laika uzskaitēm, ja es atceļu abonementu?" Tas arī tur pieder. Katra atbilde saīsina pārdošanas ciklu un samazina atbalsta slodzi, jo apmeklētājs, kurš redz atbildi rakstiski, produktam uzticas vairāk nekā apmeklētājs, kuram jājautā.

Aģentūras noteikums: nerakstiet nevienu FAQ atbildi, kamēr neesat izskatījis atbalsta biļetes, pārdošanas zvanu piezīmes un ievada e-pastus. Kādi jautājumi patiešām atkārtojas? Tie tiek iekļauti. Viss pārējais nonāk funkciju lapā vai nekur. Un vietnei attīstoties, pārskatiet FAQ — katras jaunas cenu izmaiņas vai funkcijas palaišana rada jaunus jautājumus, un FAQ ir lētākā vieta, kur tos noķert.

Ir arī iemesls domāt par FAQ struktūru, ne tikai saturu. Garš, ritināms jautājumu saraksts ir grūti pārskatāms; grupēšana pa kategorijām (Norēķini, Integrācijas, Konta pārvaldība) ar satura rādītāju augšpusē padara to patiešām lietojamu. Meklēšanas funkcija palīdz, kad saraksts izaug virs noteikta izmēra — šī ir tā lapas daļa, kur dizains ir tikpat svarīgs kā teksts, jo nemeklējams FAQ ir nelasīts FAQ.

Vēl viena lieta, kas ir neērtā daļa: FAQ bieži ir godīgākā lapa vietnē, jo tā ir viena lapa, kurā atbildat uz jautājumu, ko apmeklētājs baidās uzdot. Ja jautājums šķiet neērti atbildams — "Vai es tiešām varu atcelt jebkurā laikā?" "Vai bezmaksas plāns rāda reklāmas?" — šī neērtā sajūta ir pierādījums, ka tas tur pieder, nevis iemesls to atmest. Apmeklētājam ir šis jautājums neatkarīgi no tā, vai jūs uz to atbildat; ja neatbildat, viņš izsecinās atbildi, un izsecinātā atbilde būs sliktāka par patiesību.

6. solis — apvienojiet un veiciet kvalitātes pārbaudi visās lapās, pirms rādāt klientam.

Jūs grasāties rādīt klientam pabeigto vietni. Pirms to darāt, atveriet cenu lapu un funkciju lapu blakus. Pārbaudiet katru funkcijas nosaukumu: vai tie sakrīt? Pārbaudiet katru skaitli: vai cenu lapā ir "10 projekti", funkciju lapā "līdz 10 projektiem" un API atsaucē "maks. 10" — vai tas viss ir vienādi? Pārbaudiet katru solījumu: vai "neierobežoti projekti" ir kaut kur vietnē, un, ja ir, vai tā ir taisnība? Pēc tam meklējiet paša produkta vārdnīcu: vai visur ir "darbvietas", vai arī tā paslīd uz "komandas"? Tieši šeit jūs noķerat, ka sākumlapā ir "nav nepieciešama kredītkarte", bet reģistrēšanās plūsmā bezmaksas izmēģinājumam tomēr tiek prasīta kredītkarte — tieši tā nekonsekvences klase, kas nogalina uzticību.

No iekšpuses uz āru secības ieguvums parādās tieši šeit. Tā kā katra lapa tika atvasināta no tiem pašiem ierobežojumiem, konsekvences darbs ir verifikācijas pārbaude, nevis glābšanas misija. Bet neizlaidiet to. Izdzīvojošās pretrunas ir smalkās — funkcija, ko cenu lapā sauc par "apstiprinājumiem", bet API dokumentācijā par "pārskatīšanas plūsmām", ekrānuzņēmums sākumlapā, kas rāda tumšā režīma paneli, kuru produkts nepiegādā, apgalvojums, ka produktam "uzticas attālinātās komandas", kas nāk no zīmola prezentācijas un neatbilst klienta faktiskajam klientu sarakstam.

Praktiska metode: padariet ierobežojumu sarakstu par QA pārbaudes scenāriju. Izejiet cauri katrai lapai un pārbaudiet katru faktu pret sarakstu. Tas darbojas, jo ierobežojumu saraksts tika uzrakstīts pirmajā nedēļā, pirms lapas pastāvēja, tāpēc tas ir patiesi neatkarīgs avots. Ja sākat QA no dizaina vai no atmiņas, jūs palaidīsit garām faktus, kas mainījās, kamēr veidojāt.

Šajā brīdī darba secības iemesls kļūst acīmredzams. Ja lapas tiek veidotas paralēli no dažādiem avotiem, šī QA pārbaude katru reizi atrod konfliktus, un katrs konflikts nozīmē pārstrādāšanu lapā, kas izskatās pabeigta. Ja lapas tiek veidotas secīgi no viena ierobežojumu saraksta, QA pārbaude atrod drukas kļūdas. Tā ir atšķirība starp atkārtojamu procesu un pastāvīgu krīzi. Lai visa vietne arī pēc palaišanas stāstītu vienu stāstu — jaunas funkcijas, jaunas komandas, jauni tekstu autori — jums ir nepieciešama tās pašas disciplīnas uzturēšanas versija, un sistēma SaaS vietnes stāsta apvienošanai visās lapās ir dabisks nākamais solis.

Piezīmes, kas šo uztur godīgu.

Trīs lietas, ko šī sistēma neapgalvo. Pirmkārt, ļoti agrīnā posma SaaS bez API, ar vienu plānu un vienu acīmredzamu lietošanas gadījumu, secībai ir daudz mazāka nozīme; jūs varētu veidot šo vietni jebkurā secībā, un saskaņošanas darbs būtu triviāls. Sistēma atmaksājas tad, kad ir patiesa sarežģītība — vairāki plāni, API, daudzas funkcijas, vairākas auditorijas. Nepiemērojiet to kā dogmu produktam, kas būtībā ir galvenā lapa ar reģistrēšanās pogu.

Otrkārt, veidošana no iekšpuses uz āru sākumā rada lēnu redzamu progresu. Klients lūdza sākumlapu, bet jūs piegādājat cenu tabulu un ierobežojumu dokumentu. Viņi pretojas, jo sākumlapa ir tas, ko viņi var parādīt investoriem un savai komandai. Šo cerību pārvaldīšana — parādot, kā cenu lapas lēmumi veido visu pārējo — ir daļa no darba, nevis tā neveiksme. Viens veids, kā saglabāt tempu, ir agri izveidot aptuvenu sākumlapas maketu, skaidri marķētu kā konteineru, kas gaida saturu, lai klients varētu redzēt galamērķi, kamēr jūs veidojat skeletu.

Treškārt, ierobežojumu saraksts mainās. Cenas mainās, API aug, plāni vairojas. Sistēma pieņem, ka pēc palaišanas jūs atjaunināt ierobežojumu dokumentu, jo vietne sabruks brīdī, kad tā pārstās atspoguļot produkta reālos ierobežojumus. Tās ir no iekšpuses uz āru pieejas uzturēšanas izmaksas: patiesības avots ir patiess tikai tad, ja kāds tam pieder.

Secinājums.

Visizplatītākā kļūme SaaS vietņu projektos nav vājš teksts vai slikts dizains — tās ir lapas, kas savstarpēji nesaskan, jo tās tika veidotas nepareizā secībā. Sāciet ar cenu lapu un API dokumentāciju, kur dzīvo produkta reālie ierobežojumi; atvasiniet funkciju demonstrāciju no faktiskajām darbplūsmām; iegūstiet FAQ no reālām sarunām; un beidziet ar konsekvences pārbaudi, kas verificē, nevis glābj. Dariet to vairākiem dažādiem klientiem, un jūs atklāsiet, ka tas ir mazāk radošs process un vairāk konveijera līnija — kas aģentūrā ir tieši tas, ko vēlaties. Radošais darbs joprojām ir; tas vienkārši tiek pielietots tur, kur tam ir vislielākā ietekme.