SaaS web sajtovi iznutra prema van: Zašto cijene i dokumentacija dolaze prvi

Sažetak

Većina savjeta o SaaS web sajtovima počinje od početne stranice i ostavlja cijene, dokumentaciju i FAQ kao dodatke naknadno — zbog čega te stranice završe u međusobnim proturječjima. Ovaj članak zagovara izgradnju iznutra prema van: krenite od stranice s cijenama i API dokumentacije, gdje su stvarna ograničenja proizvoda, i iz njih izvedite sve ostalo. Predstavlja okvir od šest koraka: prikupite ograničenja, izgradite stranicu s cijenama kao kostur, tretirajte API dokumentaciju kao površinu proizvoda, izvedite prikaz funkcija iz radnih tokova, 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 upozorenja o tome kada je okvir pretjeran i kako upravljati očekivanjima klijenata.

Većina savjeta o izgradnji SaaS web sajtova je pogrešna. Savjetuju vam da počnete od početne stranice — hero sekcije, naslova, snimka ekrana proizvoda — a cijene, dokumentaciju i FAQ tretirate kao stranice koje popunjavate nakon što je dizajn odobren. A onda, nedjeljama kasnije, usklađujete obećanje iz naslova "beskonačno sve" sa stvarnim ograničenjima na stranici s cijenama, a sekcija s funkcijama ponosno prikazuje beta funkciju koju API dokumentacija uopće ne spominje. Taj redoslijed funkcionira samo kada je proizvod dovoljno jednostavan da usklađivanje nije potrebno, što je rijetko slučaj. Ono što stvarno funkcionira — posebno kada to radite više puta za potpuno različite klijente — je izgradnja sajta iznutra prema van: krenite od najograničenijih, najmanje glamuroznih stranica (cijene i API dokumentacija), i pustite da one generiraju početnu stranicu, prikaz funkcija i FAQ. Evo okvira od šest koraka za to, i usput ću ukazati gdje postaje neugodno, jer postaje.

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

	Prvo stranica (najčešće)	Prvo ograničenja (ovaj okvir)
Gdje počinjete	Hero sekcija početne stranice i vizualni elementi	Stranica s cijenama i API dokumentacija
Šta pokreće tekst	Priča o brendu i dizajn	Stvarna ograničenja i radni tokovi proizvoda
Prikaz funkcija	Navodi sve što proizvod radi	Prati puteve kojima stvarni korisnici idu
FAQ	Napisan na kraju, na osnovu nagađanja	Prikupljen iz podrške i prodaje
Rezultat pri lansiranju	Nedosljedne tvrdnje, skriveni sukobi	Stranice se čitaju kao jedan proizvod

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

Klijent vam da listu funkcija, brend prezentaciju i demo link, i traži početnu stranicu. Do kraja prvog poziva, već raspravljate o hero tekstu i shemi boja. Pokušajte to usporiti. Zatražite stranicu s cijenama i ograničenja paketa — čak i ako su samo Google Doc s bilješkama — i otkrit ćete da se cijeli projekat mijenja.

Tražite čvrsta ograničenja: šta znači sjedište, kako se broji korištenje podataka, koje funkcije postoje na kom nivou paketa, postoji li API i šta on zapravo može. Ta ograničenja su temeljna istina. Svaka marketinška tvrdnja koju kasnije napišete mora preživjeti kontakt s njima.

Evo tipičnog scenarija. Klijent je alat za praćenje vremena: Free paket, Pro paket, Enterprise paket. Prodajna prezentacija kaže "skalira se na svaki tim." Pro stranica kaže "neograničeni projekti." Ali tim podrške potvrđuje da su Pro računi 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 se ovo ne riješi, jer je "neograničeni projekti" sada pravno pitanje, a ne pitanje teksta. Da ste počeli od početne stranice, napisali biste "neograničeni projekti" u hero sekciji i otkrili sukob dvije sedmice kasnije, nakon što je dizajn odobren. Početi s ograničenjima znači da se sukob pojavi u prvoj sedmici, kada popravak ne košta ništa.

