Lõpeta funktsioonide müümine, müü üleminekut

Kokkuvõte

Teie kliendi SaaS-veebisait ei ebaõnnestu seetõttu, et see halvasti välja näeb. See ebaõnnestub, sest see ei vasta kunagi ühele olulisele küsimusele: miks peaksin ma üle minema? Agentuuritöös ei saa te iga toote jaoks unikaalset veenmismudelit üles ehitada. Selle asemel kasutage sama viieküsimuselist auditit, et leida igale SaaS-ile üleminekupäästik. Seejärel rakendage seda päästikut igal lehel: funktsioonid muutuvad tõestuseks, hinnad selguseks, KKK vastuväidete purustajaks ja API-dokumendid arendaja esimeseks võiduks. See raamistik muudab ühekordse ümberkujunduse korratavaks protsessiks. Tulemus: kiirem tarne, vähem parandusi ja lehed, mis tegelikult konverteerivad.

Teie kliendil pole disainiprobleemi. Tal on üleminekupobleem. Ostjal on juba tööriist, töövoog ja meeskond, kes vihkab muutusi. Nad ei võrdle teie kliendi funktsioone tühja lehega. Nad võrdlevad jäämise valu lahkumise valuga. Veebisaidi ülesanne ei ole loetleda, mida toode teeb. See on muuta üleminek lihtsamaks ja väärtuslikumaks kui status quo. Kui ta seda ei tee, on sait tapeet.

Agentuuris töötades tunnete seda teravalt. Võtate SaaS-kliendi, asutaja ütleb: „me vajame kaasaegset veebisaiti," ja kõik eeldavad, et lahendus on visuaalne. See ei ole. Saate lohistada auhinnatud disaini vale sõnumi peale ja see konverteerib täpselt samamoodi nagu vana sait. Kuid leidke üleminekupäästik ja sõnum teeb raske töö. Peate selle lihtsalt kiiresti leidma — iga kliendi, iga kvartali jaoks, valdkondades, mida te veel ei tunne. Sellepärast vajate raamistikku, mida saate käivitada esimesel päeval, ilma kolmekuulise avastusfaasita.

Mõelge, mida üleminek hõlmab: andmete eksportimine, meeskonna koolitamine, uue liidese õppimine, harjumuste muutmine. Teie kliendi veebisait peab selle jada tunduma vältimatuna. Funktsioonide loend seda teha ei suuda. Selge pilt elust pärast üleminekut suudab. See pilt on sõnum. Kõik muu saidil toetab seda.

Siin on raamistik: määratlege üleminek. Seejärel sundige iga lehte selle nimel argumenteerima.

Vastuväide	Mida see tegelikult kaitseb	Mida selle asemel teha
'Iga klient on erinev.'	Sinu hirm mallide ees	Leia üleminekupäästik viie küsimuse auditiga
'Me vajame rohkem ekraanipilte.'	Hirm tühjade sektsioonide ees	Asenda tootepildid tõestusega
'Hinnakiri on püha.'	Finantsdirektori ärevus	Kasuta selgust, et vähendada hinnashokki
'API-dokumendid on arendaja probleem.'	Arendusmeeskonna väravavalvamine	Käsitle dokumente veenva meediumina
'KKK on igav.'	Toe ülekoormatud postkast	Kasuta KKK-d viimaste kahtluste hajutamiseks
'Meil pole aega kohandamiseks.'	Perfektsionism tarne arvelt	Ehita karkass, mitte lumehelves

Kasutage seda tabelit esimesel kohtumisel kontrollnimekirjana. Ükski selles olev vastuväide pole tegelik takistus. See on taotlus teistsuguse raamistiku järele.

'Iga klient on erinev' on tõsi — ja ebaoluline

Siin on nihe: toode on erinev, turg on erinev, ostja käitumine mitte. Ostjad tahavad kolme asja: „Kas ma saan sellest aru?" „Kas ma saan sellele usaldada?" „Kas üleminek on odavam kui jäämine?" See on universaalne. Seega ärge standardiseerige disaini. Standardiseerige küsitlus.

Alustage viieküsimuselise auditiga. Viige see läbi esimesel avastuskõnel. See võtab kakskümmend minutit ja töötab iga SaaS-i puhul.

