SaaS sajtovi iznutra napolje: Zašto su cene i dokumentacija prvi

Sažetak

Većina saveta o SaaS sajtovima počinje od početne stranice, a cene, dokumentaciju i FAQ ostavlja po strani — zbog čega te stranice na kraju protivreče jedna drugoj. Ovaj članak zagovara gradnju iznutra napolje: počnite od stranice sa cenama i API dokumentacije, gde su stvarna ograničenja proizvoda, i izvedite sve ostalo iz njih. Predstavlja okvir od šest koraka: prikupite ograničenja, napravite stranicu sa cenama kao kostur, tretirajte API dokumentaciju kao površinu proizvoda, izvedite prikaz funkcija iz radnih tokova, prikupite FAQ iz stvarnih razgovora i završite proverom doslednosti. Pristup je namenjen agencijama kojima je potreban proces koji se može ponoviti kod različitih klijenata. Takođe uključuje napomene o tome kada je okvir preteran i kako upravljati očekivanjima klijenata.

Većina saveta o izgradnji SaaS sajtova je pogrešna. Savetuje vam da počnete od početne stranice — hero sekcije, naslova, snimka ekrana proizvoda — a cene, dokumentaciju i FAQ tretirate kao stranice koje popunjavate nakon što je dizajn odobren. Zatim, nedeljama kasnije, usklađujete obećanje iz naslova o „neograničenom svemu“ sa stvarnim ograničenjima korišćenja na stranici sa cenama, a sekcija sa funkcijama ponosno prikazuje beta funkciju koju API dokumentacija ni ne pominje. Takav redosled funkcioniše samo kada je proizvod dovoljno jednostavan da usklađivanje nije potrebno, što je retko slučaj. Ono što zaista funkcioniše — posebno kada to radite iznova za potpuno različite klijente — jeste da sajt gradite iznutra napolje: počnite od najograničenijih, najmanje glamuroznih stranica (cene i API dokumentacija) i neka one generišu početnu stranicu, prikaz funkcija i FAQ. Evo okvira od šest koraka za to, a usput ću ukazati na mesta gde postaje neugodno, jer postaje.

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

	Prvo stranica (najčešće)	Prvo ograničenja (ovaj okvir)
Gde počinjete	Hero i vizuali početne stranice	Stranica sa cenama i API dokumentacija
Šta oblikuje tekst	Priča o brendu i dizajn	Stvarna ograničenja i radni tokovi proizvoda
Prikaz funkcija	Navodi sve što proizvod radi	Prati puteve koje stvarni korisnici prolaze
FAQ	Napisan na kraju, iz nagađanja	Prikupljen iz podrške i prodaje
Rezultat pri pokretanju	Nedosledne tvrdnje, skriveni sukobi	Stranice deluju kao jedan proizvod

Korak 1 — Pročitajte stranicu sa cenama pre nego što napišete ijednu reč.

Klijent vam da spisak funkcija, brend prezentaciju i link za demo, i traži početnu stranicu. Do kraja prvog poziva, razgovarate o hero tekstu i shemi boja. Pokušajte to da usporite. Zatražite stranicu sa cenama i ograničenja planova — čak i ako su samo Google Doc sa beleškama — i videćete da se ceo projekat menja.

Tražite čvrsta ograničenja: šta znači sedište (seat), kako se broji korišćenje podataka, koje funkcije postoje na kom nivou plana, da li postoji API i šta on zaista može. Ova ograničenja su osnovna istina. Svaka marketinška tvrdnja koju kasnije iznesete mora preživeti kontakt sa njima.

Evo tipičnog scenarija. Klijent je alat za praćenje vremena: Free 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 su Pro nalozi zapravo ograničeni na 10 aktivnih projekata po radnom prostoru, a API dokumentacija kaže da projekat može imati najviše 50 članova. Početna stranica se ne piše dok neko ne reši ovo, jer je „neograničeni projekti“ sada pravno pitanje, a ne tekstualno. Da ste počeli od početne stranice, napisali biste „neograničeni projekti“ u hero sekciju i otkrili sukob dve nedelje kasnije, nakon što je dizajn odobren. Početi od ograničenja znači da se sukob pojavljuje u prvoj nedelji, kada popravka ne košta ništa.

