SaaS web stranice iznutra prema van: zašto su cijene i dokumentacija na prvom mjestu

Sažetak

Većina savjeta o SaaS web stranicama počinje s početnom stranicom, a cijene, dokumentaciju i FAQ ostavlja po strani – što je razlog zašto te stranice na kraju proturječe jedna drugoj. Ovaj članak zagovara izgradnju iznutra prema van: krenite od stranice s cijenama i API dokumentacije, gdje su stvarna ograničenja proizvoda, i izvedite sve ostalo iz njih. Predstavlja okvir od šest koraka: prikupite ograničenja, izgradite stranicu s cijenama kao kostur, tretirajte API dokumentaciju kao površinu proizvoda, izvedite prikaz značajki iz radnih tijekova, prikupite FAQ iz stvarnih razgovora i završite provjerom dosljednosti. Pristup je namijenjen agencijama kojima je potreban ponovljiv proces za različite klijente. Također uključuje napomene o tome kada je okvir pretjeran i kako upravljati očekivanjima klijenata.

Većina savjeta o izgradnji SaaS web stranica je pogrešna. Kaže vam da krenete od početne stranice – hero sekcije, naslova, snimke zaslona proizvoda – a cijene, dokumentaciju i FAQ tretirate kao stranice koje popunjavate nakon što je dizajn odobren. Zatim, tjednima kasnije, usklađujete obećanje iz naslova o „neograničeno sve" sa stvarnim ograničenjima korištenja na stranici cijena, a odjeljak o značajkama ponosno prikazuje beta značajku koju API dokumentacija uopće ne spominje. Taj redoslijed funkcionira samo kad je proizvod dovoljno jednostavan da usklađivanje nije potrebno, što je rijetko slučaj. Ono što zapravo funkcionira – osobito kada to radite opetovano za potpuno različite klijente – jest izgradnja stranice iznutra prema van: krenite od najograničenijih, najmanje glamuroznih stranica (cijene i API dokumentacija) i neka one generiraju početnu stranicu, prikaz značajki i FAQ. Ovdje je okvir od šest koraka za to, a usput ću označiti gdje postaje neugodno, jer postaje.

Brza mapa razlike, jer cijeli argument počiva na njoj:

	Stranica-prva (najčešće)	Ograničenje-prva (ovaj okvir)
Gdje počinjete	Hero i vizuali početne stranice	Stranica s cijenama i API dokumentacija
Što pokreće tekst	Priča o brendu i dizajn	Stvarna ograničenja i radni tijekovi proizvoda
Prikaz značajki	Navodi sve što proizvod radi	Slijedi putove koje stvarni korisnici koriste
FAQ	Napisan na kraju, od nagađanja	Prikupljen iz podrške i prodaje
Rezultat pri pokretanju	Nedosljedne tvrdnje, skriveni sukobi	Stranice se čitaju kao jedan proizvod

Korak 1 — Pročitajte stranicu s cijenama prije nego napišete ijednu riječ.

Klijent vam da popis značajki, prezentaciju brenda i poveznicu za demo te traži početnu stranicu. Do kraja prvog poziva raspravljate o hero tekstu i shemama boja. Pokušajte to usporiti. Zatražite stranicu s cijenama i ograničenja planova – čak i ako su samo Google dokument s bilješkama – i otkrit ćete da se cijeli projekt mijenja.

Tražite čvrsta ograničenja: što znači korisničko mjesto (seat), kako se broji korištenje podataka, koje značajke postoje na kojoj razini plana, postoji li API i što on zapravo može. Ta ograničenja su temeljna istina. Svaka marketinška tvrdnja koju kasnije iznesete mora izdržati dodir s njima.

Evo tipičnog scenarija. Klijent je alat za praćenje vremena: besplatni plan, Pro plan, Enterprise plan. Prodajna prezentacija kaže „prilagođava se svakom timu". Pro stranica kaže „neograničeni projekti". Ali tim podrške potvrđuje da Pro računi zapravo imaju ograničenje od 10 aktivnih projekata po radnom prostoru, a API dokumentacija kaže da projekt može imati najviše 50 članova. Početna stranica se ne piše dok netko ne riješi ovo, jer „neograničeni projekti" sada postaju pravno pitanje, a ne pitanje teksta. Da ste krenuli od početne stranice, napisali biste „neograničeni projekti" u hero sekciji i otkrili sukob dva tjedna kasnije, nakon što je dizajn odobren. Početi s ograničenjima znači da se sukob pojavi u prvom tjednu, kada popravak ne košta ništa.

