Ne funkciókat adj el, hanem a váltást

Összefoglaló

Az ügyfeled SaaS-webhelye nem azért bukik meg, mert rosszul néz ki. Azért bukik meg, mert soha nem válaszol arra az egy kérdésre, ami számít: miért váltsak? Ügynökségi munkánál nem építhetsz egyedi meggyőzési modellt minden termékhez. Helyette használd ugyanazt az öt kérdésből álló auditot, hogy megtaláld a váltási triggert bármely SaaS-hez. Aztán vidd végig ezt a triggert minden oldalon: a funkciók bizonyítékká válnak, az árazás átláthatósággá, a GYIK kifogásrombolóvá, az API-dokumentáció pedig a fejlesztő első sikerévé. Ez a keretrendszer egyszeri redesignból ismételhető folyamatot csinál. Az eredmény: gyorsabb szállítás, kevesebb módosítás és olyan oldalak, amelyek tényleg konvertálnak.

Az ügyfelednek nincs dizájnproblémája. Váltási problémája van. A vevőnek már van eszköze, munkafolyamata és egy csapata, aki utálja a változást. Nem az ügyfeled funkcióit hasonlítják egy üres laphoz. Hanem a maradás fájdalmát hasonlítják a váltás fájdalmához. A webhely feladata nem az, hogy felsorolja, mit csinál a termék. Hanem az, hogy a váltást könnyebbnek és értékesebbnek mutassa, mint a jelenlegi állapotot. Ha ezt nem teszi, a webhely csak háttérkép.

Ügynökségnél élesen érzed ezt. Felveszel egy SaaS-ügyfelet, az alapító azt mondja: 'modern webhelyre van szükségünk', és mindenki azt feltételezi, hogy a megoldás vizuális. Pedig nem. Egy díjnyertes dizájnt is ráhúzhatsz a rossz üzenetre, és pontosan ugyanúgy fog konvertálni, mint a régi oldal. De ha megtalálod a váltási triggert, az üzenet végzi a nehéz munkát. Csak gyorsan meg kell találnod – minden ügyfélnél, minden negyedévben, olyan iparágakban is, amelyeket még nem ismersz. Ezért kell egy keretrendszer, amit az első naptól futtathatsz, három hónapos felfedező fázis nélkül.

Gondold át, mit jelent egy váltás: adatok exportálása, a csapat betanítása, új UI megtanulása, szokások megváltoztatása. Az ügyfeled webhelyének elkerülhetetlenné kell tennie ezt a sorozatot. Egy funkciólista ezt nem tudja megtenni. A váltás utáni élet tiszta képe igen. Az a kép az üzenet. Minden más az oldalon ezt támogatja.

Itt a keretrendszer: határozd meg a váltást. Aztán kényszerítsd minden oldalt, hogy mellette érveljen.

Kifogás	Valójában mit véd	Ehelyett mit tegyél
'Minden ügyfél más.'	A sablonoktól való félelmed	Találd meg a váltási triggert egy ötkérdéses audittal
'Több képernyőképre van szükségünk.'	Az üres szekcióktól való félelem	Cseréld le a termékképeket bizonyítékokra
'Az árazás szent.'	A CFO szorongása	Használj átláthatóságot az ársokk csökkentésére
'Az API-dokumentáció fejlesztői probléma.'	A fejlesztőcsapat kapuőrzése	Kezeld a dokumentációt meggyőző csatornaként
'A GYIK unalmas.'	A túlterhelt támogatási bejövő	Használd a GYIK-et az utolsó pillanatban felmerülő kétségek eloszlatására
'Nincs időnk testreszabni.'	A perfekcionizmus a szállítás rovására	Építs vázat, ne hópehelyet

Használd ezt a táblázatot ellenőrzőlistaként az első megbeszélésen. A rajta szereplő kifogások egyike sem valódi akadály. Ez egy másik keretrendszer iránti kérés.

'Minden ügyfél más' igaz – és lényegtelen

