Ne vitatkozz a kosárelhagyásról: Szerezz jóváhagyást a fizetési javításokhoz

Összefoglaló

A legtöbb kosárelhagyási tanács azt feltételezi, hogy az akadály a fizetési folyamatod – az űrlapok, a gombok, a lépések száma. Ha egy kis belső marketingcsapatban dolgozol, a tényleges akadály általában belső: egy nem technikai főnök, aki bizonyítékot akar, egy fejlesztői háttérlista, egy korábbi sikertelen kísérlet, vagy egy homályos érzés, hogy "ez nem a marketing dolga". Ez a cikk magukra az ellenvetésekre úgy tekint, mint CRO-problémákra. Megmutatja, hogyan alakítsd át a "mutasd az adatokat" kérést egy délutáni ellenőrzéssé, hogyan válaszd szét a kódmódosításokat a szöveg- és beállításmódosításoktól, és miért nem mozdítja meg a mutatót a bizalom nélküli egyszerűsítés. Kapni fogsz egy táblázatot is az öt leggyakoribb ellenvetésről, és egy őszinte választ a vendégként történő fizetés mögötti kompromisszumról. A cél az, hogy a következő kérésed annyira konkrét és annyira kicsi legyen, hogy ne vita, hanem terv legyen belőle.

A legtöbb kosárelhagyási tanács olyan embereknek szól, akik már most megváltoztathatják a fizetési folyamatukat. Azt mondja, egyszerűsítsd az űrlapot, add hozzá a vendégként történő fizetést, mutasd meg a szállítási költséget az utolsó lépés előtt, mintha az egyetlen dolog, ami közted és egy jobb konverziós arány között áll, az lenne, hogy tudod, mit kell tenni. Ha egy kis belső marketingcsapatban dolgozol, ez ritkán jelent problémát. Te már tudod, mik a javítások. A probléma az, hogy minden javításnak túl kell élnie egy beszélgetést egy nem technikai főnökkel, aki bizonyítékot, határidőt és költségbecslést akar, mielőtt bármihez is nyúlhatnál.

Ami valójában működik, az nem a taktikák hosszabb listája. Hanem az, ha magára a jóváhagyási folyamatra is a konverzióoptimalizálás részeként tekintesz. Az ellenállás, amit hallasz – "nincs adatunk", "nem kapunk fejlesztői időt", "ezt már próbáltuk", "ez nem a mi dolgunk" – nem zaj. Minden ellenvetés megmondja, hogy a projekt melyik részét nem tetted még konkrétummá. Válaszolj az ellenvetésre, és a változás többé nem kérés, hanem terv.

Ez a cikk végigveszi az öt ellenvetést, amelyek a legtöbb fizetési folyamat-javítást megakasztják, egy futó példán keresztül, és egy táblázattal zárul, amelyet magaddal vihetsz a következő költségvetési megbeszélésre. Az összekötő szál egyszerű: a legjobb CRO-lépés, amit ebben a negyedévben tehetsz, nem egy újratervezés. Hanem az, hogy a következő változtatást elég kicsivé tedd ahhoz, hogy a főnököd igent mondhasson anélkül, hogy úgy érezné, szerencsejátékot játszik.

"Mutasd az adatokat" annyit jelent: mutasd meg a tölcsért

Tegyük fel, hogy egy kis szabadtéri felszereléseket gyártó cégnél dolgozol. A főnököd épp most mondta, hogy a szállítási költségek tönkreteszik a rendeléseket. Hátradől, és azt mondja: "Ez erős állítás. Van adatunk?" Nincs eszközöd, amely megmutatná, hol szállnak ki a vásárlók. Elkezdesz beszélni a munkamenet-rögzítésekről és eseménykövetésről, és a főnököd szeme üveges lesz. A projekt meghal a megbeszélésen.

