Pārtrauciet pārdot funkcijas, pārdodiet pāreju

Kopsavilkums

Jūsu klienta SaaS vietne necieš neveiksmi, jo tā izskatās slikti. Tā necieš neveiksmi, jo tā nekad neatbild uz vienu svarīgu jautājumu: kāpēc man vajadzētu pārslēgties? Aģentūras darbā jūs nevarat atjaunot unikālu pārliecināšanas modeli katram produktam. Tā vietā izmantojiet to pašu piecu jautājumu auditu, lai atrastu pārslēgšanas trigeri jebkuram SaaS. Pēc tam izmantojiet šo trigeri visās lapās: funkcijas kļūst par pierādījumu, cenas kļūst par skaidrību, FAQ kļūst par iebildumu graujošu, un API dokumentācija kļūst par izstrādātāja pirmo uzvaru. Šis ietvars pārvērš vienreizēju pārveidi par atkārtojamu procesu. Rezultāts: ātrāka piegāde, mazāk pārskatījumu un lapas, kas patiešām pārvērš.

Jūsu klientam nav dizaina problēmas. Tam ir pārslēgšanās problēma. Pircējam jau ir rīks, darba plūsma un komanda, kas ienīst pārmaiņas. Viņi nesalīdzina jūsu klienta funkcijas ar tukšu lapu. Viņi salīdzina palikšanas sāpes ar aiziešanas sāpēm. Vietnes uzdevums nav uzskaitīt, ko produkts dara. Tas ir panākt, lai pāreja izskatītos vieglāka un vērtīgāka nekā pašreizējais stāvoklis. Ja tā to nedara, vietne ir tapetes.

Strādājot aģentūrā, jūs to izjūtat asi. Jūs uzņemat SaaS klientu, dibinātājs saka 'mums ir nepieciešama moderna vietne', un visi pieņem, ka risinājums ir vizuāls. Tas tā nav. Jūs varat uzvilkt godalgotu dizainu uz nepareizā vēstījuma, un tas pārvērsīs tieši tāpat kā vecā vietne. Bet atrodiet pārslēgšanas trigeri, un vēstījums paveic galveno darbu. Jums tas vienkārši jāatrod ātri — katram klientam, katru ceturksni, nozarēs, kuras jūs vēl nepazīstat. Tāpēc jums ir nepieciešams ietvars, ko varat izmantot jau pirmajā dienā, bez trīs mēnešu izpētes fāzes.

Padomājiet par to, ko ietver pāreja: datu eksportēšana, komandas apmācība, jauna lietotāja interfeisa apgūšana, ieradumu maiņa. Jūsu klienta vietnei šī secība jāpadara neizbēgama. Funkciju saraksts to nevar izdarīt. Skaidrs attēls par dzīvi pēc pārejas var. Šis attēls ir vēstījums. Viss pārējais vietnē to atbalsta.

Šeit ir ietvars: definējiet pāreju. Pēc tam piespiediet katru lapu to aizstāvēt.

Iebildums	Ko tas īstenībā aizsargā	Ko darīt tā vietā
'Katrs klients ir atšķirīgs.'	Jūsu bailes no veidnēm	Atrodiet pārslēgšanas trigeri ar piecu jautājumu auditu
'Mums vajag vairāk ekrānuzņēmumu.'	Bailes no tukšām sadaļām	Aizstājiet produkta attēlus ar pierādījumiem
'Cenas ir svētas.'	Finanšu direktora nemiers	Izmantojiet skaidrību, lai mazinātu cenu šoku
'API dokumentācija ir izstrādātāju problēma.'	Izstrādātāju komandas vārtsargu loma	Uztveriet dokumentāciju kā pārliecinošu līdzekli
'FAQ ir garlaicīgs.'	Atbalsta pārslogotā iesūtne	Izmantojiet FAQ, lai kliedētu pēdējā brīža šaubas
'Mums nav laika pielāgot.'	Perfekcionisms attiecībā uz piegādi	Izveidojiet skeletu, nevis sniegpārsliņu

Izmantojiet šo tabulu kā kontrolsarakstu pirmajā sapulcē. Jebkurš iebildums tajā nav īsts šķērslis. Tas ir lūgums pēc cita ietvara.

'Katrs klients ir atšķirīgs' ir patiess — un nebūtisks

