SaaS-verkkosivustojen diagnostiikka, jota toimistosi voi hyödyntää uudelleen saamatta asiakkaita näyttämään samanlaisilta

Yhteenveto

Kuinka monta kertaa tällä neljänneksellä olet käynyt täsmälleen saman kartoituspuhelun—samat kysymykset tuotteesta, asiakkaasta, kilpailijasta—kahdelle asiakkaalle, jotka väittivät olevansa täysin erilaisia? Tiedät jo, että vastaukset ovat erilaisia, mutta tehtävät, jotka jokaisen SaaS-sivuston on hoidettava, eivät ole. Jokainen SaaS-tuoteverkkosivusto on pieni joukko koneita, jotka suorittavat samoja tehtäviä: selittää, mitä tuote tekee, näyttää mitä se maksaa, kertoa kehittäjille miten integroida, vastata vastaväitteisiin, jotka estävät ostoksen, ja todistaa yrityksen uskottavuus. Toistettava diagnostiikka, joka auditoi nämä viisi tehtävää, selviää kontaktista minkä tahansa asiakkaan kanssa, koska tehtävät eivät muutu. Järjestelmä, jonka rakennat sen ympärille, mahdollistaa siirtymisen toimeksiannosta toiseen aloittamatta nollasta. Se vie vähemmän aikaa kuin nykyinen kartoitusprosessisi, se antaa asiakkaalle selkeän syyn luottaa sinuun, ja se tuottaa toimitettavan, joka ei näytä mallipohjalta, koska kysymykset ovat vakioita mutta vastaukset ovat yksilöllisiä.

Kuinka monta kertaa tällä neljänneksellä olet käynyt täsmälleen saman kartoituspuhelun—samat kysymykset tuotteesta, asiakkaasta, kilpailijasta—kahdelle asiakkaalle, jotka väittivät olevansa täysin erilaisia? Tiedät jo, että vastaukset ovat erilaisia, mutta tehtävät, jotka jokaisen SaaS-sivuston on hoidettava, eivät ole. Jokainen SaaS-tuoteverkkosivusto on pieni joukko koneita, jotka suorittavat samoja tehtäviä: selittää, mitä tuote tekee, näyttää mitä se maksaa, kertoa kehittäjille miten integroida, vastata vastaväitteisiin, jotka estävät ostoksen, ja todistaa yrityksen uskottavuus. Toistettava diagnostiikka, joka auditoi nämä viisi tehtävää, selviää kontaktista minkä tahansa asiakkaan kanssa, koska tehtävät eivät muutu. Järjestelmä, jonka rakennat sen ympärille, mahdollistaa siirtymisen toimeksiannosta toiseen aloittamatta nollasta. Se vie vähemmän aikaa kuin nykyinen kartoitusprosessisi, se antaa asiakkaalle selkeän syyn luottaa sinuun, ja se tuottaa toimitettavan, joka ei näytä mallipohjalta, koska kysymykset ovat vakioita mutta vastaukset ovat yksilöllisiä.

'Asiakkaani ovat liian erilaisia yhdelle järjestelmälle'

Aja sama viisikohtainen diagnostiikka jokaiselle asiakkaalle ennen kuin kirjoitat sanaakaan mainostekstiä tai avaat suunnittelutyökalun. Erot, jotka tekevät asiakkaistasi erityisiä—toimiala, yleisö, hinnoittelumalli—sijaitsevat yhteisen perustan päällä. Palkanlaskennan SaaS-ohjelmistolla ja sosiaalisen median ajastustyökalulla ei ole mitään yhteistä paitsi viisi tehtävää, joita jokainen sivu hoitaa. Jos auditoit näitä tehtäviä, löydät samat kaavat samoista paikoista.

