Nustokite pardavinėti funkcijas, parduokite perėjimą

Santrauka

Jūsų kliento SaaS svetainė nepralaimi todėl, kad atrodo blogai. Ji pralaimi todėl, kad niekada neatsako į vienintelį svarbų klausimą: kodėl man reikia pereiti? Agentūros darbui negalite kiekvienam produktui iš naujo kurti unikalaus įtikinėjimo modelio. Vietoj to naudokite tą patį penkių klausimų auditą, kad rastumėte perėjimo trigerį bet kokiam SaaS. Tada pritaikykite tą trigerį kiekviename puslapyje: funkcijos tampa įrodymu, kainodara – aiškumu, DUK – prieštaravimų naikintoju, o API dokumentai – pirmąja kūrėjo pergale. Ši sistema paverčia vienkartinį pertvarkymą pakartojamu procesu. Rezultatas: greitesnis pristatymas, mažiau pataisymų ir puslapiai, kurie iš tikrųjų konvertuoja.

Jūsų klientas neturi dizaino problemos. Jis turi perėjimo problemą. Pirkėjas jau turi įrankį, darbo eigą ir komandą, kuri nekenčia pokyčių. Jie nelygina jūsų kliento funkcijų su tuščiu puslapiu. Jie lygina skausmą likti su skausmu išeiti. Svetainės darbas yra ne išvardyti, ką produktas daro, o padaryti perėjimą lengvesnį ir vertingesnį nei esama padėtis. Jei ji to nedaro, svetainė yra tik tapetai.

Dirbdami agentūroje, tai jaučiate ypač aštriai. Paimate SaaS klientą, įkūrėjas sako: 'mums reikia modernios svetainės', ir visi mano, kad pataisymas yra vizualus. Taip nėra. Galite užtempti apdovanojimą pelniusį dizainą ant neteisingos žinutės, ir jis konvertuos lygiai taip pat, kaip sena svetainė. Bet suraskite perėjimo trigerį – ir žinutė atliks sunkųjį darbą. Tiesiog turite jį rasti greitai – kiekvienam klientui, kiekvieną ketvirtį, pramonės šakose, kurių dar nepažįstate. Todėl jums reikia sistemos, kurią galėtumėte paleisti pirmą dieną, be trijų mėnesių atradimo fazės.

Pagalvokite, ką apima perėjimas: duomenų eksportavimas, komandos mokymas, naujos sąsajos mokymasis, įpročių keitimas. Jūsų kliento svetainė turi padaryti, kad ši seka atrodytų neišvengiama. Funkcijų sąrašas to negali. Aiškus gyvenimo po perėjimo vaizdas gali. Tas vaizdas ir yra žinutė. Viskas kitas svetainėje ją palaiko.

Štai sistema: apibrėžkite perėjimą. Tada priverskite kiekvieną puslapį jį argumentuoti.

Prieštaravimas	Ką jis iš tikrųjų saugo	Ką daryti vietoj to
'Kiekvienas klientas yra kitoks.'	Jūsų baimė šablonų	Raskite perėjimo trigerį naudodami penkių klausimų auditą
'Mums reikia daugiau ekrano nuotraukų.'	Baimė tuščių sekcijų	Pakeiskite produkto nuotraukas įrodymais
'Kainodara yra šventa.'	Finansų direktoriaus nerimas	Naudokite aiškumą, kad sumažintumėte kainų šoką
'API dokumentai – kūrėjų problema.'	Kūrėjų komandos vartų sargyba	Traktuokite dokumentus kaip įtikinamąją priemonę
'DUK nuobodus.'	Palaikymo komandos užtvindytas el. paštas	Naudokite DUK, kad išsklaidytumėte paskutinės akimirkos abejones
'Neturime laiko pritaikyti.'	Perfekcionizmas, o ne pristatymas	Kurkite skeletą, o ne snaigę

Naudokite šią lentelę kaip kontrolinį sąrašą pirmajame susitikime. Bet kuris joje esantis prieštaravimas nėra tikra kliūtis. Tai prašymas kitokios sistemos.

'Kiekvienas klientas yra kitoks' – tiesa, ir nesvarbu