Lūk, pārmaiņa: produkts ir atšķirīgs, tirgus ir atšķirīgs, pircēja uzvedība nav. Pircēji vēlas trīs lietas: 'Vai es to saprotu?' 'Vai es tam varu uzticēties?' 'Vai pāreja ir lētāka nekā palikšana?' Tas ir universāli. Tāpēc nestandartizējiet dizainu. Standartizējiet iztaujāšanu.

Sāciet ar piecu jautājumu auditu. Veiciet to pirmajā iepazīšanās zvanā. Tas aizņem divdesmit minūtes un darbojas jebkuram SaaS.

• Kas ir lietotājs un kas ir pircējs? (Tie reti ir viena un tā pati persona.)
• Ko viņi šodien dara tā vietā, lai izmantotu jūsu klienta produktu?
• Kādas ir vienīgās kaitinošās sāpes pašreizējā darba plūsmā?
• No kā viņi baidās, ka tas sabojāsies, ja viņi pārslēgsies?
• Kāds ir ātrākais 'ieguvums', ko viņi iegūtu uzreiz pēc pārejas?

Izstaigāsim divus klientus, lai redzētu, kā tas darbojas.

Pirmkārt, projektu pārvaldības rīks. Lietotājs ir komandas vadītājs, pircējs ir arī komandas vadītājs. Tas dara to pašu, ko esošais rīks. Sāpes? Neviens nezina, kam pieder nākamais uzdevums. Bailes? Migrēt simtiem projektu un zaudēt visu statusu. Ātrais ieguvums? Informācijas panelis, kas uzreiz parāda uzdevumu īpašnieku. Trigeris: 'Nekad vairs nevajag dzīties pakaļ uzdevuma īpašniekam.' Tas ir virsraksts.

Otrkārt, nekustamo īpašumu potenciālo klientu izsekotājs. Lietotājs ir aģents, pircējs ir mākleris. Sāpes? Dublēti potenciālie klienti parādās trīs vietās, un labie paliek auksti. Bailes? Aģenti nereģistrēs datus. Ātrais ieguvums? Automātiska datu papildināšana no MLS sarakstiem, lai aģenti visu izdarītu ar diviem klikšķiem. Trigeris: 'Nekad nezaudējiet potenciālo klientu divreiz.'

Tie paši pieci jautājumi. Divi dažādi produkti. Tagad jums ir galvenais vēstījums mājaslapai, funkciju sadaļas pirmais rindkopa un e-pasta sērijas tēmas rindiņa. Pārslēgšanas trigeris ir atjaunojams resurss: katra lapa, katra sadaļa, katrs apakšvirsraksts var to aizstāvēt. Tā ir jūsu starta līnija.

Tas pats trigeris sniedz arī vietnes karti. Lapa, kas izskaidro trigeri, ir mājaslapa. Lapa, kas pierāda trigeri, ir funkciju sadaļa. Lapa, kas noņem bailes, ir FAQ. Lapa, kas parāda pārejas izmaksas, ir cenu lapa. Pēkšņi visai vietnei ir viens stāstījums, nevis lapu pa lapai komiteja.

Varat arī veikt konkurentu izpēti, uzdodot tos pašus piecus jautājumus par konkurenta vietni. Tas ir lēts veids, kā pirmajā zvanā parādīt vērtību. Jūs atradīsiet konkurenta trūkstošo pārslēgšanas trigeri, un jūsu klients kļūst par acīmredzamo alternatīvu.

Ko darīt, ja produkts ir patīkama papildinājums, nevis sāpju mazinātājs? Tad pārslēgšanas trigeris ir lielāks: ietaupītā nauda, izvairīšanās no riska vai iegūtais statuss. Atbilstības rīkam trigeris ir 'izvairieties no soda.' Drošības rīkam trigeris ir 'nokārtojiet auditu.' Sociālo mediju plānotājam trigeris ir 'atgūstiet divas stundas katru nedēļu.' Audits to joprojām atrod. Daži trigeri vienkārši ir mazāk emocionāli.

Ekrānuzņēmumi ir viszemākās vērtības pierādījums lapā