Itt a váltás: a termék más, a piac más, a vásárlói viselkedés nem. A vásárlók három dolgot akarnak: 'Ezt értem?' 'Megbízhatok benne?' 'Olcsóbb váltani, mint maradni?' Ez univerzális. Tehát ne a dizájnt szabványosítsd. Hanem a kikérdezést.

Kezdd egy ötkérdéses audittal. Futtasd le az első discovery híváson. Húsz percet vesz igénybe, és bármely SaaS-nél működik.

• Ki a felhasználó, és ki a vásárló? (Ritkán ugyanaz a személy.)
• Mit csinálnak ma ahelyett, hogy az ügyfeled termékét használnák?
• Mi az egyetlen bosszantó fájdalom a jelenlegi munkafolyamatban?
• Mitől félnek, hogy elromlik, ha váltanak?
• Mi a leggyorsabb 'siker', amit váltás után azonnal kapnak?

Nézzünk két ügyfelet, hogy lásd, hogyan működik.

Először is, egy projektmenedzsment eszköz. A felhasználó egy csapatvezető, a vásárló is a csapatvezető. Ugyanazt csinálja, mint a jelenlegi rendszer. A fájdalom? Senki sem tudja, kié a következő feladat. A félelem? Több száz projekt migrálása és az összes státusz elvesztése. A gyors siker? Egy irányítópult, amely első pillantásra megmutatja a feladat tulajdonosát. A trigger: 'Soha többé ne keress feladattulajdonost.' Ez a címsor.

Másodszor, egy ingatlanközvetítői leadkövető. A felhasználó egy ügynök, a vásárló egy bróker. A fájdalom? A duplikált leadek három helyen jelennek meg, és a jók elhidegülnek. A félelem? Az ügynökök nem rögzítik az adatokat. A gyors siker? Automatikus adatbővítés az MLS-listákból, így az ügynökök két kattintással kész vannak. A trigger: 'Soha ne veszíts el egy leadet kétszer.'

Ugyanaz az öt kérdés. Két különböző termék. Mostantól megvan a főoldal központi üzenete, a funkciószekció első bekezdése és az e-mail-sorozat tárgysora. A váltási trigger megújuló erőforrás: minden oldal, minden szekció, minden alcím érvelhet mellette. Ez a rajtvonal.

Ugyanez a trigger adja az oldaltérképet is. Az oldal, amely elmagyarázza a triggert, a főoldal. Az oldal, amely bizonyítja a triggert, a funkciók szekciója. Az oldal, amely eloszlatja a félelmet, a GYIK. Az oldal, amely megmutatja a váltás költségét, az árazási oldal. Hirtelen az egész webhelynek egy narratívája van, nem pedig oldalankénti bizottság.

Versenyzői elemzést is futtathatsz úgy, hogy ugyanezt az öt kérdést teszed fel a versenytárs oldaláról. Ez olcsó módja annak, hogy értéket mutass az első híváson. Meg fogod találni a versenytárs hiányzó váltási triggerét, és az ügyfeled lesz a nyilvánvaló alternatíva.

Mi van, ha a termék csak egy 'jó, ha van' jellegű dolog, nem fájdalomcsillapító? Akkor a váltási trigger nagyobb: megtakarított pénz, elkerült kockázat vagy szerzett státusz. Egy megfelelőségi eszköznél a trigger 'kerüld el a bírságot.' Egy biztonsági eszköznél a trigger 'menj át az auditon.' Egy közösségimédia-ütemezőnél a trigger 'szerezz vissza két órát minden héten.' Az audit akkor is megtalálja. Néhány trigger csak kevésbé érzelmes.

A képernyőképek a legalacsonyabb értékű bizonyítékok az oldalon

