SaaS weby zvnútra von: Prečo sú ceny a dokumentácia na prvom mieste

Zhrnutie

Väčšina rád o SaaS weboch začína domovskou stránkou a ceny, dokumentáciu a FAQ necháva bokom ako dodatočné myšlienky — preto tieto stránky nakoniec protirečia jedna druhej. Tento článok argumentuje za budovanie zvnútra von: začnite cenovou stránkou a API dokumentáciou, kde žijú skutočné obmedzenia produktu, a odvodte od nich všetko ostatné. Predstavuje šesťkrokový rámec: zhromaždite obmedzenia, postavte cenovú stránku ako kostru, zaobchádzajte s API dokumentáciou ako s produktovým povrchom, odvodte ukážku funkcií z pracovných postupov, zozbierajte FAQ z reálnych rozhovorov a na konci vykonajte kontrolu konzistencie. Tento prístup je vytvorený pre agentúry, ktoré potrebujú opakovateľný proces naprieč rôznymi klientmi. Zahŕňa aj upozornenia na to, kedy je rámec zbytočný a ako riadiť očakávania klientov.

Väčšina rád o budovaní SaaS webov je naopak. Hovorí vám, aby ste začali s domovskou stránkou — s hero sekciou, nadpisom, snímkou obrazovky produktu — a ceny, dokumentáciu a FAQ považovali za stránky, ktoré vyplníte po schválení dizajnu. Potom, o niekoľko týždňov neskôr, zosúlaďujete sľub z nadpisu o „neobmedzenom všetkom“ so skutočnými limitmi na cenovej stránke a sekcia funkcií hrdo ukazuje beta funkciu, ktorú API dokumentácia ani nespomína. Tento postup funguje len vtedy, keď je produkt dostatočne jednoduchý na to, aby nebolo potrebné žiadne zosúlaďovanie, čo je zriedkavé. Čo skutočne funguje — najmä keď to robíte opakovane pre úplne odlišných klientov — je postaviť web zvnútra von: začnite s najobmedzenejšími, najmenej atraktívnymi stránkami (ceny a API dokumentácia) a nechajte ich vygenerovať domovskú stránku, ukážku funkcií a FAQ. Tu je šesťkrokový rámec na to, a po ceste upozorním na to, kde to začína byť nepríjemné, pretože to tak je.

Rýchla mapa rozdielu, pretože celý argument na ňom stojí:

	Najprv stránka (najbežnejšie)	Najprv obmedzenia (tento rámec)
Kde začať	Domovská stránka hero a vizuály	Cenová stránka a API dokumentácia
Čo riadi text	Príbeh značky a dizajn	Skutočné limity a pracovné postupy produktu
Ukážka funkcií	Zoznam všetkého, čo produkt robí	Nasleduje cesty, ktoré používajú skutoční používatelia
FAQ	Napísané na konci, z dohadov	Zozbierané z podpory a predaja
Výsledok pri spustení	Nekonzistentné tvrdenia, skryté konflikty	Stránky sa čítajú ako jeden produkt

Krok 1 — Prečítajte si cenovú stránku predtým, ako napíšete čo i len slovo.

Klient vám dá zoznam funkcií, brand deck a demo odkaz a požiada o domovskú stránku. Na konci prvého hovoru už diskutujete o hero texte a farebných schémach. Skúste to spomaliť. Požiadajte o cenovú stránku a limity plánov — aj keď sú to len Google Doc s poznámkami — a zistíte, že sa celý projekt zmení.

Hľadáte tvrdé obmedzenia: čo znamená miesto, ako sa počíta využitie dát, ktoré funkcie existujú na ktorej úrovni plánu, či existuje API a čo dokáže. Tieto obmedzenia sú základná pravda. Každé marketingové tvrdenie, ktoré neskôr urobíte, musí prežiť kontakt s nimi.

Tu je typický scenár. Klient je nástroj na sledovanie času: Free plán, Pro plán, Enterprise plán. Predajná prezentácia hovorí „škáluje sa na akýkoľvek tím.“ Stránka Pro hovorí „neobmedzené projekty.“ Ale podpora potvrdí, že Pro účty sú v skutočnosti obmedzené na 10 aktívnych projektov na pracovný priestor a API dokumentácia hovorí, že projekt môže mať najviac 50 členov. Domovská stránka sa nikdy nenapíše, kým to niekto nevyrieši, pretože „neobmedzené projekty“ sú teraz právna otázka, nie otázka textu. Ak by ste začali s domovskou stránkou, napísali by ste „neobmedzené projekty“ do hero sekcie a objavili by ste konflikt o dva týždne neskôr, po schválení dizajnu. Začať s obmedzeniami znamená, že konflikt vyjde na povrch v prvom týždni, keď jeho oprava nič nestojí.