Paņemiet vientuļāko rindiņu jūsu klienta funkciju tabulā: 'OAuth 2.0 atbalsts.' Kādas emocijas tas izraisa? Nekādas. Tas ir kontrolsarakssta vienums izstrādātājam, kurš nav pircējs. Tomēr, kad jūs lūdzat klientam viņu funkciju lapu, viņi jums iedod veselu sienu šādu rindiņu. Aizpildiet lapu ar ekrānuzņēmumiem, un jūs darāt kaut ko vēl izplatītāku: rādāt produktu, nevis rezultātu.

Ekrānuzņēmumiem ir vieta. Labs produkta darbības GIF ir pierādījums. Bet lielākā daļa ekrānuzņēmumu ir produkta portreti. Pircējiem ir nepieciešams stāsts par 'pirms un pēc'. Funkciju sadaļa ir vislabākā vieta, kur to pastāstīt. Izmantojiet formulu Funkcija-Ieguvums-Pierādījums (FBP). Nosauciet funkciju, savienojiet to ar ieguvumu, pēc tam pierādiet to ar faktu, procesu vai nelielu demonstrāciju. Bez izdomātiem skaitļiem — izmantojiet novērojamus rezultātus, piemēram, 'darbojas ar Google Workspace' vai 'iestatīšana aizņem mazāk par minūti.'

Sākotnējais bloks no klienta:

• OAuth 2.0 atbalsts
• Uz lomām balstīta piekļuves kontrole (RBAC)
• SCIM nodrošināšana

Trīs punkti ar piegādātāja žargonu. Tagad izlaidiet katru caur FBP.

Funkcija: OAuth 2.0 atbalsts.
Ieguvums: Viens pieteikšanās visai komandai. Vairs nav IT biļešu.
Pierādījums: Darbojas ar Google Workspace un Microsoft Entra.

Funkcija: Uz lomām balstīta piekļuves kontrole.
Ieguvums: Sniedziet administratoriem, redaktoriem un skatītājiem tieši tās atļaujas, kas viņiem nepieciešamas.
Pierādījums: Piešķiriet skatīšanās tiesības darbuzņēmējam mazāk nekā minūtē.

Funkcija: SCIM nodrošināšana.
Ieguvums: Automātiski pievienojiet un noņemiet lietotājus no jūsu HR sistēmas.
Pierādījums: Sinhronizējas ar Okta un Rippling.

Funkcijas nemainījās. Mainījās pārliecināšana. Jūsu klients teiks: 'Bet korporatīvie pircēji sagaida, ka redzēs vārdus OAuth un SCIM.' Taisnība. Pievienojiet tehnisku apakšrindiņu izstrādātājiem, kuri pārbauda lapu. Bet ievietojiet šo rindiņu ar mazu burtu zem ieguvuma. Pirmā auditorija ir pircējs, kurš izlemj, vai rezervēt sapulci. Otrā auditorija ir izstrādātājs, kurš atzīmē izvēles rūtiņas. Veidojiet savu funkciju demonstrāciju ap pierādījumu, nevis produkta attēliem, un jūs pārtrauksiet veidot aizpildījumu.

Kad izmantojat ekrānuzņēmumu, lieciet tam parādīt rezultātu, nevis ekrānu. Projektu pārvaldības klientam ekrānuzņēmums ar tāfeli, kur katram uzdevumam ir skaidrs īpašnieks, ir pierādījums. Nekustamo īpašumu klientam ekrānuzņēmums ar vienu tīru kontaktpersonas ierakstu ar automātiski papildinātiem datiem ir pierādījums. Ekrānuzņēmums ar informācijas paneļa tukšo stāvokli ir dizaina līdzeklis, nevis pārliecināšanas līdzeklis.

Ievietojiet tehniskās specifikācijas sakļautā sadaļā vai izstrādātāju resursu cilnē. Lietotājs redz ieguvumu; izstrādātājs var iedziļināties. Tas uztur lapu tīru un auditoru apmierinātu.

Labs tests jebkuram funkciju apgalvojumam: vai pircējs to atkārtotu savam priekšniekam? 'Viens pieteikšanās' ir atkārtojams. 'OAuth 2.0 atbalsts' nav. Ja jūsu klienta funkciju lapa neiztur ūdens dzesētāja testu, tā vēl nav pārliecinoša.

Cenu lapas ir mīnu lauks. Tieši tāpēc jums tās vajadzētu skart