Štai kas pasikeičia: produktas kitoks, rinka kitokia, pirkėjo elgsena – ne. Pirkėjai nori trijų dalykų: 'Ar aš tai suprantu?' 'Ar galiu tuo pasitikėti?' 'Ar perėjimas pigesnis nei likti?' Tai universalu. Tad nestandartizuokite dizaino. Standartizuokite klausinėjimą.

Pradėkite nuo penkių klausimų audito. Atlikite jį pirmojo atradimo skambučio metu. Jis trunka dvidešimt minučių ir tinka bet kokiam SaaS.

• Kas yra vartotojas, o kas pirkėjas? (Jie retai būna tas pats asmuo.)
• Ką jie daro šiandien vietoj to, kad naudotų jūsų kliento produktą?
• Koks yra vienintelis erzinantis skausmas toje dabartinėje darbo eigoje?
• Ko jie bijo, kad suges, jei pereis?
• Koks yra greičiausias 'laimėjimas', kurį jie gautų iškart po perėjimo?

Peržiūrėkite du klientus, kad pamatytumėte, kaip tai veikia.

Pirma, projektų valdymo įrankis. Vartotojas yra komandos vadovas, pirkėjas taip pat komandos vadovas. Jis daro tą patį, ką ir dabartinis įrankis. Skausmas? Niekas nežino, kam priklauso kita užduotis. Baimė? Migruoti šimtus projektų ir prarasti visą būseną. Greitas laimėjimas? Skydelis, kuris iš karto rodo užduoties savininką. Trigertis: 'Niekada nebeieškokite užduoties savininko.' Tai antraštė.

Antra, nekilnojamojo turto potencialių klientų sekimo įrankis. Vartotojas yra agentas, pirkėjas – brokeris. Skausmas? Dublikatai pasikartoja trijose vietose, o geri potencialūs klientai atšąla. Baimė? Agentai neves duomenų. Greitas laimėjimas? Automatinis praturtinimas iš MLS sąrašų, kad agentai baigtų darbą dviem paspaudimais. Trigertis: 'Niekada nepraraskite potencialaus kliento du kartus.'

Tie patys penki klausimai. Du skirtingi produktai. Dabar turite pagrindinę žinutę pagrindiniam puslapiui, pirmąją funkcijų skyriaus pastraipą ir el. laiškų sekos temą. Perėjimo trigertis yra atsinaujinantis išteklius: kiekvienas puslapis, kiekvienas skyrius, kiekviena paantraštė gali jį argumentuoti. Tai jūsų starto linija.

Tas pats trigertis taip pat suteikia jums svetainės schemą. Puslapis, kuris paaiškina trigerį, yra pagrindinis puslapis. Puslapis, kuris įrodo trigerį, yra funkcijų skyrius. Puslapis, kuris pašalina baimę, yra DUK. Puslapis, kuris parodo perėjimo kainą, yra kainodaros puslapis. Staiga visa svetainė turi vieną pasakojimą, o ne puslapio po puslapio komitetą.

Taip pat galite atlikti konkurentų analizę, užduodami tuos pačius penkis klausimus apie konkurento svetainę. Tai pigus būdas parodyti vertę pirmojo skambučio metu. Rasite konkurento trūkstamą perėjimo trigerį, ir jūsų klientas tampa akivaizdžia alternatyva.

O jei produktas yra 'gražu turėti', o ne skausmo malšintojas? Tada perėjimo trigertis yra didesnis: sutaupyti pinigai, išvengta rizika ar įgyta padėtis. Atitikties įrankiui trigertis – 'išvengti baudos.' Saugos įrankiui – 'išlaikyti auditą.' Socialinės medijos planuokliui – 'atgauti dvi valandas kiekvieną savaitę.' Auditas vis tiek jį randa. Kai kurie trigeriai tiesiog mažiau emocionalūs.

Ekrano nuotraukos yra mažiausiai vertingas įrodymas puslapyje

Paimkite vienišiausią eilutę savo kliento funkcijų lentelėje: 'OAuth 2.0 palaikymas.' Kokią emociją tai sukelia? Jokios. Tai kontrolinio sąrašo elementas kūrėjui, kuris nėra pirkėjas. Vis dėlto, kai paprašote kliento funkcijų puslapio, jis įteikia jums sieną tokių eilučių. Užpildykite puslapį ekrano nuotraukomis ir darysite kažką dar labiau įprasto: rodysite produktą, o ne rezultatą.