Čo presne by ste mali v tomto kroku zhromaždiť? Definície plánov a akúkoľvek porovnávaciu tabuľku funkcií podľa plánov. API dokumentáciu alebo aspoň zoznam toho, čo API dokáže a čo nie. Najčastejšie otázky tímu podpory (viac o tom v kroku 5). Predajnú prezentáciu, s upozornením, že predajné prezentácie sú miesto, kde žije fantázia. A samotný produkt, otvorený tak, aby ste videli stránky nastavení, kde sa limity vynucujú — pretože produkt samotný je konečná autorita. Obrazovka nastavení, ktorá hovorí „Maximum 10 projektov“, prepíše akúkoľvek tabuľku.

Tento krok neprodukuje žiadny výstup. Produkuje zoznam faktov — limity, definície, výnimky — podľa ktorých skontrolujete každú ďalšiu stránku. Pre agentúru je to tiež krok, ktorý oddeľuje opakovateľnú prácu od hasenia požiarov. Zapíšte obmedzenia do zdieľaného dokumentu a vytvorili ste zdroj pravdy, na ktorý sa bude odvolávať každá budúca aktualizácia stránky.

Krok 2 — Postavte cenovú stránku ako kostru celého webu.

Cenová stránka nepôsobí ako miesto, kde začať. Je to tabuľka s číslami a názvami plánov — najmenej atraktívna stránka na webe. Ale je to zmluva produktu s používateľom a je to miesto, kde sa rozhoduje o informačnej architektúre celého webu. Ak je úlohou webu vzdelávať návštevníka, kým nie je pripravený na registráciu, cenová stránka je miesto, kde sa toto vzdelávanie stretáva. Každá funkcia, ktorá je dôležitá pre rozhodovanie o kúpe, je tam pomenovaná; každý limit, ktorý je dôležitý, je tam uvedený alebo naň odkazuje.

Vezmite si nástroj na sledovanie času. Tri plány: Free, Pro, Enterprise. Tabuľka potrebuje stĺpce, ktoré odrážajú, ako sa produkt skutočne segmentuje — počet projektov, integrácie, hĺbka reportov. Pre každú bunku potrebujete úprimnú hodnotu, nie tú vysnívanú. Ak Pro zahŕňa 10 aktívnych projektov, bunka hovorí 10 aktívnych projektov, s odkazom na cenový FAQ vysvetľujúcim, čo znamená „aktívny“ a čo sa stane, keď dosiahnete limit. Jedno z náročnejších rozhodnutí je, čo povedať o pláne, ktorý chcete, aby si návštevníci najviac kúpili. Mnohé cenové stránky robia kotevný plán zrejmým — zvýraznený, s odznakom „Najobľúbenejší“ — a text okolo neho vysvetľuje, prečo je pre tohto návštevníka ten pravý. Pre nástroj na sledovanie času je Pro kotva: tam sa integrácie a hĺbka reportov skutočne začínajú, takže stránka by to mala vysvetliť explicitne, a nie predpokladať, že si návštevník tabuľku prečíta a urobí si záver sám.

Tu sa tiež rozhoduje, ktoré výrazy budú kanonické na celom webe. Ak produkt nazýva skupiny „pracovné priestory“ na cenovej stránke, ale marketingový text hovorí „tímy,“ každá následná stránka zdedí nekonzistentnosť. Napísanie cenovej stránky ako prvej vás núti vybrať slovník a mali by ste vybrať to, čo používa samotný produkt — pretože produkt a dokumentácia sa s ním musia zhodovať, a marketingový web je ten, ktorý sa môže prispôsobiť.

Cenová stránka tiež potrebuje svoj vlastný FAQ. Otázky, ktoré tam patria, sú tie, ktoré súvisia s konkrétnou mechanikou plánov: čo sa počíta ako miesto, čo sa stane, keď prejdete na nižší plán, či je fakturácia ročná alebo mesačná, čo znamená „aktívny“ pre projekt. Existuje dobre rozvinutá prax štruktúrovania cenových stránok na konverziu a mechanika stojí za preštudovanie. Ale v tomto rámci nie je úlohou cenovej stránky len konvertovať — je uzamknúť faktické rozhodnutia, ktoré bude každá iná stránka dodržiavať. Ak chcete hlbšiu mechaniku, tento sprievodca opravou SaaS cenových stránok ju podrobne pokrýva.

Krok 3 — Zaobchádzajte s API dokumentáciou ako s produktovým povrchom, nie ako s manuálom.

