SaaS svetainės diagnostika, kurią jūsų agentūra gali naudoti pakartotinai, neversdama klientų atrodyti vienodai

Santrauka

Kiek kartų šį ketvirtį vedėte tą pačią atradimo skambutį – tuos pačius klausimus apie produktą, klientą, konkurentą – dviem klientams, kurie tvirtino, kad jie visiškai skirtingi? Jūs jau žinote, kad atsakymai bus skirtingi, bet užduotys, kurias turi atlikti kiekviena SaaS svetainė, nesikeičia. Kiekviena SaaS produkto svetainė yra mažas mašinų rinkinys, kuris atlieka tas pačias užduotis: paaiškinti, ką produktas daro, parodyti, kiek jis kainuoja, pasakyti kūrėjams, kaip integruoti, atsakyti į prieštaravimus, kurie stabdo pirkimą, ir įrodyti, kad įmonė yra patikima. Kartojama diagnostika, kuri įvertina šias penkias užduotis, išliks veiksminga su bet kuriuo klientu, nes užduotys nesikeičia. Sistema, kurią sukuriate aplink ją, leidžia pereiti nuo vieno projekto prie kito be pradžios iš nulio. Tai užima mažiau laiko nei dabartinis atradimo procesas, suteikia klientui aiškią priežastį jumis pasitikėti ir sukuria rezultatą, kuris neatrodo šabloninis, nes klausimai yra standartiniai, bet atsakymai yra konkretūs.

Kiek kartų šį ketvirtį vedėte tą pačią atradimo skambutį – tuos pačius klausimus apie produktą, klientą, konkurentą – dviem klientams, kurie tvirtino, kad jie visiškai skirtingi? Jūs jau žinote, kad atsakymai bus skirtingi, bet užduotys, kurias turi atlikti kiekviena SaaS svetainė, nesikeičia. Kiekviena SaaS produkto svetainė yra mažas mašinų rinkinys, kuris atlieka tas pačias užduotis: paaiškinti, ką produktas daro, parodyti, kiek jis kainuoja, pasakyti kūrėjams, kaip integruoti, atsakyti į prieštaravimus, kurie stabdo pirkimą, ir įrodyti, kad įmonė yra patikima. Kartojama diagnostika, kuri įvertina šias penkias užduotis, išliks veiksminga su bet kuriuo klientu, nes užduotys nesikeičia. Sistema, kurią sukuriate aplink ją, leidžia pereiti nuo vieno projekto prie kito be pradžios iš nulio. Tai užima mažiau laiko nei dabartinis atradimo procesas, suteikia klientui aiškią priežastį jumis pasitikėti ir sukuria rezultatą, kuris neatrodo šabloninis, nes klausimai yra standartiniai, bet atsakymai yra konkretūs.

„Mano klientai per daug skirtingi vienai sistemai“

Paleiskite tą pačią penkių punktų diagnostiką kiekvienam klientui, prieš parašydami nors žodį teksto ar atidarydami dizaino įrankį. Skirtumai, dėl kurių jūsų klientai yra ypatingi – pramonė, auditorija, kainodaros modelis – yra ant bendro pagrindo. Atlyginimų apskaitos SaaS ir socialinės žiniasklaidos planavimo įrankis neturi nieko bendro, išskyrus penkias užduotis, kurias atlieka kiekvienas puslapis. Jei įvertinsite šias užduotis, rasite tuos pačius modelius tose pačiose vietose.

