Spletne strani SaaS od znotraj navzven: zakaj so cene in dokumentacija na prvem mestu

Povzetek

Večina nasvetov o spletnih straneh SaaS se začne z domačo stranjo, cene, dokumentacijo in pogosta vprašanja pa pusti ob strani – zato te strani na koncu med seboj nasprotujejo. Ta članek zagovarja gradnjo od znotraj navzven: začnite s cenikom in API dokumentacijo, kjer živijo dejanske omejitve izdelka, in iz njih izpeljite vse ostalo. Predstavlja šeststopenjski okvir: zberite omejitve, zgradite cenik kot ogrodje, obravnavajte API dokumentacijo kot produktno površino, izpeljite predstavitev funkcij iz delovnih tokov, poberite pogosta vprašanja iz resničnih pogovorov in na koncu naredite preverjanje skladnosti. Pristop je namenjen agencijam, ki potrebujejo ponovljiv proces za različne stranke. Vključuje tudi opozorila o tem, kdaj je okvir pretiran in kako upravljati pričakovanja strank.

Večina nasvetov o gradnji spletnih strani SaaS je obrnjena na glavo. Pravi, naj začnete z domačo stranjo – z hero sekcijo, naslovom, posnetkom zaslona izdelka – cenik, dokumentacijo in pogosta vprašanja pa obravnavajte kot strani, ki jih izpolnite, ko je dizajn odobren. Tedne pozneje nato usklajujete obljubo iz naslova o "neomejenem vsem" z dejanskimi omejitvami uporabe na ceniku, sekcija s funkcijami pa ponosno prikazuje beta funkcijo, ki je API dokumentacija sploh ne omenja. Tak vrstni red deluje le, kadar je izdelek dovolj preprost, da usklajevanje ni potrebno, kar pa je redko. Kar dejansko deluje – še posebej, kadar to počnete znova in znova za popolnoma različne stranke – je gradnja spletišča od znotraj navzven: začnite z najbolj omejenimi, najmanj glamuroznimi stranmi (cenik in API dokumentacija) in naj te ustvarijo domačo stran, predstavitev funkcij in pogosta vprašanja. Tukaj je šeststopenjski okvir za to, sproti pa bom opozoril, kje postane neprijetno, ker postane.

Kratek pregled razlike, ker celoten argument temelji na njej:

	Najprej stran (najpogosteje)	Najprej omejitve (ta okvir)
Kje začnete	Hero sekcija in vizualije domače strani	Cenik in API dokumentacija
Kaj poganja vsebino	Zgodba blagovne znamke in dizajn	Dejanske omejitve in delovni tokovi izdelka
Predstavitev funkcij	Našteje vse, kar izdelek počne	Sledi potem, ki jih uporabljajo resnični uporabniki
Pogosta vprašanja	Napisana nazadnje, iz ugibanj	Pobrana iz podpore in prodaje
Rezultat ob lansiranju	Neskladne trditve, skriti konflikti	Strani delujejo kot en izdelek

1. korak — Preberite cenik, preden napišete besedo.

Stranka vam izroči seznam funkcij, predstavitev blagovne znamke in povezavo do demonstracije ter zahteva domačo stran. Do konca prvega klica že razpravljate o besedilu v hero sekciji in barvni shemi. Poskusite to upočasniti. Zahtevajte cenik in omejitve paketov – tudi če so le Google Dokument z zapiski – in odkrili boste, da se celoten projekt spremeni.

Iščete trde omejitve: kaj pomeni sedež, kako se šteje poraba podatkov, katere funkcije obstajajo na kateri ravni paketa, ali obstaja API in kaj dejansko zmore. Te omejitve so temeljna resnica. Vsaka marketinška trditev, ki jo pozneje navedete, mora ob stiku z njimi preživeti.

Tukaj je tipičen scenarij. Stranka je orodje za beleženje časa: brezplačni paket, Pro paket, Enterprise paket. Prodajna predstavitev pravi "prilagaja se vsaki ekipi." Stran Pro pravi "neomejeni projekti." Toda ekipa za podporo potrdi, da so računi Pro dejansko omejeni na 10 aktivnih projektov na delovni prostor, API dokumentacija pa pravi, da ima lahko projekt največ 50 članov. Domača stran ni napisana, dokler tega nekdo ne razreši, ker je "neomejeni projekti" zdaj pravno vprašanje, ne vprašanje besedila. Če bi začeli z domačo stranjo, bi v hero sekciji napisali "neomejeni projekti" in konflikt odkrili dva tedna pozneje, po tem ko je bila oblika podpisana. Začetek z omejitvami pomeni, da se konflikt pokaže v prvem tednu, ko popravilo ne stane ničesar.

