SaaS vietnes diagnostika, ko jūsu aģentūra var izmantot atkārtoti, nepadarot klientus līdzīgus

Kopsavilkums

Cik reizes šajā ceturksnī esat veicis tieši to pašu atklāšanas zvanu — tos pašus jautājumus par produktu, klientu, konkurentu — diviem klientiem, kuri uzstāja, ka viņi ir pilnīgi atšķirīgi? Jūs jau zināt, ka atbildes būs atšķirīgas, bet uzdevumi, kas jāveic katrai SaaS vietnei, nav. Katra SaaS produkta vietne ir neliels mašīnu kopums, kas veic vienus un tos pašus uzdevumus: izskaidro, ko produkts dara, parāda, cik tas maksā, pastāsta izstrādātājiem, kā integrēt, atbild uz iebildumiem, kas aptur pirkumu, un pierāda, ka uzņēmums ir uzticams. Atkārtojama diagnostika, kas pārbauda šos piecus uzdevumus, izdzīvos saskarē ar jebkuru klientu, jo uzdevumi nemainās. Sistēma, ko ap to izveidojat, ļauj pāriet no viena projekta uz nākamo, nesākot no nulles. Tas prasa mazāk laika nekā jūsu pašreizējais atklāšanas process, dod klientam skaidru iemeslu jums uzticēties, un rada nodevumu, kas neizskatās pēc šablona, jo jautājumi ir standarta, bet atbildes ir specifiskas.

Cik reizes šajā ceturksnī esat veicis tieši to pašu atklāšanas zvanu — tos pašus jautājumus par produktu, klientu, konkurentu — diviem klientiem, kuri uzstāja, ka viņi ir pilnīgi atšķirīgi? Jūs jau zināt, ka atbildes būs atšķirīgas, bet uzdevumi, kas jāveic katrai SaaS vietnei, nav. Katra SaaS produkta vietne ir neliels mašīnu kopums, kas veic vienus un tos pašus uzdevumus: izskaidro, ko produkts dara, parāda, cik tas maksā, pastāsta izstrādātājiem, kā integrēt, atbild uz iebildumiem, kas aptur pirkumu, un pierāda, ka uzņēmums ir uzticams. Atkārtojama diagnostika, kas pārbauda šos piecus uzdevumus, izdzīvos saskarē ar jebkuru klientu, jo uzdevumi nemainās. Sistēma, ko ap to izveidojat, ļauj pāriet no viena projekta uz nākamo, nesākot no nulles. Tas prasa mazāk laika nekā jūsu pašreizējais atklāšanas process, dod klientam skaidru iemeslu jums uzticēties, un rada nodevumu, kas neizskatās pēc šablona, jo jautājumi ir standarta, bet atbildes ir specifiskas.

'Mani klienti ir pārāk atšķirīgi vienai sistēmai'

Palaidiet to pašu piecu punktu diagnostiku katram klientam, pirms uzrakstāt vārdu teksta vai atverat dizaina rīku. Atšķirības, kas padara jūsu klientus īpašus — nozare, auditorija, cenu modelis — atrodas uz kopīga pamata. Algu SaaS un sociālo mediju plānošanas rīkam nav nekā kopīga, izņemot piecus uzdevumus, ko veic katra lapa. Ja auditējat šos uzdevumus, atradīsiet tos pašus modeļus tajās pašās vietās.