Sivu tai osio	Mitä asiakkaasi yleensä pyytää	Mitä sivulla todella tapahtuu
Ominaisuuksien esittely	'Näytä kaikki ominaisuudet, jotka rakensimme'	Näytetään lopputulos, jonka käyttäjä saa, ei vain toiminto. Visuaalit, kuten kuvakaappaukset, GIF-kuvat tai videot, tulisi osoittaa hetki, jolloin tuote muuttaa jonkun työskentelytapaa.
Hinnoittelu	'Tee hinnoista helppolukuiset'	Ostaja pakotetaan päättämään, mikä paketti on hänelle. Tasojen tulisi näkyä etenemisenä, joka ohjaa valintaa, ei tasavertaisena hintalistana.
API-dokumentaatio	'Kehittäjämme löytävät sen dokumenteista'	Usein ensimmäinen testi, jonka kehittäjä suorittaa arvioidessaan, voiko tuotteeseen luottaa. Selkeys on täällä ominaisuus, ei mukavuus.
UKK-osio	'Vastaa kysymyksiin, jotta tukipuhelut vähenevät'	Viimeinen asia, jonka ostaja lukee ennen napin painamista. Sen tulisi käsitellä hinnoitteluvastaväitteitä ja reunatapauksia, ei vain yleisiä yrityskysymyksiä.
Sosiaalinen todiste	'Laita logot ylös'	Todiste siitä, että aiemmin esitetyt väitteet ovat totta. Logot ja suosittelut ovat luottamuksen indikaattoreita, eivät koristeita.

Diagnostiikka ei ole mallipohja. Se on joukko kysymyksiä, joita kysyt jokaiselta sivulta: auttaako tämä ostajaa ymmärtämään, mitä tuote tekee, tekeekö se seuraavasta vaiheesta ilmeisen, vastaako se vastaväitteeseen, joka tällä hetkellä estää kaupan? Kun kysyt nämä kysymykset asiakkaan läsnä ollessa, asiakas näkee sinut henkilönä, joka ymmärtää heidän markkinaansa, eikä kymmenentenä toimistona, joka esitti dioja. SaaS-verkkosivustoja koskeva tutkimus viittaa yrityksiin, kuten HubSpot, Slack ja Zendesk, esimerkkeinä hyvin järjestetyistä UKK-osioista, ja Stripeen, GitHubiin ja Twilioniin dokumentaation selkeyden standardeina. Yksikään näistä yrityksistä ei päässyt sinne kohtelemalla UKK:ta tukipyyntöjen kasana. He kohtelivat sitä konversiopintana. Tämä on asenne, jonka diagnostiikkasi on tuotava jokaiselle asiakkaalle.

Ota esimerkiksi asiakas, joka myy varastonhallintaohjelmistoa, ja toinen, joka myy palkanlaskentaohjelmistoa. Diagnostiikka paljastaa usein samat kolme aukkoa: ominaisuussivu mainitsee moduuleja lopputulosten sijaan, hinnoittelusivu ei perustele hyppyä pakettien välillä, ja UKK vastaa tukikysymyksiin ostoepäröintien sijaan. Koska olet nähnyt nämä aukot molemmissa, tiedät tarkalleen, mitä pyytää suunnitteluvaiheessa. Asiakas näkee prosessin, joka on yksilöllinen, ei yleinen. Kirjoita diagnostiikka yksisivuiseksi PDF:ksi, jossa on pisteet 1–5 jokaiselle tehtävälle ja muistiinpano jokaiselle. Jaa se asiakkaalle ennen suunnittelun käynnistystä. Tämä antaa teille yhteisen sanaston ja muuttaa auditoinnin toimitettavaksi, josta voit veloittaa. Tämä on toistettavan järjestelmän ydin, ja meillä on erillinen opastus järjestelmän perustamiseen tästä.

'Se tekee työstämme samannäköistä kuin kaikilla muilla'

Vakioi kysymykset, joita kysyt, älä vastauksia, joita toimitat. Diagnostiikka antaa sinulle arviointiperusteet, ei asettelua. SaaS-ominaisuuksien esittelyä koskeva tutkimus osoittaa, että niissä käytetään visuaaleja, kuten kuvakaappauksia, GIF-kuvia tai videoita—mutta näiden visuaalien sisältö on erilainen jokaiselle tuotteelle. Henkilöstöhallintatyökalun palkkaraportointiominaisuus ja varastonhallintaohjelmiston viivakoodin skannausominaisuus eivät koskaan näytä samanlaisilta. Vakioksi jää kysymys, jonka esität strategiselle mielellesi: 'Näyttääkö tämä sivu lopputuloksen vai vain toiminnon?'