Vývojár hodnotí nástroj na sledovanie času. Ich spoločnosť potrebuje automaticky ťahať dochádzkové výkazy do mzdového systému. Dokumentácia je organizovaná abecedne podľa endpointov: /projects, /reports, /timesheets, /users. Vývojár netuší, ktorým volaním začať, a sekcia „Autentifikácia“ predpokladá znalosti, ktoré nemá — dokumentácia nikdy nevysvetlí, že API kľúč vytvoríte na stránke nastavení v časti „Integrácie.“ Vývojár zatvorí kartu, presvedčený, že sa produkt nebude dať čisto integrovať. A predsa každá potrebná informácia bola v dokumentácii prítomná; len bola organizovaná v poradí, aké by použila referenčná príručka, nie v poradí, aké by použil človek.

Dokumentácia organizovaná podľa pracovných postupov by zmenila tento výsledok: „Rýchly štart,“ „Autentifikácia,“ „Stiahnuť dochádzky,“ „Vytvoriť projekt,“ „Webhooky a synchronizácia.“ Každá sekcia vedie s úlohou, potom ukazuje endpoint. Rýchly štart môže trvať päť minút a vyprodukovať úspešné API volanie — čo je dokumentačný ekvivalent bezplatnej skúšky. Pre produkt zameraný na vývojárov je to najpresvedčivejšia stránka na webe.

Pre každý SaaS, ktorý má API, je dokumentácia stránkou vášho webu, či už ste to tak naplánovali, alebo nie. Priemyselný benchmark — stanovený spoločnosťami ako Stripe, GitHub a Twilio — je dokumentácia, ktorá sa číta ako produkt: vysvetľuje úlohu, ktorú sa vývojár snaží splniť, a nielen dostupné endpointy. Princíp je, že API dokumentácia je súčasťou produktového zážitku a mala by nasledovať rovnakú logiku zvnútra von ako zvyšok webu: začnite s úlohami, ktoré vývojár môže vykonať, potom odhaľte mechaniku.

Bonus pre agentúru je, že písanie dokumentácie týmto spôsobom vytiahne zoznam obmedzení na povrch — čo API skutočne dokáže, kde sú limity rýchlosti, ktoré endpointy chýbajú — a zachytíte tieto konflikty skôr, než sa objavia na marketingovej stránke. Ak je API dokumentácia veľkou súčasťou webu tohto klienta, existuje hlbší sprievodca písaním dokumentácie, ktorú vývojári skutočne používajú.

Krok 4 — Odvodte ukážku funkcií z pracovných postupov, nie zo zoznamu funkcií.

Klient vám pošle tabuľku so 40 funkciami a požiada o stránku funkcií. Jednoduchá odpoveď je mriežka: 40 položiek, každá s ikonou a popisom. Výsledok pôsobí dôkladne, ale číta sa ako šum, pretože mriežka nemá príbeh. Nikto nenavštevuje SaaS web, aby sa dozvedel o každej funkcii; navštevujú ho, aby zistili, či tento produkt robí tú jednu vec, kvôli ktorej prišli. Preto by mala byť ukážka postavená z pracovných postupov, nie zo zoznamu funkcií.

Prejdite si príklad. Najčastejšia víťazná cesta nástroja na sledovanie času, podľa tímu podpory klienta, je vedúci tímu, ktorý sa zaregistruje, pozve troch kolegov, vytvorí projekt a na konci týždňa spustí report. To je pracovný postup. Ukážka funkcií by ho mala nasledovať: sekcia o pozvaní tímu (zahŕňa miesta a roly), sekcia o nastavení projektu (zahŕňa šablóny a nastavenia projektu), sekcia o reportovacom dashboarde (zahŕňa grafy a možnosti exportu). Každá sekcia ukazuje snímku obrazovky z toho presného momentu v produkte, nie orezanú snímku zriedkavo používaného panela nastavení. Návštevník vidí svoju vlastnú cestu a funkcie, ktoré vidí po ceste, sú tie, ktoré sú pre neho dôležité.

Nadväzujúci pracovný postup, pre mierne odlišného návštevníka, je manažér, ktorý nástroj sám nikdy nepoužíva: schvaľuje dochádzky a kontroluje týždenný report. Ukážka môže na konci pridať sekciu pre tohto návštevníka — „Pre manažérov“ — bez prerušenia rozprávania. Dva pracovné postupy na začiatok zvyčajne stačia; nepotrebujete jeden pre každú personu.

