Sisältä ulospäin - SaaS-verkkosivustot: Miksi hinnoittelu ja dokumentaatio ensin

Tiivistelmä

Useimmat neuvot SaaS-verkkosivustojen rakentamiseen aloittavat etusivusta ja jättävät hinnoittelun, dokumentaation ja UKK:n jälkiajatuksiksi – minkä vuoksi nämä sivut päätyvät olemaan ristiriidassa keskenään. Tämä artikkeli kannattaa sisältä ulospäin -rakentamista: aloita hinnoittelusivusta ja API-dokumentaatiosta, joissa tuotteen todelliset rajoitteet asuvat, ja johda kaikki muu niistä. Se esittää kuusivaiheisen viitekehyksen: kerää rajoitteet, rakenna hinnoittelusivu runkona, käsittele API-dokumentaatiota tuotepintana, johda ominaisuuksien esittely työnkuluista, kerää UKK oikeista keskusteluista ja lopeta yhdenmukaisuustarkistuksella. Lähestymistapa on suunniteltu toimistoille, jotka tarvitsevat toistettavan prosessin eri asiakkaiden välillä. Se sisältää myös varauksia siitä, milloin viitekehys on liioittelua ja miten asiakkaiden odotuksia hallitaan.

Useimmat neuvot SaaS-verkkosivustojen rakentamiseen ovat nurinpäin. Ne kehottavat aloittamaan etusivusta – hero-osiosta, otsikosta, tuotekuvakaappauksesta – ja kohtelemaan hinnoittelua, dokumentaatiota ja UKK:ta sivuina, jotka täytetään, kun muotoilu on hyväksytty. Sitten, viikkoja myöhemmin, joudut sovittamaan otsikon lupauksen "rajattomasta kaikesta" hinnoittelusivun todellisiin käyttörajoituksiin, ja ominaisuusosio ylpeästi esittelee beta-ominaisuutta, jota API-dokumentaatio ei edes mainitse. Tämä järjestys toimii vain, jos tuote on niin yksinkertainen, ettei sovittelua tarvita – mikä on harvoin asia. Se, mikä todella toimii – etenkin kun teet tämän toistuvasti täysin erilaisille asiakkaille – on rakentaa sivusto sisältä ulospäin: aloita rajoitetuimmista, vähiten loisteliaista sivuista (hinnoittelu ja API-dokumentaatio), ja anna niiden tuottaa etusivu, ominaisuuksien esittely ja UKK. Tässä on kuusivaiheinen viitekehys tähän, ja matkan varrella huomautan, missä se muuttuu epämukavaksi, koska niin se tekee.

Nopea kartta erosta, koska koko argumentti lepää sen varassa:

	Sivu edellä (yleisin)	Rajoite edellä (tämä viitekehys)
Mistä aloitat	Etusivun hero ja visuaalit	Hinnoittelusivu ja API-dokumentaatio
Mikä ohjaa tekstiä	Bränditarina ja muotoilu	Tuotteen todelliset rajoitteet ja työnkulut
Ominaisuuksien esittely	Listaa kaiken, mitä tuote tekee	Seuraa polkuja, joita oikeat käyttäjät kulkevat
UKK	Kirjoitettu viimeisenä, arvauksista	Kerätty tuesta ja myynnistä
Tulos julkaisussa	Epäjohdonmukaiset väitteet, piilotetut ristiriidat	Sivut viestivät yhtä tuotetta

Vaihe 1 — Lue hinnoittelusivu ennen kuin kirjoitat sanaakaan.

Asiakas antaa sinulle ominaisuuslistan, brändiesityksen ja demolinkin ja pyytää etusivua. Ensimmäisen puhelun loppuun mennessä keskustelet hero-tekstistä ja värimaailmasta. Yritä hidastaa. Pyydä hinnoittelusivu ja pakettien rajoitukset – vaikka ne olisivat vain Google Doc muistiinpanoineen – ja huomaat, että koko projekti muuttuu.

Etsit kovia rajoitteita: mitä paikka tarkoittaa, miten datan käyttö lasketaan, mitkä ominaisuudet ovat milläkin pakettitasolla, onko API olemassa ja mitä se oikeasti osaa. Nämä rajoitteet ovat perustotuus. Jokaisen myöhemmin tekemäsi markkinointiväitteen on kestettävä kosketus niiden kanssa.