Što točno trebate prikupiti u ovom koraku? Definicije planova i bilo koju usporednu tablicu značajki po planovima. API dokumentaciju ili barem popis onoga što API može i ne može. Najčešća pitanja tima podrške (više o tome u koraku 5). Prodajnu prezentaciju, uz napomenu da su prodajne prezentacije mjesto gdje živi fantazija. I stvarni proizvod, otvoren tako da možete vidjeti stranice s postavkama gdje se ograničenja provode – jer proizvod sam po sebi je konačni autoritet. Zaslon s postavkama koji kaže „Maksimalno 10 projekata" nadjačava bilo koju proračunsku tablicu.

Ovaj korak ne proizvodi isporučivi rezultat. Proizvodi popis činjenica – ograničenja, definicije, iznimke – s kojima ćete uspoređivati svaku drugu stranicu. Za agenciju je ovo također korak koji odvaja ponovljivi posao od gašenja požara. Zapišite ograničenja u zajednički dokument i izgradili ste izvor istine na koji će se svako buduće ažuriranje stranice pozivati.

Korak 2 — Izgradite stranicu s cijenama kao kostur cijele web stranice.

Stranica s cijenama ne djeluje kao mjesto za početak. To je tablica s brojevima i nazivima planova – najmanje glamurozna stranica na web mjestu. Ali to je ugovor proizvoda s korisnikom i mjesto gdje se odlučuje o informacijskoj arhitekturi cijele stranice. Ako je posao web stranice educirati posjetitelja dok ne bude spreman prijaviti se, stranica s cijenama je mjesto gdje se ta edukacija sužava. Svaka značajka koja je važna za odluku o kupnji imenovana je tu; svako ograničenje koje je važno navedeno je ili povezano.

Uzmite alat za praćenje vremena. Tri plana: Free, Pro, Enterprise. Tablica treba stupce koji odražavaju kako se proizvod zapravo segmentira – broj projekata, integracije, dubina izvještavanja. Za svaku ćeliju trebate iskrenu vrijednost, a ne aspiracijsku. Ako Pro uključuje 10 aktivnih projekata, ćelija kaže 10 aktivnih projekata, s poveznicom na FAQ o cijenama koji objašnjava što znači „aktivno" i što se događa kada dosegnete ograničenje. Jedna od težih odluka ovdje je što reći o planu koji najviše želite da posjetitelji kupe. Mnoge stranice s cijenama čine sidreni plan očitim – istaknutim, s oznakom „Najpopularnije" – a tekst oko njega objašnjava zašto je pravi izbor za ovog posjetitelja. Za alat za praćenje vremena, Pro je sidro: tu zapravo počinju integracije i dubina izvještavanja, pa bi stranica to trebala izrijekom obrazložiti, umjesto da pretpostavi da će posjetitelj sam pročitati tablicu i zaključiti.

Ovdje također odlučujete koji će pojmovi biti kanonski na cijeloj web stranici. Ako proizvod grupe naziva „radni prostori" na stranici s cijenama, ali marketinški tekst kaže „timovi", svaka sljedeća stranica nasljeđuje nedosljednost. Pisanje stranice s cijenama prvo prisiljava vas da odaberete vokabular, a trebali biste odabrati ono što proizvod sam koristi – jer proizvod i dokumentacija moraju odgovarati tome, a marketinška web stranica je ta koja se može saviti.

Stranica s cijenama također treba vlastiti FAQ. Pitanja koja tamo pripadaju vezana su uz specifičnu mehaniku planova: što se računa kao korisničko mjesto, što se događa kada smanjite plan, je li naplata godišnja ili mjesečna, što znači „aktivno" za projekt. Postoji dobro razvijena praksa strukturiranja stranica s cijenama za konverziju i mehaniku vrijedi proučiti. Ali unutar ovog okvira, posao stranice s cijenama nije samo konverzija – već zaključavanje činjeničnih odluka kojih će se svaka druga stranica pridržavati. Ako želite dublje mehanike, ovaj vodič za popravljanje SaaS stranica s cijenama pokriva ih detaljno.

Korak 3 — Tretirajte API dokumentaciju kao površinu proizvoda, a ne kao priručnik.