Lapa vai sadaļa	Ko jūsu klients parasti lūdz	Kas patiesībā notiek lapā
Funkciju demonstrācija	'Parādiet katru funkciju, ko esam izveidojuši'	Parāda lietotāja iegūto rezultātu, ne tikai funkciju. Vizuālie materiāli, piemēram, ekrānuzņēmumi, GIF vai video, jāizmanto, lai parādītu brīdi, kad produkts maina to, kā cilvēks strādā.
Cenas	'Padariet cenas viegli lasāmas'	Pircējs ir spiests izlemt, kurš plāns ir viņam. Līmeņiem jābūt kā progresijai, kas virza izvēli, nevis plakanam cenu sarakstam.
API dokumentācija	'Mūsu izstrādātāji to atradīs dokumentācijā'	Bieži vien pirmais tests, ko izstrādātājs veic, novērtējot, vai produktam var uzticēties. Skaidrība šeit ir funkcija, nevis pieklājība.
FAQ sadaļa	'Atbildiet uz jautājumiem, lai atbalsta zvanu skaits samazinātos'	Pēdējā lieta, ko pircējs izlasa pirms pogas klikšķināšanas. Tai jāatbild uz cenu iebildumiem un īpašiem gadījumiem, ne tikai uz vispārīgiem uzņēmuma jautājumiem.
Sociālie pierādījumi	'Uzlieciet logotipus'	Pierādījums, ka iepriekš izteiktie apgalvojumi ir patiesi. Logotipi un atsauksmes ir uzticības rādītāji, nevis dekorācija.

Diagnostika nav šablons. Tas ir jautājumu kopums, ko uzdodat par katru lapu: vai tas palīdz pircējam saprast, ko produkts dara, vai tas padara nākamo soli acīmredzamu, vai tas atbild uz iebildumu, kas šobrīd bloķē pārdošanu? Kad uzdodat šos jautājumus klienta klātbūtnē, klients redz jūs kā cilvēku, kurš saprot viņu tirgu, nevis kā desmito aģentūru, kas rādīja slaidu prezentāciju. Pētījumi par SaaS vietnēm norāda uz tādiem uzņēmumiem kā HubSpot, Slack un Zendesk kā labi organizētu FAQ sadaļu piemēriem, un uz Stripe, GitHub un Twilio kā dokumentācijas skaidrības standartiem. Neviens no šiem uzņēmumiem to nesasniedza, izturoties pret FAQ kā pret atbalsta biļešu kaudzi. Viņi to uztvēra kā konversijas virsmu. Šāda attieksme ir jūsu diagnostikai jāienes katram klientam.

Iedomājieties klientu, kurš pārdod inventāra programmatūru, un citu, kurš pārdod algu programmatūru. Diagnostika bieži atklāj tās pašas trīs nepilnības: funkciju lapa min moduļus, nevis rezultātus, cenu lapa nepamato lēcienu starp plāniem, un FAQ atbild uz atbalsta jautājumiem, nevis uz pirkšanas vilcināšanos. Tā kā esat redzējis šīs nepilnības abos, jūs precīzi zināt, ko prasīt dizaina posmā. Klients redz procesu, kas ir specifisks, nevis vispārīgs. Uzrakstiet diagnostiku kā vienas lapas PDF ar vērtējumu no 1 līdz 5 par katru uzdevumu un piezīmi par katru. Dalieties tajā ar klientu pirms dizaina uzsākšanas. Tas dod jums kopīgu vārdu krājumu un pārvērš auditu par nodevumu, par kuru varat iekasēt maksu. Tas ir atkārtojamas sistēmas kodols, un mums ir atsevišķs ceļvedis, kā to izveidot šeit.

'Tas padarīs mūsu darbu līdzīgu visu pārējo darbam'

Standartizējiet jautājumus, ko uzdodat, nevis atbildes, ko piegādājat. Diagnostika dod vērtēšanas rubriku, nevis izkārtojumu. Pētījumi par SaaS funkciju demonstrācijām rāda, ka tās izmanto vizuālos materiālus, piemēram, ekrānuzņēmumus, GIF vai video — taču šo vizuālo materiālu saturs katram produktam ir atšķirīgs. Algas atskaišu funkcija HR rīkā un svītrkoda skenēšanas funkcija inventāra programmatūrā nekad neizskatīsies vienādi. Pastāvīgs paliek jautājums, ko uzdodat savai stratēģiskajai domāšanai: 'Vai šī lapa parāda rezultātu, vai tikai funkciju?'