Vedd az ügyfeled funkciótáblázatának legmagányosabb sorát: 'OAuth 2.0 támogatás.' Milyen érzelmet vált ki? Semmit. Ez egy ellenőrzőlista-elem egy fejlesztőnek, aki nem a vásárló. Mégis, amikor kéred az ügyfél funkcióoldalát, a falat tele van ezekkel. Töltsd meg az oldalt képernyőképekkel, és még gyakoribb dolgot csinálsz: a terméket mutatod az eredmény helyett.

A képernyőképeknek van helyük. A termék működését bemutató jó GIF bizonyíték. De a legtöbb képernyőkép termékportré. A vásárlóknak előtte-utána történetre van szükségük. A funkciószekció a legjobb hely ennek elmesélésére. Használd a Funkció-Előny-Bizonyíték (FBP) képletet. Nevezd meg a funkciót, kapcsold össze egy előnnyel, majd bizonyítsd ténnyel, folyamattal vagy kis demóval. Ne használj kitalált számokat – használj megfigyelhető eredményeket, mint például 'együttműködik a Google Workspace-szel' vagy 'kevesebb mint egy perc alatt beállítható.'

Eredeti blokk az ügyféltől:

• OAuth 2.0 támogatás
• Szerep alapú hozzáférés-szabályozás (RBAC)
• SCIM-kiosztás

Három beszállítói zsargonpont. Most futtasd át mindegyiket az FBP-n.

Funkció: OAuth 2.0 támogatás.
Előny: Egyetlen bejelentkezés az egész csapatnak. Nincs több IT-jegy.
Bizonyíték: Együttműködik a Google Workspace-szel és a Microsoft Entra-val.

Funkció: Szerep alapú hozzáférés-szabályozás.
Előny: Adj az adminisztrátoroknak, szerkesztőknek és megtekintőknek pontosan azokat a jogosultságokat, amelyekre szükségük van.
Bizonyíték: Adj megtekintési jogot egy vállalkozónak kevesebb mint egy perc alatt.

Funkció: SCIM-kiosztás.
Előny: Adj hozzá és távolíts el felhasználókat automatikusan a HR-rendszeredből.
Bizonyíték: Szinkronizál az Okta és a Rippling rendszerrel.

A funkciók nem változtak. A meggyőzés igen. Az ügyfeled azt fogja mondani: 'De a vállalati vásárlók azt várják, hogy lássák az OAuth és SCIM szavakat.' Igaz. Adj hozzá egy technikai alsort a fejlesztőknek, akik auditálják az oldalt. De tedd ezt a sort kis betűvel az előny alá. Az első közönség a vásárló, aki eldönti, hogy lefoglaljon-e egy megbeszélést. A második közönség a fejlesztő, aki kipipálja a dobozokat. A funkcióbemutatót bizonyítékokra építsd, ne termékfotókra, és nem fogsz többé tölteléktervezést csinálni.

Ha mégis képernyőképet használsz, az eredményt mutasson, ne képernyőt. A projektmenedzsment ügyfélnek egy tábla képernyőképe, ahol minden feladatnak tiszta tulajdonosa van, bizonyíték. Az ingatlanos ügyfélnek egyetlen tiszta kapcsolatfelvételi rekord képernyőképe automatikus adatbővítéssel bizonyíték. Az irányítópult üres állapotának képernyőképe dizájnelem, nem meggyőzési eszköz.

Tedd a műszaki specifikációkat egy behajtható szekcióba vagy fejlesztői erőforrás-fülre. A felhasználó az előnyt látja; a fejlesztő belemélyedhet. Ez tisztán tartja az oldalt, és a naplózó is elégedett.

Jó teszt bármely funkcióállításhoz: elismételné-e a vásárló a főnökének? Az 'egy bejelentkezés' elismételhető. Az 'OAuth 2.0 támogatás' nem. Ha az ügyfeled funkcióoldala nem megy át a kávéfőző-teszten, még nem meggyőző.

Az árazási oldalak aknamezők. Pontosan ezért kell hozzányúlnod

