SaaS dijagnostika web stranice koju vaša agencija može ponovno koristiti bez da klijenti izgledaju isto

Sažetak

Koliko ste puta ovog kvartala vodili potpuno isti discovery poziv—ista pitanja o proizvodu, klijentu, konkurenciji—s dva klijenta koja su tvrdila da su potpuno različiti? Već znate da će odgovori biti drugačiji, ali zadaci koje svaka SaaS stranica mora obaviti nisu. Svaka SaaS web stranica proizvoda je mali skup strojeva koji obavljaju iste zadatke: objasniti što proizvod radi, pokazati koliko košta, reći developerima kako se integrirati, odgovoriti na prigovore koji zaustavljaju kupnju i dokazati da je tvrtka vjerodostojna. Ponovljiva dijagnostika koja revidira tih pet zadataka preživjet će kontakt s bilo kojim klijentom jer se zadaci ne mijenjaju. Sustav koji izgradite oko nje ono je što vam omogućuje da prijeđete s jednog angažmana na sljedeći bez početka od nule. Troši manje vremena od vašeg trenutnog procesa otkrivanja, klijentu daje jasan razlog da vam vjeruje i proizvodi isporuku koja ne izgleda kao predložak jer su pitanja standardna, ali odgovori su specifični.

Koliko ste puta ovog kvartala vodili potpuno isti discovery poziv—ista pitanja o proizvodu, klijentu, konkurenciji—s dva klijenta koja su tvrdila da su potpuno različiti? Već znate da će odgovori biti drugačiji, ali zadaci koje svaka SaaS stranica mora obaviti nisu. Svaka SaaS web stranica proizvoda je mali skup strojeva koji obavljaju iste zadatke: objasniti što proizvod radi, pokazati koliko košta, reći developerima kako se integrirati, odgovoriti na prigovore koji zaustavljaju kupnju i dokazati da je tvrtka vjerodostojna. Ponovljiva dijagnostika koja revidira tih pet zadataka preživjet će kontakt s bilo kojim klijentom jer se zadaci ne mijenjaju. Sustav koji izgradite oko nje ono je što vam omogućuje da prijeđete s jednog angažmana na sljedeći bez početka od nule. Troši manje vremena od vašeg trenutnog procesa otkrivanja, klijentu daje jasan razlog da vam vjeruje i proizvodi isporuku koja ne izgleda kao predložak jer su pitanja standardna, ali odgovori su specifični.

'Moji klijenti su previše različiti za jedan sustav'

Provedite istu dijagnostiku od pet točaka na svakom klijentu prije nego napišete ijednu riječ teksta ili otvorite alat za dizajn. Razlike koje čine vaše klijente posebnima—industrija, publika, model naplate—leže na zajedničkom temelju. SaaS za obračun plaća i alat za planiranje društvenih mreža nemaju ništa zajedničko osim pet zadataka koje svaka stranica obavlja. Ako revidirate te zadatke, pronaći ćete iste obrasce na istim mjestima.

Stranica ili odjeljak	Što vaš klijent obično traži	Što se zapravo događa na stranici
Prikaz značajki	'Pokaži svaku značajku koju smo izradili'	Prikazuje ishod koji korisnik dobiva, ne samo funkciju. Vizuali poput snimaka zaslona, GIF-ova ili videozapisa trebali bi prikazati trenutak u kojem proizvod mijenja način na koji netko radi.
Cijene	'Neka cijene budu lako čitljive'	Kupac je prisiljen odlučiti koji je plan za njega. Razine moraju djelovati kao napredovanje koje vodi do izbora, a ne kao običan popis cijena.
API dokumentacija	'Naši developeri će to pronaći u dokumentaciji'	Često je to prvi test koji developer pokrene kada procjenjuje može li se proizvodu vjerovati. Jasnoća je ovdje značajka, a ne luksuz.
Odjeljak s čestim pitanjima	'Odgovorite na pitanja da se smanji broj poziva podršci'	Posljednje što kupac pročita prije klika na gumb. Trebao bi obraditi prigovore na cijenu i rubne slučajeve, ne samo generička pitanja o tvrtki.
Društveni dokaz	'Postavi logotipe'	Dokaz da su ranije tvrdnje istinite. Logotipi i preporuke pokazatelji su povjerenja, a ne ukras.