Ārsta uzņemšanas veidlapa nepadara visas diagnozes vienādas; tā padara ārstu uzticamu. Jūsu sistēma ir uzņemšanas veidlapa. Klients joprojām saņem pielāgotu vietni, bet jūs saņemat diagnostiku, ko var atkārtot. Tas, kas patiesībā padarīs jūsu darbu vispārīgu, ir diagnostikas trūkums — jo bez tās jūs atgriežaties pie tā paša hero attēla, tās pašas trīs kolonnu funkciju izkārtojuma, tās pašas mājaslapas struktūras, ko izmantojāt iepriekšējā projektā, lai tikai ātri virzītos uz priekšu. Diagnostika liek jums pamatot struktūru ar pierādījumiem, tāpēc katra vietne strukturāli atšķiras tur, kur tas nepieciešams.

Praksē tas nozīmē, ka diagnostika var likt sākt viena klienta funkciju lapu ar importa vedņa video, bet cita — ar velkamā un nomešanas atskaišu veidotāja GIF. Lapas struktūra paliek nemainīga, bet aktīvi, teksts un ritms ir unikāli. Klients redz pielāgotu darbu; jūs redzat atkārtojamu procesu. Kad klientam prezentējat diagnostiku, jūs demonstrējat, ka zināt, kas jādara katrai SaaS vietnei. Tas ir spēcīgāks arguments nekā 'mēs izveidosim unikālu dizainu.' Dizains ir diagnozes sekas, nevis sākumpunkts.

'Mums nav laika auditēt katru lapu'

Veiciet fokusēto 90 minūšu versiju, nevis pilnu auditu. Lielākā daļa aģentūru atklāšanas procesu jau ir audits, tikai ne strukturēts. Jūs pavadāt četrdesmit piecas minūtes atklāšanas zvanā, kas aptver fonu, konkurentus un 'ko jūs no tā vēlaties', pēc tam nedēļām reaģējat. Diagnostika to apgriež: jūs novērtējat piecus uzdevumus, uzskaitāt augstākās ietekmes labojumus un pārejat uz dizainu. Tas ietaupa laiku, jo pārtraucat darbu pārtaisīšanu pēc pirmās dizaina pārskatīšanas. Lētākie labojumi ir tie, ko veicat, pirms kāds ir redzējis pikseļus.

Šeit ir konkrēts 90 minūšu sadalījums: pirmais bloks (30 minūtes) pārskata mājaslapu un funkciju lapu pieciem uzdevumiem. Otrais bloks (30 minūtes) pārskata cenu lapu un FAQ. Trešais bloks (15 minūtes) pārbauda, vai API dokumentācija atbild uz 'vai es varu izgūt datus', un pēdējās 15 minūtes uzskaita galvenos labojumus un atbildīgo par katru. Jums nav jālasa katra lapa no augšas līdz apakšai; jums jānoskaidro, vai uzdevums tiek veikts. Ja cenu lapā nav FAQ, dizains tiks apstiprināts ātrāk, ja to pamanīsit pirms ceturtās cenu kolonnas izveides. Ja API dokumentācija ir rakstīta atbilstoši iekšējam standartam, nevis izstrādātāja standartam, jūs to uzzināsit pirms tekstu autora instruēšanas.

Vienā projektā diagnostika atklāja, ka mērķa pircējs ļoti baidījās no datu migrācijas. FAQ, ko pievienojām šai atbildei, izmaksāja divas stundas rakstīšanas. Bez diagnostikas šīs bailes būtu mūs pavadījušas cauri dizainam, izstrādei un pēc uzsākšanas atbalsta pārslodzei. 90 minūšu versija nav fāze, kas notiek pirms projekta; tā ir projekta pirmā fāze. Tā arī dod godīgu veidu, kā veikt tāmi: jūs atstājat sesiju ar sarakstu, kas pastāv un kas nepastāv, tāpēc piedāvājums, ko rakstāt, ir balstīts uz pierādījumiem, nevis minējumiem.