• Kes on kasutaja ja kes on ostja? (Nad on harva sama inimene.)
• Mida nad teevad täna selle asemel, et kasutada teie kliendi toodet?
• Mis on see üks tüütu valu praeguses töövoos?
• Mida nad kardavad, et läheb katki, kui nad üle lähevad?
• Mis on kõige kiirem „võit", mille nad saaksid kohe pärast üleminekut?

Vaadake kahte klienti, et näha, kuidas see töötab.

Esimene, projektihaldustööriist. Kasutaja on meeskonna juht, ostja on samuti meeskonna juht. See teeb sama asja mis olemasolev tööriist. Valu? Keegi ei tea, kelle käes on järgmine ülesanne. Hirm? Sadade projektide migreerimine ja kogu staatuse kaotamine. Kiire võit? Armatuurlaud, mis näitab ülesande omanikku ühe pilguga. Päästik: „Ära kunagi enam jälita ülesande omanikku." See on pealkiri.

Teine, kinnisvara müügivihjete jälgija. Kasutaja on maakler, ostja on maakleribüroo juht. Valu? Dubleerivad müügivihjed ilmuvad kolmes kohas ja head lähevad külmaks. Hirm? Maaklerid ei logi andmeid. Kiire võit? Automaatne rikastamine MLS-i andmebaasist, nii et maaklerid saavad hakkama kahe klikiga. Päästik: „Ära kunagi kaota müügivihjet kaks korda."

Samad viis küsimust. Kaks erinevat toodet. Teil on nüüd keskne sõnum avalehele, funktsioonide sektsiooni esimene lõik ja e-kirjade seeria teemarida. Üleminekupäästik on taastuv ressurss: iga leht, iga sektsioon, iga alapealkiri saab selle nimel argumenteerida. See on teie stardijoon.

Sama päästik annab teile ka saidikaardi. Leht, mis selgitab päästikut, on avaleht. Leht, mis tõestab päästikut, on funktsioonide sektsioon. Leht, mis eemaldab hirmu, on KKK. Leht, mis näitab ülemineku maksumust, on hinnaleht. Järsku on kogu saidil üks narratiiv lehekülgede kaupa komitee asemel.

Saate teha ka konkurentide analüüsi, esitades samad viis küsimust konkurendi saidi kohta. See on odav viis esimesel kõnel väärtust näidata. Leiate konkurendi puuduva üleminekupäästiku ja teie kliendist saab ilmne alternatiiv.

Mis siis, kui toode on meeldiv lisa, mitte valuvaigisti? Siis on üleminekupäästik suurem: säästetud raha, välditud risk või saadud staatus. Vastavustööriista puhul on päästik „vältige trahvi." Turbetööriista puhul on päästik „läbige audit." Sotsiaalmeedia ajastaja puhul on päästik „saate iga nädal kaks tundi tagasi." Audit leiab selle ikkagi. Mõned päästikud on lihtsalt vähem emotsionaalsed.

Ekraanipildid on lehe kõige vähem väärtuslik tõestus

Võtke kõige üksildasem rida teie kliendi funktsioonide tabelis: „OAuth 2.0 tugi." Millise emotsiooni see tekitab? Mitte ühtegi. See on kontrollnimekirja kirje arendajale, kes pole ostja. Kuid kui küsite kliendilt nende funktsioonide lehte, annavad nad teile seina selliseid. Täitke leht ekraanipiltidega ja teete midagi veelgi tavalisemat: näitate toodet tulemuse asemel.

Ekraanipiltidel on koht. Hea GIF toote tööst on tõend. Kuid enamik ekraanipilte on tooteportreed. Ostjad vajavad enne-pärast lugu. Funktsioonide sektsioon on parim koht selle rääkimiseks. Kasutage funktsiooni-kasu-tõestuse valemit (FBP). Nimetage funktsioon, ühendage see kasuga, seejärel tõestage seda faktiga, protsessiga või väikese demoga. Pole väljamõeldud numbreid – kasutage jälgitavaid tulemusi nagu „töötab Google Workspace'iga" või „seadistamine alla minuti."

Kliendi algne plokk:

• OAuth 2.0 tugi
• Rollipõhine juurdepääsukontroll (RBAC)
• SCIM-provisioneerimine

Kolm tarnija žargooni täppi. Nüüd käige igaüks FBP-st läbi.