Programer procjenjuje alat za praćenje vremena. Njihova tvrtka treba automatski povući evidenciju radnog vremena u platni sustav. Dokumentacija je organizirana abecedno prema krajnjim točkama: /projects, /reports, /timesheets, /users. Programer nema pojma s kojim pozivom početi, a odjeljak „Autentifikacija" pretpostavlja znanje koje nemaju – dokumentacija nikad ne objašnjava da se API ključ kreira na stranici postavki pod „Integracije". Programer zatvara karticu, uvjeren da se proizvod neće čisto integrirati. Ipak, svaki potreban podatak bio je prisutan u dokumentaciji; samo je bio organiziran redoslijedom kojim bi se koristio referentni priručnik, a ne redoslijedom kojim bi se koristio čovjek.

Dokumentacija organizirana prema radnom tijeku promijenila bi taj ishod: „Brzi početak", „Autentifikacija", „Povlačenje evidencije radnog vremena", „Kreiranje projekta", „Webhooks i sinkronizacija". Svaki odjeljak vodi s poslom, a zatim prikazuje krajnju točku. Brzi početak mogao bi trajati pet minuta i proizvesti uspješan API poziv – što je dokumentacijski ekvivalent besplatne probne verzije. Za proizvod usmjeren na programere, ovo je najuvjerljivija stranica na web mjestu.

Za svaki SaaS koji ima API, dokumentacija je stranica vaše web stranice, bilo da ste to tako planirali ili ne. Industrijsko mjerilo – postavljeno od strane Stripea, GitHub-a i Twilio-a – je dokumentacija koja se čita kao proizvod: objašnjava posao koji programer pokušava obaviti, a ne samo dostupne krajnje točke. Načelo je da su API dokumenti dio iskustva proizvoda i da bi trebali slijediti istu logiku iznutra prema van kao i ostatak web stranice: krenite od poslova koje programer može obaviti, a zatim otkrijte mehaniku.

Bonus za agenciju je što pisanje dokumentacije na ovaj način izbacuje popis ograničenja na površinu – što API zapravo može, gdje su ograničenja brzine, koje krajnje točke nedostaju – i uhvatit ćete te sukobe prije nego što se pojave na marketinškoj stranici. Ako je API dokumentacija glavni dio web stranice ovog klijenta, postoji dublji vodič za pisanje dokumentacije koju programeri stvarno koriste.

Korak 4 — Izvedite prikaz značajki iz radnih tijekova, a ne s popisa značajki.

Klijent vam pošalje proračunsku tablicu s 40 značajki i traži stranicu značajki. Laki odgovor je mreža: 40 stavki, svaka s ikonom i opisom. Rezultat djeluje temeljito, ali čita se kao buka, jer mreža nema priču. Nitko ne posjećuje SaaS web stranicu da bi naučio svaku značajku; posjećuju kako bi saznali radi li ovaj proizvod onaj jedan posao zbog kojeg su došli. Stoga prikaz značajki treba biti izgrađen iz radnih tijekova, a ne s popisa značajki.

Prođite kroz primjer. Najčešći put do uspjeha alata za praćenje vremena, prema timu podrške klijenta, je voditelj tima koji se registrira, pozove tri kolege, kreira projekt i na kraju tjedna pokrene izvještaj. To je radni tijek. Prikaz značajki trebao bi ga slijediti: odjeljak o pozivanju tima (pokriva korisnička mjesta i uloge), odjeljak o postavljanju projekta (pokriva predloške i postavke projekta), odjeljak o nadzornoj ploči izvještaja (pokriva grafikone i mogućnosti izvoza). Svaki odjeljak prikazuje snimku zaslona iz tog točnog trenutka u proizvodu, a ne izrezanu snimku rijetko korištene ploče s postavkama. Posjetitelj vidi vlastiti put, a značajke koje usput vidi su one koje su im važne.

Sljedeći radni tijek, za malo drugačijeg posjetitelja, je izvršni direktor koji sam nikad ne koristi alat: odobrava evidenciju radnog vremena i pregledava tjedni izvještaj. Prikaz značajki može dodati odjeljak za tog posjetitelja na kraju – „Za menadžere" – bez narušavanja narativa. Dva radna tijeka obično su dovoljna za početak; ne trebate po jedan za svaku personu.