Kaj natančno bi morali zbrati v tem koraku? Definicije paketov in morebitno primerjalno tabelo funkcij po paketih. API dokumentacijo ali vsaj seznam, kaj API zmore in česa ne. Najpogostejša vprašanja ekipe za podporo (več o tem v 5. koraku). Prodajno predstavitev, z opozorilom, da so prodajne predstavitve kraj, kjer živi fantazija. In dejanski izdelek, odprt tako, da vidite nastavitvene strani, kjer se omejitve uveljavljajo – ker je izdelek sam končna avtoriteta. Nastavitveni zaslon, ki pravi "Največ 10 projektov", preglasi vsako preglednico.

Ta korak ne ustvari dobavljivega rezultata. Ustvari seznam dejstev – omejitve, definicije, izjeme – s katerim boste preverjali vsako drugo stran. Za agencijo je to tudi korak, ki loči ponovljivo delo od gašenja požarov. Zapišite omejitve v skupni dokument in zgradili boste vir resnice, na katerega se bo sklicevala vsaka prihodnja posodobitev strani.

2. korak — Zgradite cenik kot ogrodje celotnega spletišča.

Cenik se ne zdi kot prostor za začetek. To je tabela s številkami in imeni paketov – najmanj glamurozna stran na spletišču. A to je pogodba izdelka z uporabnikom in tu se odloča o informacijski arhitekturi celotnega spletišča. Če je naloga spletišča izobraževati obiskovalca, dokler ni pripravljen za prijavo, je cenik mesto, kjer se to izobraževanje steka. Vsaka funkcija, ki je pomembna za nakupno odločitev, je tam poimenovana; vsaka omejitev, ki je pomembna, je navedena ali z njo povezana.

Vzemite orodje za beleženje časa. Trije paketi: Free, Pro, Enterprise. Tabela potrebuje stolpce, ki odražajo, kako izdelek dejansko segmentira – število projektov, integracije, globina poročanja. Za vsako celico potrebujete pošteno vrednost, ne želene. Če Pro vključuje 10 aktivnih projektov, celica pravi 10 aktivnih projektov, s povezavo do pogostih vprašanj na ceniku, ki pojasnjujejo, kaj pomeni "aktivno" in kaj se zgodi, ko dosežete omejitev. Ena težjih odločitev tukaj je, kaj reči o paketu, ki ga najbolj želite prodati obiskovalcem. Mnogi ceniki naredijo sidrni paket očiten – poudarjen, z značko "Najbolj priljubljen" – in besedilo okoli njega pojasni, zakaj je prava izbira za tega obiskovalca. Za orodje za beleženje časa je Pro sidrni paket: tu se integracije in globina poročanja dejansko začnejo, zato bi morala stran to izrecno povedati, namesto da domneva, da bo obiskovalec prebral tabelo in sam prišel do tega sklepa.

Tu se tudi odločite, kateri izrazi bodo kanonični na celotnem spletišču. Če izdelek skupine na ceniku imenuje "delovni prostori", marketinško besedilo pa pravi "ekipe", potem vsaka naslednja stran podeduje to nedoslednost. Pisanje cenika najprej vas prisili, da izberete besedišče, in izberite tisto, ki ga uporablja izdelek sam – ker morajo izdelek in dokumentacija temu ustrezati, marketinško spletišče pa se lahko prilagodi.

Cenik potrebuje tudi lastna pogosta vprašanja. Vprašanja, ki spadajo tja, so tista, povezana s specifičnimi mehanikami paketov: kaj šteje kot sedež, kaj se zgodi, ko znižate paket, ali je obračun letni ali mesečni, kaj "aktivno" pomeni za projekt. Obstaja dobro razvita praksa strukturiranja cenikov za konverzije in mehanike je vredno preučiti. Toda v tem okviru naloga cenika ni le pretvarjanje obiskovalcev – je zaklepanje dejanskih odločitev, ki jih bo upoštevala vsaka druga stran. Če želite globlje mehanike, ta vodnik o odpravljanju težav s ceniki SaaS podrobno pokriva.

3. korak — API dokumentacijo obravnavajte kot produktno površino, ne kot priročnik.