Šta tačno trebate prikupiti u ovom koraku? Definicije paketa i tabelu poređenja funkcija po paketima. API dokumentaciju, ili barem listu 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 mjesto gdje živi fantazija. I sam proizvod, otvoren tako da vidite stranice postavki gdje su ograničenja primijenjena — jer je sam proizvod konačni autoritet. Ekran s postavkama koji kaže "Maksimalno 10 projekata" nadjačava svaku tabelu.

Ovaj korak ne proizvodi isporučivi rezultat. Proizvodi listu činjenica — ograničenja, definicije, izuzetke — s kojima ćete provjeravati svaku drugu stranicu. Za agenciju, ovo je također korak koji odvaja ponovljiv rad 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 cijelog sajta.

Stranica s cijenama ne djeluje kao mjesto za početak. To je tabela s brojevima i nazivima paketa — najmanje glamurozna stranica na sajtu. Ali ona je ugovor proizvoda s korisnikom i mjesto gdje se odlučuje o informacijskoj arhitekturi cijelog sajta. Ako je posao sajta da educira posjetioca dok ne bude spreman da se prijavi, stranica s cijenama je mjesto gdje ta edukacija konvergira. Svaka funkcija koja je bitna za kupovnu odluku je tamo imenovana; svako ograničenje koje je bitno je navedeno ili linkovano.

Uzmite alat za praćenje vremena. Tri paketa: Free, Pro, Enterprise. Tabela treba kolone koje odražavaju kako se proizvod zaista segmentira — broj projekata, integracije, dubinu izvještavanja. Za svaku ćeliju trebate iskrenu vrijednost, ne aspirativnu. Ako Pro uključuje 10 aktivnih projekata, ćelija kaže 10 aktivnih projekata, s linkom na FAQ o cijenama koji objašnjava šta znači "aktivan" i šta se dešava kada dostignete ograničenje. Jedna od težih odluka ovdje je šta reći o paketu koji najviše želite da posjetioci kupe. Mnoge stranice s cijenama čine glavni paket očiglednim — istaknutim, sa značkom "Najpopularniji" — a tekst oko njega objašnjava zašto je pravi izbor za tog posjetioca. Za alat za praćenje vremena, Pro je glavni paket: tu stvarno počinju integracije i dubina izvještavanja, pa bi stranica to trebala eksplicitno objasniti, umjesto da pretpostavlja da će posjetilac pročitati tabelu i sam zaključiti.

Ovo je također mjesto gdje odlučujete koji će termini biti kanonski na cijelom sajtu. Ako proizvod grupe naziva "radni prostori" na stranici s cijenama, a marketinški tekst kaže "timovi," svaka naredna stranica nasljeđuje nedosljednost. Pisanje stranice s cijenama prvo vas prisiljava da odaberete vokabular, i trebali biste odabrati ono što sam proizvod koristi — jer proizvod i dokumentacija moraju odgovarati tome, a marketinški sajt je taj koji se može prilagoditi.

Stranica s cijenama također treba vlastiti FAQ. Pitanja koja tu pripadaju su ona vezana za specifičnu mehaniku paketa: šta se računa kao sjedište, šta se dešava kada pređete na niži paket, da li je naplata godišnja ili mjesečna, šta "aktivan" znači za projekat. Postoji razvijena praksa za strukturiranje stranica s cijenama radi konverzije, i vrijedi se upoznati s mehanikom. Ali unutar ovog okvira, posao stranice s cijenama nije samo konverzija — već da zaključa činjenične odluke kojih će se svaka druga stranica pridržavati. Ako želite dublju mehaniku, ovaj vodič o popravljanju SaaS stranica s cijenama detaljno ih obrađuje.

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