A hiba itt az, hogy azt feltételezed, hogy az "adat" egy olyan irányítópultot jelent, amivel nem rendelkezel. A legtöbb korai javításhoz a szükséges adatok már ott vannak a saját boltodban – csak még nem jártad végig úgy, ahogy egy vásárló tenné. Az e-kereskedelmi útmutatók következetesen az elhagyás néhány okára mutatnak: váratlan költségek, bonyolult fizetési folyamat, fiók létrehozására kényszerítés, bizalomhiány, korlátozott fizetési lehetőségek és lassú szállítás. Ez a lista az ellenőrzőlistád.

Ezt csináld vele. Nyiss egy inkognitóablakot, és menj a saját termékoldaladra. Tegyél egy hátizsákot a kosárba. Most görgess lassan, és minden lépésnél készíts egy képernyőképet. Mikor látja először a vásárló a teljes költséget, beleértve a szállítást? Számold meg a képernyőket a "kosárba helyezés" és a "ezért az összegért fogsz fizetni" között. Próbálj meg fiók létrehozása nélkül fizetni, és jegyezd fel, hogy pontosan mikor akadsz el. Keresd meg a visszaküldési szabályzatot, és jegyezd fel, hány kattintásba kerül elolvasni. Csináld végig az egészet telefonon is, ahol az elrendezés mindig másképp viselkedik.

A végén lesz tizenöt-húsz képernyőképed, és egy sor olyan megfigyelésed, ami így néz ki: "A kosár oldalán nincs említés a szállításról. A fizetési oldalon jelenik meg először a szállítási díj. A fizetési folyamat fiókot kér a fizetés előtt. A visszaküldési szabályzat linkje a láblécben van, hat bekezdéssel lejjebb." Ez bizonyíték, és nehéz vitatkozni vele, mert a főnököd két perc alatt reprodukálni tudja.

Egy részlet, ami élesebbé teszi az ellenőrzést: csináld egy olyan kollégával, aki még soha nem látta a webhelyedet. Meg fogsz lepődni, mit nem veszel észre, ha már hozzászoktál a rendszerhez. Kérd meg, hogy beszéljen hangosan, miközben vásárolni próbál. Nem használhatósági laboratóriumot futtatsz; olyan pillanatokra figyelsz, amikor egy normális ember azt mondja: "várj, mi?" Pontosan ezekben a pillanatokban élnek az elhagyás okai.

Amikor bemutatod az ellenőrzést, ne a javítással kezdd. Kezdd a reprodukcióval: "Add hozzá ezt a terméket, menj a kosárhoz, és nézd meg, hol van a szállítás. Most próbálj meg fiók nélkül fizetni." Hadd tapasztalja meg a főnök maga a frusztrációt. Aki már bosszankodott a fizetési folyamatodon, az már nem szkeptikus; szövetséges.

Az általános elv: mielőtt változtatást kérnél, adj a vezetődnek valamit, amit látni és ellenőrizni tud, ne egy állítást, amit hitből kell elfogadnia. Egy képernyőkép többet ér, mint egy előrejelzés. Ez a fajta ellenőrzés abban is segít, hogy elkerüld a kis csapatok CRO-jának leggyakoribb hibamódját – amikor olyan problémára javasolsz megoldást, amelyről még nem igazolódott be, hogy létezik. Ha azon gondolkodsz, hogy a probléma maga a fizetési folyamat, vagy valami korábbi a tölcsérben, egy korábbi cikk az elhagyás valódi okának diagnosztizálásáról hasznos következő lépés lehet.

"Nincs fejlesztői időnk" általában azt jelenti, hogy még nem választottad el a beállításokat a kódtól

A főnököd a "fizetési folyamat optimalizálása" alatt azt képzeli, hogy egy fejlesztő két hétig dolgozik. Tudod, hogy a háttérlista három hónapos, ezért meg sem kérdezed. De a szokásos elhagyási lista javításainak nagy része egyáltalán nem igényel fejlesztőt.