Lääkärin esitietolomake ei tee kaikista diagnooseista samanlaisia; se tekee lääkäristä luotettavan. Sinun viitekehyksesi on esitietolomake. Asiakas saa edelleen räätälöidyn verkkosivuston, mutta sinä saat toistettavan diagnostiikan. Asia, joka todella tekee työstäsi geneeristä, on diagnostiikan puute—koska ilman sitä turvaudut samaan hero-kuvaan, samaan kolmen sarakkeen ominaisuusasetteluun, samaan etusivun rakenteeseen, jota käytit edellisessä projektissa vain edetäksesi nopeasti. Diagnostiikka pakottaa sinut perustelemaan rakenteen todisteilla, joten jokainen sivusto on rakenteellisesti erilainen siellä, missä sen on oltava.

Käytännössä tämä tarkoittaa, että diagnostiikka saattaa kehottaa aloittamaan yhden asiakkaan ominaisuussivun videolla tuontitoiminnosta ja toisen GIF-kuvalla vedä ja pudota -raporttien rakentajasta. Sivun rakenne pysyy samana, mutta sisällöt, tekstit ja rytmi ovat ainutlaatuisia. Asiakas näkee räätälöityä työtä; sinä näet toistettavan prosessin. Kun esität diagnostiikan asiakkaalle, osoitat tietäväsi, mitä jokaisen SaaS-sivuston on tehtävä. Se on vahvempi myyntipuhe kuin 'luomme ainutlaatuisen muotoilun.' Muotoilu on diagnoosin seuraus, ei lähtökohta.

'Meillä ei ole aikaa auditoida jokaista sivua'

Tee kohdennettu 90 minuutin versio, älä täyttä auditointia. Useimmat toimistojen kartoitusprosessit ovat jo valmiiksi auditointeja, mutta jäsentymättömiä. Käytät 45 minuuttia kartoituspuheluun, joka kattaa taustat, kilpailijat ja 'mitä haluat tästä,' ja sitten vietät viikkoja reagoimiseen. Diagnostiikka kääntää tämän: pisteytät viisi tehtävää, listaat suurimman vipuvaikutuksen korjaukset ja siirryt muotoiluun. Se säästää aikaa, koska lopetat työn tekemisen uudelleen ensimmäisen muotoilukatselmuksen jälkeen. Halvimmat korjaukset ovat ne, jotka teet ennen kuin kukaan näkee pikseleitä.

Tässä on konkreettinen 90 minuutin jako: ensimmäinen lohko (30 minuuttia) tarkastelee etusivua ja ominaisuussivua viiden tehtävän osalta. Toinen lohko (30 minuuttia) silmäilee hinnoittelusivua ja UKK:ta. Kolmas lohko (15 minuuttia) tarkistaa, vastaavatko API-dokumentit kysymykseen 'saanko tiedot ulos,' ja viimeiset 15 minuuttia listataan tärkeimmät korjaukset ja niiden omistajat. Sinun ei tarvitse lukea jokaista sivua ylhäältä alas; sinun on selvitettävä, hoidetaanko tehtävä. Jos hinnoittelusivulla ei ole UKK:ta, muotoilu hyväksytään nopeammin, jos huomaat sen ennen kuin luonnostelet neljännen hinnoittelusarakkeen. Jos API-dokumentit on kirjoitettu sisäisen standardin mukaan eikä kehittäjän standardin mukaan, tiedät sen ennen kuin annat briefin copywriterille.

Yhdessä toimeksiannossa diagnostiikka paljasti, että kohdeostaja pelkäsi datan siirtoa. UKK, jonka lisäsimme vastaukseksi, vaati kaksi tuntia kirjoitustyötä. Ilman diagnostiikkaa tuo pelko olisi seurannut meitä muotoilun, kehityksen ja jälkikäteen myös julkaisun jälkeiseen tukipaineeseen. 90 minuutin versio ei ole vaihe, joka edeltää projektia; se on projektin ensimmäinen vaihe. Se antaa myös rehellisen tavan arvioida: poistut istunnosta listan kanssa siitä, mitä on olemassa ja mitä ei, joten kirjoittamasi tarjous perustuu todisteisiin, ei arvauksiin.