Jūs dzirdēsiet: 'Neaiztieciet cenas. Tās ir tādas jau gadiem.' Patiesībā viņi saka 'mēs baidāmies.' Mulsinoša cenu lapa neaizsargā ieņēmumus; tā tos nopludina. Jūsu uzdevums ir pārvērst lapu no izmaksu sarunām par skaidrības paziņojumu.

Sāciet, uzskaitot jautājumus, uz kuriem jūsu pārdošanas komanda atbild katru nedēļu. Pierakstiet tos burtiski. 'Vai jūs iekasējat maksu par lietotāju?' 'Kas notiek, ja es pazemināšu plānu?' 'Vai ir uzstādīšanas maksa?' 'Vai es varu izmēģināt bez kredītkartes?' 'Kāda ir jūsu atgriešanas politika?' Ievietojiet tos lapā. Pircējam nevajadzētu rezervēt zvanu, lai uzzinātu, vai izmēģinājumam ir nepieciešama kredītkarte.

Pēc tam ņemiet klienta trīs plānus: Pamata, Pro, Uzņēmuma. Pārdēvējiet tos atbilstoši klienta situācijai. Ko katrs plāns faktiski dod cilvēkam? Solo, Komanda, Organizācija. Vai arī Creator, Studio, Enterprise. Nosaukums nav dekorācija; tas ir pirmais skaidrības brīdis.

Lūk, konkrēts piemērs ar pārdēvētu plānu tabulu:

Vecais plāns	Jaunais plāns	Solījums
Pamata	Solo	Vienai personai, kurai nepieciešama vienkārša darba plūsma
Pro	Komanda	Komandai, kurai nepieciešama sadarbība un informācijas paneļi
Uzņēmuma	Organizācija	Uzņēmumam, kuram nepieciešama drošība, SSO un atbalsts

Pēc tam izveidojiet salīdzināšanas tabulu. Pārtrauciet ieradumu iebāzt katru funkciju katrā rindā. Sāciet katru rindu ar lietotāja jautājumu, uz kuru tā atbild. 'Cik lietotāju?' 'Ko mēs varam uzaicināt?' 'Kādas drošības funkcijas mēs saņemam?' Pircējs lasa tabulu, lai meklētu 'vai es iederos.' Padariet šo meklēšanu vieglu.

Visbeidzot, pievienojiet cenu FAQ. Atbildiet uz nepatīkamo jautājumu: 'Kas notiek ar maniem datiem, ja es aiziešu?' Uzrakstiet atbildi kā cilvēks: 'Eksportējiet visu ar vienu klikšķi pirms abonementa beigām. Bez maksas, bez bloķēšanas.' Tas ir pārejas uzticības lauzējs. Lielākā daļa klientu to neuzrakstīs, jo tas šķiet kā uzaicinājums aiziet. Tā nav. Tā ir atļauja pirkt bez bailēm.

Jūsu aģentūrai šeit ir iebūvēta priekšrocība: jūs jau esat veikuši piecu jautājumu auditu, tāpēc jūs zināt bailes. Ievietojiet bailes FAQ. Ja jums ir nepieciešama veidne, ar ko sākt, cenu lapas konversijas ceļvedis ir veidne.

Nedodiet klientam iespēju slēpt cenas. 'Sazinieties ar mums' lapa ir siena. Pārejai ir nepieciešams skaitlis, ar ko salīdzināt. Ja cena ir augsta, lapai jāpaskaidro, kas ir iekļauts un kāpēc tas ir tā vērts. Ja cena ir zema, noenkurojiet to pret pašreizējā stāvokļa izmaksām. Projektu pārvaldības rīkam pašreizējais stāvoklis ir trīs atsevišķi rīki: uzdevumu lietotne, tērzēšanas lietotne un izklājlapa. Pārejas cena neizskatās augsta, ja to salīdzina ar visu trīs ikmēneša izmaksām. Padariet šo salīdzinājumu skaidru lapā.

Rakstot cenu FAQ, neizmantojiet piegādātāja valodu. Sakiet 'jūs' un 'jūsu dati.' Cenu lapa, kurā visu laiku tiek lietots 'mēs piedāvājam, mēs nodrošinām', šķiet kā uzņēmuma brošūra. Apgrieziet to uz 'jūs varat, jūsu komanda.' Tas ir pārejas notikums gramatikā.