Vedd a négy nagyot. Átlátható árazás: a szállítási költség vagy az "ingyenes szállítás bizonyos összeg felett" üzenet gyakran egy mondat, amit a kosár oldalára illeszthetsz, vagy egy beállítás a platformodon. Vendégként történő fizetés: sok e-kereskedelmi platformon ez egy kapcsoló a beállításokban, nem egyedi fejlesztés. Fizetési lehetőségek: egy új fizetési szolgáltató hozzáadása valóban technikai jellegű, de annak megjelenítése, hogy mely opciókat fogadod el, egy jelvény vagy ikon a fizetési oldalon – marketingterület. Visszaküldési szabályzat: egy világos, őszinte visszaküldési szabályzat szöveg, és a linket bárki áthelyezheti, aki szerkeszteni tud egy oldalt.

Vissza a szabadtéri felszereléseket gyártó céghez egy pillanatra. A visszaküldési szabályzat a láblécben van elásva, és a vásárlók, akik idegesek a vásárlás miatt, soha nem találják meg. A főnököd azt feltételezi, hogy a javítás "a lábléc és a sablon újraépítését" jelenti. De a tényleges javítás egy sor szöveg hozzáadása a "Kosárba teszem" gomb alá: "30 napos visszaküldés, kérdések nélkül – lásd szabályzatunkat." A link egy már létező oldalra mutat. Ez egy CMS-szerkesztés, nem egy sprint.

A beállítások szempont is fontos. Ha a platformodon van vendégként történő fizetési lehetőség, annak bekapcsolása nem kódmódosítás; konfigurációs változás. Lehet, hogy meg kell találnod a beállítást, el kell olvasnod a dokumentációt, és egyszer tesztelned kell – de ez egy délutáni munka, nem fejlesztői sprint. Ha nincs hozzáférésed a beállítások oldalához, kérj egyszer hozzáférést. Az első alkalommal talán egy fejlesztőnek végig kell vezetnie; a második alkalommal már magadtól is meg tudod csinálni.

Egy további kategória: a rendelésvisszaigazoló oldal és e-mail. Ha a visszaigazolás sablonos, vagy nem állítja be a szállítási elvárásokat, az egy újabb marketing tulajdonában lévő felület. Átírhatod anélkül, hogy hozzányúlnál a rendelési rendszerhez. Azok az ügyfelek, akik tudják, mi történik ezután, kisebb valószínűséggel írnak az ügyfélszolgálatnak, és az ügyfélszolgálati e-mailek mennyisége olyan mutató, amit a főnököd meg fog érteni.

A figyelmeztetést érdemes őszintén kimondani: néhány javítás valóban kódot igényel, és ha úgy teszel, mintha nem lenne így, az a hitelességedbe kerül. De az ellenvetés gyakran azért merül fel, mert a kérést "javítsd meg a fizetési folyamatot" keretbe foglaltad ahelyett, hogy "változtasd meg ezt a mondatot a kosár oldalán". Ha elég kicsire foglalod, hogy a marketinghez tartozzon, az ellenállás fele eltűnik. Amikor valóban fejlesztőre van szükséged, sokkal erősebb az érved, ha azt mondhatod: "ezen a listán minden szöveg és beállítás – csak ez az egyetlen tétel igényel kódot."

"Már próbáltuk az egyszerűsítést" azt jelenti, hogy rossz okot javítottál

Hat hónappal ezelőtt valaki a csapatodból eltávolított három mezőt a fizetési űrlapról. A főnök erre úgy hivatkozott, mint bizonyítékra, hogy "már próbáltuk a CRO-t". A rendelések nem változtak. Most egy bizalommal kapcsolatos javítást javasolsz, és a főnök azt mondja: "Ez miért lenne más?"