Tässä tyypillinen skenaario. Asiakas on ajanseurantatyökalu: ilmainen paketti, Pro-paketti, Enterprise-paketti. Myyntiesitys sanoo "skaalautuu mille tahansa tiimille." Pro-sivu sanoo "rajoittamattomat projektit." Mutta tukitiimi vahvistaa, että Pro-tilit on itse asiassa rajoitettu 10 aktiiviseen projektiin työtilaa kohden, ja API-dokumentaatio sanoo, että projektissa voi olla enintään 50 jäsentä. Etusivua ei kirjoiteta ennen kuin joku ratkaisee tämän, koska "rajoittamattomat projektit" on nyt juridinen kysymys, ei tekstikysymys. Jos olisit aloittanut etusivusta, olisit kirjoittanut "rajoittamattomat projektit" hero-osioon ja huomannut ristiriidan kaksi viikkoa myöhemmin, kun muotoilu oli jo hyväksytty. Rajoitteista aloittaminen tarkoittaa, että ristiriita tulee esiin ensimmäisellä viikolla, jolloin sen korjaaminen ei maksa mitään.

Mitä sinun tarkalleen ottaen pitäisi kerätä tässä vaiheessa? Pakettien määritelmät ja mahdollinen ominaisuus-paketti-vertailutaulukko. API-dokumentaatio tai ainakin lista siitä, mitä API osaa ja ei osaa. Tukitiimin yleisimmät kysymykset (lisää vaiheessa 5). Myyntiesitys, varaumalla että myyntiesitykset ovat paikka, jossa fantasia asuu. Ja itse tuote, avattuna niin, että näet asetussivut, joilla rajoitteet pannaan täytäntöön – koska tuote itse on lopullinen auktoriteetti. Asetusnäyttö, joka sanoo "Enintään 10 projektia", ohittaa minkä tahansa laskentataulukon.

Tämä vaihe ei tuota toimitusta. Se tuottaa listan faktoja – rajoitteita, määritelmiä, poikkeuksia – joihin vertaat jokaista muuta sivua. Toimistolle tämä on myös vaihe, joka erottaa toistettavan työn tulipalojen sammuttelusta. Kirjoita rajoitteet yhteiseen dokumenttiin, ja olet rakentanut totuuden lähteen, johon jokainen tuleva sivupäivitys viittaa.

Vaihe 2 — Rakenna hinnoittelusivu koko sivuston runkona.

Hinnoittelusivu ei tunnu paikalta aloittaa. Se on taulukko numeroineen ja pakettinimineen – sivuston vähiten loistelias sivu. Mutta se on tuotteen sopimus käyttäjän kanssa, ja siellä päätetään koko sivuston informaatioarkkitehtuuri. Jos sivuston tehtävä on kouluttaa kävijä siihen pisteeseen, että tämä on valmis rekisteröitymään, hinnoittelusivu on paikka, johon tämä koulutus huipentuu. Jokainen ostopäätökseen vaikuttava ominaisuus nimetään siellä; jokainen merkityksellinen rajoite mainitaan tai linkitetään.

Otetaan ajanseurantatyökalu. Kolme pakettia: Free, Pro, Enterprise. Taulukon sarakkeiden tulee kuvastaa sitä, miten tuote todella segmentoituu – projektien määrä, integraatiot, raportoinnin syvyys. Jokaiseen soluun tarvitset rehellisen arvon, et tavoitteellista. Jos Pro sisältää 10 aktiivista projektia, solussa lukee 10 aktiivista projektia, ja linkki hinnoittelun UKK:hon, joka selittää, mitä "aktiivinen" tarkoittaa ja mitä tapahtuu, kun raja saavutetaan. Yksi vaikeimmista päätöksistä tässä on se, mitä sanot paketista, jota eniten haluat kävijöiden ostavan. Monilla hinnoittelusivuilla ankkuripaketti on ilmeinen – korostettu, "Suosituin"-merkillä – ja sen ympärillä oleva teksti selittää, miksi se sopii juuri tälle kävijälle. Ajanseurantatyökalussa Pro on ankkuri: siellä integraatiot ja raportoinnin syvyys todella alkavat, joten sivun tulisi tehdä tämä selväksi nimenomaisesti, eikä olettaa, että kävijä lukee taulukon ja päättelee sen itse.