Developer (programer) evaluira alat za praćenje vremena. Njihova kompanija treba automatski prenositi evidenciju radnog vremena u sistem plata. Dokumentacija je organizovana abecedno prema endpointima: /projects, /reports, /timesheets, /users. Developer nema pojma kojim pozivom da počne, a sekcija "Autentifikacija" pretpostavlja znanje koje nemaju — dokumentacija nikada ne objašnjava da se API ključ kreira na stranici postavki pod "Integracije." Developer zatvara tab, uvjeren da se proizvod neće čisto integrirati. Ipak, svaka potrebna informacija bila je prisutna u dokumentaciji; samo je bila organizovana redoslijedom kojim bi se koristio referentni priručnik, a ne redoslijedom kojim bi se koristio čovjek.

Dokumentacija organizovana prema radnim tokovima promijenila bi taj ishod: "Brzi početak," "Autentifikacija," "Preuzimanje evidencije vremena," "Kreiranje projekta," "Webhooks i sinhronizacija." Svaka sekcija počinje zadatkom, a zatim prikazuje endpoint. Brzi početak može potrajati pet minuta i proizvesti uspješan API poziv — što je dokumentacijski ekvivalent besplatne probe. Za proizvod koji je prvenstveno namijenjen developerima, ovo je najuvjerljivija stranica na sajtu.

Za svaki SaaS koji ima API, dokumentacija je stranica vašeg web sajta, bilo da ste to tako planirali ili ne. Industrijski standard — postavljen od strane Stripe-a, GitHub-a i Twilio-a — je dokumentacija koja se čita kao proizvod: objašnjava zadatak koji developer pokušava obaviti, a ne samo dostupne endpoint-e. Princip je da je API dokumentacija dio iskustva proizvoda i da bi trebala slijediti istu logiku iznutra prema van kao i ostatak sajta: krenite od zadataka koje developer može obaviti, zatim otkrijte mehaniku.

Bonus za agenciju je da pisanje dokumentacije na ovaj način izvlači listu ograničenja na površinu — šta API zapravo može, gdje su ograničenja stope, koji endpoint-i nedostaju — i uhvatit ćete te sukobe prije nego što se pojave na marketinškoj stranici. Ako je API dokumentacija glavni dio sajta ovog klijenta, dublji vodič za pisanje dokumentacije koju developeri zaista koriste.

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

Klijent vam emailom šalje tabelu sa 40 funkcija i traži stranicu s funkcijama. Lako rješenje je mreža: 40 stavki, svaka s ikonom i opisom. Rezultat djeluje temeljito, ali čita se kao šum, jer mreža nema priču. Niko ne posjećuje SaaS web sajt da bi naučio sve funkcije; posjećuju da bi saznali da li ovaj proizvod radi za njih potreban posao. Zato prikaz funkcija treba biti izgrađen od radnih tokova, a ne od liste funkcija.

Prođimo kroz primjer. Najčešći put koji vodi do uspjeha za alat za praćenje vremena, prema timu podrške klijenta, jeste vođa tima koji se prijavi, pozove tri kolege, kreira projekat i pokrene izvještaj na kraju sedmice. To je radni tok. Prikaz funkcija treba da ga prati: sekcija o pozivanju tima (pokriva sjedišta i uloge), sekcija o postavljanju projekta (pokriva šablone i postavke projekta), sekcija o dashboardu za izvještaje (pokriva grafikone i opcije izvoza). Svaka sekcija prikazuje snimak ekrana iz tog tačnog trenutka u proizvodu, a ne izrezani snimak rijetko korišćene ploče s postavkama. Posjetilac vidi vlastiti put, a funkcije koje vide usput su one koje su njima bitne.

Naredni radni tok, za malo drugačijeg posjetioca, je rukovodilac koji sam nikada ne koristi alat: oni odobravaju evidenciju radnog vremena i pregledaju sedmični izvještaj. Prikaz funkcija može dodati sekciju za tog posjetioca na kraju — "Za menadžere" — bez narušavanja narativa. Dva radna toka su obično dovoljna za početak; ne trebate po jedan za svaku personu.