Oprez – stvaran – jest da prikaz značajki temeljen na radnim tijekovima zahtijeva poznavanje stvarnih uobičajenih radnih tijekova. To zahtijeva razgovor s podrškom i prodajom, a ne samo s voditeljem proizvoda. Ako vam klijent ne može reći tri glavna načina na koje ljudi koriste proizvod, to je prva stvar koju treba popraviti, jer će web stranica inače nagađati. Ovaj korak često otkriva da proizvod nema jasan primarni radni tijek – što je problem proizvoda, a ne web stranice. Pošteno to označite; web stranica ne može proizvesti radni tijek koji ne postoji. Za sustavan način slaganja tih radnih tijekova, ovaj članak o strukturiranju prikaza značajki za konverzije provodi vas kroz slijed odluka.

Korak 5 — Prikupite FAQ iz podrške i prodaje, ne iz mašte.

Imate dva dana do objave web stranice, a FAQ je još uvijek prazan. Instinkt je napisati deset pitanja u jedno poslijepodne – obično pitanja na koja biste vi željeli da proizvod odgovori, a ne ona koja stvarni kupci postavljaju. To je pogrešno. FAQ ima specifičan posao: ukloniti posljednje sumnje između posjetitelja i prijave. Učinkovite FAQ stranice, poput onih koje vidite od HubSpota, Slacka i Zendeska, funkcioniraju jer su organizirane oko stvarnih upita, pretražive i sažete. One su proizvod slušanja, a ne izmišljanja.

Realistični scenarij: na stranici ste s cijenama i znate da je najveća prepreka za alat za praćenje vremena integracija: „Funkcionira li ovo s QuickBooksom?" Pregled dnevnika podrške pokazuje da je to najčešće prodajno pitanje. To pitanje, s odgovorom, pripada na FAQ stranicu cijena. Drugo najčešće, s prodajnih poziva, je „Što se događa s mojom evidencijom radnog vremena ako otkažem?" To također tamo pripada. Svaki odgovor skraćuje prodajni ciklus i smanjuje opterećenje podrške, jer posjetitelj koji vidi odgovor u pisanom obliku više vjeruje proizvodu nego posjetitelj koji mora pitati.

Pravilo za agenciju: ne napišite nijedan FAQ odgovor dok ne pogledate tickete podrške, bilješke s prodajnih poziva i onboarding e-poštu. Koja se pitanja zapravo ponavljaju? Ta idu unutra. Sve ostalo ide na stranicu značajki ili nigdje. Kako se web stranica razvija, ponovno posjetite FAQ – svaka nova promjena cijena ili lansiranje značajki stvara nova pitanja, a FAQ je najjeftinije mjesto za njihovo hvatanje.

Postoji i razlog za razmišljanje o strukturi FAQ-a, a ne samo o sadržaju. Duga, klizajuća lista pitanja teško se skenira; grupiranje po kategorijama (Naplata, Integracije, Upravljanje računom) sa sadržajem na vrhu čini je zapravo upotrebljivom. Funkcija pretraživanja pomaže kada lista naraste preko određene veličine – ovo je dio stranice gdje dizajn igra jednako veliku ulogu kao i tekst, jer FAQ koji se ne može pretraživati je FAQ koji se ne čita.

Još jedna stvar, koja je neugodni dio: FAQ je često najiskrenija stranica na web mjestu, jer je to jedina stranica na kojoj odgovarate na pitanje koje se posjetitelj boji postaviti. Ako se na pitanje osjećate neugodno odgovoriti – „Mogu li stvarno otkazati bilo kada?" „Prikazuje li besplatni plan oglase?" – taj neugodni osjećaj je dokaz da tamo pripada, a ne razlog da ga izbacite. Posjetitelj ima to pitanje bez obzira odgovorili vi ili ne; ako ne odgovorite, zaključit će odgovor, a odgovor koji zaključe bit će gori od istine.

Korak 6 — Ujednačite i provjerite kvalitetu na svakoj stranici, prije nego što je pokažete klijentu.

Upravo ćete klijentu pokazati gotovu web stranicu. Prije toga otvorite stranicu s cijenama i stranicu značajki jednu pored druge. Provjerite svaki naziv značajke: podudaraju li se? Provjerite svaki broj: kaže li stranica s cijenama „10 projekata", a stranica značajki „do 10 projekata" i API referenca „maks. 10" – sve isto? Provjerite svako obećanje: je li „neograničeni projekti" bilo gdje na web mjestu i, ako jest, je li istinito? Zatim potražite vlastiti vokabular proizvoda: kaže li svugdje „radni prostori" ili se izmigolji u „timove"? Ovdje ćete uhvatiti da početna stranica kaže „nije potrebna kreditna kartica", dok tijek registracije zapravo traži kreditnu karticu za besplatnu probnu verziju – upravo klasa nedosljednosti koja ubija povjerenje.