Puslapis arba sekcija	Ko jūsų klientas paprastai prašo	Kas iš tikrųjų vyksta puslapyje
Funkcijų demonstravimas	„Parodykite kiekvieną mūsų sukurtą funkciją“	Rodomas rezultatas, kurį gauna vartotojas, o ne tik funkcija. Vaizdinės priemonės, tokios kaip ekrano kopijos, GIF ar vaizdo įrašai, turėtų parodyti momentą, kai produktas pakeičia žmogaus darbo būdą.
Kainodara	„Padarykite kainas lengvai skaitomas“	Pirkėjas priverstas nuspręsti, kuris planas jam tinka. Pakopos turėtų būti suvokiamos kaip progresija, kuri veda pasirinkimą, o ne plokščias kainų sąrašas.
API dokumentacija	„Mūsų kūrėjai tai ras dokumentuose“	Dažnai pirmas testas, kurį kūrėjas atlieka vertindamas, ar produktu galima pasitikėti. Aiškumas čia yra funkcija, o ne malonumas.
DUK sekcija	„Atsakykite į klausimus, kad sumažėtų palaikymo skambučių“	Paskutinis dalykas, kurį pirkėjas skaito prieš spustelėdamas mygtuką. Ji turėtų spręsti kainodaros prieštaravimus ir kraštinius atvejus, o ne tik bendrus įmonės klausimus.
Socialinis įrodymas	„Įdėkite logotipus“	Įrodymas, kad anksčiau pateikti teiginiai yra teisingi. Logotipai ir atsiliepimai yra pasitikėjimo rodikliai, o ne dekoracijos.

Diagnostika nėra šablonas. Tai klausimų rinkinys, kurį užduodate kiekvienam puslapiui: ar tai padeda pirkėjui suprasti, ką produktas daro, ar tai daro kitą žingsnį akivaizdų, ar tai atsako į prieštaravimą, kuris šiuo metu blokuoja pardavimą? Kai užduodate šiuos klausimus dalyvaujant klientui, klientas mato jus kaip žmogų, kuris supranta jų rinką, o ne kaip dešimtą agentūrą, kuri rodė skaidres. SaaS svetainių tyrimai nurodo tokias įmones kaip HubSpot, Slack ir Zendesk kaip gerai organizuotų DUK sekcijų pavyzdžius, o Stripe, GitHub ir Twilio – kaip dokumentacijos aiškumo standartus. Nė viena iš šių įmonių nepasiekė to, traktuodama DUK kaip palaikymo bilietų krūvą. Jos traktavo jį kaip konversijos paviršių. Tokį požiūrį jūsų diagnostika turi atnešti kiekvienam klientui.

Apsvarstykite klientą, kuris parduoda atsargų apskaitos programinę įrangą, ir kitą, kuris parduoda atlyginimų apskaitos programinę įrangą. Diagnostika dažnai atskleidžia tas pačias tris spragas: funkcijų puslapis mini modulius, o ne rezultatus, kainodaros puslapis nepateisina šuolio tarp planų, o DUK atsako į palaikymo klausimus, o ne į pirkimo dvejones. Kadangi matėte šias spragas abiejuose, tiksliai žinote, ko prašyti dizaino etape. Klientas mato konkretų, o ne bendrą procesą. Užrašykite diagnostiką kaip vieno puslapio PDF su kiekvienos užduoties įvertinimu nuo 1 iki 5 ir pastaba kiekvienai. Pasidalinkite ja su klientu prieš dizaino pradžią. Tai suteikia bendrą žodyną ir paverčia auditą rezultatu, už kurį galite imti mokestį. Tai yra kartojamos sistemos esmė, ir mes turime atskirą išsamų aprašymą, kaip nustatyti tą sistemą čia.

„Tai privers mūsų darbą atrodyti kaip visų kitų“

Standartizuokite klausimus, kuriuos užduodate, o ne atsakymus, kuriuos pateikiate. Diagnostika suteikia vertinimo kriterijus, o ne maketą. SaaS funkcijų demonstravimo tyrimai rodo, kad jie naudoja vaizdines priemones, tokias kaip ekrano kopijos, GIF ar vaizdo įrašai – bet tų vaizdinių priemonių turinys kiekvienam produktui skiriasi. Atlyginimų ataskaitų funkcija HR įrankyje ir brūkšninių kodų nuskaitymo funkcija atsargų apskaitos programinėje įrangoje niekada neatrodys vienodai. Pastovus lieka klausimas, kurį užduodate savo strateginiam protui: „Ar šis puslapis rodo rezultatą, ar tik funkciją?“