Razvijalec ocenjuje orodje za beleženje časa. Njihovo podjetje mora samodejno prenašati časovnice v sistem za obračun plač. Dokumentacija je organizirana po abecedi glede na končne točke: /projects, /reports, /timesheets, /users. Razvijalec nima pojma, s katerim klicem začeti, in razdelek "Avtentikacija" predpostavlja znanje, ki ga nima – dokumentacija nikoli ne pojasni, da ustvarite API ključ na nastavitveni strani pod "Integracije". Razvijalec zapre zavihek, prepričan, da se izdelek ne bo čisto integriral. Vendar je bil vsak potreben podatek v dokumentaciji prisoten; le organiziran je bil v vrstnem redu, kot bi ga uporabil referenčni priročnik, ne v vrstnem redu, kot bi ga uporabil človek.

Dokumentacija, organizirana po delovnih tokovih, bi spremenila ta izid: "Hitri začetek", "Avtentikacija", "Prenos časovnic", "Ustvarjanje projekta", "Webhooks in sinhronizacija". Vsak razdelek najprej vodi opravilo, nato prikaže končno točko. Hitri začetek bi lahko zahteval pet minut in ustvaril uspešen API klic – kar je dokumentacijski ekvivalent brezplačnega preizkusa. Za izdelek, ki je najprej namenjen razvijalcem, je to najbolj prepričljiva stran na spletišču.

Za vsak SaaS, ki ima API, je dokumentacija stran vašega spletišča, ne glede na to, ali ste to načrtovali ali ne. Industrijsko merilo – ki so ga postavili Stripe, GitHub in Twilio – je dokumentacija, ki se bere kot izdelek: pojasni opravilo, ki ga razvijalec poskuša doseči, ne samo razpoložljivih končnih točk. Načelo je, da je API dokumentacija del izkušnje izdelka in mora slediti isti logiki od znotraj navzven kot preostali del spletišča: začnite z opravili, ki jih razvijalec lahko opravi, nato razkrijte mehaniko.

Bonus za agencijo je, da pisanje dokumentacije na ta način prisili seznam omejitev na plan – kaj API dejansko zmore, kje so omejitve hitrosti, katere končne točke manjkajo – in te konflikte boste ujeli, preden se pojavijo na marketinški strani. Če je API dokumentacija velik del spletišča te stranke, obstaja poglobljeni vodnik o pisanju dokumentacije, ki jo razvijalci dejansko uporabljajo.

4. korak — Predstavitev funkcij izpeljite iz delovnih tokov, ne iz seznama funkcij.

Stranka vam po e-pošti pošlje preglednico s 40 funkcijami in zahteva stran s funkcijami. Enostaven odgovor je mreža: 40 elementov, vsak z ikono in napisom. Rezultat deluje temeljit, a bere se kot šum, ker mreža nima zgodbe. Nihče ne obišče spletne strani SaaS, da bi izvedel vse funkcije; obiščejo jo, da bi izvedeli, ali ta izdelek opravi tisto eno opravilo, zaradi katerega so prišli. Zato bi morala biti predstavitev zgrajena iz delovnih tokov, ne iz seznama funkcij.

Preverimo primer. Najpogostejša zmagovalna pot orodja za beleženje časa, po besedah ekipe za podporo stranke, je vodja ekipe, ki se registrira, povabi tri sodelavce, ustvari projekt in ob koncu tedna zažene poročilo. To je delovni tok. Predstavitev funkcij bi mu morala slediti: razdelek o povabilu vaše ekipe (ki zajema sedeže in vloge), razdelek o nastavitvi projekta (ki zajema predloge in nastavitve projekta), razdelek o nadzorni plošči poročanja (ki zajema grafikone in možnosti izvoza). Vsak razdelek prikazuje posnetek zaslona iz tistega trenutka v izdelku, ne obrezanega posnetka zaslona redko uporabljene plošče z nastavitvami. Obiskovalec vidi svojo pot in funkcije, ki jih vidi na poti, so tiste, ki so zanj pomembne.

Nadaljnji delovni tok, za nekoliko drugačnega obiskovalca, je vodja, ki orodja sam nikoli ne uporablja: odobri časovnice in pregleda tedensko poročilo. Predstavitev lahko na koncu doda razdelek za tega obiskovalca – "Za vodje" – ne da bi prekinila pripoved. Dva delovna toka sta običajno dovolj za začetek; ne potrebujete enega za vsako osebo.