'Minun ei-tekninen asiakkaani ei tarvitse API-dokumentteja'

Käytä päätöspuuta, et tarkistuslistaa: jos tuotteella on julkinen API tai integraatiotarina, API-dokumentit ovat ydinsivu; jos ei, jätä ne tietoisesti pois. API-dokumentteja koskeva tutkimus on tylyä: yritykset, kuten Stripe, GitHub ja Twilio, asettavat dokumentaation selkeyden standardin, koska heidän kehittäjänsä ovat käytännössä ostajia. Jos asiakkaallasi on kehittäjille suunnattu integraatio, dokumentit eivät ole kehittäjän mukavuus; ne ovat luottamusväline, joka sijaitsee hinnoittelusivun vieressä. Ei-tekninen asiakas ei ehkä koskaan katso niitä, mutta ostosta arvioiva kehittäjä kyllä katsoo.

Päätöspuu on osa järjestelmää. Kun asiakas sanoo 'meillä ei ole kehittäjäyleisöä,' kysy yksi kysymys: 'vaatiiko jokin osa käyttöönottoasi kehittäjän kytkemään tuotteen toiseen järjestelmään?' Jos kyllä, dokumentit jäävät. Jos ei, jätät ne väliin ja panostat UKK:hon ja sosiaaliseen todisteeseen. Sovella samaa logiikkaa sosiaaliseen todisteeseen: yhdelle asiakkaalle rivi logoja riittää; toiselle vaaditaan yksityiskohtainen suositus mitattavine tuloksineen. Diagnostiikka kertoo kumman, sen sijaan että oletuksena käyttäisit jokaista kerättävissä olevaa logoa. Tämä valinta tekee viitekehyksestä toistettavan mutta ei jäykän. Jos haluat selvittää, mitä 'selkeys' tarkoittaa käytännössä, tämä API-dokumentaation opas käy rakenteen läpi.

'Mutta asiakkaani haluaa ominaisuuslistan, ei lopputuloksia'

Kun asiakas sanoo haluavansa tuoda esiin ominaisuuksiaan, pyydä heitä nimeämään käyttäjän tehtävä, jonka kukin ominaisuus avaa. Yleinen oletus on, että ominaisuuksien esittely on se paikka, missä kauppa voitetaan. Diagnostiikka ehdottaa toisin: tyypillisessä SaaS-sivustossa hinnoittelusivu on paikka, missä lopullinen henkinen matematiikka tapahtuu, ja UKK on paikka, missä viimeinen vastaväite ratkaistaan. Ominaisuuksien esittely on välttämätön, mutta sen tehtävä on kapea—näyttää hetki, jolloin tuotteesta tulee arvokas. Pitkä lista ominaisuuksia, joista jokaisen alla on kappale tekstiä, ei tee sitä.

Asiakkaat vastustavat tätä, koska lista tuntuu konkreettiselta ja helpolta hyväksyä. Mutta sivu, jossa on viisikymmentä ominaisuutta, saa kävijän silmäilemään, ja kävijä, joka silmäilee ominaisuussivuasi, on jo siirtänyt huomionsa hinnoittelutaulukkoon. Järjestelmäsi tehtävä on tehdä asiakkaalle mukavaksi tämä kompromissi: et poista ominaisuuksia, siirrät ne sinne, missä niitä luetaan. Hyvin sijoitettu UKK, jossa sanotaan 'integroidumme työkaluihin, joita jo käytät,' tekee usein enemmän työtä kuin ominaisuussivu, joka sanoo saman asian väärän otsikon alla. Tämä on se vivahde, jonka useimmat artikkelit ohittavat, ja juuri sellainen kompromissi, jonka diagnostiikka voi tehdä näkyväksi.