Tässä myös päätät, mitkä termit ovat kanonisia koko sivustolla. Jos tuote kutsuu ryhmiä "työtiloiksi" hinnoittelusivulla, mutta markkinointiteksti sanoo "tiimit", jokainen myöhempi sivu perii epäjohdonmukaisuuden. Kirjoittamalla hinnoittelusivun ensin pakotat itsesi valitsemaan sanaston, ja sinun tulisi valita se, mitä tuote itse käyttää – koska tuotteen ja dokumentaation on vastattava sitä, ja markkinointisivu on se, joka voi taipua.

Hinnoittelusivu tarvitsee myös oman UKK:nsa. Kysymykset, jotka kuuluvat sinne, liittyvät pakettien erityisiin mekaniikkoihin: mikä lasketaan paikaksi, mitä tapahtuu, kun alennat pakettia, onko laskutus vuosi- vai kuukausittaista, mitä "aktiivinen" tarkoittaa projektin kohdalla. Käytäntöä hinnoittelusivujen rakenteesta konversiota varten on kehitetty paljon, ja mekaniikkoihin kannattaa tutustua. Mutta tässä viitekehyksessä hinnoittelusivun tehtävä ei ole vain konvertoida – se on lukita ne tosiasiapäätökset, joita jokainen muu sivu noudattaa. Jos haluat syvällisemmän mekaniikan, tämä opas SaaS-hinnoittelusivujen korjaamiseen käsittelee ne yksityiskohtaisesti.

Vaihe 3 — Käsittele API-dokumentaatiota tuotepintana, ei käsikirjana.

Kehittäjä arvioi ajanseurantatyökalua. Heidän yrityksensä tarvitsee automaattisesti vetää työaikakirjaukset palkanlaskentajärjestelmään. Dokumentaatio on järjestetty aakkosittain päätepisteen mukaan: /projects, /reports, /timesheets, /users. Kehittäjällä ei ole aavistustakaan, mistä kutsusta aloittaa, ja "Authentication"-osio olettaa tietämystä, jota heillä ei ole – dokumentaatio ei koskaan selitä, että API-avain luodaan asetussivulla "Integrations"-kohdassa. Kehittäjä sulkee välilehden vakuuttuneena, että tuote ei integroidu puhtaasti. Kuitenkin kaikki tarvittava tieto oli dokumentaatiossa; se oli vain järjestetty siinä järjestyksessä, jota viitemanuaali käyttäisi, ei siinä järjestyksessä, jota ihminen käyttäisi.

Työnkulun mukaan järjestetty dokumentaatio olisi muuttanut lopputuloksen: "Pika-aloitus," "Todenna," "Vedä työaikakirjaukset," "Luo projekti," "Webhookit ja synkronointi." Jokainen osio johtaa työllä, sitten näyttää päätepisteen. Pika-aloitus saattaa viedä viisi minuuttia ja tuottaa onnistuneen API-kutsun – mikä on dokumentaation vastine ilmaiselle kokeilulle. Kehittäjälähtöiselle tuotteelle tämä on sivuston vakuuttavin sivu.

Jokaiselle SaaS:lle, jolla on API, dokumentaatio on sivustoosi sivu riippumatta siitä, suunnittelitko sen niin vai et. Alan vertailukohta – jonka ovat asettaneet esimerkiksi Stripe, GitHub ja Twilio – on dokumentaatio, joka lukee kuin tuote: se selittää työn, jota kehittäjä yrittää tehdä, ei vain saatavilla olevia päätepisteitä. Periaate on, että API-dokumentaatio on osa tuotekokemusta, ja sen tulisi noudattaa samaa sisältä ulospäin -logiikkaa kuin muu sivusto: aloita töistä, jotka kehittäjä voi suorittaa, ja paljasta sitten mekaniikka.

Toimistolle bonuksena on, että dokumentaation kirjoittaminen tällä tavalla pakottaa rajoitelistan pinnalle – mitä API oikeasti osaa, missä ovat nopeusrajoitukset, mitkä päätepisteet puuttuvat – ja huomaat nämä ristiriidat ennen kuin ne ilmestyvät markkinointisivulle. Jos API-dokumentaatio on merkittävä osa tämän asiakkaan sivustoa, tässä on syvällisempi opas dokumentaation kirjoittamiseen, jota kehittäjät todella käyttävät.