Výhrada — skutočná — je, že ukážka založená na pracovných postupoch vyžaduje poznať, aké sú bežné pracovné postupy. To si vyžaduje rozhovory s podporou a predajom, nielen s produktovým manažérom. Ak vám klient nevie povedať top tri spôsoby, ako ľudia produkt používajú, to je prvá vec, ktorú treba opraviť, pretože web bude inak hádať. Tento krok často odhalí, že produkt nemá jasný primárny pracovný postup — čo je problém produktu, nie webu. Pomenujte to úprimne; web nemôže vyrobiť pracovný postup, ktorý neexistuje. Pre systematický spôsob zoradenia týchto pracovných postupov tento článok o štruktúrovaní ukážky funkcií pre konverzie prechádza rozhodovacou sekvenciou.

Krok 5 — Zozbierajte FAQ z podpory a predaja, nie z vašej predstavivosti.

Máte dva dni pred spustením webu a FAQ je stále prázdne. Inštinkt je napísať desať otázok za popoludnie — zvyčajne otázky, na ktoré by ste chceli, aby produkt odpovedal, a nie tie, ktoré sa pýtajú skutoční zákazníci. To je naopak. FAQ má špecifickú úlohu: odstrániť posledné pochybnosti medzi návštevníkom a registráciou. Efektívne FAQ stránky, ako tie od HubSpot, Slack a Zendesk, fungujú, pretože sú organizované okolo reálnych otázok, sú prehľadávateľné a stručné. Sú výsledkom počúvania, nie vymýšľania.

Realistický scenár: ste na cenovej stránke a viete, že najväčším problémom pre nástroj na sledovanie času je integrácia: „Funguje to s QuickBooks?“ Prehľad logov podpory ukazuje, že to je najčastejšia predpredajná otázka. Táto otázka so svojou odpoveďou patrí do FAQ na cenovej stránke. Druhá najčastejšia, z predajných hovorov, je „Čo sa stane s mojimi dochádzkami, ak zruším predplatné?“ To tam patrí tiež. Každá odpoveď skracuje predajný cyklus a znižuje zaťaženie podpory, pretože návštevník, ktorý vidí odpoveď napísanú, dôveruje produktu viac ako návštevník, ktorý sa musí pýtať.

Pravidlom pre agentúru: nenapíšte ani jednu FAQ odpoveď, kým sa nepozriete na tiketovú podporu, poznámky z predajných hovorov a onboardovacie e-maily. Aké otázky sa skutočne opakujú? Tie tam patria. Všetko ostatné ide na stránku funkcií alebo nikam. A ako sa web vyvíja, vracajte sa k FAQ — každá zmena cien alebo spustenie novej funkcie vytvára nové otázky a FAQ je najlacnejšie miesto, kde ich zachytiť.

Existuje tiež dôvod premýšľať o štruktúre FAQ, nielen o obsahu. Dlhý, rolujúci zoznam otázok sa ťažko prehľadáva; zoskupenie podľa kategórie (Fakturácia, Integrácie, Správa účtu) s obsahom na začiatku ho robí skutočne použiteľným. Funkcia vyhľadávania pomáha, keď zoznam presiahne určitú veľkosť — to je časť stránky, kde dizajn záleží rovnako ako text, pretože nevyhľadávateľný FAQ je neprečítaný FAQ.

Ešte jedna vec, ktorá je nepríjemnou súčasťou: FAQ je často najúprimnejšia stránka na webe, pretože je to tá jediná stránka, kde odpovedáte na otázku, ktorú sa návštevník bojí spýtať. Ak je otázka nepríjemná na zodpovedanie — „Naozaj môžem kedykoľvek zrušiť?“ „Zobrazuje bezplatný plán reklamy?“ — ten nepríjemný pocit je dôkazom, že tam patrí, nie dôvodom, aby ste ju vyhodili. Návštevník má túto otázku, či už na ňu odpoviete, alebo nie; ak neodpoviete, bude si domýšľať odpoveď, a odpoveď, ktorú si domyslí, bude horšia ako pravda.

Krok 6 — Zjednoťte a otestujte všetky stránky, predtým ako ukážete klientovi.

Chystáte sa ukázať klientovi hotový web. Predtým, ako to urobíte, otvorte vedľa seba cenovú stránku a stránku funkcií. Skontrolujte každý názov funkcie: zhodujú sa? Skontrolujte každé číslo: hovorí cenová stránka „10 projektov“, stránka funkcií „až 10 projektov“ a API referenčná príručka „max 10“ — všetko rovnako? Skontrolujte každý sľub: je „neobmedzené projekty“ niekde na webe, a ak áno, je to pravda? Potom hľadajte slovník produktu: hovorí všade „pracovné priestory“, alebo sa to zvŕta na „tímy“? Tu zachytíte, že domovská stránka hovorí „bez zadania kreditnej karty“, zatiaľ čo registračný tok v skutočnosti pýta kreditnú kartu na bezplatnej skúške — presne tá trieda nekonzistentnosti, ktorá zabíja dôveru.