Upit — pravi — je da prikaz funkcija zasnovan na radnim tokovima zahtijeva poznavanje stvarnih uobičajenih radnih tokova. To zahtijeva razgovor s podrškom i prodajom, ne samo s product menadžerom. Ako klijent ne može reći koja su tri glavna načina na koja ljudi koriste proizvod, to je prva stvar koju treba riješiti, jer će web sajt u suprotnom nagađati. Ovaj korak često otkriva da proizvod nema jasan primarni radni tok — što je problem proizvoda, a ne problem web sajta. Iskreno to označite; web sajt ne može proizvesti radni tok koji ne postoji. Za sistematski način redanja ovih radnih tokova, ovaj članak o strukturiranju prikaza funkcija za konverzije prolazi kroz sekvencu odlučivanja.

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

Imate dva dana prije nego što sajt bude objavljen, a FAQ je još uvijek prazan. Instinkt je da napišete deset pitanja u jednom popodnevu — obično pitanja na koja biste vi htjeli da proizvod odgovori, a ne ona koja stvarni korisnici postavljaju. To je pogrešno. FAQ ima specifičan posao: da ukloni posljednje sumnje između posjetioca i prijave. Učinkovite FAQ stranice, poput onih koje vidite od HubSpot-a, Slack-a i Zendesk-a, funkcionišu jer su organizovane oko stvarnih upita, pretražive su i sažete. One su proizvod slušanja, a ne izmišljanja.

Realističan scenario: na stranici ste s cijenama i znate da je najveći prekidač dogovora za alat za praćenje vremena integracija: "Da li ovo radi s QuickBooks-om?" Pregled dnevnika podrške pokazuje da je to najčešće pretprodajno pitanje. To pitanje, s odgovorom, pripada FAQ-u na stranici s cijenama. Drugo najčešće, iz prodajnih poziva, je "Šta se dešava s mojom evidencijom vremena ako otkažem?" To također pripada tamo. Svaki odgovor skraćuje prodajni ciklus i smanjuje opterećenje podrške, jer posjetilac koji vidi odgovor napisan vjeruje proizvodu više nego onaj koji mora pitati.

Pravilo za agenciju: ne pišite nijedan FAQ odgovor dok ne pogledate tickete podrške, bilješke s prodajnih poziva i emailove o uvođenju. Koja se pitanja zapravo ponavljaju? Ta idu unutra. Sve ostalo ide na stranicu s funkcijama ili nigdje. Kako se sajt razvija, ponovo posjetite FAQ — svaka promjena cijena ili lansiranje funkcije stvara nova pitanja, a FAQ je najjeftinije mjesto da ih uhvatite.

Također postoji razlog da razmislite o strukturi FAQ-a, ne samo o sadržaju. Duga lista pitanja koja se pomiče teško se skenira; grupiranje po kategorijama (Naplata, Integracije, Upravljanje računom) sa sadržajem na vrhu čini je stvarno upotrebljivom. Funkcija pretraživanja pomaže kada lista preraste određenu veličinu — ovo je dio stranice gdje dizajn jednako važan kao i tekst, jer FAQ koji se ne može pretraživati je FAQ koji se ne čita.

Još jedna stvar, koja je neugodan dio: FAQ je često najiskrenija stranica na sajtu, jer je to jedina stranica gdje odgovarate na pitanje koje se posjetilac plaši postaviti. Ako se pitanje čini neugodnim za odgovor — "Mogu li zaista otkazati bilo kada?" "Da li besplatni paket prikazuje oglase?" — taj neugodan osjećaj je dokaz da tamo pripada, a ne razlog da ga izostavite. Posjetilac ima to pitanje bez obzira na to da li vi odgovorite; ako ne odgovorite, zaključit će odgovor, a odgovor koji zaključe bit će gori od istine.

Korak 6 — Ujedinite i provjerite kvalitet na svakoj stranici, prije nego što je pokažete klijentu.