Funktsioon: OAuth 2.0 tugi.
Kasu: üks sisselogimine kogu meeskonnale. Rohkem IT-pileteid pole.
Tõestus: töötab Google Workspace'i ja Microsoft Entraga.

Funktsioon: rollipõhine juurdepääsukontroll.
Kasu: andke administraatoritele, toimetajatele ja vaatajatele täpselt need õigused, mida nad vajavad.
Tõestus: andke töövõtjale vaatamisõigus alla minuti.

Funktsioon: SCIM-provisioneerimine.
Kasu: lisage ja eemaldage kasutajaid automaatselt oma personalisüsteemist.
Tõestus: sünkroonib Okta ja Ripplinguga.

Näete? Funktsioonid ei muutunud. Veenmine muutus. Teie klient ütleb: „Aga ettevõtete ostjad ootavad, et näevad sõnu OAuth ja SCIM." Tõsi. Lisage arendajatele, kes lehte auditeerivad, tehniline alarida. Kuid pange see rida väikese kirjana kasu alla. Esimene sihtrühm on ostja, kes otsustab, kas kohtumine broneerida. Teine sihtrühm on arendaja, kes märgib linnukesed. Struktureeri oma funktsioonide tutvustus tõestuse ümber, mitte tootepiltide ümber, ja te lõpetate täitematerjali disainimise.

Kui te ekraanipilti kasutate, laske sellel näidata tulemust, mitte ekraani. Projektihalduskliendi jaoks on tõestus ekraanipilt tahvlist, kus igal ülesandel on selge omanik. Kinnisvarakliendi jaoks on tõestus ekraanipilt ühest puhtast kontaktikirjest automaatselt rikastatud andmetega. Armatuurlaua tühja oleku ekraanipilt on disainiressurss, mitte veenmisressurss.

Pange tehnilised kirjeldused kokkupandavasse sektsiooni või arendaja ressursside vahekaardile. Kasutaja näeb kasu; arendaja saab süveneda. See hoiab lehe puhtana ja auditi teostaja rahulolevana.

Hea test iga funktsiooniväite jaoks: kas ostja kordaks seda oma ülemusele? „Üks sisselogimine" on korratav. „OAuth 2.0 tugi" ei ole. Kui teie kliendi funktsioonide leht ei läbi veesüdamiku testi, pole see veel veenev.

Hinnalehed on miiniväli. Just seepärast peaksite neid puudutama

Te kuulete: „Ära puuduta hindu. See on olnud aastaid selline." Mida nad tegelikult ütlevad, on „me kardame." Segadust tekitav hinnaleht ei kaitse tulu; see laseb seda lekkida. Teie ülesanne on muuta leht kulu läbirääkimisest selguse avalduseks.

Alustage küsimuste loetlemisest, millele teie müügimeeskond igal nädalal vastab. Kirjutage need sõna-sõnalt üles. „Kas te küsitate tasu kasutaja kohta?" „Mis juhtub, kui ma lähen üle odavamale plaanile?" „Kas on paigaldustasu?" „Kas saan proovida ilma krediitkaardita?" „Mis on teie tagasimaksepoliitika?" Pange need lehele. Ostja ei peaks kohtumist broneerima, et teada saada, kas proovimiseks on vaja krediitkaarti.

Järgmiseks võtke kliendi kolm plaani: Basic, Pro, Enterprise. Nimetage need ümber vastavalt kliendi olukorrale. Mida iga plaan kellegi jaoks tegelikult teeb? Solo, Team, Organization. Või Creator, Studio, Enterprise. Nimi ei ole kaunistus; see on esimene selguse hetk.

Vana plaan	Uus plaan	Lubadus
Basic	Solo	Ühele inimesele, kes vajab lihtsat töövoogu
Pro	Team	Meeskonnale, mis vajab koostööd ja armatuurlaudu
Enterprise	Org	Ettevõttele, mis vajab turvet, SSO-d ja tuge

Seejärel looge võrdlustabel. Murdke muster, kus iga funktsioon kuhjatakse igasse ritta. Alustage iga rida kasutaja küsimusega, millele see vastab. „Mitu kasutajat?" „Keda saame kutsuda?" „Milliseid turbefunktsioone me saame?" Ostja loeb tabelit, et otsida „kas ma sobiksin." Muutke see otsing lihtsaks.