Šta tačno treba da prikupite u ovom koraku? Definicije planova i tabelu poređenja funkcija po planu. API dokumentaciju, ili bar spisak 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, s napomenom da su prodajne prezentacije mesto gde živi fantazija. I sam proizvod, otvoren da vidite stranice sa podešavanjima gde se ograničenja primenjuju — jer je sam proizvod konačni autoritet. Ekran sa podešavanjima koji kaže „Maksimum 10 projekata“ nadjačava bilo koju tabelu.

Ovaj korak ne proizvodi isporučivi rezultat. Proizvodi listu činjenica — ograničenja, definicije, izuzetke — prema kojima ćete proveravati svaku drugu stranicu. Za agenciju, ovo je korak koji odvaja posao koji se može ponoviti 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 — Napravite stranicu sa cenama kao kostur celog sajta.

Stranica sa cenama ne deluje kao mesto za početak. To je tabela sa brojevima i nazivima planova — najmanje glamurozna stranica na sajtu. Ali to je ugovor proizvoda sa korisnikom i tu se odlučuje o informacionoj arhitekturi celog sajta. Ako je posao sajta da obrazuje posetioca dok ne bude spreman da se prijavi, stranica sa cenama je mesto gde se to obrazovanje susreće. Svaka funkcija koja je bitna za odluku o kupovini je tu imenovana; svako ograničenje koje je bitno je navedeno ili je linkovano.

Uzmimo alat za praćenje vremena. Tri plana: Free, Pro, Enterprise. Tabela treba da ima kolone koje odražavaju kako se proizvod zaista segmentira — broj projekata, integracije, dubinu izveštavanja. Za svaku ćeliju potrebna vam je iskrena vrednost, a ne ona aspiracijska. Ako Pro uključuje 10 aktivnih projekata, ćelija kaže 10 aktivnih projekata, sa linkom ka FAQ o cenama koji objašnjava šta znači „aktivno“ i šta se dešava kada dostignete ograničenje. Jedna od težih odluka ovde je šta reći o planu koji najviše želite da posetioci kupe. Mnoge stranice sa cenama čine sidreni plan očiglednim — istaknutim, sa značkom „Najpopularnije“ — a tekst oko njega objašnjava zašto je pravi izbor za ovog posetioca. Za alat za praćenje vremena, Pro je sidro: tu zaista počinju integracije i dubina izveštavanja, pa bi stranica trebalo da to eksplicitno objasni, umesto da pretpostavlja da će posetilac sam pročitati tabelu i to zaključiti.

Ovo je takođe mesto gde odlučujete koji će termini biti kanonski na celom sajtu. Ako proizvod grupe naziva „radni prostori“ (workspaces) na stranici sa cenama, a marketinški tekst kaže „timovi“, svaka naredna stranica nasleđuje nedoslednost. Pisanje stranice sa cenama prvo vas primorava da izaberete vokabular, a trebalo bi da izaberete ono što sam proizvod koristi — jer proizvod i dokumentacija moraju da se slažu s tim, a marketinški sajt je taj koji može da se prilagodi.

Stranica sa cenama takođe treba da ima sopstveni FAQ. Pitanja koja tu pripadaju su ona vezana za specifične mehanike planova: šta se računa kao sedište, šta se dešava kada smanjite plan, da li se naplata vrši godišnje ili mesečno, šta „aktivno“ znači za projekat. Postoji dobro razvijena praksa strukturisanja stranica sa cenama za konverziju, a mehanike vredi proučiti. Ali u okviru ovog okvira, posao stranice sa cenama nije samo konverzija — već da učvrsti činjenične odluke kojih će se svaka druga stranica pridržavati. Ako želite dublje mehanike, ovaj vodič za popravljanje SaaS stranica sa cenama ih detaljno pokriva.

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

Developer procenjuje alat za praćenje vremena. Njihova kompanija treba da automatski prenese evidenciju radnog vremena u sistem za obračun plata. Dokumentacija je organizovana abecedno po endpointima: /projects, /reports, /timesheets, /users. Developer nema pojma koji poziv da počne, a sekcija „Autentifikacija“ pretpostavlja znanje koje oni nemaju — dokumentacija nikada ne objašnjava da se API ključ kreira na stranici sa podešavanjima pod „Integracije“. Developer zatvara tab, ubeđen da se proizvod neće čisto integrisati. A ipak je svaka neophodna informacija bila prisutna u dokumentaciji; samo je bila organizovana redosledom kojim bi se koristio referentni priručnik, a ne redosledom kojim bi se koristio čovek.