Opozorilo – resnično – je, da predstavitev, temelječa na delovnih tokovih, zahteva poznavanje dejanskih pogostih delovnih tokov. To zahteva pogovor s podporo in prodajo, ne le s produktnim vodjem. Če vam stranka ne more povedati treh glavnih načinov uporabe izdelka, je to prva stvar, ki jo je treba popraviti, ker bo sicer spletna stran ugibala. Ta korak pogosto razkrije, da izdelek nima jasnega primarnega delovnega toka – kar je problem izdelka, ne problema spletne strani. Iskreno to označite; spletna stran ne more izdelati delovnega toka, ki ne obstaja. Za sistematičen način urejanja teh delovnih tokov ta članek o strukturiranju predstavitve funkcij za konverzije podrobno opiše zaporedje odločitev.

5. korak — Pogosta vprašanja poberite iz podpore in prodaje, ne iz svoje domišljije.

Do lansiranja spletišča imate še dva dni, pogosta vprašanja pa so še vedno prazna. Nagon je, da v enem popoldnevu napišete deset vprašanj – običajno vprašanja, na katera bi vi želeli, da izdelek odgovori, ne tista, ki jih dejanski kupci postavljajo. To je narobe. Pogosta vprašanja imajo posebno nalogo: odstraniti zadnje dvome med obiskovalcem in prijavo. Učinkovite strani s pogostimi vprašanji, kot so tiste pri HubSpot, Slack in Zendesk, delujejo, ker so organizirane okoli resničnih poizvedb, iskalne in jedrnate. So produkt poslušanja, ne izumljanja.

Realističen scenarij: na ceniku ste in veste, da je največji razlog za odstop pri orodju za beleženje časa integracija: "Ali to deluje s QuickBooks?" Pregled dnevnika podpore pokaže, da je to najpogostejše vprašanje pred prodajo. To vprašanje z odgovorom sodi na pogosta vprašanja na ceniku. Drugo najpogostejše, iz prodajnih klicev, je "Kaj se zgodi z mojimi časovnicami, če prekličem?" Tudi to sodi tja. Vsak odgovor skrajša prodajni cikel in zmanjša obremenitev podpore, ker obiskovalec, ki vidi odgovor v pisni obliki, izdelku bolj zaupa kot obiskovalec, ki mora vprašati.

Pravilo za agencijo: ne napišite niti enega odgovora na pogosta vprašanja, dokler ne pregledate vstopnic podpore, zapiskov prodajnih klicev in e-poštnih sporočil za uvajanje. Katera vprašanja se dejansko ponavljajo? Tista gredo noter. Vse ostalo gre na stran s funkcijami ali nikamor. In ko se spletišče razvija, znova preglejte pogosta vprašanja – vsaka sprememba cenika ali lansiranje funkcije ustvari nova vprašanja, pogosta vprašanja pa so najcenejše mesto, kjer jih ujeti.

Obstaja tudi razlog za razmislek o strukturi pogostih vprašanj, ne le o vsebini. Dolg, pomikajoč se seznam vprašanj je težko preleteti; združevanje po kategorijah (Zaračunavanje, Integracije, Upravljanje računa) s kazalom na vrhu ga naredi dejansko uporabnega. Funkcija iskanja pomaga, ko seznam preseže določeno velikost – to je del strani, kjer sta dizajn in besedilo enako pomembna, ker neiskalna pogosta vprašanja niso prebrana.

Še ena stvar, ki je neprijeten del: pogosta vprašanja so pogosto najbolj iskrena stran na spletišču, ker je to stran, kjer odgovorite na vprašanje, ki si ga obiskovalec ne upa zastaviti. Če je na vprašanje neprijetno odgovoriti – "Ali lahko res prekličem kadar koli?" "Ali brezplačni paket prikazuje oglase?" – je ta neprijeten občutek dokaz, da tja sodi, ne razlog, da ga izpustite. Obiskovalec ima to vprašanje ne glede na to, ali odgovorite; če ne, si bo izmislil odgovor, in odgovor, ki si ga bo izmislil, bo slabši od resnice.

6. korak — Združite in preverite kakovost na vsaki strani, preden jo pokažete stranki.

Stranki boste kmalu pokazali končano spletišče. Preden to storite, odprite cenik in stran s funkcijami eno poleg druge. Preverite vsako ime funkcije: ali se ujemajo? Preverite vsako številko: ali cenik pravi "10 projektov" in stran s funkcijami "do 10 projektov" ter API referenca "največ 10" – vse enako? Preverite vsako obljubo: ali je "neomejeni projekti" kjer koli na spletišču in če je, ali je resnična? Nato poiščite besedišče izdelka: ali povsod pravi "delovni prostori" ali zdrsne v "ekipe"? Tu ujamete, da domača stran pravi "brez zahtevane kreditne kartice", medtem ko postopek prijave dejansko zahteva kreditno kartico za brezplačni preizkus – točno tista vrsta nedoslednosti, ki uniči zaupanje.