Spremate se pokazati klijentu završeni sajt. Prije toga, otvorite stranicu s cijenama i stranicu s funkcijama jednu pored druge. Provjerite svaki naziv funkcije: da li se podudaraju? Provjerite svaki broj: da li stranica s cijenama kaže "10 projekata", stranica s funkcijama "do 10 projekata", a API referenca "maks. 10" — svi isto? Provjerite svako obećanje: je li "neograničeni projekti" bilo gdje na sajtu, i ako jeste, da li je istinito? Zatim pretražite vlastiti vokabular proizvoda: da li svugdje kaže "radni prostori" ili sklizne u "timove"? Ovdje uhvatite da početna stranica kaže "nije potrebna kreditna kartica" dok proces prijave zapravo traži kreditnu karticu za besplatnu probu — upravo klasa nedosljednosti koja ubija povjerenje.

Korist od redoslijeda iznutra prema van ovdje dolazi do izražaja. Budući da je svaka stranica izvedena iz istih ograničenja, posao dosljednosti je provjera, a ne misija spašavanja. Ali nemojte to preskočiti. Kontradikcije koje prežive su suptilne — funkcija nazvana "odobrenja" na stranici s cijenama, ali "tokovi pregleda" u API dokumentaciji, snimak ekrana na početnoj stranici koji prikazuje dashboard u tamnom načinu koji proizvod ne isporučuje, tvrdnja da je proizvod "pouzdan za udaljene timove" koja dolazi iz brend prezentacije i ne odgovara stvarnoj listi kupaca klijenta.

Praktična tehnika: neka lista ograničenja bude scenarij za QA prolaz. Prođite kroz svaku stranicu i provjerite svaku činjenicu s listom. To funkcioniše jer je lista ograničenja napisana u prvoj sedmici, prije nego što su stranice postojale, pa je zaista nezavisan izvor. Ako krenete s QA iz dizajna ili iz pamćenja, propustit ćete činjenice koje su se promijenile dok ste gradili.

U ovom trenutku, razlog za redoslijed rada 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 ponovljivog procesa i stalne krize. Da bi cijeli sajt nakon lansiranja pričao jednu priču — nove funkcije, novi timovi, novi copywriteri — potrebna vam je verzija održavanja iste discipline, i okvir za objedinjavanje priče SaaS web sajta na stranicama je prirodni sljedeći korak.

Upozorenja koja ovo drže iskrenim.

Tri stvari koje ovaj okvir ne tvrdi. Prvo, za SaaS u vrlo ranoj fazi bez API-ja, s jednim paketom i jednom očiglednom upotrebom, redoslijed je mnogo manje bitan; mogli biste taj sajt izgraditi bilo kojim redoslijedom i posao usklađivanja bio bi trivijalan. Okvir se isplati kada postoji prava složenost — više paketa, API, mnogo funkcija, nekoliko publika. Nemojte ga primjenjivati kao dogmu na proizvod koji je u suštini landing stranica s dugmetom za prijavu.

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

Treće, lista ograničenja se mijenja. Cijene se mijenjaju, API-ji rastu, paketi se množe. Okvir pretpostavlja da ažurirate dokument s ograničenjima nakon lansiranja, jer će web sajt početi propadati čim prestane odražavati stvarna ograničenja proizvoda. To je trošak održavanja pristupa iznutra prema van: izvor istine je istinit samo ako ga neko posjeduje.

Zaključak.

Najčešći neuspjeh u SaaS web sajt projektima nije slab tekst ili loš dizajn — to su stranice koje se ne slažu jedna s drugom, jer su izgrađene pogrešnim redoslijedom. Krenite od stranice s cijenama i API dokumentacije, gdje su stvarna ograničenja proizvoda; izvedite prikaz funkcija iz stvarnih radnih tokova; prikupite FAQ iz stvarnih razgovora; i završite prolazom za provjeru dosljednosti koji provjerava, a ne spašava. Uradite to kod nekoliko različitih klijenata i otkrit ćete da je to manje kreativan proces, a više traka za sklapanje — što je, u agenciji, upravo ono što želite. Kreativni rad je i dalje tu; samo je primijenjen tamo gdje ima najviše poluge.