Azt fogod hallani: 'Ne nyúlj az árazáshoz. Ez így volt évek óta.' Valójában azt mondják: 'félünk.' Egy zavaros árazási oldal nem védi a bevételt; elszivárogtatja. A feladatod az, hogy az oldalt költségtárgyalásból világos nyilatkozattá alakítsd.

Kezdd azzal, hogy listázd a kérdéseket, amelyeket az értékesítő csapatod minden héten megválaszol. Írd le őket szó szerint. 'Felhasználónként számolsz fel díjat?' 'Mi történik, ha alacsonyabb csomagra váltok?' 'Van beállítási díj?' 'Kipróbálhatom hitelkártya nélkül?' 'Mi a visszatérítési politikád?' Tedd ezeket az oldalra. Egy vásárlónak nem szabad felhívnia téged, hogy megtudja, kell-e hitelkártya a próbaverzióhoz.

Következő lépésként vedd az ügyfél három csomagját: Basic, Pro, Enterprise. Nevezd át őket az ügyfél helyzete alapján. Mit csinál valójában az egyes csomagok valakinek? Solo, Team, Szervezet. Vagy Kreator, Stúdió, Vállalat. A név nem dísz; ez az első világosság-pillanat.

Itt egy konkrét példa az átnevezett csomagtáblázatra:

Régi csomag	Új csomag	Az ígéret
Basic	Egyéni	Egy személynek, aki egyszerű munkafolyamatot igényel
Pro	Csapat	Egy csapatnak, amely együttműködést és irányítópultokat igényel
Enterprise	Szervezet	Egy vállalatnak, amely biztonságot, SSO-t és támogatást igényel

Aztán építsd meg az összehasonlító táblázatot. Törd meg a mintát, hogy minden funkciót minden sorba beleönts. Vezesd minden sort azzal a felhasználói kérdéssel, amelyre válaszol. 'Hány felhasználó?' 'Kit hívhatunk meg?' 'Milyen biztonsági funkciókat kapunk?' A vásárló azért olvassa a táblázatot, hogy keressen: 'beleillik-e.' Tedd könnyűvé ezt a keresést.

Végül adj hozzá egy árazási GYIK-et. Válaszolj a kellemetlen kérdésre: 'Mi történik az adataimmal, ha elmegyek?' Írd a választ emberien: 'Exportálj mindent egy kattintással az előfizetésed lejárta előtt. Nincsenek díjak, nincs bezárás.' Ez a váltás bizalomépítője. A legtöbb ügyfél nem írja meg, mert úgy érzik, mintha távozásra hívnának. Pedig nem. Ez az engedély, hogy félelem nélkül vásároljanak.

Az ügynökségednek beépített előnye van itt: már lefuttattad az ötkérdéses auditot, így ismered a félelmet. Tedd a félelmet a GYIK-be. Ha sablonra van szükséged a kezdéshez, az árazási oldal konverziós útmutatója a sablon.

Ne hagyd, hogy az ügyfél elrejtse az árakat. A 'lépjen kapcsolatba velünk' oldal egy fal. A váltáshoz szám kell az összehasonlításhoz. Ha az ár magas, az oldal magyarázza el, mi van benne, és miért éri meg. Ha az ár alacsony, horgonyozd a jelenlegi állapot költségéhez. Egy projektmenedzsment eszköznél a jelenlegi állapot három külön eszköz: egy feladatkezelő alkalmazás, egy csevegőalkalmazás és egy táblázatkezelő. A váltás ára nem tűnik magasnak, ha összehasonlítod mindhárom havi költségével. Tedd ezt az összehasonlítást egyértelművé az oldalon.

Amikor az árazási GYIK-et írod, ne használj szállítói nyelvezetet. Mondd azt, hogy 'te' és 'a te adataid.' Az olyan árazási oldal, amely mindig 'kínáljuk, biztosítjuk' kifejezéseket használ, vállalati brosúrának tűnik. Fordítsd meg 'te tudod, a te csapatod' formára. Ez a váltás a nyelvtanban történik.