Dokumentacija organizovana po radnim tokovima promenila bi taj ishod: „Brzi početak“, „Autentifikacija“, „Preuzmi evidenciju vremena“, „Kreiraj projekat“, „Webhooks i sinhronizacija“. Svaka sekcija počinje zadatkom, zatim prikazuje endpoint. Brzi početak bi mogao da traje pet minuta i da proizvede uspešan API poziv — što je dokumentacioni ekvivalent besplatne probne verzije. Za proizvod koji je prvo namenjen developerima, ovo je najubedljivija stranica na sajtu.

Za svaki SaaS koji ima API, dokumentacija je stranica vašeg sajta, bilo da ste to tako planirali ili ne. Industrijski standard — koji su postavili Stripe, GitHub i Twilio — je dokumentacija koja se čita kao proizvod: objašnjava zadatak koji developer pokušava da uradi, a ne samo dostupne endpoint-e. Princip je da je API dokumentacija deo iskustva proizvoda i da treba da prati istu logiku iznutra napolje kao i ostatak sajta: počnite sa zadacima koje developer može da obavi, zatim otkrijte mehaniku.

Bonus za agenciju je da pisanje dokumentacije na ovaj način izvlači listu ograničenja na površinu — šta API zaista može, gde su ograničenja brzine (rate limits), koji endpointi nedostaju — i uhvatićete te sukobe pre nego što se pojave na marketinškoj stranici. Ako je API dokumentacija glavni deo sajta ovog klijenta, postoji dublji vodič za pisanje dokumentacije koju developeri zaista koriste.

Korak 4 — Izvedite prikaz funkcija iz radnih tokova, a ne iz liste funkcija.

Klijent vam mejlom šalje tabelu sa 40 funkcija i traži stranicu sa funkcijama. Laki odgovor je mreža: 40 stavki, svaka sa ikonicom i natpisom. Rezultat deluje temeljno, ali se čita kao buka, jer mreža nema priču. Niko ne posećuje SaaS sajt da bi naučio svaku funkciju; posećuju ga da bi saznali da li ovaj proizvod radi onaj jedan posao zbog kojeg su došli. Zato prikaz funkcija treba graditi od radnih tokova, a ne od liste funkcija.

Prođimo kroz primer. Najčešći put do uspeha alata za praćenje vremena, prema timu podrške klijenta, je vođa tima koji se prijavi, pozove tri kolege, kreira projekat i pokrene izveštaj na kraju nedelje. To je radni tok. Prikaz funkcija treba da ga prati: sekcija o pozivanju tima (pokriva sedišta i uloge), sekcija o postavljanju projekta (pokriva šablone i podešavanja projekta), sekcija o dashboard-u za izveštaje (pokriva grafikone i opcije izvoza). Svaka sekcija prikazuje snimak ekrana tačno tog trenutka u proizvodu, a ne isečeni snimak retko korišćenog panela sa podešavanjima. Posetilac vidi sopstveni put, a funkcije koje vide usput su one koje su njima bitne.

Sledeći radni tok, za malo drugačijeg posetioca, je rukovodilac koji nikada sam ne koristi alat: oni odobravaju evidenciju vremena i pregledaju nedeljni izveštaj. Prikaz funkcija može dodati sekciju za tog posetioca na kraju — „Za menadžere“ — bez narušavanja narativa. Dva radna toka su obično dovoljna za početak; ne treba vam jedan za svaku personu.

Ograničenje — stvarno — je da prikaz funkcija zasnovan na radnim tokovima zahteva poznavanje uobičajenih radnih tokova. To zahteva razgovor sa podrškom i prodajom, ne samo sa projektnim menadžerom. Ako klijent ne može da vam kaže tri najčešća načina na koje ljudi koriste proizvod, to je prva stvar koju treba popraviti, jer će sajt inače nagađati. Ovaj korak često otkriva da proizvod nema jasan primarni radni tok — što je problem proizvoda, a ne sajta. Pošteno to označite; sajt ne može da proizvede radni tok koji ne postoji. Za sistematski način da poredate ove radne tokove, ovaj tekst o strukturisanju prikaza funkcija za konverzije prolazi kroz sekvencu odluka.

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