Tu se izkaže korist vrstnega reda od znotraj navzven. Ker je bila vsaka stran izpeljana iz istih omejitev, je delo usklajevanja preverjanje, ne reševalna akcija. A tega ne preskočite. Protislovja, ki preživijo, so subtilna – funkcija, imenovana "odobritve" na ceniku, a "pregledovalni tokovi" v API dokumentaciji, posnetek zaslona na domači strani s temnim načinom nadzorne plošče, ki ga izdelek ne vključuje, trditev, da izdelku "zaupajo oddaljene ekipe", ki prihaja iz predstavitve blagovne znamke in se ne ujema z dejanskim seznamom strank stranke.

Praktična tehnika: naredite seznam omejitev za scenarij preverjanja kakovosti. Pojdite skozi vsako stran in preverite vsako dejstvo glede na seznam. To deluje, ker je bil seznam omejitev napisan v prvem tednu, preden so strani obstajale, zato je resnično neodvisen vir. Če začnete preverjanje kakovosti iz dizajna ali iz spomina, boste spregledali dejstva, ki so se spremenila med gradnjo.

Na tej točki postane razlog za zaporedje dela očiten. Ko so strani zgrajene vzporedno iz različnih virov, to preverjanje kakovosti vsakič najde konflikte, vsak konflikt pa pomeni predelavo strani, ki je videti končana. Ko so strani zgrajene zaporedno iz enega seznama omejitev, preverjanje kakovosti najde tipkarske napake. To je razlika med ponovljivim procesom in nenehno krizo. Da bi celotno spletišče po lansiranju pripovedovalo eno zgodbo – nove funkcije, nove ekipe, novi avtorji besedil – potrebujete vzdrževalno različico iste discipline in okvir za poenotenje zgodbe spletišča SaaS po straneh je naravni naslednji korak.

Opozorila, ki ohranjajo poštenost.

Tri stvari, ki jih ta okvir ne trdi. Prvič, za zelo zgodnjo fazo SaaS brez API-ja, z enim samim paketom in enim očitnim primerom uporabe je vrstni red veliko manj pomemben; to spletišče bi lahko zgradili v poljubnem vrstnem redu in delo usklajevanja bi bilo trivialno. Okvir se obrestuje, ko obstaja resnična kompleksnost – več paketov, API, veliko funkcij, več občinstev. Ne uporabljajte ga kot dogmo za izdelek, ki je v bistvu ciljna stran z gumbom za prijavo.

Drugič, gradnja od znotraj navzven na začetku prinaša počasen viden napredek. Stranka je zahtevala domačo stran, vi pa dobavljate tabelo s cenami in dokument z omejitvami. Uprli se bodo, ker je domača stran tisto, kar lahko pokažejo vlagateljem in svoji ekipi. Upravljanje tega pričakovanja – pokazati jim, kako odločitve na ceniku oblikujejo vse naprej – je del dela, ne njegov neuspeh. Eden od načinov za ohranjanje zagona je, da zgodaj pripravite grobi mockup domače strani, jasno označen kot posoda, ki čaka na vsebino, da lahko stranka vidi cilj, medtem ko gradite ogrodje.

Tretjič, seznam omejitev se spreminja. Cene se spreminjajo, API-ji rastejo, paketi se množijo. Okvir predpostavlja, da dokument z omejitvami posodabljate tudi po lansiranju, ker bo spletišče začelo propadati, ko ne bo več odražalo dejanskih omejitev izdelka. To je strošek vzdrževanja pristopa od znotraj navzven: vir resnice je resničen le, če ga nekdo lastniško vzdržuje.

Zaključek.

Najpogostejši neuspeh v projektih spletnih strani SaaS ni šibko besedilo ali slab dizajn – to so strani, ki si med seboj nasprotujejo, ker so bile zgrajene v napačnem vrstnem redu. Začnite s cenikom in API dokumentacijo, kjer živijo dejanske omejitve izdelka; predstavitev funkcij izpeljite iz dejanskih delovnih tokov; pogosta vprašanja poberite iz resničnih pogovorov; in končajte s preverjanjem skladnosti, ki preverja, ne rešuje. To naredite pri nekaj različnih strankah in ugotovili boste, da je to manj kreativen proces in bolj tekoči trak – kar je v agenciji točno tisto, kar želite. Kreativno delo je še vedno prisotno; le uporabljeno je tam, kjer ima največ vzvodnega učinka.