Azért lenne más, mert az űrlap egyszerűsítése és a bizalomépítés más problémákat old meg. A kutatások és a mindennapi tapasztalatok is azt sugallják, hogy az emberek akkor hagyják el a kosarat, amikor nem bíznak a boltban – amikor a visszaküldési szabályzat nem egyértelmű, a fizetési lehetőségek vékonynak tűnnek, vagy a domain ismeretlennek érződik. Ha ez a kiváltó ok, egy rövidebb űrlap nem segít. Képzeld el, hogy egy drága hátizsákot vásárolsz egy boltból, amelyről soha nem hallottál. A fizetési folyamat három mezőből áll, a lehető legtisztább. Mégis habozol, mert a kockázat nem az űrlap – hanem az, hogy megérkezik-e a termék, és visszaküldheted-e, ha nem. Ez a habozás nem UX-probléma; meggyőzési probléma.

Honnan tudod, hogy a bizalom az ok? Nézd meg a részleteket. A termékeid drágák-e ahhoz képest, amit egy impulzusvásárló kockáztatna? Új-e a boltod, vagy szokatlannak tűnik a domain? Nincs-e visszaküldési szabályzat a vásárlási gomb közelében? Nincsenek értékelések, vagy nagyon kevés van? Ha több igenre is igennel válaszoltál, a bizalom valószínűleg nagyobb tényező, mint az űrlap hossza. Ha az űrlapod valóban hosszú – tíz vagy több mező, olyan opcionálisakkal, amelyek nem relevánsak –, akkor a bonyolultság lehet a probléma. A lényeg az, hogy ellenőrizned kell, nem találgatnod.

Egy praktikus módja annak, hogy teszteld, a bizalom vagy a bonyolultság-e a kiváltó ok: adj hozzá egyetlen bizalmi elemet – a visszaküldési szabályzat linkjét a "Kosárba teszem" gomb közelébe –, és hagyd érintetlenül az űrlapot. Ha a visszaküldéssel kapcsolatos támogatási kérdések vagy a kilépési viselkedés javul, a bizalom volt a probléma valószínűleg. Ha semmi sem változik, akkor következő lépésként nézd meg a bonyolultságot.

Van itt egy hasznos ellentmondásos szempont is. A bizalmi jelzések hozzáadása nem automatikus nyeremény. Ha értékelési widgetet teszel a termékoldalra, és nincsenek értékeléseid, akkor csak azt mutatod a vásárlóknak, hogy "0 értékelés" – ami rosszabb, mintha egyáltalán nem mutatnál értékeléseket. Egy egyszerű, konkrét garanciaüzenet, amelyet valódi visszaküldési szabályzat támaszt alá, őszintébb és ingyen van. Hasonlóképpen, az űrlap "egyszerűsítése" nem ugyanaz, mint a szükséges mezők elrejtése. Ha szükséged van a szállítási címre, szükséged van rá; ha eltávolítod, hogy rövidebb legyen az űrlap, csak rossz kézbesítéseket és visszaküldéseket generálsz. Az egyszerűsítésnek a szükségtelen terhet kell eltávolítania, nem pedig máshová csempészni.

Ez az árnyalat ugyanaz a logika, mint amiért a "mindent egyszerűsíts" megközelítés a fizetési folyamatban tévedés. Nem arról van szó, hogy az egyszerűsítés rossz; hanem arról, hogy az egyszerűsítés csak egy a több kar közül, és ha anélkül húzod meg, hogy tudnád, melyik okot célozod, elpazarolhatsz egy negyedévet.

"Előbb terv kell" valójában folyamatkérés

A főnököd azt mondja: "Rendben, meggyőztél, hogy van probléma. Most írj nekem egy tervet." Lefagysz, mert egy éves kísérleti programot képzelsz el statisztikai szignifikanciával és ütemtervvel. Tudod, hogy nincs ehhez forgalmad vagy költségvetésed, ezért elakadsz.

Egy tervnek nem kell ambiciózusnak lennie. Lehet egyetlen hurok: válassz egy okot az elhagyási ellenőrzőlistáról, keresd meg a képernyőt, ahol az hibát okoz, végezz egy változtatást, és figyelj egy mutatót. Aztán lépj a következő okra.