Az árazási GYIK-et ugyanúgy tesztelheted, mint bármi mást: olvasd fel hangosan. Ha egy idegen az íróasztal túloldalán ellazulna, akkor jó. Ha inkább intene egy értékesítőnek, akkor súrlódást adtál hozzá.

A dokumentáció, amit figyelmen kívül hagyasz, üzleteket zár le (vagy öl meg)

Itt egy fejlesztő a laptopjánál. Éppen az ügyfeled API-ját értékeli. A főnöke azt kérdezte: 'Tudunk ezzel integrálódni?' Egy dolgot akar: bizonyítékot, hogy a csapata nem pazarol el egy hetet. Nem a referencia-dokumentációval kezdi. A gyorsindítóval kezdi.

Az olyan cégek, mint a Stripe, a GitHub és a Twilio, mércét állítanak az API-dokumentáció terén. A titok nem az, hogy minden végpontot szépen dokumentálnak. Hanem az, hogy az első futtatás öt percet vesz igénybe. Mutatnak egy apró eredményt, ami sikernek tűnik. Ez a váltási trigger a fejlesztőnek: azonnali, konkrét haladás.

Az ügyfeled API-dokumentációja az első oldal, amit egy technikai vásárló a főoldal után elolvas. Ha telefonkönyvnek tűnik, az üzlet csendben meghal. A dokumentáció marketingeszköz, nem technikai kötelesség. Tehát tedd ezt:

1. Írj hárommondatos leírást egyszerű magyar nyelven. 'Küldj egy szerződést, és visszakapsz egy aláírt példányt. Ez az API sablonokat és adatokat aláírt PDF-ekké alakít.'
2. Illessz be egy másolható kódmintát, amely meghív egy homokozó-végpontot. Mutasd meg az első válasz JSON-t, amely bizonyítja a sikert.
3. Adj hozzá egy felhasználási esetet, 'Önszerveződő számlák', és linkeld a konkrét végpontokat.

Mozgasd a teljes referenciát alább. A fejlesztő, aki bemásolja az első kódrészletet, belső bajnokká válik. A bajnok biztonsági felülvizsgálatot kér, nem elutasítást. Az ügyfeled még az értékesítési hívás előtt célba ér. Az API-dokumentációs útmutató ugyanezt a folyamatot mutatja be.

A felhasználási eset egy ígéret útvonallal. A dokumentumautomatizálási ügyfélnek írd: 'Önszerveződő számlák: küldj egy megrendelésszámot, és kapsz egy formázott számlát, tételeket és egy PDF-et egyetlen hívásban.' Ez nem dokumentációs oldal; ez egy értékesítési oldal, amely történetesen kódot tartalmaz.

Csatolj egy beágyazott API-kulcsot a homokozóhoz. Abban a pillanatban, amikor egy fejlesztő beilleszthet és sikert lát, a váltás valósággá válik. Nem kell értékesítési hívás.

A dokumentációs oldal az SEO-t is táplálja. A fejlesztők pontos hibaszövegekre és integrációs nevekre keresnek. Írj oldalakat ezekre a keresésekre: egy bekezdést minden hibakódhoz, egy oldalt minden integrációhoz. Így válik a dokumentáció csatornává.

Használj állandó oldalsávot 'kipróbálom most' gombbal. Adj hozzá keresősávot, amely indexeli a kódpéldákat. Minél gördülékenyebb a keresés, annál kompetensebbnek tűnik a cég. És ne feledkezz meg egy 90 másodperc alatti rövid videóról, amely egy működő példát mutat, nem pedig céges áttekintést.

A GYIK nem támogatási tartalom. Ez az utolsó akadály konverziója

'Senki sem olvas GYIK-eket' – ezt fogod hallani, amíg eszedbe nem jut, ki olvassa: egy vevő egy csendes szobában, aki habozik kérdést feltenni. A GYIK az az oldal, ahol az üzletek privát módon zárulnak. Kezeld úgy.