Lõpuks lisage hindade KKK. Vastake inetule küsimusele: „Mis juhtub minu andmetega, kui ma lahkun?" Kirjutage vastus nagu inimene: „Eksportige kõik ühe klõpsuga enne tellimuse lõppu. Tasusid pole, lukustust pole." See on ülemineku usalduse murdja. Enamik kliente seda ei kirjuta, sest see tundub lahkumiskutsena. See ei ole. See on luba osta ilma hirmuta.

Teie agentuuril on siin loomulik eelis: olete juba viieküsimuselise auditi läbi viinud, nii et teate hirmu. Pange hirm KKK-sse. Kui vajate alustamiseks mall, on hinnalehe konversioonijuhend see mall.

Ärge laske kliendil hindu peita. „Kontakteeruge meiega" leht on sein. Üleminek vajab numbrit, millega võrrelda. Kui hind on kõrge, peaks leht selgitama, mis sisaldub ja miks see seda väärt on. Kui hind on madal, ankurdatke see status quo kuluga. Projektihaldustööriista puhul on status quo kolm eraldi tööriista: ülesannete rakendus, vestlusrakendus ja tabelarvutusprogramm. Ülemineku hind ei tundu kõrge, kui võrrelda seda kõigi kolme igakuise kuluga. Tehke see võrdlus lehel selgesõnaliseks.

Kui kirjutate hindade KKK-d, ärge kasutage müüja keelt. Öelge „sina" ja „sinu andmed". Hinnaleht, mis kasutab kogu aeg „me pakume, me pakume", mõjub ettevõtte brošüürina. Pöörake see ümber „saate, teie meeskond". See on üleminek, mis toimub grammatikas.

Hindade KKK-d saate testida samamoodi nagu kõike muud: lugege see valjusti. Kui võõras laua teisel poolel lõdvestuks, on see hea. Kui nad tõstaksid käe müügimehe jaoks, olete lisanud hõõrdumist.

Dokumendid, mida te ignoreerite, sõlmivad (või tapavad) tehinguid

Siin on arendaja sülearvuti taga. Ta hindab teie kliendi API-t. Tema ülemus küsis: „Kas me saame sellega integreeruda?" Ta tahab ühte asja: tõestust, et tema meeskond ei raiska nädalat. Ta ei alusta viitedokumentidest. Ta alustab kiirjuhendist.

Ettevõtted nagu Stripe, GitHub ja Twilio seavad API-dokumentide standardi. Saladus pole selles, et nad dokumenteerivad iga lõpp-punkti kaunilt. See on see, et nad muudavad esimese käivituse viis minutit kestvaks. Nad näitavad väikest tulemust, mis näeb välja nagu edu. See on üleminekupäästik arendajale: vahetu, konkreetne edasiminek.

Teie kliendi API-dokumendid on esimene leht, mida tehniline ostja pärast avalehte loeb. Kui see loeb nagu telefoniraamat, sureb tehing vaikselt. Dokumendid on turundusvara, mitte tehniline kohustus. Seega tehke nii:

Pange kiirjuhend enne kõike muud. Näite aeg. Teie klient ehitab dokumendiautomaatika API-t. Viide on tihe sisukord, mis ulatub tuhandetele ridadele. Arendaja jõuab kohale, näeb „Autentimine" ja muutub heituks.

1. Kirjutage kolme lauseline kirjeldus lihtsas keeles. „Saatke leping, saage tagasi täidetud koopia. See API muudab mallid ja andmed allkirjastatud PDF-ideks."
2. Kleepige kopeeri-kleebi koodinäidis, mis kutsub liivakasti lõpp-punkti. Näidake esimest JSON-vastust, mis tõestab edu.
3. Lisage üks kasutusjuhtum: „Arved, mis pannakse ise kokku," ja linkige seotud lõpp-punktid.

Liigutage täielik viide allapoole. Arendaja, kes kopeerib esimese koodilõigu, saab sisemiseks pooldajaks. Pooldaja taotleb turvaülevaadet, mitte tagasilükkamist. Teie klient sõlmitakse enne müügikõnet. API-dokumentatsiooni juhend juhendab sama protsessi läbi.