Jūs varat pārbaudīt cenu FAQ tāpat kā visu pārējo: izlasiet to skaļi. Ja svešinieks galda otrā pusē atslābinātos, tas ir labi. Ja viņš paceltu roku, lai piezvanītu pārdevējam, jūs esat pievienojuši berzi.

Dokumentācija, ko ignorējat, slēdz (vai nogalina) darījumus

Te ir izstrādātāja pie klēpjdatora. Viņa vērtē jūsu klienta API. Viņas priekšnieks jautāja: 'Vai mēs varam ar to integrēties?' Viņa vēlas vienu lietu: pierādījumu, ka viņas komanda netērēs nedēļu. Viņa nesāk ar atsauces dokumentāciju. Viņa sāk ar ātrās darbības sākumu.

Tādi uzņēmumi kā Stripe, GitHub un Twilio nosaka API dokumentācijas standartu. Noslēpums nav tajā, ka viņi skaisti dokumentē katru galapunktu. Tas ir tajā, ka viņi panāk, lai pirmais izmēģinājums aizņemtu piecas minūtes. Viņi parāda mazu rezultātu, kas izskatās pēc panākuma. Tas ir pārslēgšanas trigeris izstrādātājam: tūlītējs, konkrēts progress.

Jūsu klienta API dokumentācija ir pirmā lapa, ko tehniskais pircējs lasa pēc mājaslapas. Ja tā lasās kā telefongrāmata, darījums klusi mirst. Dokumentācija ir mārketinga līdzeklis, nevis tehnisks pienākums. Tāpēc rīkojieties šādi:

Ievietojiet ātrās darbības sākumu pirms visa cita. Ir piemēra laiks. Jūsu klients veido dokumentu automatizācijas API. Atsauce ir blīvs satura rādītājs, kas stiepjas tūkstošiem rindiņu. Izstrādātājs nonāk lapā, ierauga 'Autentifikācija' un kļūst nevēlīgs.

Pārstrukturējiet dokumentācijas augšdaļu:

1. Uzrakstiet trīs teikumu aprakstu vienkāršā angļu valodā. 'Nosūtiet līgumu, saņemiet atpakaļ izpildītu kopiju. Šī API pārvērš veidnes un datus par parakstītiem PDF.'
2. Ielīmējiet kopēšanai gatavu koda paraugu, kas izsauc smilškastes galapunktu. Parādiet pirmo atbildes JSON, kas pierāda panākumu.
3. Pievienojiet vienu lietošanas gadījumu, 'Rēķini, kas paši saliekas,' un saistiet iesaistītos galapunktus.

Pārvietojiet pilno atsauci zemāk. Izstrādātājs, kurš nokopē pirmo fragmentu, kļūst par iekšējo čempionu. Čempions pieprasa drošības pārskatīšanu, nevis noraidījumu. Jūsu klients iegūst darījumu pirms pārdošanas zvana. API dokumentācijas ceļvedis apraksta to pašu procesu.

Lietošanas gadījums ir solījums ar maršrutu. Dokumentu automatizācijas klientam uzrakstiet: 'Rēķini, kas paši saliekas: nosūtiet pirkuma pasūtījuma numuru un saņemiet formatētu rēķinu, rindas vienumus un PDF vienā zvanā.' Tā nav dokumentācijas lapa; tā ir pārdošanas lapa, kurā gadās būt kodam.

Iekļaujiet iegultu API atslēgu smilškastei. Brīdī, kad izstrādātājs var ielīmēt un redzēt panākumu, pāreja kļūst reāla. Nav nepieciešams pārdošanas zvans.

Dokumentācijas lapa baro arī SEO. Izstrādātāji meklē precīzus kļūdu ziņojumus un integrāciju nosaukumus. Rakstiet lapas šiem vaicājumiem: rindkopu katram kļūdas kodam, lapu katrai integrācijai. Tā dokumentācija kļūst par kanālu.

Izmantojiet pastāvīgu sānjoslu ar pogu 'izmēģināt tagad'. Pievienojiet meklēšanas joslu, kas indeksē koda piemērus. Jo vienmērīgāka meklēšana, jo kompetentāks izskatās uzņēmums. Un neaizmirstiet par īsu video, kas īsāks par 90 sekundēm, kurā redzams strādājošs piemērs, nevis uzņēmuma pārskats.