Vaihe 4 — Johda ominaisuuksien esittely työnkuluista, älä ominaisuuslistasta.

Asiakas lähettää sinulle sähköpostitse laskentataulukon, jossa on 40 ominaisuutta, ja pyytää ominaisuussivua. Helppo vastaus on ruudukko: 40 kohdetta, kukin kuvakkeella ja selitteellä. Tulos tuntuu perusteelliselta, mutta se lukee kohinalta, koska ruudukolla ei ole tarinaa. Kukaan ei vieraile SaaS-verkkosivustolla oppiakseen kaikki ominaisuudet; he vierailevat oppiakseen, tekeekö tämä tuote sen yhden työn, jonka vuoksi he tulivat. Joten esittely tulisi rakentaa työnkuluista, ei ominaisuusluettelosta.

Työstä esimerkki läpi. Ajanseurantatyökalun yleisin voittava polku, asiakkaan tukitiimin mukaan, on tiiminvetäjä, joka rekisteröityy, kutsuu kolme kollegaa, luo projektin ja ajaa raportin viikon lopussa. Se on työnkulku. Ominaisuuksien esittelyn tulisi seurata sitä: osio tiimin kutsumisesta (kattaa paikat ja roolit), osio projektin perustamisesta (kattaa mallit ja projektiasetukset), osio raportointinäkymästä (kattaa kaaviot ja vientivaihtoehdot). Jokainen osio näyttää kuvakaappauksen juuri siitä hetkestä tuotteessa, ei rajattua kuvakaappausta harvoin käytetystä asetuspaneelista. Käyttäjä näkee oman polkunsa, ja ominaisuudet, jotka he näkevät matkan varrella, ovat ne, jotka ovat heille tärkeitä.

Jatkotyönkulku, hieman erilaiselle kävijälle, on johtaja, joka ei koskaan käytä työkalua itse: he hyväksyvät työaikakirjaukset ja tarkastelevat viikkoraportin. Esittely voi lisätä osion tälle kävijälle loppuun – "Johtajille" – rikkomatta kerrontaa. Kaksi työnkulkua on yleensä riittävä alku; et tarvitse yhtä jokaista persoonaa varten.

Varoitus – todellinen sellainen – on, että työnkulkuihin perustuva esittely edellyttää, että tiedät, mitkä yleiset työnkulut todella ovat. Se vaatii keskustelua tuen ja myynnin kanssa, ei vain tuotepäällikön kanssa. Jos asiakas ei osaa kertoa kolmea yleisintä tapaa, joilla ihmiset käyttävät tuotetta, se on ensimmäinen asia korjata, koska verkkosivusto arvaa muuten. Tämä vaihe paljastaa usein, että tuotteella ei ole selkeää ensisijaista työnkulkua – mikä on tuoteongelma, ei verkkosivuongelma. Mainitse se rehellisesti; verkkosivusto ei voi valmistaa työnkulkua, jota ei ole olemassa. Systemaattisen tavan järjestää nämä työnkulut saat tästä artikkelista ominaisuuksien esittelyn rakenteesta konversiota varten, joka käy läpi päätössekvenssin.

Vaihe 5 — Kerää UKK tuesta ja myynnistä, älä mielikuvituksestasi.

Sinulla on kaksi päivää aikaa ennen sivuston julkaisua, ja UKK on edelleen tyhjä. Vaisto on kirjoittaa kymmenen kysymystä iltapäivässä – yleensä kysymyksiä, joihin haluaisit tuotteen vastaavan, eikä niitä, joita todelliset asiakkaat kysyvät. Se on nurinpäin. UKK:lla on tietty tehtävä: poistaa viimeiset epäilykset kävijän ja rekisteröitymisen väliltä. Tehokkaat UKK-sivut, kuten ne, joita näet HubSpotilta, Slackilta ja Zendeskiltä, toimivat, koska ne on järjestetty todellisten kysymysten ympärille, ne ovat haettavia ja ytimekkäitä. Ne ovat kuuntelemisen tuote, eivät keksimisen.