Imate dva dana do objavljivanja sajta, a FAQ je i dalje prazan. Instinkt je da napišete deset pitanja za jedno popodne — obično pitanja na koja biste vi želeli da proizvod odgovori, a ne ona koja stvarni korisnici postavljaju. To je pogrešno. FAQ ima konkretan zadatak: da ukloni poslednje sumnje između posetioca i prijave. Efikasne FAQ stranice, poput onih koje vidite kod HubSpot-a, Slack-a i Zendesk-a, funkcionišu jer su organizovane oko stvarnih upita, pretražive i sažete. One su proizvod slušanja, a ne izmišljanja.

Realističan scenario: na stranici ste sa cenama i znate da je najveća prepreka za alat za praćenje vremena integracija: „Da li ovo radi sa QuickBooks-om?“ Pregled dnevnika podrške pokazuje da je to najčešće pitanje pre prodaje. To pitanje, sa svojim odgovorom, pripada FAQ-u na stranici sa cenama. Drugo najčešće, iz prodajnih poziva, je „Šta se dešava sa mojom evidencijom vremena ako otkažem?“ I to tu pripada. Svaki odgovor skraćuje prodajni ciklus i smanjuje opterećenje podrške, jer posetilac koji vidi odgovor u pisanoj formi veruje proizvodu više nego posetilac koji mora da pita.

Pravilo za agenciju: ne pišite nijedan FAQ odgovor dok ne pogledate tikete podrške, beleške sa prodajnih poziva i imejlove o uključivanju korisnika. Koja se pitanja zaista ponavljaju? Ta idu unutra. Sve ostalo ide na stranicu funkcija ili nigde. I kako se sajt razvija, ponovo posetite FAQ — svaka nova promena cena ili lansiranje funkcije stvara nova pitanja, a FAQ je najjeftinije mesto da ih uhvatite.

Postoji i razlog da razmišljate o strukturi FAQ-a, a ne samo o sadržaju. Duga lista pitanja koja se skroluje teško se skenira; grupisanje po kategorijama (Naplata, Integracije, Upravljanje nalogom) sa sadržajem na vrhu čini je zaista upotrebljivom. Funkcija pretrage pomaže kada lista preraste određenu veličinu — ovo je deo stranice gde dizajn podjednako važi kao i tekst, jer FAQ koji se ne može pretraživati je FAQ koji se ne čita.

Još jedna stvar, koja je neugodni deo: FAQ je često najiskrenija stranica na sajtu, jer je to stranica na kojoj odgovarate na pitanje koje se posetilac plaši da postavi. Ako pitanje deluje neugodno za odgovor — „Mogu li zaista otkazati bilo kada?“ „Da li besplatni plan prikazuje oglase?“ — taj osećaj neugodnosti je dokaz da tu pripada, a ne razlog da ga izbacite. Posetilac ima to pitanje bez obzira da li vi odgovorite; ako ne odgovorite, oni će izvući zaključak, a zaključak koji izvuku biće gori od istine.

Korak 6 — Ujednačite i proverite svaku stranicu, pre nego što je pokažete klijentu.

Spremate se da klijentu pokažete gotov sajt. Pre toga, otvorite stranicu sa cenama i stranicu funkcija jednu pored druge. Proverite svaki naziv funkcije: da li se poklapaju? Proverite svaki broj: da li stranica sa cenama kaže „10 projekata“, stranica funkcija „do 10 projekata“, a API referenca „maks. 10“ — sve isto? Proverite svako obećanje: da li je „neograničeni projekti“ bilo gde na sajtu i, ako jeste, da li je tačno? Zatim potražite sopstveni vokabular proizvoda: da li svuda piše „radni prostori“ ili se provlači „timovi“? Ovo je mesto gde ćete uhvatiti da početna stranica kaže „nije potrebna kreditna kartica“, dok tok prijave zapravo traži kreditnu karticu za besplatnu probnu verziju — tačno ona vrsta nedoslednosti koja ubija poverenje.