Kasutusjuhtum on lubadus marsruudiga. Dokumendiautomaatika kliendi jaoks kirjutage: „Arved, mis pannakse ise kokku: saatke ostutellimuse number ja saage ühe kõnega tagasi vormindatud arve, reaüksused ja PDF." See pole dokumentide leht; see on müügileht, mis juhtumisi sisaldab koodi.

Lisage manustatud API-võti liivakasti jaoks. Hetkel, kui arendaja saab kleepida ja näha edu, muutub üleminek reaalseks. Müügikõnet pole vaja.

Dokumentide leht toidab ka SEO-d. Arendajad otsivad täpseid veateateid ja integratsiooninimesid. Kirjutage lehed nende päringute jaoks: lõik iga veakoodi jaoks, leht iga integratsiooni jaoks. Nii saavad dokumendid kanaliks.

Kasutage püsivat külgriba nupuga „Proovi kohe". Lisage otsinguriba, mis indekseerib koodinäiteid. Mida sujuvam on otsing, seda pädevam ettevõte välja näeb. Ja ärge unustage lühikest videot alla 90 sekundi, mis näitab töötavat näidet, mitte ettevõtte ülevaadet.

KKK pole tugiteave. See on viimase takistuse konversioon

„Keegi ei loe KKK-sid" – seda kuulete, kuni mäletate, kes loeb: ostja vaikses ruumis, kõhklev küsimust esitamast. KKK on leht, kus tehingud sõlmitakse privaatselt. Kohelge seda nii.

HubSpot, Slack ja Zendesk saavad sellest õigesti aru. Nende KKK- ja abisektsioonid on organiseeritud, otsitavad ja lühidad. See struktuur ongi asja mõte. See annab märku pädevusest. Otsitav KKK paneb ostja mõtlema: need inimesed on mu probleemile mõelnud.

Siin on kõige odavam täiustus, mida saate täna mõne kliendi saidil teha: korraldage olemasolev KKK ümber neljaks ostuetapi rühmaks: Alustamine, Hinnad ja arveldus, Turve ja vastavus, Üleminek ja migreerimine. Seejärel kirjutage igast rühmast üks vastus ümber.

Teeme ülemineku rühma. Praegune vastus küsimusele „Kui raske on migreerimine?" ütleb: „Meie imporditööriist toetab CSV-d ja API-t." See on funktsioonide loend. Kirjutage see ümber lubadusena pluss sammude loendina:

„Me impordime teie andmed teie eest. Saatke CSV, teeme proovikäigu, te kontrollite valimit ja teeme ülemineku 30-minutilises aknas. Kui midagi näeb valesti välja, pöörame kohe tagasi."

Nüüd võrrelge kahte vastust. Kumb sõlmib tehingu? Esimene kirjeldab mehhanismi; teine kirjeldab ohutut protsessi. See on sama struktuur nagu funktsioonide lehel: kasu pluss tõestus.

Minge kaugemale: võtke iga küsimus, millele tugi vastab kaks korda nädalas, ja kirjutage vastus enne seda, kui pilet tekib. See on lõputu sihulehtede sisu allikas. Kui KKK lakkab olemast prügimägi ja hakkab olema veenmisvahend, jääb kogu lugu ühtseks. See osa on seestpoolt-väljapoole lähenemine, mida kasutate kõige muu jaoks.

Korraldage otsing silmas pidades. Otsitav KKK, mis leiab vastuse ühe klahvivajutusega, mõjub toote funktsioonina. See on täpselt see pädevuse signaal, mida soovite.

Ärge sundige ostjaid avama eraldi abikeskust. Pange KKK lehele, mis küsimuse esile kutsus. Kui hinnaküsimus ilmub hinnalehel, vastake seal. Kui turvaküsimus ilmub hinnalehel, vastake ka seal. Vastus kuulub kahtluse punkti.

Turvarühm on koht, kus IT otsustab tööriista blokeerida. Vastake sellistele küsimustele nagu „Kus andmeid hoitakse?" konkreetselt. Kui ütlete „EL-is", öelge piirkond. Kui ütlete „krüpteeritud puhkeolekus", nimetage standard. Lühike vastus on tugevam kui valge raamatu link.

Iga KKK-vastus peaks olema võimalikult lühike ja lõppema järgmise sammuga: „Registreeruge liivakasti kontoga" või „Rääkige toega." Vastus ilma järgmise sammuta on ummiktee.