'Manam netehniskajam klientam nav vajadzīga API dokumentācija'

Izmantojiet lēmumu koku, nevis kontrolsarakstu: ja produktam ir publisks API vai integrācijas stāsts, API dokumentācija ir galvenā lapa; ja nē, apzināti to izlaidiet. Pētījumi par API dokumentāciju ir skaidri: tādi uzņēmumi kā Stripe, GitHub un Twilio nosaka dokumentācijas skaidrības standartu, jo viņu izstrādātāji faktiski ir pircēji. Ja jūsu klientam ir izstrādātājiem paredzēta integrācija, dokumentācija nav izstrādātāju ērtība; tā ir uzticības ierīce, kas atrodas blakus cenu lapai. Netehnisks klients to nekad neskatīs, bet izstrādātājs, kurš izvērtē pirkumu, noteikti skatīs.

Lēmumu koks ir daļa no sistēmas. Kad klients saka 'mums nav izstrādātāju auditorijas', uzdodiet vienu jautājumu: 'vai kāda jūsu ieviešanas procesa daļa prasa izstrādātājam savienot produktu ar citu sistēmu?' Ja jā, dokumentācija paliek. Ja nē, izlaidiet to un ieguldiet pūles FAQ un sociālajos pierādījumos. Piemērojiet to pašu loģiku sociālajiem pierādījumiem: vienam klientam pietiek ar logotipu rindu; citam ir nepieciešama detalizēta atsauksme ar izmērāmiem rezultātiem. Diagnostika norāda, kurš variants ir nepieciešams, nevis automātiski iekļauj visus logotipus, ko varat savākt. Šī izvēle padara sistēmu atkārtojamu bez stingrības. Ja nepieciešams saprast, ko 'skaidrība' nozīmē praksē, šis API dokumentācijas ceļvedis izskaidro struktūru.

'Bet mans klients vēlas funkciju sarakstu, nevis rezultātus'

Kad klients saka, ka vēlas parādīt savas funkcijas, lūdziet viņiem nosaukt lietotāja uzdevumu, ko katra funkcija atver. Izplatīts pieņēmums ir, ka funkciju demonstrācija ir vieta, kur uzvarat pārdošanā. Diagnostika liecina pretējo: tipiskā SaaS vietnē cenu lapa ir vieta, kur notiek pēdējie mentālie aprēķini, un FAQ ir vieta, kur tiek atrisināts pēdējais iebildums. Funkciju demonstrācija ir būtiska, bet tās uzdevums ir šaurs — parādīt brīdi, kad produkts kļūst vērtīgs. Garš funkciju saraksts ar rindkopu zem katras to nedara.

Klienti pretojas tam, jo saraksts šķiet taustāms un viegli apstiprināms. Bet lapa ar piecdesmit funkcijām rada pārskrienošu apmeklētāju, un apmeklētājs, kurš pārskrien jūsu funkciju lapu, jau ir pārvietojis savu uzmanību uz cenu tabulu. Jūsu sistēmas uzdevums ir padarīt klientam ērtu šo kompromisu: jūs nenoņemat funkcijas, jūs tās pārvietojat uz vietu, kur tās tiks lasītas. Labi novietota FAQ, kurā teikts 'mēs integrējamies ar rīkiem, kurus jūs jau izmantojat', bieži vien dod vairāk nekā funkciju lapa, kas saka to pašu zem nepareizā virsraksta. Šī ir nianse, ko lielākā daļa rakstu izlaiž, un tieši šādu kompromisu diagnostika var padarīt skaidru.