Ekrano nuotraukos turi vietą. Geras GIF, rodantis produktą darbe, yra įrodymas. Tačiau dauguma ekrano nuotraukų yra produkto portretai. Pirkėjams reikia istorijos 'prieš ir po.' Funkcijų skyrius yra geriausia vieta tai papasakoti. Naudokite formulę 'Funkcija-Nauda-Įrodymas' (FBP). Įvardykite funkciją, susiekite ją su nauda, tada įrodykite faktu, procesu ar maža demonstracija. Jokių išgalvotų skaičių – naudokite stebimus rezultatus, pvz., 'veikia su Google Workspace' arba 'sukuriama per mažiau nei minutę.'

Originalus kliento blokas:

• OAuth 2.0 palaikymas
• Vaidmenimis pagrįsta prieigos kontrolė (RBAC)
• SCIM teikimas

Trys tiekėjo žargono punktai. Dabar kiekvieną išnagrinėkite pagal FBP.

Funkcija: OAuth 2.0 palaikymas.
Nauda: Vienas prisijungimas visai komandai. Jokių daugiau IT bilietų.
Įrodymas: Veikia su Google Workspace ir Microsoft Entra.

Funkcija: Vaidmenimis pagrįsta prieigos kontrolė.
Nauda: Suteikite administratoriams, redaktoriams ir peržiūrėtojams būtent tokias teises, kokių jiems reikia.
Įrodymas: Suteikite peržiūros teises rangovui per mažiau nei minutę.

Funkcija: SCIM teikimas.
Nauda: Automatiškai pridėkite ir šalinkite naudotojus iš savo HR sistemos.
Įrodymas: Sinchronizuojasi su Okta ir Rippling.

Funkcijos nepasikeitė. Pasikeitė įtikinėjimas. Jūsų klientas pasakys: 'Bet įmonių pirkėjai tikisi matyti žodžius OAuth ir SCIM.' Tiesa. Pridėkite techninę eilutę kūrėjams, kurie audituoja puslapį. Bet įdėkite tą eilutę mažu šriftu po nauda. Pirmoji auditorija yra pirkėjas, kuris nusprendžia, ar užsisakyti susitikimą. Antroji auditorija – kūrėjas, kuris pažymi langelius. Struktūrizuokite savo funkcijų vitriną pagal įrodymus, o ne produkto nuotraukas, ir nustosite kurti užpildą.

Kai naudojate ekrano nuotrauką, įsitikinkite, kad ji rodo rezultatą, o ne ekraną. Projektų valdymo klientui ekrano nuotrauka lentoje, kurioje kiekviena užduotis turi aiškų savininką, yra įrodymas. Nekilnojamojo turto klientui ekrano nuotrauka su vienu švariu kontakto įrašu su automatiškai praturtintais duomenimis yra įrodymas. Ekrano nuotrauka, rodanti tuščią prietaisų skydelio būseną, yra dizaino priemonė, o ne įtikinėjimo priemonė.

Techninę specifikaciją įdėkite į išskleidžiamą skyrių arba kūrėjų išteklių skirtuką. Vartotojas mato naudą; kūrėjas gali įsigilinti. Tai išlaiko puslapį švarų ir auditorių patenkintą.

Geras bet kurio funkcijos teiginio testas: ar pirkėjas pakartotų jį savo viršininkui? 'Vienas prisijungimas' pakartojamas. 'OAuth 2.0 palaikymas' – ne. Jei jūsų kliento funkcijų puslapis neišlaiko vandens aušintuvo testo, jis dar nėra įtikinantis.

Kainodaros puslapiai yra minų laukas. Būtent todėl turėtumėte juos liesti

Išgirsite: 'Nelieskite kainodaros. Ji tokia jau metų metus.' Ką jie iš tikrųjų sako: 'mes bijome.' Painus kainodaros puslapis neapsaugo pajamų; jis jas praleidžia. Jūsų darbas – paversti puslapį iš kaštų derybų į aiškumo pareiškimą.