Tegyük ezt konkrétabbá a szabadtéri felszereléseket gyártó céggel. Az ellenőrzésed azt találta, hogy a szállítás meglepetést okoz az embereknek a fizetési oldalon. A terved erre a hónapra: adj hozzá egy sort a kosár oldalához, amely azt mondja, hogy a szállítási költséget a fizetésnél számoljuk ki, és hogy azt mindig a fizetés előtt mutatjuk. A mutató, amit figyelsz, a szállítással kapcsolatos támogatási e-mailek száma, plusz egy egyszerű előtte-utána összehasonlítás arról, hogy a fizetési oldalra érkezők közül hányan teljesítik ténylegesen a rendelést. Ennyi. Ha a támogatási e-mailek csökkennek, és a fizetés befejezése nem esik vissza, javítottál az élményen. Jövő hónapban előtérbe hozod a visszaküldési szabályzat linkjét. Az azt követő hónapban, ha a platformod lehetővé teszi, bekapcsolod a vendégként történő fizetést. Ez egy terv.

Konkrétan a terv így nézhet ki. Első hét: lefuttatod az ellenőrzést, és megmutatod a főnöknek a képernyőképeket. Második hét: szerkeszted a kosár oldalát, hogy megemlítsd a szállítást, és megkéred az ügyfélszolgálatot, hogy kezdjék el megjelölni a szállítással kapcsolatos kérdéseket. Harmadik hét: megnézed a platform beállítását a vendégként történő fizetéshez, és bekapcsolod, vagy előkészíted a fiók létrehozására szolgáló felhívás szövegét. Negyedik hét: átnézed a támogatási jegyzeteket, és megnézed a fizetés befejezésének számát. Ez egy olyan terv, amit a főnököd naptárba tud illeszteni – pontosan ezt jelenti a "terv" szó egy nem technikai vezetőnek.

A figyelmeztetés itt az, hogy ne változtass túl sok mindent egyszerre. Egy kis webhelyen tudnod kell, hogy melyik változtatás hozta az eredményt. Hetente vagy havonta egy változtatás lassú dicsekvésre, de gyors tanulásra. Az A/B tesztek luxus; egy nyilvánvaló hibánál a számodra fontos mutató előtte-utána összehasonlítása gyakran elég a következő lépés igazolásához. Ha ennek a huroknak egy formálisabb változatát szeretnéd, az útmutatónk a megismételhető CRO-folyamat kiépítéséhez e-kereskedelmi ügyfeleknek lépésről lépésre bemutatja.

Még egy dolog: válassz folyamatmutatót, ne a teljes bevételt. A bevétel száz ok miatt ingadozik. Egy folyamatmutató – például "milyen gyakran említik a támogatásban a szállítást", "átlagosan milyen messzire jut a vásárló, mielőtt kilép", vagy "hány fizetési oldalnézésből lesz rendelés" – megmondja, hogy az adott változtatás elvégezte-e a dolgát. Ha nincs ehhez analitikád, használj emberi visszajelzést: kérd meg az ügyfélszolgálatot, hogy kezdjék el feljegyezni, amikor egy ügyfél szállítási meglepetést említ. Az is adat.

"Ez nem a marketing dolga" eltűnik, amikor a sajátodnak vallod az üzenetet

Egy megbeszélésen a fejlesztő azt mondja, a fizetési folyamat rendben van. A termékmenedzser azt mondja, ez munkafolyamat-kérdés. A főnököd azt mondja, valakinek felelősséget kell vállalnia, és mindenki a padlót nézi. Attól tartasz, hogy a marketingnek nincs felhatalmazása a fizetési folyamat felett, ezért csendben maradsz.

Íme az újragondolás: a fizetési folyamat az, ahol a marketing ígéreted próbára tétele történik. Ha a termékoldalad azt mondja, "ingyenes szállítás bizonyos összeg felett", a fizetési folyamat pedig magyarázat nélkül felszámítja a szállítást, az üzenethiba. A marketing tulajdonolja a garanciák megfogalmazását, a költségek átláthatóságát és a bizalmi jelzések elhelyezését – ami az elhagyási ellenőrzőlista nagy része. A pixel-elrendezés a fejlesztő területe; a történet, amelyet a vásárló a fizetés szélén állva olvas, a tiéd.