Odmena za poradie zvnútra von prichádza tu. Pretože každá stránka bola odvodená z rovnakých obmedzení, práca na konzistencii je overovacím prechodom, nie záchrannou misiou. Ale nevynechávajte ho. Rozpory, ktoré prežijú, sú tie jemné — funkcia nazvaná „schvaľovania“ na cenovej stránke, ale „procesy recenzií“ v API dokumentácii, snímka obrazovky na domovskej stránke zobrazujúca dashboard v tmavom režime, ktorý produkt nemá, tvrdenie, že produkt je „dôveryhodný pre vzdialené tímy“, ktoré pochádza z brand deku a nezodpovedá skutočnému zoznamu zákazníkov klienta.

Praktická technika: urobte zo zoznamu obmedzení scenár pre QA prechod. Prejdite každú stránku a skontrolujte každý fakt proti zoznamu. Toto funguje, pretože zoznam obmedzení bol napísaný v prvom týždni, predtým ako stránky existovali, takže je to skutočne nezávislý zdroj. Ak začnete QA z dizajnu alebo z pamäti, uniknú vám fakty, ktoré sa zmenili počas budovania.

V tomto bode je dôvod na sekvenčné poradie práce zrejmý. Keď sa stránky stavajú paralelne z rôznych zdrojov, tento QA prechod vždy nájde konflikty a každý konflikt znamená prepracovanie hotovo vyzerajúcej stránky. Keď sa stránky stavajú v poradí z jedného zoznamu obmedzení, QA prechod nájde preklepy. To je rozdiel medzi opakovateľným procesom a neustálou krízou. Aby celý web po spustení rozprával jeden príbeh — nové funkcie, nové tímy, noví copywriteri — potrebujete udržiavaciu verziu tej istej disciplíny a rámec na zjednotenie príbehu SaaS webu naprieč stránkami je prirodzeným ďalším krokom.

Výhrady, ktoré to udržiavajú úprimné.

Tri veci, ktoré tento rámec netvrdí. Po prvé, pre veľmi skoré štádium SaaS bez API, s jediným plánom a jedným zrejmým prípadom použitia, poradie záleží oveľa menej; mohli by ste ten web postaviť v akomkoľvek poradí a zosúlaďovacia práca by bola triviálna. Rámec sa oplatí, keď existuje skutočná zložitosť — viacero plánov, API, mnoho funkcií, niekoľko publik. Neaplikujte ho ako dogmu na produkt, ktorý je v podstate landing page s tlačidlom na registráciu.

Po druhé, budovanie zvnútra von na začiatku produkuje pomalý viditeľný pokrok. Klient požiadal o domovskú stránku a vy dodávate cenovú tabuľku a dokument s obmedzeniami. Budú tlačiť proti tomu, pretože domovská stránka je to, čo môžu ukázať investorom a vlastnému tímu. Riadenie tohto očakávania — ukázať im, ako rozhodnutia na cenovej stránke formujú všetko ostatné — je súčasťou práce, nie jej zlyhaním. Jedným spôsobom, ako udržať tempo, je vytvoriť skoro hrubý mockup domovskej stránky, jasne označený ako kontajner čakajúci na obsah, aby klient videl cieľ, kým vy budete stavať kostru.

Po tretie, zoznam obmedzení sa mení. Ceny sa menia, API rastie, plány sa množia. Rámec predpokladá, že dokument s obmedzeniami budete aktualizovať aj po spustení, pretože web začne upadať v momente, keď prestane odrážať skutočné limity produktu. To sú náklady na údržbu prístupu zvnútra von: zdroj pravdy je pravdivý len vtedy, ak ho niekto vlastní.

Záver.

Najčastejším zlyhaním v projektoch SaaS webov nie je slabý text alebo zlý dizajn — sú to stránky, ktoré si navzájom odporujú, pretože boli postavené v nesprávnom poradí. Začnite s cenovou stránkou a API dokumentáciou, kde žijú skutočné obmedzenia produktu; odvodte ukážku funkcií zo skutočných pracovných postupov; zozbierajte FAQ z reálnych rozhovorov; a skončite prechodom na konzistenciu, ktorý overuje, nie zachraňuje. Urobte to u niekoľkých rôznych klientov a zistíte, že je to menej kreatívny proces a viac montážna linka — čo je v agentúre presne to, čo chcete. Kreatívna práca je stále tam; len sa aplikuje tam, kde má najväčšiu páku.