Realistinen skenaario: olet hinnoittelusivulla, ja tiedät, että suurin kaupan este ajanseurantatyökalulle on integraatio: "Toimiiko tämä QuickBooksin kanssa?" Tukilokien tarkastelu osoittaa, että se on yleisin myyntiä edeltävä kysymys. Tämä kysymys vastauksineen kuuluu hinnoittelusivun UKK:hon. Toiseksi yleisin, myyntipuheluista, on "Mitä työaikakirjauksilleni tapahtuu, jos peruutan?" Se kuuluu myös sinne. Jokainen vastaus lyhentää myyntisykliä ja vähentää tukikuormaa, koska kävijä, joka näkee vastauksen kirjallisena, luottaa tuotteeseen enemmän kuin kävijä, jonka on kysyttävä.

Toimiston sääntö: älä kirjoita yhtäkään UKK-vastausta ennen kuin olet käynyt läpi tukipyynnöt, myyntipuhelujen muistiinpanot ja perehdytyssähköpostit. Mitkä kysymykset todella toistuvat? Ne mukaan. Kaikki muu menee ominaisuussivulle tai ei minnekään. Ja sivuston kehittyessä käy UKK läpi uudelleen – jokainen uusi hinnoittelumuutos tai ominaisuuden julkaisu luo uusia kysymyksiä, ja UKK on halvin paikka poimia ne.

On myös syytä miettiä UKK:n rakennetta, ei vain sisältöä. Pitkä, vierivä kysymyslista on vaikea silmäillä; ryhmittely luokittain (laskutus, integraatiot, tilinhallinta) sisällysluettelon kanssa alussa tekee siitä todella käytettävän. Hakutoiminto auttaa, kun lista kasvaa tietyn koon yli – tämä on sivun osa, jossa muotoilulla on yhtä suuri merkitys kuin tekstillä, koska ei-haettava UKK on lukematon UKK.

Vielä yksi asia, joka on epämukava osa: UKK on usein sivuston rehellisin sivu, koska se on ainoa sivu, jolla vastaat kysymykseen, jota kävijä pelkää kysyä. Jos kysymys tuntuu epämukavalta vastata – "Voinko todella peruuttaa milloin tahansa?" "Näyttääkö ilmainen paketti mainoksia?" – se epämukava tunne on todiste, että se kuuluu sinne, ei syy jättää pois. Käyttäjällä on tämä kysymys riippumatta siitä, vastaatko vai et; jos et vastaa, he päättelevät vastauksen, ja päättelemänsä vastaus on pahempi kuin totuus.

Vaihe 6 — Yhdenmukaista ja testaa laatu jokaisella sivulla ennen kuin näytät asiakkaalle.

Olet näyttämässä asiakkaalle valmista sivustoa. Ennen sitä avaa hinnoittelusivu ja ominaisuussivu vierekkäin. Tarkista jokainen ominaisuuden nimi: vastaavatko ne toisiaan? Tarkista jokainen luku: sanooko hinnoittelusivu "10 projektia" ja ominaisuussivu "jopa 10 projektia" ja API-viite "enintään 10" – kaikki samoja? Tarkista jokainen lupaus: onko "rajoittamattomat projektit" missään sivustolla, ja jos on, onko se totta? Etsi sitten tuotteen omaa sanastoa: sanotaanko kaikkialla "työtilat", vai lipsahtaako se "tiimeihin"? Tässä kohtaa huomaat, että etusivu sanoo "ei luottokorttia vaadita", mutta rekisteröitymisprosessi itse asiassa kysyy luottokorttia ilmaisen kokeilun yhteydessä – juuri se epäjohdonmukaisuuden luokka, joka tappaa luottamuksen.

Sisältä ulospäin -järjestyksen palkinto tulee tässä. Koska jokainen sivu johdettiin samoista rajoitteista, yhdenmukaisuustyö on varmistuskierros, ei pelastusoperaatio. Mutta älä ohita sitä. Selviävät ristiriidat ovat hienovaraisia – ominaisuus nimeltä "hyväksynnät" hinnoittelusivulla, mutta "tarkistusvirrat" API-dokumentaatiossa, kuvakaappaus etusivulla, joka näyttää tumman tilan hallintapaneelin, jota tuote ei toimita, väite, että tuote on "etätiimien luottama", joka tuli brändiesityksestä eikä vastaa asiakkaan todellista asiakaslistaa.