Nagrada za redosled iznutra napolje stiže ovde. Pošto je svaka stranica izvedena iz istih ograničenja, posao doslednosti je prolaz provere, a ne misija spasavanja. Ali nemojte ga preskočiti. Protivrečnosti koje prežive su suptilne — funkcija koja se na stranici sa cenama zove „odobrenja“, ali u API dokumentaciji „tokovi pregleda“, snimak ekrana na početnoj stranici koji prikazuje dashboard u tamnom režimu koji proizvod ne isporučuje, tvrdnja da je proizvod „pouzdan za udaljene timove“ koja je došla iz brend prezentacije i ne odgovara stvarnoj listi klijenata klijenta.

Praktična tehnika: neka lista ograničenja bude scenario za prolaz QA. Prođite kroz svaku stranicu i proverite svaku činjenicu prema listi. Ovo funkcioniše jer je lista ograničenja napisana u prvoj nedelji, pre nego što su stranice postojale, tako da je zaista nezavisan izvor. Ako QA počnete od dizajna ili iz sećanja, propustićete činjenice koje su se promenile dok ste gradili.

U ovom trenutku, razlog za sekvenciranje posla postaje očigledan. Kada se stranice grade paralelno iz različitih izvora, ovaj QA prolaz svaki put pronalazi sukobe, a svaki sukob znači ponovni rad na stranici koja izgleda gotovo. Kada se stranice grade sekvencijalno iz jedne liste ograničenja, QA prolaz pronalazi greške u kucanju. To je razlika između procesa koji se može ponoviti i stalne krize. Da bi ceo sajt nakon pokretanja pričao jednu priču — nove funkcije, novi timovi, novi tekstopisci — potrebna vam je verzija iste discipline za održavanje, i okvir za ujedinjenje priče SaaS sajta na svim stranicama je prirodni sledeći korak.

Ograničenja koja čuvaju iskrenost ovog pristupa.

Tri stvari koje ovaj okvir ne tvrdi. Prvo, za SaaS u vrlo ranoj fazi bez API-ja, sa jednim planom i jednim očiglednim slučajem upotrebe, redosled je mnogo manje bitan; taj sajt možete napraviti u bilo kom redosledu i posao usklađivanja bio bi trivijalan. Okvir se isplati kada postoji stvarna složenost — više planova, API, mnogo funkcija, više publika. Nemojte ga primenjivati kao dogmu na proizvod koji je u suštini landing stranica sa dugmetom za prijavu.

Drugo, gradnja iznutra napolje na početku proizvodi spor vidljiv napredak. Klijent je tražio početnu stranicu, a vi isporučujete tabelu cena i dokument sa ograničenjima. Oni će se pobuniti, jer je početna stranica ono što mogu pokazati investitorima i svom timu. Upravljanje tim očekivanjem — pokazivanje kako odluke o stranici sa cenama oblikuju sve nizvodno — deo je posla, a ne njegov neuspeh. Jedan način da održite zamah je da rano napravite grubi mockup početne stranice, jasno označen kao kontejner koji čeka sadržaj, kako bi klijent mogao da vidi odredište dok vi gradite kostur.

Treće, lista ograničenja se menja. Cene se menjaju, API-ji rastu, planovi se umnožavaju. Okvir pretpostavlja da ažurirate dokument ograničenja nakon pokretanja, jer će sajt početi da propada u trenutku kada prestane da odražava stvarna ograničenja proizvoda. Ovo je trošak održavanja pristupa iznutra napolje: izvor istine je istinit samo ako neko brine o njemu.

Zaključak.

Najčešći neuspeh u SaaS sajt projektima nije slab tekst ili loš dizajn — već stranice koje se međusobno ne slažu, jer su izgrađene pogrešnim redosledom. Počnite sa stranicom sa cenama i API dokumentacijom, gde žive stvarna ograničenja proizvoda; izvedite prikaz funkcija iz stvarnih radnih tokova; prikupite FAQ iz stvarnih razgovora; i završite prolazom doslednosti koji proverava, a ne spasava. Uradite to kod nekoliko različitih klijenata i otkrićete da je to manje kreativni proces, a više traka za sklapanje — što je u agenciji upravo ono što želite. Kreativni rad je i dalje tu; samo se primenjuje tamo gde ima najveću polugu.