Dijagnostika nije predložak. To je niz pitanja koja postavljate za svaku stranicu: čini li ovo da kupac razumije što proizvod radi, čini li sljedeći korak očitim, odgovara li na prigovor koji trenutačno blokira prodaju? Kada ova pitanja postavljate u prisutnosti klijenta, klijent vas vidi kao osobu koja razumije njihovo tržište, a ne kao desetu agenciju koja je pokazala slajdove. Istraživanja o SaaS web stranicama ukazuju na tvrtke poput HubSpota, Slacka i Zendeka kao na primjere dobro organiziranih FAQ odjeljaka, te na Stripe, GitHub i Twilio kao standarde jasnoće dokumentacije. Nijedna od tih tvrtki nije došla do toga tretirajući FAQ kao hrpu tiketa za podršku. Tretirali su ga kao površinu za konverziju. To je stav koji vaša dijagnostika treba donijeti svakom klijentu.

Uzmite u obzir klijenta koji prodaje softver za zalihe i drugog koji prodaje softver za obračun plaća. Dijagnostika često otkrije iste tri praznine: stranica sa značajkama spominje module umjesto ishoda, stranica s cijenama ne opravdava skok između planova, a FAQ odgovara na pitanja podrške umjesto na dvojbe pri kupnji. Budući da ste te praznine vidjeli u oba slučaja, točno znate što tražiti u fazi dizajna. Klijent vidi proces koji je specifičan, a ne generički. Napišite dijagnostiku kao jednopartni PDF s ocjenom od 1 do 5 za svaki zadatak i bilješkom za svaki. Podijelite je s klijentom prije početka dizajna. To vam daje zajednički vokabular i pretvara reviziju u isporuku za koju možete naplatiti. To je srž ponovljivog sustava, a mi imamo zaseban vodič o tome kako postaviti taj sustav ovdje.

'Zbog toga će naš rad izgledati kao svi ostali'

Standardizirajte pitanja koja postavljate, a ne odgovore koje isporučujete. Dijagnostika vam daje rubriku za ocjenjivanje, a ne izgled. Istraživanja o prikazu značajki u SaaS-u pokazuju da koriste vizuale poput snimaka zaslona, GIF-ova ili videozapisa—ali sadržaj tih vizuala različit je za svaki proizvod. Značajka izvještavanja o plaćama u HR alatu i značajka skeniranja barkoda u softveru za zalihe nikada neće izgledati isto. Ono što ostaje konstantno jest pitanje koje postavljate svom strateškom umu: 'Prikazuje li ova stranica ishod ili samo funkciju?'

Liječnički upitnik ne čini sve dijagnoze jednakima; čini liječnika pouzdanim. Vaš je okvir taj upitnik. Klijent i dalje dobiva prilagođenu web stranicu, ali vi dobivate dijagnostiku koja je ponovljiva. Ono što će zapravo učiniti da vaš rad izgleda generički jest nedostatak dijagnostike—jer bez nje vraćate se na istu hero sliku, isti raspored značajki u tri stupca, istu strukturu početne stranice koju ste koristili za prošli projekt samo da biste ubrzali. Dijagnostika vas tjera da strukturu opravdate na temelju dokaza, tako da je svaka stranica strukturno drugačija tamo gdje je to potrebno.

U praksi to znači da bi vam dijagnostika mogla reći da jednu klijentovu stranicu sa značajkama započnete videozapisom čarobnjaka za uvoz, a drugu s GIF-om izvjestitelja za izradu izvješća metodom povuci i ispusti. Struktura stranice ostaje ista, ali su sredstva, tekst i tempo jedinstveni. Klijent vidi prilagođeni rad; vi vidite ponovljiv proces. Kada klijentu predstavite dijagnostiku, pokazujete da znate što svaka SaaS stranica mora raditi. To je jača ponuda od 'napravit ćemo jedinstveni dizajn.' Dizajn je posljedica dijagnoze, a ne polazište.

'Nemamo vremena pregledati svaku stranicu'