Isplata redoslijeda iznutra prema van stiže ovdje. Jer je svaka stranica izvedena iz istih ograničenja, posao dosljednosti je provjera umjesto misije spašavanja. Ali nemojte to preskočiti. Proturječja koja prežive su suptilna – značajka nazvana „odobrenja" na stranici s cijenama, ali „tijekovi pregleda" u API dokumentaciji, snimka zaslona na početnoj stranici koja prikazuje nadzornu ploču u tamnom načinu koju proizvod ne isporučuje, tvrdnja da proizvodu „vjeruju udaljeni timovi" koja dolazi iz prezentacije brenda i ne odgovara stvarnom popisu kupaca klijenta.

Praktična tehnika: neka popis ograničenja bude scenarij za provjeru kvalitete. Prođite kroz svaku stranicu i provjerite svaku činjenicu prema popisu. Ovo funkcionira jer je popis ograničenja napisan u prvom tjednu, prije nego što su stranice postojale, pa je istinski neovisan izvor. Ako krenete s provjerom kvalitete iz dizajna ili iz sjećanja, propustit ćete činjenice koje su se promijenile dok ste gradili.

U ovom trenutku razlog za slijed rada postaje očit. Kada se stranice grade paralelno iz različitih izvora, ova provjera kvalitete svaki put pronalazi sukobe, a svaki sukob znači ponovni rad na stranici koja izgleda gotovo. Kada se stranice grade sekvencijalno s jednog popisa ograničenja, provjera kvalitete nalazi tipfeler. To je razlika između ponovljivog procesa i stalne krize. Kako biste cijelu web stranicu nakon pokretanja održali jednom pričom – nove značajke, novi timovi, novi copywriteri – trebate održavanu verziju iste discipline, a okvir za ujednačavanje priče SaaS web stranice na stranicama prirodan je sljedeći korak.

Oprez koji ovo čini iskrenim.

Tri stvari koje ovaj okvir ne tvrdi. Prvo, za SaaS u vrlo ranoj fazi bez API-ja, s jednim planom i jednim očitim slučajem upotrebe, redoslijed je mnogo manje važan; mogli biste izgraditi tu web stranicu bilo kojim redoslijedom i posao usklađivanja bio bi trivijalan. Okvir se isplati kada postoji stvarna složenost – više planova, API, mnoge značajke, više publika. Ne primjenjujte ga dogmatski na proizvod koji je u biti odredišna stranica s gumbom za prijavu.

Drugo, izgradnja iznutra prema van na početku proizvodi spor vidljivi napredak. Klijent je tražio početnu stranicu, a vi isporučujete tablicu cijena i dokument s ograničenjima. Oni će uzvratiti, jer početna stranica je ono što mogu pokazati investitorima i vlastitom timu. Upravljanje tim očekivanjem – pokazujući im kako odluke o stranici s cijenama oblikuju sve nizvodno – dio je posla, a ne njegov neuspjeh. Jedan način da zadržite zamah jest rano izraditi grubi mockup početne stranice, jasno označen kao spremnik koji čeka sadržaj, kako bi klijent mogao vidjeti odredište dok vi gradite kostur.

Treće, popis ograničenja se mijenja. Cijene se mijenjaju, API-ji rastu, planovi se množe. Okvir pretpostavlja da dokument s ograničenjima održavate ažuriranim nakon pokretanja, jer će web stranica propasti čim prestane odražavati stvarna ograničenja proizvoda. To je trošak održavanja pristupa iznutra prema van: izvor istine istinit je samo ako netko posjeduje taj dokument.

Zaključak.

Najčešći neuspjeh u SaaS web projektima nije slab tekst ili loš dizajn – već stranice koje se međusobno ne slažu, jer su izgrađene krivim redoslijedom. Krenite od stranice s cijenama i API dokumentacije, gdje su stvarna ograničenja proizvoda; izvedite prikaz značajki iz stvarnih radnih tijekova; prikupite FAQ iz stvarnih razgovora; i završite provjerom dosljednosti koja verificira, a ne spašava. Učinite to kod nekoliko različitih klijenata i otkrit ćete da je to manje kreativni proces, a više proizvodna linija – što je, u agenciji, upravo ono što želite. Kreativni rad i dalje postoji; samo se primjenjuje tamo gdje ima najveću polugu.