Pradėkite išvardydami klausimus, į kuriuos jūsų pardavimų komanda atsako kiekvieną savaitę. Užrašykite juos pažodžiui. 'Ar imate mokestį už vartotoją?' 'Kas atsitiks, jei sumažinsiu planą?' 'Ar yra sąrankos mokestis?' 'Ar galiu išbandyti be kreditinės kortelės?' 'Kokia jūsų pinigų grąžinimo politika?' Įdėkite juos į puslapį. Pirkėjas neturėtų rezervuoti skambučio, kad sužinotų, ar bandomajam laikotarpiui reikia kreditinės kortelės.

Tada paimkite kliento tris planus: Basic, Pro, Enterprise. Pervadinkite juos pagal kliento situaciją. Ką kiekvienas planas iš tikrųjų duoda žmogui? Solo, Team, Organization. Arba Creator, Studio, Enterprise. Pavadinimas nėra dekoracija; tai pirmasis aiškumo momentas.

Štai konkretus pervadinto planų lentelės pavyzdys:

Senasis planas	Naujasis planas	Pažadas
Basic	Solo	Vienam asmeniui, kuriam reikia paprastos darbo eigos
Pro	Team	Komandai, kuriai reikia bendradarbiavimo ir skydelių
Enterprise	Org	Įmonei, kuriai reikia saugumo, SSO ir palaikymo

Tada sukurkite palyginimo lentelę. Sulaužykite įprotį suversti kiekvieną funkciją į kiekvieną eilutę. Pradėkite kiekvieną eilutę nuo naudotojo klausimo, į kurį ji atsako. 'Kiek naudotojų?' 'Ką galime pakviesti?' 'Kokias saugos funkcijas gauname?' Pirkėjas skaito lentelę, kad ieškotų 'ar aš tinku.' Palengvinkite tą paiešką.

Galiausiai pridėkite kainodaros DUK. Atsakykite į nemalonų klausimą: 'Kas atsitiks mano duomenims, jei išeisiu?' Parašykite atsakymą kaip žmogus: 'Eksportuokite viską vienu spustelėjimu prieš pasibaigiant prenumeratai. Jokių mokesčių, jokio užrakinimo.' Tai perėjimo pasitikėjimo laužytojas. Dauguma klientų to nerašys, nes atrodo, kad tai kvietimas išeiti. Tai ne. Tai leidimas pirkti be baimės.

Jūsų agentūra čia turi įmontuotą pranašumą: jau atlikote penkių klausimų auditą, todėl žinote baimę. Įdėkite baimę į DUK. Jei jums reikia šablono, nuo ko pradėti, kainodaros puslapio konversijos vadovas yra šablonas.

Neleiskite klientui slėpti kainodaros. Puslapis 'susisiekite su mumis' yra siena. Perėjimui reikia skaičiaus, su kuriuo būtų galima palyginti. Jei kaina didelė, puslapyje turėtų būti paaiškinta, kas įtraukta ir kodėl verta. Jei kaina maža, palyginkite ją su esamos padėties kaina. Projektų valdymo įrankiui esama padėtis yra trys atskiri įrankiai: užduočių programa, pokalbių programa ir skaičiuoklė. Perėjimo kaina neatrodo didelė, kai palyginate su visų trijų mėnesine kaina. Padarykite šį palyginimą aiškų puslapyje.

Rašydami kainodaros DUK, nenaudokite tiekėjo kalbos. Sakykite 'jūs' ir 'jūsų duomenys.' Kainodaros puslapis, kuriame nuolat vartojama 'mes siūlome, mes teikiame', atrodo kaip įmonės brošiūra. Apverskite į 'jūs galite, jūsų komanda.' Tai perėjimas, vykstantis gramatikoje.

Kainodaros DUK galite išbandyti taip pat, kaip ir viską kita: perskaitykite garsiai. Jei nepažįstamasis kitoje stalo pusėje atsipalaiduotų, gerai. Jei jis iškeltų ranką prašydamas pardavėjo, pridėjote trintį.

Dokumentai, kurių nepaisote, užbaigia (arba žudo) sandorius