Napravite fokusiranu verziju od 90 minuta, a ne potpunu reviziju. Većina procesa otkrivanja u agencijama već je revizija, samo nestrukturirana. Potrošite četrdeset pet minuta na discovery poziv koji pokriva pozadinu, konkurenciju i 'što želite od ovoga', a zatim tjednima reagiramo. Dijagnostika to preokreće: ocijenite pet zadataka, popišite poboljšanja s najvećim učinkom i prijeđite na dizajn. Štedi vrijeme jer prestajete ponovno raditi posao nakon prvog dizajn pregleda. Najjeftinija poboljšanja su ona koja napravite prije nego itko vidi piksele.

Evo konkretne podijele od 90 minuta: prvi blok (30 minuta) pregledava početnu stranicu i stranicu sa značajkama za pet zadataka. Drugi blok (30 minuta) prelijeće stranicu s cijenama i FAQ. Treći blok (15 minuta) provjerava odgovaraju li API dokumenti na 'mogu li izvući podatke', a posljednjih 15 minuta popisuje najvažnije popravke i vlasnika za svaki. Ne morate čitati svaku stranicu od vrha do dna; trebate utvrditi obavlja li se zadatak. Ako stranica s cijenama nema FAQ, dizajn će biti odobren brže ako to uočite prije nego što napravite četvrti stupac s cijenama. Ako su API dokumenti napisani prema internom standardu, a ne prema standardu developera, znat ćete to prije nego što date brifing copywriteru.

U jednom angažmanu dijagnostika je otkrila da se ciljni kupac užasava migracije podataka. FAQ koji smo dodali za taj odgovor koštao je dva sata pisanja. Bez dijagnostike, taj bi strah pratio nas kroz dizajn, kroz razvoj, do preopterećenja podrške nakon pokretanja. Verzija od 90 minuta nije faza koja prethodi projektu; ona je prva faza projekta. Također vam daje iskren način procjene: iz sesije izlazite s popisom onoga što postoji, a što ne, pa je prijedlog koji pišete utemeljen na dokazima, a ne na nagađanjima.

'Moj ne-tehnički klijent ne treba API dokumentaciju'

Koristite stablo odlučivanja, a ne kontrolni popis: ako proizvod ima javni API ili priču o integraciji, API dokumentacija je osnovna stranica; ako ne, svjesno je preskočite. Istraživanja o API dokumentaciji su jasna: tvrtke poput Stripea, GitHub i Twilio postavljaju standard jasnoće dokumentacije jer su njihovi developeri zapravo kupci. Ako vaš klijent ima integraciju usmjerenu prema developerima, dokumentacija nije pogodnost za developere; ona je uređaj za povjerenje koji stoji uz stranicu s cijenama. Netehnički kupac možda nikada neće pogledati dokumentaciju, ali developer koji procjenjuje kupnju sigurno hoće.

Stablo odlučivanja dio je sustava. Kada klijent kaže 'nemamo publiku developera', postavite jedno pitanje: 'zahtijeva li bilo koji dio vašeg onboardinga da developer poveže proizvod s drugim sustavom?' Ako da, dokumentacija ostaje. Ako ne, preskočite je i usmjerite napore na FAQ i društveni dokaz. Primijenite istu logiku na društveni dokaz: za jednog klijenta dovoljan je niz logotipa; za drugog je potrebna detaljna preporuka s mjerljivim rezultatima. Dijagnostika vam govori što odabrati, umjesto da automatski uzmete svaki logotip koji možete prikupiti. Taj izbor čini okvir ponovljivim bez krutosti. Ako trebate razraditi što 'jasnoća' znači u praksi, ovaj vodič o API dokumentaciji provodi vas kroz strukturu.

'Ali moj klijent želi popis značajki, a ne ishode'

Kada klijent kaže da želi pokazati svoje značajke, zamolite ga da navede korisnički zadatak koji svaka značajka omogućuje. Uobičajena pretpostavka je da se na prikazu značajki osvaja prodaja. Dijagnostika sugerira drugačije: na tipičnoj SaaS stranici, stranica s cijenama mjesto je gdje se događa konačna mentalna matematika, a FAQ je gdje se rješava posljednji prigovor. Prikaz značajki je bitan, ali njegova je uloga uska—pokazati trenutak kada proizvod postaje vrijedan. Dugačak popis značajki s odlomkom ispod svake ne čini to.