Diagnostika arī dod jums aizstāvamu iemeslu, lai pretotos darba apjoma palielināšanai. Kad klients lūdz pievienot vēl vienu funkciju rindu mājaslapā, varat norādīt uz tabulu un teikt: 'šīs lapas uzdevums ir parādīt rezultātus, nevis katalogizēt funkcionalitāti.' Vispārīgs lapu veidotājs var izveidot funkciju režģi, bet tas nevar izlemt, vai režģi vajadzētu aizstāt ar video vai FAQ. Šis lēmums ir īstais produkts, un tas ir iemesls, kāpēc sistēma nepadara jūsu darbu par preci.

'Mums jau ir iekšējs process'

Ja jūsu aģentūrai ir mājaslapas process vai cenu lapas kontrolsaraksts, iebildums parasti ir par to, ka nevēlas to aizstāt. Jums nav. Piecu uzdevumu diagnostika nav jūsu radošā procesa aizstājējs; tā ir priekšējā daļa, kas to baro. Lielākā daļa iekšējo procesu problēma ir tā, ka tie ir neredzami. Tie dzīvo vecākā dizainera galvā. Diagnostika padara procesu redzamu, lai jaunāks komandas loceklis varētu veikt pirmo piegājienu, un jūs varat to pārskatīt minūtēs. Tā ir atkārtojamība, kas jums patiesībā nepieciešama aģentūrā ar vairākiem klientiem.

Redzams process arī maina sarunu ar klientiem. Tā vietā, lai teiktu 'mums ir patentēts dizaina process', varat teikt 'mēs veicam diagnostiku pret pieciem uzdevumiem, kas jādara katrai SaaS vietnei, un pēc tam veidojam dizainu ap atklājumiem.' Pirmais teikums ir melnā kaste, kas satrauc klientus. Otrais ir skaidra metode, kas viņus iesaista. Diagnostika kļūst par daļu no jūsu pārdošanas stāsta, ne tikai ražošanas rīku.

'Klients saka, ka pašreizējā vietne ir laba'

Diagnostika joprojām darbojas, ja klients vēlas tikai atsvaidzinājumu. Tā dod jums bāzes līniju. Jūs novērtējat pašreizējo vietni un parādāt, ka konkrēta lapa neizpilda konkrētu uzdevumu. Varat teikt: 'Jūsu FAQ lapa ir strukturēta, bet tā neatbild uz jautājumu, ko jūsu pārdošanas komanda dzird katru nedēļu', un tas ir uz faktiem balstīts iemesls izmaiņām, nevis estētiska izvēle. Tas bieži ir maigākais veids, kā sākt pārveidi: jūs nesakāt klientam, ka viņu vietne ir neglīta, jūs sakāt, ka viens uzdevums netiek veikts.

Tas arī pasargā jūs no bieži sastopamas neveiksmes, kad klients uzstāj uz mīļota mājaslapas elementa saglabāšanu, kas kaitē konversijai. Diagnostika dod jums vārdu krājumu, lai teiktu 'šis elements neveic nevienu no pieciem uzdevumiem', un klients var redzēt pierādījumus. Iebildums vairs nav gaumes jautājums.

Diagnoze ir produkts

Atkārtojamība nav par to, lai iespiestu katru klientu vienā šablonā. Tā ir par standarta procesa vadīšanu, kas atklāj to, kas ir unikāls katram klientam. Piecu uzdevumu diagnostika aizņem mazāk nekā divas stundas, dod jūsu komandai kopīgu valodu un klientam skaidru lēmumu sarakstu. Aģentūra, kas var solīt konsekventu diagnostiku, var piesaistīt klientu nedēļas laikā un piegādāt mēneša laikā, ne tāpēc, ka darbs būtu vieglāks, bet tāpēc, ka atklāšana ir prognozējama. Un, kad klients jautā, kāpēc jums jāuzdod tik daudz jautājumu, atbilde ir vienkārša: jūs neaudicionējat, jūs diagnosticējat.

Lai dziļāk izprastu, kā funkciju demonstrācijai un cenu lapai būtu jāsadarbojas un kāpēc mīti ap tām saglabājas, skatiet šo mītus kliedējošo ceļvedi.