Tinklaraštis
Pakartojama SaaS svetainių sistema agentūroms
Į etapą orientuota sistema, leidžianti jūsų agentūrai kurti nuoseklias SaaS svetaines, kad jos neatrodytų vienodai.
Santrauka
Dauguma SaaS svetainių patarimų – tai gražių ekrano nuotraukų galerija; ji neišgyvena susidūrimo su antruoju klientu. Ši sistema įkvėpimą pakeičia pasikartojančiu procesu: įvertinkite kliento etapą, kiekvienam puslapiui priskirkite vieną užduotį, kurkite funkcijas nuo „aha“ momento, paverskite kainodarą sprendimo pagalba ir leiskite API dokumentams parduoti. Taip pat sužinosite, kaip iš tikrų pokalbių išgauti DUK ir standartizuoti rezultatus nekopijuojant dizaino. Sukurtas agentūroms, kurios turi užtikrinti kokybę įvairiems klientams, šis vadovas suteikia sistemą, kurią galite taikyti kiekviename projekte. Naudokite ją, kad dirbtumėte greičiau, išlaikytumėte nuoseklią kokybę ir išvengtumėte vieno dydžio sprendimų spąstų.
Dauguma patarimų apie SaaS svetaines – tai muziejaus ekskursija. Štai gražus kainodaros puslapis. Pasigrožėkite sumaniais tekstais. Išstudijuokite DUK išdėstymą. Dabar padarykite tai savo klientui. Tai žlunga per antrąjį projektą, nes tas grožis yra įmonės etapo, rinkos ir turinio gylio rezultatas, o ne išdėstymas, kurį galima nukopijuoti. Jūsų agentūrai reikia priešingybės: pasikartojančios sistemos, kuri tinka bet kuriam klientui, užtikrina pastovią kokybę ir nepaverčia kiekvienos svetainės šventove tiems patiems trims vienaragiams prekių ženklams. Nustokite kopijuoti ekrano nuotraukas. Pradėkite vykdyti procesą.
1. Įvertinkite kliento etapą prieš ką nors piešdami
Priskirkite kiekvieną klientą prie „seed“, „scale“ ar „enterprise“ etapo, prieš atidarydami wireframe. Naudokite tris signalus: komandos dydį, klientų skaičių ir tai, kiek turinio jie realiai gali sukurti. „Seed“ produktas su dešimčia klientų ir be logotipų tinklelio nėra įmonės svetainė. Įmonės produktas su šešių mėnesių pardavimo ciklu nėra demonstracinė nukreipimo puslapis. Svetainės, kurios konvertuoja, yra sukurtos įmonei, kurią klientas iš tikrųjų turi, o ne tai, kuria jis norėtų būti. Tai svarbiau nei bet kokia dizaino tendencija.
Nustatykite etapą per pirmąjį skambutį. Paklauskite, kas perka, kiek pirko ir kokie turinio ištekliai egzistuoja. Paprašykite praėjusio mėnesio palaikymo apimties arba įtraukimo laiko, jei jie turi. Atsakymas parodo, ar pagrindinė užduotis yra įrodymas, diferenciacija ar integracija. Tada pasirinkite pagrindinę svetainės užduotį pagal šią lentelę:
| Kliento etapas | Pagrindinė svetainės užduotis | Ką kurti pirmiausia |
|---|---|---|
| Seed | Įrodyti problemos ir sprendimo atitikimą | Aiškinamasis pagrindinis puslapis, demonstracinis vaizdo įrašas, vienas CTA |
| Scale | Diferencijuoti ir skatinti bandomuosius laikotarpius | Funkcijų pristatymas, palyginimo lentelė, bandomojo laikotarpio srautas |
| Enterprise | Pašalinti pardavimo trintį | Išsamūs API dokumentai, saugumo puslapis, kainodaros DUK, pardavimų kontaktas |
Pasipriešinkite, kai klientas reikalauja įmonės išdėstymo „seed“ produktui. Pasakykite tiesiai: funkcijų pristatymas, kurį sukursite, daro prielaidą, kad lankytojai jau žino, ką produktas daro. „Seed“ lankytojai nežino. Jie turi pamatyti problemą ir naudą per dešimt sekundžių. Kurkite būtent tai.
Praktiškai tai reiškia, kad pasirenkate puslapio struktūrą, atitinkančią etapą. „Seed“ klientas gauna ilgą aiškinamąjį puslapį su vienu CTA. „Scale“ klientas gauna funkcijų tinklelį su palyginimo lentele. „Enterprise“ klientas gauna nuorodas į dokumentus ir saugumo puslapį. Koreguokite pagal tai, ką jie iš tikrųjų turi.
Užfiksuokite etapą strategijos santraukoje, kad niekas nesugrįžtų prie „premium“, nes tai atrodo įspūdingai. Jūs nukrypsite. Įkūrėjas spaus animacijų. Pardavimų vadovas prašys ryškesnio funkcijų skyriaus. Etapo klasifikacija yra jūsų inkaras.
2. Kiekvienam puslapiui suteikite vieną užduotį
Prieš rašydami žodį, surašykite kiekvieną puslapį, kurį planuojate kurti, ir kiekvienam priskirkite tiksliai vieną užduotį. Tada ištrinkite bet kurį puslapį, kuris negali jos pagrįsti. Funkcijų pristatymai demonstruoja vartotojo patirtį. Kainodaros puslapiai perteikia vertę ir padeda priimti pirkimo sprendimą. DUK skyriai atsako į dažnus klausimus, mažina palaikymo apkrovą ir didina pasitikėjimą. Tai skirtingos užduotys. Kai jas sumaišote, pagrindinis puslapis išvardija funkcijas, kainodaros puslapis aiškina produktą, o DUK pateisina kainą – ir niekas nekonvertuoja.
Užrašykite užduotį kaip nurodymą, o ne tikslą. „Įtikinti „seed“ etapo lankytoją, kad produktas išsprendžia problemą per dešimt sekundžių“ yra užduotis. „Atrodyti moderniai“ yra noras. Kiekvienas puslapis turi vieną pagrindinį veiksmą – registruotis, užsisakyti demonstraciją, iškviesti API, skaityti dokumentus. Puslapis gali turėti papildomų veiksmų, bet pagrindinis yra vienintelis.
Štai kaip atrodo užduočių sąrašas „scale“ etapo projektų valdymo klientui: Pagrindinis puslapis – įtikinti lankytoją, kad produktas pakeičia jų dabartinę priemonę. Funkcijos – įrodyti, kad darbo krūvio rodinys taupo laiką. Kainodara – padaryti komandos planą akivaizdžiu pasirinkimu. Dokumentai/DUK – pašalinti integracijos baimes. Karjera – ištrinta, nėra užduoties. Apie mus – ištrinta, nėra užduoties. Tai jūsų sutartis.
Šis užduočių sąrašas yra sutartis. Jis sustabdo apimties plėtimąsi. Jis neleidžia klientui pridėti „Apie mus“ puslapio prie konversijos svetainės tik todėl, kad įkūrėjo pusbrolis mano, jog jis ten turi būti. Jei puslapis neturi užduoties, jis nėra kuriamas. Jei jis turi dvi užduotis, jis padalijamas. Čia istorijos centro sistema gali padėti jūsų funkcijų puslapiams likti prie misijos.
Pateikite užduočių sąrašą klientui prieš dizainą. Jie ginčysis. Leiskite. Sąrašas nėra pasiūlymas; tai projekto apibrėžimas. Kiekvienas išbrauktas puslapis taupo biudžetą. Kiekvienas išlaikytas puslapis turi egzistavimo priežastį. Jei jie negali įvardyti užduoties, jie negauna puslapio.
Viena išimtis: pagrindinis puslapis gali turėti dvi užduotis, jei antroji yra „nukreipti tinkamą lankytoją į tinkamą puslapį“. Bet jei pastebite, kad ginatės dėl trijų užduočių, išbraukite puslapį.
3. Dirbkite atgal nuo „aha“ momento
Sustokite su funkcijų inventorizacija. Pradėkite nuo momento, kai vartotojas pirmą kartą gauna realią vertę iš produkto. Tas momentas yra jūsų inkaras. Funkcijų pristatymams reikia vaizdų – ekrano nuotraukų, GIF, vaizdo įrašų – bet tik tada, jei tie vaizdai susieti su momentu, kuris yra svarbus. Nustatymų skydelio ekrano nuotrauka nieko neįrodo. GIF, kuriame vartotojas kuria pirmąjį projektą ir pakviečia komandos narį, įrodo vertę.
Norėdami rasti momentą, stebėkite realų vartotoją. Nesiremkite pardavimų demonstracija. Paprašykite ekrano įrašų arba atlikite penkių minučių interviu su nauju klientu. Paklauskite: ką darėte per pirmąsias dešimt minučių? Kada pagalvojote „tai veikia“? Tas atsakymas yra inkaras.
Paimkite projektų valdymo klientą. Jų „aha“ momentas nėra „turime Ganto diagramas“. Tai pirmas kartas, kai vartotojas nustato terminą, stebi, kaip pildoma laiko juosta, ir iškart pastebi perkrautą komandos narį. Šis darbo srautas gauna dėmesį. Trys jį palaikančios funkcijos – paketinis užduočių įvedimas, vaizdinė laiko juosta, darbo krūvio indikatoriai – gauna ekrano nuotraukas. Likusios trisdešimt septynios funkcijos patenka į ieškomą lentelę žemiau.
„Aha“ momentas nustato, kurios funkcijos bus pristatytos. „Seed“ klientui momentas dažnai yra pats įtraukimo srautas – registracija, duomenų importas, vertės pamatymas. Įmonei tai gali būti darbo srautas, taupantis valandą per dieną. Principas tas pats: pasirinkite tris ar keturias funkcijas, kurios sukuria momentą, ir suteikite joms vaizdinį apdorojimą. Visa kita lieka užlenkimo linijoje ieškomame sąraše.
Agentūros dažnai to praleidžia, nes lengviau paprašyti funkcijų sąrašo. Nedarykite to. Funkcijų sąrašas yra tai, ką turi konkurentas. „Aha“ momentas yra tai, ką turi klientas. Gaukite momentą ir sukurkite pristatymą aplink jį.
Padarykite „aha“ momentą vartais. Jei klientas negali suteikti prieigos prie produkto peržiūros arba negali įrašyti realaus vartotojo, pasakykite, kad funkcijų puslapis bus spėlionės. Dauguma suras ką nors. Tie, kurie neras, yra tie, kurie nesupranta savo produkto – įspėjamasis ženklas visam projektui.
4. Paverskite kainodarą sprendimo pagalba
Sukurkite kainodaros puslapį, kad sutrumpintumėte „kurį planą?“ pokalbį. Tai reiškia palyginimo lentelę ir kainodaros DUK, o ne tik kainų sąrašą. Kainodaros puslapiai yra vieta, kur funkcijų palyginimo lentelės pasiteisina. Lentelė neturi rodyti kiekvienos funkcijos; ji turi parodyti skirtumą tarp dviejų planų, kuriuos potencialus pirkėjas iš tikrųjų sveria. Jei skirtumas yra vietų skaičius arba AI kreditai, parodykite tai. Paryškinkite planą, kurį norite, kad jie pasirinktų.
Pradėkite nuo planų ribų. Paklauskite savo kliento, kas priverčia žmogų pasirinkti B planą, o ne A planą. Paprastai tai naudojimo limitai, komandos dydis arba pažangios funkcijos. Išvardykite tuos skirtumus lentelėje, vizualiai pažymėdami „rekomenduojamą“ planą. Neįtraukite kiekvienos funkcijos; įtraukite tas, kurios svarbios sprendimui. Tinklelis su keturiasdešimt eilučių yra mokslinis darbas, o ne sprendimo pagalba.
Kainodaros DUK yra sprendimo pagalbos dalis. Čia pateikite prieštaravimus: „Kas atsitinka, kai pasiekiu limitą?“ „Ar galiu vėliau pakeisti planą?“ „Ar yra nemokamas bandomasis laikotarpis?“ Tai klausimai, kurie sustabdo pirkimą. Atsakykite į juos puslapyje, kad potencialus pirkėjas neužstrigtų pardavimo skambutyje. Naudokite DUK ciklą iš 6 žingsnio, kad užpildytumėte šį skyrių.
Įspėjimas agentūroms: nesukurkite planų skirtumų. Jei kliento planai yra identiški, išskyrus kainą, tai produkto problema, o ne puslapio problema. Galite ją atskleisti – padėkite funkcijų palyginimą šalia kainos – bet negalite jos suprojektuoti. Pasipriešinkite prieš kurdami. Kainodaros puslapis yra derybų įrankis, ir jei klientas negali įvardyti skirtumo tarp planų, puslapis atrodys kaip spąstai.
Įmonėms neslėpkite kainos už „susisiekite su pardavimais“, jei klientas gali ją paskelbti. Puslapio užduotis yra padaryti pirkėją protingesnį, nesvarbu, ar kaina vieša, ar privati. Jei ji privati, paaiškinkite, kas įtraukta į įmonės planą ir ką apims skambutis. Stiprios kainodaros puslapio sistema išlaiko struktūrą nuoseklią visiems klientams.
Palyginimo lentelės geriausiai veikia, kai rodo varneles kiekvienam planui. Naudokite žalią varnelę, kad paryškintumėte rekomenduojamą variantą. Tas vienas vizualus signalas nukreipia akį ir sutrumpina sprendimą.
5. Leiskite API dokumentams parduoti
Traktuokite API dokumentaciją kaip konversijos turtą, o ne palaikymo vadovą. Kūrėjams skirtiems produktams dokumentai yra produktas. Tokios įmonės kaip „Stripe“, „GitHub“ ir „Twilio“ nustato standartą, nes žino, kad pirmasis puslapis, kurį techninis pirkėjas gali perskaityti, yra „Kaip pradėti“, o ne pagrindinis puslapis. Jei jūsų klientas turi kūrėjams skirtą produktą, dokumentai yra pardavimo puslapis.
Atlikite testą: pabandykite iškviesti API per dešimt minučių, vadovaudamiesi dokumentais. Jei negalite, klientas praranda dalį techninių pirkėjų. Dokumentuose turi būti veikiantis greitasis startas, aiškus autentifikavimo srautas ir kodo pavyzdžiai daugiau nei viena kalba. Jei klientui trūksta dokumentų, pirmiausia sukurkite greitojo starto vadovą. Jums nereikia pilnos informacijos, kad konvertuotumėte; jums reikia kelio nuo nulio iki pirmojo sėkmingo skambučio.
Svetainėje susiekite dokumentus iš funkcijų pristatymo, kainodaros palyginimo ir poraštės. Įdėkite „Kurti“ nuorodą į pagrindinę naršymo juostą, jei produktas yra API-pirmas. Tai mažai pastangų, didelės signalo vertės darbas, kurį dauguma agentūrų praleidžia, nes jis techninis. Tai jūsų pranašumas. API dokumentacijos vadovas apžvelgia tikslias dalis, kurių reikia į konversiją orientuotam dokumentų rinkiniui.
Vienas įspėjimas: nedėkite dokumentų į atskirą domeną, jei galite to išvengti. Laikykite juos subdomene, kuris išsaugo prekės ženklą ir leidžia analizuoti. Norite matyti, kurie dokumentų puslapiai veda į registracijas. Jei negalite sekti kelio nuo dokumentų iki bandomojo laikotarpio, skrendate aklai.
Jei kliento produktas nėra API-pirmas, dokumentai vis tiek svarbūs integracijos klausimams. Net mažas integracijos vadovas gali būti skirtumas tarp registracijos ir praradimo.
6. Išgaukite DUK iš tikrų pokalbių
Nerašykite DUK iš atminties. Išgaukite juos iš palaikymo bilietų, pardavimų skambučių ir įtraukimo el. laiškų. Tyrimai išryškina tokius pavyzdžius kaip „HubSpot“, „Slack“ ir „Zendesk“, kurie organizuoja turinį, prideda paiešką ir išlaiko atsakymus glaustus. Tai veikia, nes jie atsako į tikrus klausimus. Geriausi šaltiniai yra jūsų kliento pokalbiai.
Sukurkite paprastą ciklą. Paprašykite kliento dešimties geriausių praėjusio mėnesio palaikymo bilietų. Suklasifikuokite juos: prieštaravimų valdymas (pardavimai), naudojimas (palaikymas), kainodara (atsiskaitymas) ir pasitikėjimas (saugumas, atitiktis). Įdėkite kainodaros ir prieštaravimų DUK į kainodaros puslapį. Naudojimo ir pasitikėjimo DUK įdėkite į bendrą DUK arba išteklių skyrių. Laikykite atsakymus iki penkiasdešimties žodžių. Jei reikia daugiau gylio, pridėkite nuorodą į išsamų atsakymą.
Rašykite kiekvieną atsakymą kliento kalba. Jei jie klausia „kaip importuoti duomenis iš „Google“ skaičiuoklių?”, nerašykite „masinio importo funkcija įgalina migraciją“. Rašykite „eikite į nustatymus, pasirinkite importą, pasirinkite skaičiuoklę“. Trumpas ir tiesioginis laimi.
Tai nėra vienkartinė užduotis. Suplanuokite mėnesinę peržiūrą. Nauji bilietai tampa naujais DUK; seni archyvuojami. Ciklas išlaiko DUK puslapį gyvą ir mažina palaikymo apkrovą. Statinis DUK puslapis, kuris niekada nesikeičia, yra praėjusių metų problemų paminklas.
Paieškos funkcija yra būtina. Jei DUK turi daugiau nei dešimt elementų, jam reikia paieškos laukelio. Be paieškos puslapis neįvykdo savo užduoties – mažinti palaikymo apkrovą.
Agentūros turėtų standartizuoti šį ciklą kiekvienam klientui. Tai pasikartojantis procesas, nereikalaujantis dizaino talento. Klientui tai aiškus rezultatas. Jums – priežastis palaikyti ryšį po paleidimo.
7. Standartizuokite rezultatą, o ne estetiką
Sukurkite standartinį rezultatų paketą: vieno puslapio strategijos santrauką, puslapių matricą, peržiūros kontrolinį sąrašą. Priverskite kiekvieną klientą juos naudoti. Vizualų dizainą palikite prekės ženklui. Agentūros problema nėra per mažai proceso; tai per daug mėgdžiojimo. Jei kopijuojate šablono išdėstymą iš vieno kliento kitam, gaunate vienarūšes svetaines, kurios visos atrodo taip, lyg jas kūrėte jūs. Standartizuokite mąstymą, o ne temą.
Strategijos santrauka viename puslapyje užfiksuoja etapą, puslapių užduotis ir „aha“ momentą. Pasidalykite ja prieš dizainą. Puslapių matrica išvardija kiekvieną puslapį, jo užduotį ir vieną metriką, kuri parodo, kad jis veikė. Naudokite matricą, kad apribotumėte apimtį. Peržiūros kontrolinis sąrašas pagauna dažnas klaidas: trūkstamą alt tekstą, nesuderintas palyginimo lenteles, nėra CTA virš užlenkimo linijos, DUK be paieškos.
Padarykite rezultatus konkrečius. Strategijos santrauka yra vienas puslapis – jei ji ilgesnė, neradote esmės. Puslapių matrica yra skaičiuoklė, kurią atnaujinate kiekvieną savaitę. Peržiūros kontrolinis sąrašas yra pažodinis sąrašas, kurį atsispausdinate ir tikrinate. Nė vienas iš jų nereikalauja dizaino pastangų; jie reikalauja disciplinos.
Vykdykite šį paketą kiekviename projekte. Jūsų komanda dirba greičiau, nes mąstymas atliekamas vieną kartą. Kokybė išlieka nuosekli, nes kontrolinis sąrašas tas pats. Klientas vis tiek gauna unikalią svetainę, nes prekės ženklo vizualinė tapatybė atlieka diferencijavimą.
Subtilus triukas yra padaryti standartinius rezultatus nematomus galutiniame dizaine. Strategijos santrauka yra vidinis įrankis. Puslapių matrica yra planavimo įrankis. Kontrolinis sąrašas yra kokybės vartai. Nė vienas iš jų neriboja kūrybiškumo. Jie riboja chaosą.
Puslapių matrica taip pat tampa jūsų išlaikymo įrankiu. Po paleidimo galite parodyti klientui, kurie puslapiai veikia prasčiau, ir naudoti matricą sprendimams, ką taisyti. Tai paverčia vienkartinį kūrimą nuolatiniu santykiu.
Išvada
Puikių SaaS svetainių galerija naudinga įkvėpimui, o ne instrukcijoms. Agentūrai reikia sistemos. Įvertinkite kliento etapą. Priskirkite užduotis puslapiams. Pradėkite nuo „aha“ momento. Paverskite kainodarą sprendimo pagalba. Leiskite dokumentams parduoti. Išgaukite DUK. Standartizuokite rezultatus. Vykdykite tai su kitu klientu, paskui su dar vienu. Dizainas kaskart skirsis. Procesas – ne. Taip paversite gražių ekrano nuotraukų portfelį pasikartojančia agentūros paslauga.
Sources (5)
- SaaS FAQ Pages: Leading Examples of the Best Designs
- Top Examples of the Best SaaS FAQ Pages - Powered by Search
- 32 best SaaS websites to gain inspiration from in 2026 - Marketer Milk
- The Ultimate Guide to the perfect SaaS pricing page (incl. real examples) - MRR Unlocked
- The 10 Best SaaS Websites - Brafton