Gydytojo anamnezės forma nepadaro visų diagnozių vienodų; ji daro gydytoją patikimą. Jūsų sistema yra anamnezės forma. Klientas vis tiek gauna individualią svetainę, bet jūs gaunate kartojamą diagnostiką. Tai, kas iš tikrųjų privers jūsų darbą atrodyti bendrą, yra diagnostikos trūkumas – nes be jos jūs grįžtate prie to paties herojaus paveikslėlio, to paties trijų stulpelių funkcijų maketo, tos pačios pagrindinio puslapio struktūros, kurią naudojote paskutiniam projektui, kad tik greičiau. Diagnostika verčia jus pagrįsti struktūrą įrodymais, todėl kiekviena svetainė yra struktūriškai skirtinga ten, kur reikia.

Praktiškai tai reiškia, kad diagnostika gali liepti pradėti vieno kliento funkcijų puslapį su importo vedlio vaizdo įrašu, o kito – su vilkimo ir paleidimo ataskaitų kūrėjo GIF. Puslapio struktūra išlieka ta pati, bet medžiaga, tekstas ir tempas yra unikalūs. Klientas mato individualų darbą; jūs matote kartojamą procesą. Kai pristatote diagnostiką klientui, jūs parodote, kad žinote, ką kiekviena SaaS svetainė turi padaryti. Tai stipresnis pasiūlymas nei „mes sukursime unikalų dizainą“. Dizainas yra diagnozės pasekmė, o ne atspirties taškas.

„Neturime laiko įvertinti kiekvieno puslapio“

Atlikite sutelktą 90 minučių versiją, o ne pilną auditą. Dauguma agentūrų atradimo procesų jau yra auditas, tik nestruktūruotas. Jūs praleidžiate keturiasdešimt penkias minutes atradimo skambutyje, kuris apima kontekstą, konkurentus ir „ko jūs norite iš to“, tada praleidžiate savaites reaguodami. Diagnostika tai apverčia: jūs įvertinate penkias užduotis, surašote didžiausios įtakos pataisymus ir pereinate prie dizaino. Tai taupo laiką, nes nustojate perdaryti darbą po pirmosios dizaino peržiūros. Pigiausi pataisymai yra tie, kuriuos atliekate, kol kas nors dar nematė pikselių.

Štai konkretus 90 minučių padalijimas: pirmas blokas (30 min.) peržiūri pagrindinį puslapį ir funkcijų puslapį pagal penkias užduotis. Antras blokas (30 min.) perskaito kainodaros puslapį ir DUK. Trečias blokas (15 min.) patikrina, ar API dokumentai atsako į „ar galiu ištraukti duomenis“, o paskutinės 15 minučių surašo svarbiausius pataisymus ir atsakingą asmenį už kiekvieną. Jums nereikia skaityti kiekvieno puslapio nuo viršaus iki apačios; jums reikia rasti, ar užduotis atliekama. Jei kainodaros puslapyje nėra DUK, dizainas bus patvirtintas greičiau, jei tai pastebėsite prieš kuriant ketvirtą kainodaros stulpelį. Jei API dokumentai parašyti pagal vidinį standartą, o ne kūrėjo standartą, jūs tai sužinosite prieš instruktuodami tekstų autorių.

Viename projekte diagnostika atskleidė, kad tikslinis pirkėjas labai bijojo duomenų migracijos. DUK, kurį pridėjome tam atsakymui, kainavo dvi valandas rašymo. Be diagnostikos ta baimė būtų lydėjusi mus per dizainą, per plėtrą ir į paleidimo palaikymo perkrovą. 90 minučių versija nėra etapas, einantis prieš projektą; tai pirmasis projekto etapas. Tai taip pat suteikia sąžiningą būdą įvertinti: išeinate iš sesijos su sąrašu, kas egzistuoja ir ko nėra, todėl pasiūlymas, kurį rašote, yra pagrįstas įrodymais, o ne spėjimais.