Diagnostiikka antaa sinulle myös perustellun syyn vastustaa projektin paisumista. Kun asiakas pyytää lisäämään toisen rivin ominaisuuksia etusivulle, voit osoittaa taulukkoa ja sanoa 'tuon sivun tehtävä on näyttää lopputuloksia, ei luetteloida toimintoja.' Geneerinen sivupohjatyökalu voi tuottaa ominaisuusruudukon, mutta se ei voi päättää, pitäisikö ruudukko korvata videolla tai UKK:lla. Tämä päätös on todellinen tuote, ja se on syy, miksi viitekehys ei tee työstäsi bulkkitavaraa.

'Meillä on jo sisäinen prosessi'

Jos toimistollasi on etusivuprosessi tai hinnoittelusivun tarkistuslista, vastaväite liittyy yleensä siihen, ettei sitä haluta korvata. Sinun ei tarvitse. Viiden tehtävän diagnostiikka ei ole korvike luovalle prosessillesi; se on rajapinta, joka syöttää sitä. Useimpien sisäisten prosessien ongelma on, että ne ovat näkymättömiä. Ne elävät vanhemman suunnittelijan päässä. Diagnostiikka ulkoistaa prosessin niin, että junioritason tiimin jäsen voi tehdä ensimmäisen läpikäynnin, ja sinä voit tarkistaa sen minuuteissa. Tämä on se toistettavuus, jota todella tarvitset toimistossa, jolla on useita asiakkaita.

Näkyvä prosessi muuttaa myös keskustelua asiakkaiden kanssa. Sen sijaan että sanoisit 'meillä on oma suunnitteluprosessi,' voit sanoa 'ajamme diagnostiikan viittä tehtävää vasten, jotka jokaisen SaaS-sivuston on hoidettava, ja sitten suunnittelemme löydösten ympärille.' Ensimmäinen lause on musta laatikko, joka tekee asiakkaat hermostuneiksi. Toinen on selkeä menetelmä, joka kutsuu heidät mukaan. Diagnostiikasta tulee osa myyntitarinaasi, ei vain tuotantotyökalu.

'Asiakas sanoo nykyisen sivuston olevan hyvä'

Diagnostiikka toimii myös silloin, kun asiakas haluaa vain päivityksen. Se antaa sinulle lähtötason. Pisteytät nykyisen sivuston ja osoitat, että tietty sivu epäonnistuu tietyssä tehtävässä. Voit sanoa: 'UKK-sivusi on järjestetty, mutta se ei vastaa kysymykseen, jonka myyntitiimisi kuulee joka viikko,' ja se on tosiasioihin perustuva syy muutokseen, ei esteettinen mieltymys. Tämä on usein lempein tapa aloittaa uudelleensuunnittelu: et kerro asiakkaalle, että hänen sivustonsa on ruma, vaan että yksi tehtävä ei tule hoidetuksi.

Tämä suojaa sinua myös yleiseltä epäonnistumiselta, jossa asiakas haluaa pitää rakastamansa etusivun elementin, joka haittaa konversiota. Diagnostiikka antaa sinulle sanaston sanoa 'tuo elementti ei hoida yhtäkään viidestä tehtävästä,' ja asiakas näkee todisteet. Vastaväite ei ole enää makuasia.

Diagnoosi on tuote

Toistettavuus ei tarkoita jokaisen asiakkaan ahtamista samaan mallipohjaan. Se tarkoittaa standardiprosessin ajamista, joka tuo esiin sen, mikä on ainutlaatuista jokaisessa asiakkaassa. Viiden tehtävän diagnostiikka vie alle kaksi tuntia, antaa tiimillesi yhteisen kielen ja antaa asiakkaalle selkeän listan päätöksistä. Toimisto, joka voi luvata johdonmukaisen diagnostiikan, voi saada asiakkaan viikossa ja toimittaa kuukaudessa—ei siksi, että työ olisi helpompaa, vaan koska kartoitus on ennustettavaa. Ja kun asiakas kysyy, miksi sinun on kysyttävä niin monta kysymystä, vastaus on yksinkertainen: et ole koesoitossa, vaan tekemässä diagnoosia.

Jos haluat tarkemman katsauksen siitä, miten ominaisuuksien esittelyn ja hinnoittelusivun tulisi toimia yhdessä, ja miksi niitä ympäröivät myytit säilyvät, katso tämä myyttejä purkava opas.