Käytännöllinen tekniikka: tee rajoitelistasta QA-kierroksen käsikirjoitus. Käy läpi jokainen sivu ja tarkista jokainen fakta listaa vasten. Tämä toimii, koska rajoitelista kirjoitettiin ensimmäisellä viikolla ennen kuin sivuja oli olemassa, joten se on aidosti riippumaton lähde. Jos aloitat QA:n muotoilusta tai muistista, huomaamatta jäävät faktat, jotka muuttuivat rakentaessasi.

Tässä vaiheessa syy työn jaksottamiseen tulee ilmeiseksi. Kun sivut rakennetaan rinnakkain eri lähteistä, tämä QA-kierros löytää ristiriitoja joka kerta, ja jokainen ristiriita tarkoittaa uudelleentyötä valmiin näköisellä sivulla. Kun sivut rakennetaan peräkkäin yhdestä rajoitelistasta, QA-kierros löytää kirjoitusvirheitä. Se on ero toistettavan prosessin ja jatkuvan kriisin välillä. Jotta koko sivusto kertoisi yhtä tarinaa julkaisun jälkeen – uudet ominaisuudet, uudet tiimit, uudet copywriterit – tarvitset saman kurinalaisuuden ylläpitoversion, ja viitekehys SaaS-verkkosivuston tarinan yhdenmukaistamiseen sivujen välillä on luonnollinen seuraava askel.

Varaukset, jotka pitävät tämän rehellisenä.

Kolme asiaa, joita tämä viitekehys ei väitä. Ensinnäkin hyvin varhaisen vaiheen SaaS:lle, jolla ei ole API:a, on vain yksi paketti ja yksi ilmeinen käyttötapaus, järjestyksellä on paljon vähemmän merkitystä; voisit rakentaa sivuston missä tahansa järjestyksessä, ja sovittelutyö olisi triviaalia. Viitekehys maksaa itsensä takaisin, kun on todellista monimutkaisuutta – useita paketteja, API, paljon ominaisuuksia, useita yleisöjä. Älä sovella sitä dogmina tuotteeseen, joka on pohjimmiltaan laskeutumissivu rekisteröitymispainikkeella.

Toiseksi sisältä ulospäin rakentaminen tuottaa hidasta näkyvää edistymistä alussa. Asiakas pyysi etusivua, ja sinä toimitat hinnoittelutaulukon ja rajoitedokumentin. He vastustavat, koska etusivu on se, jonka he voivat näyttää sijoittajille ja omalle tiimilleen. Tämän odotuksen hallinta – näyttämällä heille, miten hinnoittelusivun päätökset muovaavat kaikkea alavirtaan – on osa työtä, ei sen epäonnistumista. Yksi tapa pitää vauhtia yllä on tuottaa karkea etusivun malli varhain, selvästi merkittynä sisältöä odottavaksi säiliöksi, jotta asiakas näkee määränpään, kun rakennat runkoa.

Kolmanneksi rajoitelista muuttuu. Hinnoittelu muuttuu, API:t kasvavat, paketit lisääntyvät. Viitekehys olettaa, että pidät rajoitedokumentin ajan tasalla julkaisun jälkeen, koska verkkosivusto alkaa rapautua heti, kun se lakkaa heijastamasta tuotteen todellisia rajoitteita. Tämä on sisältä ulospäin -lähestymistavan ylläpitokustannus: totuuden lähde on vain totuudenmukainen, jos joku omistaa sen.

Lopuksi.

Yleisin epäonnistuminen SaaS-verkkosivuprojekteissa ei ole heikko teksti tai huono muotoilu – se on sivut, jotka ovat eri mieltä keskenään, koska ne rakennettiin väärässä järjestyksessä. Aloita hinnoittelusivusta ja API-dokumentaatiosta, jossa tuotteen todelliset rajoitteet asuvat; johda ominaisuuksien esittely todellisista työnkuluista; kerää UKK oikeista keskusteluista; ja lopeta yhdenmukaisuuskierrokseen, joka varmistaa eikä pelasta. Tee se muutamalle eri asiakkaalle, ja huomaat, että se on vähemmän luova prosessi ja enemmän kokoonpanolinja – mikä toimistolla on juuri sitä, mitä haluat. Luova työ on edelleen olemassa; sitä vain sovelletaan siellä, missä sillä on eniten vipuvaikutusta.