„Mano netechninis klientas nereikalauja API dokumentų“

Naudokite sprendimų medį, o ne kontrolinį sąrašą: jei produktas turi viešą API arba integracijos istoriją, API dokumentai yra pagrindinis puslapis; jei ne, sąmoningai jų praleiskite. API dokumentų tyrimai yra tiesūs: tokios įmonės kaip Stripe, GitHub ir Twilio nustato dokumentacijos aiškumo standartą, nes jų kūrėjai iš tikrųjų yra pirkėjai. Jei jūsų klientas turi integraciją, skirtą kūrėjams, dokumentai nėra kūrėjo patogumas; jie yra pasitikėjimo įrenginys, esantis šalia kainodaros puslapio. Netechninis klientas gali niekada į juos nepažvelgti, bet kūrėjas, vertinantis pirkimą, tikrai pažvelgs.

Sprendimų medis yra sistemos dalis. Kai klientas sako „mes neturime kūrėjų auditorijos“, užduokite vieną klausimą: „ar kuri nors jūsų įdiegimo dalis reikalauja, kad kūrėjas sujungtų produktą su kita sistema?“ Jei taip, dokumentai lieka. Jei ne, praleiskite juos ir įdėkite pastangų į DUK ir socialinį įrodymą. Taikykite tą pačią logiką socialiniam įrodymui: vienam klientui pakanka logotipų eilutės; kitam reikia išsamaus atsiliepimo su išmatuojamais rezultatais. Diagnostika nurodo, kuris variantas tinka, o ne pagal nutylėjimą renka kiekvieną logotipą, kurį galite surinkti. Tas pasirinkimas daro sistemą kartojamą be standumo. Jei jums reikia išsiaiškinti, ką „aiškumas“ reiškia praktiškai, šis API dokumentacijos vadovas paaiškina struktūrą.

„Bet mano klientas nori funkcijų sąrašo, o ne rezultatų“

Kai klientas sako, kad nori parodyti savo funkcijas, paprašykite įvardyti vartotojo užduotį, kurią atrakina kiekviena funkcija. Įprasta prielaida, kad funkcijų demonstravimas yra vieta, kur laimi pardavimą. Diagnostika rodo priešingai: tipinėje SaaS svetainėje kainodaros puslapyje vyksta galutinis mentalinis skaičiavimas, o DUK išsprendžiamas paskutinis prieštaravimas. Funkcijų demonstravimas yra būtinas, bet jo užduotis yra siaura – parodyti momentą, kai produktas tampa vertingas. Ilgas funkcijų sąrašas su pastraipa po kiekviena to nepadaro.

Klientai tam priešinasi, nes sąrašas atrodo apčiuopiamas ir lengvai patvirtinamas. Bet puslapis su penkiasdešimt funkcijų sukuria paviršutinišką lankytoją, o lankytojas, kuris peržiūri funkcijų puslapį, jau nukreipė dėmesį į kainodaros lentelę. Jūsų sistemos užduotis – padaryti klientą patogų dėl šio mainų: jūs nešalinate funkcijų, o perkeliate jas ten, kur jos bus perskaitytos. Gerai įdėtas DUK, sakantis „mes integruojamės su įrankiais, kuriuos jau naudojate“, dažnai atlieka daugiau darbo nei funkcijų puslapis, sakantis tą patį po netinkama antrašte. Tai niuansas, kurį dauguma straipsnių praleidžia, ir būtent tokį mainą diagnostika gali padaryti aiškų.