Tehát nincs szükséged felhatalmazásra a kódbázis felett ahhoz, hogy változást érj el. Szükséged van egy listára azokról az üzenetekről, amelyek jelenleg hibásak, és pontosan ezt adja a tölcsér-ellenőrzés. Amikor bemutatod, nem engedélyt kérsz az architektúra megváltoztatására; azt jelented, hogy a marketingüzenet egy adott ponton megszakad. Egy hasznos mondat a főnöknek: "Nem azt kérem, hogy a fizetési folyamat az enyém legyen. Azt kérem, hogy a rajta lévő szavak az enyémek legyenek." Ez a megkülönböztetés kicsi, de erőteljes – a kérés kevésbé tűnik területfoglalásnak, és inkább tisztasági kérdésnek.

Van ennek az ellenvetésnek egy mélyebb változata, amit érdemes megnevezni. Ha a céged úgy kezeli a CRO-t, mint egy szakember dolgát, a kis belső csapat gyakran alkalmatlannak érzi magát. De nem kell statisztikusnak lenned ahhoz, hogy észrevedd az üzenethibát. Annak kell lenned, aki észreveszi, hogy a kosár oldala egy dolgot ígér, a fizetési oldal pedig mást szállít. Ez marketingkészség, nem adattudományi diploma. Ha izgulsz a folyamat miatt, kezdd a rejtett szivárgás cikkével, amelyet pontosan az ilyen helyzetben lévő csapatoknak írtak.

Referenciatáblázat a következő költségvetési megbeszéléshez

Mostanra a minta világosnak kell lennie: minden ellenvetés más-más kérés – mutasd meg a bizonyítékot, mutasd meg, hogy kicsi, mutasd meg, hogy nem a múltkori ismétlése, mutasd meg a tervet, mutasd meg, hogy a miénk. Íme egymás mellett, a válasszal, amely általában célba talál.

Az ellenvetés	Amit valójában mond	Amit mondj vagy tegyél
"Nincs adatunk"	"Látnom kell, hogy elhiggyem."	Végezz el egy délutáni ellenőrzést, és oszd meg a képernyőképeket a pontos hibapontról.
"Nem kapunk fejlesztői időt"	"Egy nagy projekttől félek."	Javasold először a szöveg-, beállítás- és szabályzatmódosításokat; kódot ne említs.
"Már próbáltuk az egyszerűsítést"	"A CRO korábban nem működött."	Mutasd meg, hogy az egyszerűsítés és a bizalom más okokat old meg, és nevezd meg, melyik okot célzod.
"Előbb terv kell"	"Folyamatot akarok, nem kívánságot."	Kínálj egy egyhónapos hurkot: egy ok, egy változtatás, egy mutató.
"Ez nem a marketing dolga"	"Egy megbízható gazdára van szükségem."	Hozz képernyőképeket a fizetési folyamaton belül meghibásodó marketingüzenetekről.

"Mi van, ha rosszabb lesz?" egyenes választ érdemel

Az utolsó ellenvetés az, amelyik megállítja az embereket, mert okos. A főnököd azt mondja: "Ha bekapcsoljuk a vendégként történő fizetést, elveszítjük az összes visszatérő ügyfelünket." Sarokba szorítva érzed magad, mert ez egy plauzibilis kimenetel.

Az őszinte válasz az, hogy a vendégként történő fizetés nem mindent-vagy-semmit. A kompromisszum valós, de megtervezheted körülötte: engedd meg az embereknek, hogy vendégként fizessenek, majd a rendelés után kérd meg őket, hogy hozzanak létre fiókot egy olyan előnnyel, amelyet valóban értékelnek – rendeléskövetés, gyorsabb újrarendelés, hűségpontok. Így megtartod a konverziós előny nagy részét, miközben továbbra is okot adsz az ügyfeleknek a regisztrációra.