Štai kūrėja prie nešiojamojo kompiuterio. Ji vertina jūsų kliento API. Jos viršininkas paklausė: 'Ar galime su tuo integruotis?' Ji nori vieno dalyko: įrodymo, kad jos komanda nešvaistys savaitės. Ji nepradeda nuo nuorodų dokumentų. Ji pradeda nuo greitosios pradžios.

Tokios įmonės kaip Stripe, GitHub ir Twilio nustato API dokumentų standartą. Paslaptis ne ta, kad jos gražiai dokumentuoja kiekvieną galinį tašką. O ta, kad pirmasis paleidimas trunka penkias minutes. Jos rodo mažą rezultatą, kuris atrodo kaip sėkmė. Tai kūrėjo perėjimo trigertis: akimirksniu pasiekiama konkreti pažanga.

Jūsų kliento API dokumentai yra pirmasis puslapis, kurį techninis pirkėjas perskaito po pagrindinio puslapio. Jei jis skaitomas kaip telefonų knyga, sandoris tyliai miršta. Dokumentai yra rinkodaros turtas, o ne techninė prievolė. Taigi darykite taip:

Pirmiausia įdėkite greitąją pradžią. Pavyzdžio laikas. Jūsų klientas kuria dokumentų automatizavimo API. Nuoroda yra tankus turinys, tęsiantis tūkstančius eilučių. Kūrėjas atvyksta, pamato 'Autentifikavimas' ir pasijunta priblokštas.

Restruktūrizuokite dokumentų viršų:

1. Parašykite trijų sakinių aprašymą aiškia anglų kalba. 'Siųskite sutartį, gaukite pasirašytą kopiją atgal. Ši API paverčia šablonus ir duomenis pasirašytais PDF.'
2. Įklijuokite kopijuojamą kodo pavyzdį, kuris iškviečia smėlio dėžės galinį tašką. Parodykite pirmąjį atsakymo JSON, kuris įrodo sėkmę.
3. Pridėkite vieną naudojimo atvejį: 'Sąskaitos faktūros, kurios susidaro pačios' – ir susiekite su konkrečiais galiniais taškais.

Pilną nuorodą perkėlimas žemiau. Kūrėjas, kuris nukopijuoja pirmąjį fragmentą, tampa vidiniu čempionu. Čempionas prašo saugumo peržiūros, o ne atmetimo. Jūsų klientas laimi prieš pardavimo skambutį. API dokumentų vadovas aprašo tą patį procesą.

Naudojimo atvejis yra pažadas su maršrutu. Dokumentų automatizavimo klientui parašykite: 'Sąskaitos faktūros, kurios susidaro pačios: nusiųskite užsakymo numerį ir gaukite suformatuotą sąskaitą faktūrą, eilutes ir PDF vienu iškvietimu.' Tai ne dokumentų puslapis; tai pardavimo puslapis, kuriame yra kodo.

Įdėkite įterptą API raktą smėlio dėžei. Kai tik kūrėjas gali įklijuoti ir pamatyti sėkmę, perėjimas tampa realus. Jokio pardavimo skambučio nereikia.

Dokumentų puslapis taip pat maitina SEO. Kūrėjai ieško tikslių klaidų pranešimų ir integracijų pavadinimų. Rašykite puslapius tiems užklausimams: pastraipą kiekvienam klaidos kodui, puslapį kiekvienai integracijai. Taip dokumentai tampa kanalu.

Naudokite nuolatinę šoninę juostą su mygtuku 'Išbandyti dabar.' Pridėkite paieškos juostą, kuri indeksuoja kodo pavyzdžius. Kuo sklandesnė paieška, tuo kompetentingesnė atrodo įmonė. Ir nepamirškite trumpo vaizdo įrašo, trumpesnio nei 90 sekundžių, kuriame rodomas veikiantis pavyzdys, o ne įmonės apžvalga.

DUK nėra palaikymo turinys. Tai paskutinės kliūties konversija

'Niekas neskaito DUK' – taip išgirsite, kol neprisiminsite, kas skaito: pirkėjas ramiame kambaryje, nedrįsdamas užduoti klausimo. DUK yra puslapis, kuriame sandoriai užbaigiami privačiai. Taip į jį ir žiūrėkite.