FAQ nav atbalsta saturs. Tā ir pēdējā šķēršļa konversija

'Neviens nelasa FAQ' — to jūs dzirdēsiet, līdz atcerēsieties, kurš to dara: pircējs klusā telpā, kurš vilcinās uzdot jautājumu. FAQ ir lapa, kurā darījumi noslēdzas privāti. Uztveriet to tā.

HubSpot, Slack un Zendesk to dara pareizi. Viņu FAQ un palīdzības sadaļas ir organizētas, meklējamas un kodolīgas. Šī struktūra ir būtība. Tā signalizē kompetenci. Meklējams FAQ liek pircējam domāt: šie cilvēki ir domājuši par manu problēmu.

Šeit ir lētākais uzlabojums, ko šodien varat veikt jebkura klienta vietnē: pārorganizējiet esošo FAQ četros pirkšanas posmu segmentos: Darba sākšana, Cenas un norēķini, Drošība un atbilstība, Pāreja un migrācija. Pēc tam pārrakstiet vienu atbildi katrā segmentā.

Darīsim pārejas segmentu. Pašreizējā atbilde uz 'Cik grūta ir migrācija?' saka: 'Mūsu importa rīks atbalsta CSV un API.' Tas ir funkciju saraksts. Pārrakstiet to kā solījumu plus soļu sarakstu:

'Mēs importēsim jūsu datus jūsu vietā. Nosūtiet CSV, mēs veicam testa importu, jūs pārbaudāt paraugu, un mēs pārslēdzamies 30 minūšu logā. Ja kaut kas izskatās nepareizi, mēs uzreiz atgriežamies.'

Tagad salīdziniet abas atbildes. Kura noslēdz darījumu? Pirmā apraksta mehānismu; otrā apraksta drošu procesu. Tā pati struktūra kā funkciju lapā: ieguvums plus pierādījums.

Ejiet tālāk: paņemiet katru jautājumu, uz kuru atbalsts atbild divas reizes nedēļā, un uzrakstiet atbildi, pirms biļete tiek izveidota. Tas ir nebeidzams galvenās lapas satura avots. Kad FAQ pārstāj būt izgāztuve un sāk būt pārliecināšanas rīks, viss stāsts paliek vienots. Tā ir daļa no iekšējās pieejas, ko izmantojat visam pārējam.

Organizējiet, domājot par meklēšanu. Meklējams FAQ, kas atrod atbildi ar vienu taustiņsitienu, šķiet kā produkta funkcija. Tas ir tieši tas kompetences signāls, ko vēlaties.

Nepiespiediet pircējus atvērt atsevišķu palīdzības centru. Ievietojiet FAQ lapā, kas izraisīja jautājumu. Ja cenu jautājums parādās cenu lapā, atbildiet uz to tur. Ja drošības jautājums parādās cenu lapā, atbildiet arī tur. Atbilde pieder šaubu brīdī.

Drošības segments ir vieta, kur IT izlemj bloķēt rīku. Atbildiet uz tādiem jautājumiem kā 'Kur tiek glabāti dati?' ar konkrētību. Ja sakāt 'ES', nosauciet reģionu. Ja sakāt 'šifrēts miera stāvoklī', nosauciet standartu. Kodolīga atbilde ir spēcīgāka par baltās grāmatas saiti.

Katrai FAQ atbildei jābūt pēc iespējas īsākai un jābeidzas ar nākamo soli: 'Reģistrējieties ar smilškastes kontu' vai 'Sazinieties ar atbalstu.' Atbilde bez nākamā soļa ir strupceļš.

Nav laika? Izveidojiet skeletu, nevis sniegpārsliņu

Pēdējais iebildums ir tas, ko jūs, iespējams, jūtat tieši tagad: 'Bet man ir četri klienti un termiņš pirmdien.' Taisnība. Uztveriet katru projektu kā pielāgotu portretu, un jūs vienmēr steigsieties. Tā vietā izveidojiet vienu atkārtoti lietojamu rezultātu: Pārejas piezīmi. Tās aizpildīšana aizņem 90 minūtes, un tā iezīmē katru lapu.

Pārejas piezīme — viena lapa, sešas rindiņas:

1. Lietotāja / pircēja dalījums: kurš parādās, kurš maksā.
2. Pašreizējā uzvedība: ko viņi šodien dara tā vietā.
3. Vienīgās sāpes: viens teikums, kaitinājums.
4. Bailes: par ko viņi uztraucas, ka tas sabojāsies pārejas laikā.
5. Ātrais ieguvums: pirmais redzamais uzlabojums pēc pārejas.
6. Pierādījums: logotipi, rezultāti vai drošības pozīcijas, kas noņem bailes.

Paņemiet to līdzi pirmajā iepazīšanās zvanā. Aizpildiet to, uzdodot piecus jautājumus. Kad esat atpakaļ pie sava galda, jums ir vēstījuma ietvars. Mājaslapas virsraksts ir ātrais ieguvums. Funkciju lapas ievads ir sāpes. Cenu tabulas vidējā kolonna ir pircējs. FAQ ir baiļu saraksts. API dokumentācijas ātrās darbības sākums ir ātrais ieguvums izstrādātājiem.

Šis skelets nepadara katru vietni identisku. Tas padara katru vietni pārliecinošu vienādi. Jūs joprojām veidojat dizainu katra klienta balsij, bet pārtraucat nepietiekami izstrādāt vēstījumu. Ja vēstījums jau ir skaidrs, jūs varat izveidot katras lapas pirmo melnrakstu vienas dienas laikā. Aģentūras īstais produkts ir process, nevis pikselis.

Lūk, pārmaiņa: jūs vairs nepārveidojat vietnes. Jūs tās pozicionējat no jauna. Un tāpēc, ka pārejas ietvars darbojas visās nozarēs, jūs varat iekasēt maksu par stratēģiju, piegādāt to atkārtojamā formā un nodot līdzekļus, kas patiešām pārvērš. Jūsu nākamajai sākuma sapulcei jāsākas ar piecu jautājumu auditu, nevis ar noskaņojuma dēli.

Izmantojiet piezīmi, lai agri noteiktu klienta cerības. Dibinātājs redz, ka vietne nav mākslas projekts; tā ir pārliecināšanas dokumentācija. Tas novērš atsauksmi 'vienkārši padariet to uzkrītošu' un pagriež sarunu uz rezultātiem. Kopīgojiet piezīmi ar klienta iekšējo mārketinga komandu, lai viņi vēlāk varētu rakstīt jaunas lapas bez vēstījuma izgudrošanas no jauna.

Piedāvājot vietni, sāciet ar pārejas piezīmi, nevis dizainu. Klienti apstiprina stratēģiju ātrāk nekā estētiku. Jūs saņemsiet mazāk lūgumu 'vai mēs varam padarīt logotipu lielāku', jo esat devis viņiem iemeslu vērtēt lapu pēc vēstījuma.

Pāreja ir stratēģija. Viss pārējais ir dekorācija.

Paņemiet vienu lietu no šī: neuzsāciet vēl vienu pārveidi, kamēr neesat atbildējuši uz pārejas jautājumu. Lielākā daļa SaaS vietņu neizdodas, jo apmeklētāji nekad neatrod iemeslu atteikties no pašreizējās darba plūsmas. Vietne neizdodas tāpēc, ka logotips ir pārāk mazs vai gradients ir novecojis.

Jūsu nākamajam sākuma zvanam vajadzētu būt piecu jautājumu auditu. Ja dibinātājs nevar formulēt pāreju, piespiediet viņu. Ja jūs varat to formulēt, tad katrai lapai ir uzdevums: funkciju lapas to pierāda, cenu lapas to attaisno, FAQ lapas to aizstāv, un API dokumentācija to demonstrē. Jūs piegādāsiet labāku produktu ātrāk. Un jums būs ietvars, ko varat izmantot katram klientam, mūžīgi.

Vietne, kas veidota ap pāreju, laika gaitā kļūst labāka. Tagad jums ir hipotēze — trigeris — un jūs varat to pārbaudīt ar siltuma kartēm, sesiju ierakstiem vai A/B testiem. Ietvars pārvērš pārveidi no notikuma par eksperimentu.

Jums nav nepieciešams 40 lappušu stratēģijas dokuments. Jums ir nepieciešamas sešas rindiņas un gatavība pateikt nē lapām, kas nekalpo pārejai. Šī skaidrība ir tas, par ko klienti jums maksā.

Pārtrauciet pārdot funkcijas. Pārdodiet pāreju. Tā ir visa stratēģija.