A HubSpot, a Slack és a Zendesk jól csinálja. A GYIK- és súgószekcióik rendezettek, kereshetők és tömörek. Ez a struktúra a lényeg. Kompetenciát jelez. Egy kereshető GYIK azt a gondolatot ébreszti a vevőben: ezek az emberek gondoltak az én problémámra.

Itt a legolcsóbb fejlesztés, amit ma bármely ügyfél oldalán elvégezhetsz: rendezd át a meglévő GYIK-et négy vásárlási szakasz szerinti csoportba: Kezdő lépések, Árazás és számlázás, Biztonság és megfelelőség, Váltás és migráció. Aztán írj át egy választ csoportonként.

Csináljuk meg a váltási csoportot. A jelenlegi válasz arra, hogy 'Milyen nehéz a migráció?', ez: 'Az importáló eszközünk támogatja a CSV-t és az API-t.' Ez egy funkciólista. Írd át ígéretként plusz lépéslistaként:

'Beimportáljuk helyetted az adataidat. Küldesz egy CSV-t, lefuttatunk egy próbafuttatást, ellenőrzöl egy mintát, és egy 30 perces időablakban átállunk. Ha bármi rossznak tűnik, azonnal visszaállítunk.'

Most hasonlítsd össze a két választ. Melyik zárja az üzletet? Az első egy mechanizmust ír le; a második egy biztonságos folyamatot. Ez ugyanaz a struktúra, mint a funkcióoldal: előny plusz bizonyíték.

Menj tovább: vedd ki minden olyan kérdést, amelyet a támogatás hetente kétszer megválaszol, és írd meg a választ, mielőtt a ticket létrejönne. Ez a landing-tartalom végtelen forrása. Amint a GYIK megszűnik szemétlerakó lenni, és meggyőző eszközzé válik, az egész történet egységes marad. Ez része a belülről kifelé megközelítésnek, amelyet minden másra használsz.

Szervezd a keresésre gondolva. Egy kereshető GYIK, amely egy billentyűleütéssel megtalálja a választ, termékfunkciónak tűnik. Pontosan ez az a kompetenciajel, amit akarsz.

Ne kényszerítsd a vásárlókat, hogy külön súgóközpontot nyissanak. Tedd a GYIK-et arra az oldalra, amely felvetette a kérdést. Ha egy árazási kérdés felmerül az árazási oldalon, ott válaszolj rá. Ha egy biztonsági kérdés felmerül az árazási oldalon, ott is válaszolj rá. A válasz oda tartozik, ahol a kétség van.

A biztonsági csoport az, ahol az IT eldönti, hogy blokkolja-e az eszközt. Válaszolj az olyan kérdésekre, mint 'Hol tárolják az adatokat?' konkrétumokkal. Ha azt mondod, 'az EU-ban', mondd meg a régiót. Ha azt mondod, 'titkosítva a tárolásban', nevezd meg a szabványt. Egy tömör válasz erősebb, mint egy whitepaper-link.

Minden GYIK-válasznak a lehető legrövidebbnek kell lennie, és egy következő lépéssel kell végződnie: 'Regisztrálj egy homokozó-fiókkal' vagy 'Beszélj a támogatással.' A válasz következő lépés nélkül zsákutca.

Nincs időd? Építs vázat, ne hópehelyet

Az utolsó kifogás az, amelyet valószínűleg épp most érzel: 'De négy ügyfelem van, és hétfőn határidő.' Igaz. Ha minden projektet egyedi portréként kezelsz, mindig kapkodni fogsz. Helyette építs egyetlen újrahasznosítható eredményt: a Váltási Memót. Kitöltése 90 percet vesz igénybe, és felvázolja az összes oldalt.

Váltási Memo – egy oldal, hat sor:

1. Felhasználó / vásárló megosztás: ki jelenik meg, ki fizet.
2. Jelenlegi viselkedés: mit csinálnak ma ahelyett.
3. Az egyetlen fájdalom: egy mondat, az idegesítő dolog.
4. A félelem: mitől félnek, hogy elromlik a váltáskor.
5. A gyors siker: az első látható javulás váltás után.
6. A bizonyíték: logók, eredmények vagy biztonsági tanúsítványok, amelyek eloszlatják a félelmet.

Vidd ezt az első discovery hívásra. Töltsd ki, miközben felteszed az öt kérdést. Mire visszaérsz az íróasztalodhoz, megvan az üzenetkeretrendszer. A főoldal címsora a gyors siker. A funkcióoldal bevezetője a fájdalom. Az árazási táblázat középső oszlopa a vásárló. A GYIK a félelmi lista. Az API-dokumentáció gyorsindítója a fejlesztők gyors sikere.

Ez a váz nem teszi minden webhelyet egyformává. Minden webhelyet ugyanúgy meggyőzővé tesz. Továbbra is az egyes ügyfelek hangjára tervezel, de nem alultervezed az üzenetet. Ha az üzenet már rendezett, egy nap alatt elkészítheted az összes oldal első vázlatát. Az ügynökség valódi terméke a folyamat, nem a pixel.

Itt a váltás: többé nem redesignozol webhelyeket. Átpozícionálod őket. És mivel a váltási keretrendszer iparágakon átível, számlázhatsz a stratégiáért, ismételhető formában szállíthatod, és olyan eszközöket adhatsz át, amelyek tényleg konvertálnak. A következő kickoffodnak az ötkérdéses audittal kell kezdődnie, nem mood boarddal.

Használd a memót a korai elvárások beállítására. Az alapító látja, hogy a webhely nem művészeti projekt; hanem meggyőzési dokumentum. Ez megakadályozza a 'csak tedd popsivá' visszajelzést, és az eredmények felé tereli a beszélgetést. Oszd meg a memót az ügyfél belső marketingcsapatával is, hogy később új oldalakat írhassanak anélkül, hogy újra kellene feltalálniuk az üzenetet.

Amikor bemutatod a webhelyet, kezdd a váltási memóval, nem a dizájnnal. Az ügyfelek gyorsabban hagyják jóvá a stratégiát, mint az esztétikát. Kevesebb 'nagyobbra tudnánk a logót' kérést kapsz, mert okot adtál nekik arra, hogy az üzenet alapján értékeljék az oldalt.

A váltás a stratégia. Minden más dísz.

Vigyél el egy dolgot ebből: ne rendelj meg újabb redesign-t, amíg nem válaszoltál a váltási kérdésre. A legtöbb SaaS-webhely azért bukik meg, mert a látogatók soha nem találnak okot arra, hogy elhagyják a jelenlegi munkafolyamatukat. Az oldal nem azért bukik meg, mert a logo túl kicsi vagy a színátmenet elavult.

A következő kickoff-hívásod az ötkérdéses audit legyen. Ha az alapító nem tudja megfogalmazni a váltást, sürgesd. Ha meg tudod fogalmazni, akkor minden oldalnak van feladata: a funkcióoldalak bizonyítják, az árazási oldalak indokolják, a GYIK-oldalak védik, az API-dokumentáció bemutatja. Gyorsabban szállítasz jobb terméket. És lesz egy keretrendszered, amelyet minden ügyfélnél futtathatsz, örökké.

A váltás-keretezett webhely idővel javul is. Mostantól van egy hipotézised – a trigger –, és tesztelheted hőtérképeken, munkamenet-felvételeken vagy A/B-teszteken. A keretrendszer a redesign-t eseményből kísérletté változtatja.

Nincs szükséged 40 oldalas stratégiai prezentációra. Hat sorra van szükséged, és arra a hajlandóságra, hogy nemet mondj azokra az oldalakra, amelyek nem a váltást szolgálják. Ez a világosság az, amiért az ügyfelek fizetnek neked.

Ne funkciókat adj el. A váltást add el. Ez az egész stratégia.