HubSpot, Slack ir Zendesk tai daro teisingai. Jų DUK ir pagalbos skyriai yra organizuoti, ieškomi ir glausti. Ta struktūra ir yra esmė. Ji signalizuoja kompetenciją. Ieškomas DUK verčia pirkėją manyti: šie žmonės apgalvojo mano problemą.

Štai pigiausias patobulinimas, kurį galite padaryti bet kurio kliento svetainei šiandien: pertvarkykite esamą DUK į keturis pirkimo etapo segmentus: Pradžia, Kainodara ir atsiskaitymai, Saugumas ir atitiktis, Perėjimas ir migracija. Tada perrašykite po vieną atsakymą kiekvienam segmentui.

Padarykime perėjimo segmentą. Dabartinis atsakymas į klausimą 'Ar sunku migruoti?' sako: 'Mūsų importavimo įrankis palaiko CSV ir API.' Tai funkcijų sąrašas. Perrašykite jį kaip pažadą su žingsnių sąrašu:

'Mes importuosime jūsų duomenis už jus. Atsiųskite CSV, mes atliksime bandomąjį paleidimą, jūs patikrinsite pavyzdį, o mes perjungsime per 30 minučių langą. Jei kas nors atrodys ne taip, akimirksniu grįšime atgal.'

Dabar palyginkite du atsakymus. Kuris užbaigia sandorį? Pirmasis aprašo mechanizmą; antrasis aprašo saugų procesą. Tai ta pati struktūra kaip funkcijų puslapyje: nauda plius įrodymas.

Eikite toliau: ištraukite kiekvieną klausimą, į kurį palaikymas atsako du kartus per savaitę, ir parašykite atsakymą prieš atsirandant bilietui. Tai nesibaigiantis nukreipimo puslapių turinio šaltinis. Kai DUK nustoja būti sąvartynu ir tampa įtikinėjimo įrankiu, visa istorija išlieka vieninga. Tai dalis „iš vidaus į išorę“ metodo, kurį naudojate viskam kitam.

Organizuokite galvodami apie paiešką. Ieškomas DUK, kuris atsakymą randa vienu klavišo paspaudimu, atrodo kaip produkto funkcija. Būtent tokį kompetencijos signalą ir norite perduoti.

Neverskite pirkėjų atidaryti atskiro pagalbos centro. Įdėkite DUK į puslapį, kuriame iškilo klausimas. Jei kainodaros klausimas atsiranda kainodaros puslapyje, atsakykite ten. Jei saugumo klausimas atsiranda kainodaros puslapyje, taip pat atsakykite ten. Atsakymas turi būti ten, kur kyla abejonė.

Saugumo segmentas yra ten, kur IT nusprendžia blokuoti įrankį. Atsakykite į tokius klausimus kaip 'Kur saugomi duomenys?' konkrečiai. Jei sakote 'ES', pasakykite regioną. Jei sakote 'šifruota ramybės būsenoje', įvardykite standartą. Trumpas atsakymas stipresnis nei baltosios knygos nuoroda.

Kiekvienas DUK atsakymas turėtų būti kuo trumpesnis ir baigtis kitos veiklos žingsniu: 'Užsiregistruokite su smėlio dėžės paskyra' arba 'Kreipkitės į palaikymą.' Atsakymas be kito žingsnio yra aklavietė.

Nėra laiko? Kurkite skeletą, o ne snaigę

Paskutinis prieštaravimas – tas, kurį tikriausiai jaučiate dabar: 'Bet aš turiu keturis klientus ir terminą pirmadienį.' Teisingai. Laikykite kiekvieną projektą unikaliu portretu ir visada skubėsite. Vietoj to sukurkite vieną daugkartinio naudojimo rezultatą: „Switch Memo“. Jį užpildyti užtrunka 90 minučių, ir jame apibrėžiamas kiekvienas puslapis.

Switch Memo — vienas puslapis, šešios eilutės:

1. Vartotojo / pirkėjo perskyrimas: kas ateina, kas moka.
2. Dabartinis elgesys: ką jie daro šiandien vietoj to.
3. Vienintelis skausmas: vienas sakinys, erzinantis dalykas.
4. Baimė: ko jie nerimauja, kad suges perėjus.
5. Greitas laimėjimas: pirmasis matomas patobulėjimas po perėjimo.
6. Įrodymas: logotipai, rezultatai ar saugumo pozicijos, kurios pašalina baimę.

Atsineškite tai į pirmąjį atradimo skambutį. Pildykite jį uždavinėdami penkis klausimus. Kai grįšite prie savo stalo, jau turėsite žinutės sistemą. Pagrindinio puslapio antraštė yra greitas laimėjimas. Funkcijų puslapio įžanga yra skausmas. Kainodaros lentelės vidurinė kolonėlė yra pirkėjas. DUK yra baimių sąrašas. API dokumentų greitoji pradžia yra greitas laimėjimas kūrėjams.

Šis skeletas nėra tas pats, kas padaryti kiekvieną svetainę identišką. Jis daro kiekvieną svetainę įtikinamą tuo pačiu būdu. Vis tiek kuriate dizainą pagal kiekvieno kliento balsą, bet nustojate nepakankamai išdirbti žinutę. Jei žinutė jau nuspręsta, galite per dieną sukurti kiekvieno puslapio pirmąjį juodraštį. Tikrasis agentūros produktas yra procesas, o ne pikselis.

Štai poslinkis: jūs nebepersidizainuojate svetainių. Jūs jas perpozicionuojate. Ir kadangi perėjimo sistema veikia įvairiose pramonės šakose, galite imti mokestį už strategiją, ją pristatyti pakartojama forma ir perduoti turtą, kuris iš tikrųjų konvertuoja. Jūsų kitas pradinis susitikimas turėtų prasidėti penkių klausimų auditu, o ne nuotaikų lenta.

Naudokite memorandumą, kad anksti nustatytumėte kliento lūkesčius. Įkūrėjas mato, kad svetainė nėra meno projektas; tai įtikinėjimo dokumentas. Tai apsaugo nuo 'tiesiog padaryk, kad išsiskirtų' atsiliepimų ir nukreipia pokalbį į rezultatus. Pasidalykite memorandumu su kliento vidine rinkodaros komanda, kad jie vėliau galėtų rašyti naujus puslapius neišradinėdami žinutės iš naujo.

Kai pristatote svetainę, pradėkite nuo Switch Memo, o ne nuo dizaino. Klientai strategiją patvirtina greičiau nei estetiką. Sulauksite mažiau prašymų 'ar galime padidinti logotipą', nes suteikėte jiems pagrindą vertinti puslapį pagal žinutę.

Perėjimas yra strategija. Visa kita – dekoracija.

Išsineškite vieną dalyką: neužsakykite kito pertvarkymo, kol neatsakėte į perėjimo klausimą. Dauguma SaaS svetainių žlunga, nes lankytojai niekada neranda priežasties atsisakyti savo dabartinės darbo eigos. Svetainė nepralaimi todėl, kad logotipas per mažas arba gradientas pasenęs.

Jūsų kitas pradinis skambutis turėtų būti penkių klausimų auditas. Jei įkūrėjas negali suformuluoti perėjimo, prispauskite jį. Jei galite jį suformuluoti, tada kiekvienas puslapis turi užduotį: funkcijų puslapiai jį įrodo, kainodaros puslapiai pagrindžia, DUK puslapiai gina, o API dokumentai demonstruoja. Pristatysite geresnį produktą greičiau. Ir turėsite sistemą, kurią galėsite naudoti kiekvienam klientui amžinai.

Svetainė, sukurta pagal perėjimo sistemą, laikui bėgant taip pat gerėja. Dabar turite hipotezę – trigerį – ir galite ją išbandyti šilumos žemėlapiuose, sesijų įrašuose ar A/B testuose. Sistema paverčia pertvarkymą iš įvykio eksperimentu.

Jums nereikia 40 puslapių strategijos dokumento. Jums reikia šešių eilučių ir noro pasakyti 'ne' puslapiams, kurie netarnauja perėjimui. Tas aiškumas ir yra tai, už ką klientai jums moka.

Nustokite pardavinėti funkcijas. Parduokite perėjimą. Tai ir yra visa strategija.