Klijenti se opiru tome jer popis djeluje opipljivo i lako ga je odobriti. Ali stranica s pedeset značajki stvara posjetitelja koji prelijeće, a posjetitelj koji prelijeće stranicu sa značajkama već je preusmjerio pažnju na tablicu s cijenama. Zadatak vašeg sustava je učiniti klijentu ugodnim taj kompromis: ne uklanjate značajke, već ih premještate tamo gdje će biti pročitane. Dobro postavljen FAQ koji kaže 'integriramo se s alatima koje već koristite' često radi više od stranice sa značajkama koja govori istu stvar pod pogrešnim naslovom. To je nijansa koju većina članaka preskače, a upravo je to vrsta kompromisa koju dijagnostika može učiniti eksplicitnom.

Dijagnostika vam također daje obranjiv razlog da se oduprete širenju opsega. Kada klijent traži da dodate još jedan red značajki na početnu stranicu, možete pokazati na tablicu i reći 'uloga te stranice je prikazati ishode, a ne katalog funkcionalnosti.' Generički graditelj stranica može generirati mrežu značajki, ali ne može odlučiti treba li mrežu zamijeniti videozapisom ili FAQ-om. Ta odluka je pravi proizvod i razlog zašto okvir ne komoditizira vaš rad.

'Već imamo interni proces'

Ako vaša agencija ima proces za početnu stranicu ili kontrolni popis za stranicu s cijenama, prigovor je obično taj što ne žele zamijeniti postojeće. Ne morate. Dijagnostika od pet zadataka nije zamjena za vaš kreativni proces; to je sučelje koje ga hrani. Problem s većinom internih procesa je što su nevidljivi. Žive u glavi višeg dizajnera. Dijagnostika eksternalizira proces tako da mlađi član tima može napraviti prvi prolaz, a vi ga pregledati za nekoliko minuta. To je ponovljivost koja vam zapravo treba u agenciji s više klijenata.

Vidljiv proces također mijenja razgovor s klijentima. Umjesto 'imamo vlastiti dizajn proces,' možete reći 'provodimo dijagnostiku pet zadataka koje svaka SaaS stranica mora obaviti, a zatim dizajniramo na temelju nalaza.' Prva rečenica je crna kutija koja čini klijente nervoznima. Druga je jasan metod koji ih poziva unutra. Dijagnostika postaje dio vaše prodajne priče, a ne samo proizvodni alat.

'Klijent kaže da je trenutna stranica u redu'

Dijagnostika funkcionira čak i ako klijent želi samo osvježenje. Daje vam polaznu osnovu. Ocijenite trenutnu stranicu i pokažite da određena stranica ne obavlja određeni zadatak. Možete reći: 'Vaša FAQ stranica je organizirana, ali ne odgovara na pitanje koje vaš prodajni tim čuje svaki tjedan,' i to je činjenični razlog za promjenu, a ne estetska preferencija. To je često najnježniji način za početak redizajna: ne govorite klijentu da je njihova stranica ružna, govorite im da se jedan zadatak ne obavlja.

To vas također štiti od uobičajenog neuspjeha kada klijent inzistira na zadržavanju omiljenog elementa početne stranice koji šteti konverziji. Dijagnostika vam daje vokabular da kažete 'taj element ne obavlja nijedan od pet zadataka,' a klijent može vidjeti dokaze. Prigovor više nije stvar ukusa.

Dijagnoza je proizvod

Ponovljivost nije u tome da svakog klijenta ugurate u isti predložak. Radi se o vođenju standardnog procesa koji otkriva ono što je jedinstveno za svakog klijenta. Dijagnostika od pet zadataka traje manje od dva sata, vašem timu daje zajednički jezik, a klijentu jasan popis odluka. Agencija koja može obećati dosljednu dijagnostiku može dobiti klijenta u tjedan dana i isporučiti u mjesec dana, ne zato što je posao lakši, već zato što je otkrivanje predvidljivo. I kada klijent pita zašto trebate postaviti toliko pitanja, odgovor je jednostavan: ne idete na audiciju, vi postavljate dijagnozu.

Za dublji uvid u to kako prikaz značajki i stranica s cijenama trebaju surađivati i zašto mitovi oko njih opstaju, pogledajte ovaj vodič koji razbija mitove.