Diagnostika taip pat suteikia jums pagrįstą priežastį atsispirti apimties plėtimui. Kai klientas prašo pridėti dar vieną funkcijų eilutę į pagrindinį puslapį, galite parodyti į lentelę ir pasakyti: „to puslapio užduotis yra rodyti rezultatus, o ne katalogizuoti funkcionalumą.“ Bendras puslapio kūrėjas galėtų sugeneruoti funkcijų tinklelį, bet jis negali nuspręsti, ar tinklelis turėtų būti pakeistas vaizdo įrašu ar DUK. Tas sprendimas yra tikrasis produktas, ir tai yra priežastis, kodėl sistema nepaverčia jūsų darbo preke.

„Mes jau turime vidinį procesą“

Jei jūsų agentūra turi pagrindinio puslapio procesą arba kainodaros puslapio kontrolinį sąrašą, prieštaravimas paprastai yra nenoras jį pakeisti. Jums to ir nereikia. Penkių užduočių diagnostika nėra jūsų kūrybinio proceso pakaitalas; tai priekinė dalis, kuri jį maitina. Daugumos vidinių procesų problema yra ta, kad jie nematomi. Jie gyvena vyresniojo dizainerio galvoje. Diagnostika externalizuoja procesą, kad jaunesnysis komandos narys galėtų atlikti pirmąjį etapą, o jūs galėtumėte jį peržiūrėti per kelias minutes. Tai yra kartojamumas, kurio jums iš tikrųjų reikia agentūroje su keliais klientais.

Matomas procesas taip pat keičia pokalbį su klientais. Vietoj „mes turime patentuotą dizaino procesą“ galite sakyti: „mes atliekame diagnostiką pagal penkias užduotis, kurias turi atlikti kiekviena SaaS svetainė, o tada kuriame dizainą pagal išvadas.“ Pirmas sakinys yra juodoji dėžė, kuri verčia klientus jaudintis. Antrasis yra aiškus metodas, kuris juos pakviečia. Diagnostika tampa jūsų pardavimo istorijos dalimi, o ne tik gamybos įrankiu.

„Klientas sako, kad dabartinė svetainė yra gera“

Diagnostika veikia net tada, jei klientas nori tik atnaujinimo. Tai suteikia jums pradinę būseną. Įvertinate dabartinę svetainę ir parodote, kad konkretus puslapis nevykdo konkrečios užduoties. Galite pasakyti: „Jūsų DUK puslapis yra organizuotas, bet neatsako į klausimą, kurį jūsų pardavimo komanda girdi kiekvieną savaitę“, ir tai yra faktais pagrįsta priežastis keisti, o ne estetinis pasirinkimas. Tai dažnai yra švelniausias būdas pradėti perprojektavimą: jūs nesakote klientui, kad jo svetainė negraži, sakote, kad viena užduotis nėra atliekama.

Tai taip pat apsaugo jus nuo įprastos nesėkmės, kai klientas reikalauja išlaikyti mėgstamą pagrindinio puslapio elementą, kuris kenkia konversijai. Diagnostika suteikia jums žodyną pasakyti: „tas elementas neatlieka nė vienos iš penkių užduočių“, ir klientas mato įrodymus. Prieštaravimas nebėra skonio reikalas.

Diagnozė yra produktas

Kartojamumas nėra kiekvieno kliento įspraudimas į tą patį šabloną. Tai standartinio proceso vykdymas, kuris išryškina tai, kas unikalu kiekvienam klientui. Penkių užduočių diagnostika trunka mažiau nei dvi valandas, suteikia jūsų komandai bendrą kalbą ir klientui aiškų sprendimų sąrašą. Agentūra, kuri gali pažadėti nuoseklią diagnostiką, gali laimėti klientą per savaitę ir pristatyti per mėnesį, ne todėl, kad darbas lengvesnis, o todėl, kad atradimas yra nuspėjamas. Kai klientas paklausia, kodėl jums reikia užduoti tiek daug klausimų, atsakymas paprastas: jūs ne dalyvaujate atrankoje, jūs diagnozuojate.

Norėdami giliau suprasti, kaip funkcijų demonstravimas ir kainodaros puslapis turėtų veikti kartu ir kodėl mitai apie juos išlieka, žr. šį mitus griaunantį vadovą.