Ezt keretezheted pilótaként is: "Futtassuk a vendégként történő fizetést két hétig, és nézzük meg, mi történik a fióklétrehozásokkal. Ha csökkennek a fiókok, és a bevétel nem változik, visszakapcsolhatjuk." Egy visszafordítható pilóta egy állandónak hangzó változtatást alacsony kockázatú tesztté alakít.

A mélyebb pont az, hogy minden konverziós javítás csere, és a csere az üzleti modelledtől függ. Ha előfizetéses szolgáltatást futtatsz, amely a fiókoktól függ, az általános vendégfizetés valóban árthat neked. A helyes kérdés nem az, hogy "jó-e a vendégként történő fizetés?", hanem hogy "mit vagyunk hajlandóak feláldozni, és mit tehetünk helyette?" Ez az az árnyalat, amit az általános bevált gyakorlat-listák kihagynak, és ezért számít egy kis csapat ítélőképessége többet, mint egy ellenőrzőlista.

Ugyanez a csere logika vonatkozik a fizetési módokra is. A korlátozott fizetési lehetőségek gyakori elhagyási ok – de további lehetőségek hozzáadása nem ingyenes. Minden plusz módszer beállítást, díjakat, csalási kockázatot és támogatási kérdéseket ad hozzá. Ha a legtöbb ügyfeled már így is egyféleképpen fizet, a logók hosszú listája lenyűgözőnek tűnhet anélkül, hogy változtatna a viselkedésen. A lépés az, hogy megnézd, mit használnak valójában az ügyfeleid, nem pedig azt, hogy a legnagyobb boltot másold, amit találsz.

Ez vonatkozik a sebességre is. A lassú szállítás szerepel az elhagyási listán, de a szállítási sebességet általában nem tudod beállítással megjavítani. Amit tehetsz, az a pontos elvárások beállítása: ha tudod, hogy egy terméknek egy hétbe telik a kiszállítása, mondd azt, hogy "5 munkanapon belül kiszállítjuk" ahelyett, hogy elrejtenéd. A vásárló, aki ismeri a várakozási időt, dönteni tud; a vásárló, aki fizetés után tudja meg, a visszaküldés.

Következtetés: tedd a következő változtatást elég kicsivé ahhoz, hogy igent lehessen mondani rá

Az ellenvetések kezelése nem puha készség. Prioritás. Amikor a főnököd adatokat kér, azt mondja, hogy a projekt túl absztrakt. Amikor azt mondja, nincs fejlesztői idő, azt mondja, hogy a projekt túl nagynak hangzik. Amikor azt mondja, korábban nem működött, azt mondja, hogy az okot soha nem erősítették meg. Nevezd meg a valódi akadályt, és a megoldás kisebbé, láthatóbbá és visszafordíthatóbbá válik.

Egy egyoldalas ellenőrzés, egyetlen mondat a kosár oldalán, a vendégfizetés mint beállítás, egy visszaküldési szabályzat-link eggyel közelebb a döntéshez – egyik sem fogja azt éreztetni veled, hogy "igazi" CRO-t csinálsz. De ezek azok a változtatások, amelyek túlélik a nem technikai főnökkel folytatott beszélgetést, mert kevésbe kerülnek, napokig tartanak, és visszavonhatók, ha nem működnek. Kezdd azzal az egy szivárgással, amelyről már tudsz, adj a főnöködnek valamit, amire kattinthat, és hadd vigye tovább az eredmény a következő érvet.

Végül egy figyelmeztetés: egyik sem garantálja a konverzió növekedését. Lehetséges, hogy elvégzed a változtatásokat, és nem látsz különbséget, mert a valódi akadály olyasmi, amit a boltból nem látsz. Ez a lehetőség pontosan az oka annak, hogy a változtatásokat kicsinek és visszafordíthatónak tartod. A tévedés költsége alacsony; a semmittevés költsége, mert tökéletes bizonyítékra vártál, egy negyedévnyi elveszett értékesítés.