Pole aega? Ehitage karkass, mitte lumehelves

Viimane vastuväide on see, mida te tõenäoliselt praegu tunnete: „Aga mul on neli klienti ja esmaspäeval tähtaeg." Õiglane. Kohelge iga projekti kui kohandatud portreed ja te jääte alati heitlema. Selle asemel ehitage üks korduvkasutatav väljund: ülemineku memo. Selle täitmine võtab 90 minutit ja see visandab iga lehe.

Ülemineku memo – üks leht, kuus rida:

1. Kasutaja / ostja jaotus: kes ilmub, kes maksab.
2. Praegune käitumine: mida nad täna selle asemel teevad.
3. Üks valu: üks lause, tüütus.
4. Hirm: mida nad muretsevad, et üleminekul läheb katki.
5. Kiire võit: esimene nähtav täiustus pärast üleminekut.
6. Tõestus: logod, tulemused või turbeasendid, mis eemaldavad hirmu.

Võtke see esimesele avastuskõnele. Täitke see viie küsimuse esitamise ajal. Selleks ajaks, kui olete oma laua taga, on teil sõnumi raamistik. Avalehe pealkiri on kiire võit. Funktsioonide lehe sissejuhatus on valu. Hinnatabeli keskmine veerg on ostja. KKK on hirmude loend. API-dokumentide kiirjuhend on arendajate kiire võit.

See karkass ei muuda iga saiti identselt välja nägema. See muudab iga saidi veenvaks samal viisil. Disainite ikkagi iga kliendi hääle järgi, kuid lõpetate sõnumi aladisainimise. Kui sõnum on juba paigas, saate iga lehe esimese mustandi ühe päevaga valmis. Agentuuri tegelik toode on protsess, mitte piksel.

Siin on nihe: te ei kujunda enam saite ümber. Te positsioneerite neid ümber. Ja kuna üleminekuraamistik püsib eri tööstusharudes, saate strateegia eest küsida, tarnida seda korrataval kujul ja üle anda varad, mis tegelikult konverteerivad. Teie järgmine käivitamine peaks algama viieküsimuselise auditiga, mitte meeleolulaud.

Kasutage memot, et ootused varakult paika panna. Asutaja näeb, et sait pole kunstiprojekt; see on veenmisdokument. See hoiab ära „tehke see lihtsalt pop" tagasiside ja pöörab vestluse tulemuste poole. Jagage memot kliendi siseturundusmeeskonnaga, et nad saaksid hiljem uusi lehti kirjutada ilma sõnumit uuesti leiutamata.

Kui esitlete saiti, alustage üleminekumemost, mitte disainist. Kliendid kiidavad strateegia heaks kiiremini kui esteetika. Saate vähem „kas saame logo suuremaks" taotlusi, sest olete andnud neile põhjuse lehte sõnumi põhjal hinnata.

Üleminek on strateegia. Kõik muu on kaunistus.

Võtke sellest üks asi: ärge tellige uut ümberkujundust enne, kui olete üleminekuküsimusele vastanud. Enamik SaaS-saite ebaõnnestub, sest külastajad ei leia kunagi põhjust oma praegusest töövoost loobuda. Sait ei ebaõnnestu sellepärast, et logo on liiga väike või gradient on vananenud.

Teie järgmine käivituskõne peaks olema viieküsimuseline audit. Kui asutaja ei suuda üleminekut sõnastada, suruge teda. Kui suudate selle sõnastada, on igal lehel töö: funktsioonide lehed tõestavad seda, hinnalehed põhjendavad seda, KKK-lehed kaitsevad seda ja API-dokumendid demonstreerivad seda. Annate parema toote kiiremini. Ja teil on raamistik, mida saate kasutada iga kliendiga igavesti.

Üleminekupõhine sait muutub aja jooksul ka paremaks. Teil on nüüd hüpotees – päästik – ja saate seda testida kuumakaartide, sessioonide salvestuste või A/B-testide abil. Raamistik muudab ümberkujunduse sündmusest katseks.

Te ei vaja 40-leheküljelist strateegia esitlust. Vajate kuut rida ja valmisolekut öelda ei lehtedele, mis üleminekut ei teeni. See selgus on see, mille eest kliendid teile maksavad.

Lõpetage funktsioonide müümine. Müüge üleminekut. See on kogu strateegia.