Спрете да спорите за изоставените колички: Получете одобрение за корекции в чекаута

Обобщение

Повечето съвети за изоставени колички предполагат, че пречката е вашият чекаут — формулярите, бутоните, броят на стъпките. Ако сте в малък вътрешен маркетингов екип, действителната пречка обикновено е вътрешна: нетехнически ръководител, който иска доказателства, изостанал списък със задачи за разработка, предишен неуспешен експеримент или смътното усещане, че „това не е работа на маркетинга“. Тази статия третира тези възражения като самостоятелни CRO проблеми. Тя показва как да превърнете „покажи ми данните“ в еднодневен одит, как да разделите промените в кода от промените в текста и настройките и защо опростяването без доверие няма да промени нещата. Ще получите също таблица с петте възражения, които ще чувате най-често, и директен отговор на компромиса зад гостуващия чекаут. Целта е да направите следващата си заявка толкова конкретна и малка, че да престане да бъде дебат и да се превърне в план.

Повечето съвети за изоставени колички са написани за хора, които вече могат да променят чекаута си. Те ви казват да опростите формуляра, да добавите гостуващ чекаут, да покажете разходите за доставка преди последната стъпка, сякаш единственото нещо, което стои между вас и по-добър коефициент на конверсия, е да знаете какво да правите. Ако сте в малък вътрешен маркетингов екип, това рядко е проблемът. Вие вече знаете какви са корекциите. Проблемът е, че всяка корекция трябва да премине през разговор с нетехнически ръководител, който иска доказателства, график и оценка на разходите, преди да ви бъде позволено да докоснете каквото и да било.

Това, което наистина работи, не е по-дълъг списък от тактики. Това е да третирате процеса на одобрение като част от проблема с оптимизацията на конверсията. Съпротивата, която чувате — „нямаме данни“, „не можем да получим време от разработчиците“, „опитвали сме това преди“, „това не е наша работа“ — не е шум. Всяко възражение ви казва коя част от проекта още не сте направили конкретна. Отговорете на възражението и промяната престава да бъде заявка и се превръща в план.

Тази статия преминава през петте възражения, които спират повечето корекции в чекаута, с непрекъснат пример, и завършва с таблица, която можете да занесете на следващата среща за бюджета. Основната линия е проста: най-добрият CRO ход, който можете да направите това тримесечие, не е редизайн. Това е да направите следващата промяна достатъчно малка, така че шефът ви да може да каже „да“, без да се чувства сякаш рискува.

„Покажи ми данните“ означава покажи ми фунията

Да речем, че работите за малка компания за екипировка за открито. Шефът ви току-що ви е казал, че разходите за доставка убиват поръчките. Тя се обляга назад и казва: „Това е силно твърдение. Имаме ли данни?“ Вие нямате инструмент, който показва къде клиентите напускат. Започвате да говорите за записи на сесии и проследяване на събития, а очите ѝ се остъкляват. Проектът умира в срещата.

Грешката тук е да предположите, че „данни“ трябва да означава табло, което нямате. За повечето ранни корекции данните, от които се нуждаете, вече съществуват в собствения ви магазин — просто не сте го преминали така, както би го направил клиент. Ръководствата за електронна търговия постоянно посочват малък набор от причини, поради които хората изоставят количките: неочаквани разходи, сложен процес на чекаут, принуждаване да създадат акаунт, липса на доверие, ограничени възможности за плащане и бавна доставка. Този списък е вашият контролен списък за одит.

Ето какво правите с него. Отворете прозорец в режим инкогнито и отидете на собствената си продуктова страница. Добавете раница в количката. Сега превъртайте бавно, като правите екранна снимка на всяка стъпка. Кога клиентът вижда за първи път общата цена, включително доставката? Пребройте екраните между „добавяне в количката“ и „ще ви бъде таксувана тази сума“. Опитайте се да завършите поръчката без да създавате акаунт и отбележете точния момент, в който сте блокирани. Намерете политиката си за връщане и отбележете колко кликвания са необходими, за да я прочетете. Направете всичко отново на телефон, където оформлението винаги се държи различно.

Ще получите петнадесет или двадесет екранни снимки и набор от наблюдения, които изглеждат така: „На страницата на количката не се споменава доставка. На страницата за плащане таксата за доставка се появява за първи път. Чекаутът изисква акаунт, преди плащането да е възможно. Линкът към политиката за връщане е в долния колонтитул, шест параграфа надолу.“ Това са доказателства и е трудно да се спори с тях, защото шефът ви може да ги възпроизведе за две минути.

Един детайл, който прави одита по-остър: направете го с колега, който никога не е виждал сайта ви. Ще се изненадате какво пропускате, когато сте свикнали със системата. Нека той говори на глас, докато се опитва да купи нещо. Не провеждате лаборатория за използваемост; слушате за моменти, в които нормален човек казва „чакай, какво?“ Точно тези моменти са мястото, където живеят причините за изоставяне.

Когато представяте одита, не започвайте с корекцията. Започнете с възпроизвеждането: „Добавете този артикул, отидете в количката и потърсете доставката. Сега опитайте да завършите поръчка без акаунт.“ Оставете шефа сам да изпита разочарованието. Човек, който е бил раздразнен от чекаута ви, вече не е скептик; той е съюзник.

Общият принцип: преди да поискате промяна, дайте на ръководителя си нещо, което може да види и провери, а не твърдение, което трябва да приеме на вяра. Една екранна снимка струва повече от прогноза. Този вид одит също така ви помага да избегнете най-честия начин на провал при CRO за малки екипи — предлагане на корекция за проблем, който всъщност не сте потвърдили, че съществува. Ако се чудите дали проблемът ви е самият чекаут или нещо по-рано във фунията, по-ранна статия за диагностициране на истинската причина за изоставяне е полезна следваща стъпка.

„Нямаме време от разработчици“ обикновено означава, че не сте разделили настройките от кода

Шефът ви чува „оптимизация на чекаута“ и си представя разработчик, който работи две седмици. Вие знаете, че списъкът със задачи е три месеца дълъг, така че дори не си правите труда да попитате. Но повечето корекции от стандартния списък за изоставяне изобщо не изискват разработчик.

Вземете четирите големи. Прозрачно ценообразуване: показването на разходите за доставка или известие за „безплатна доставка над определена сума“ често е изречение, което можете да добавите на страницата на количката, или настройка във вашата платформа. Гостуващ чекаут: в много платформи за електронна търговия това е превключвател в настройките, а не индивидуална разработка. Възможности за плащане: действителното добавяне на нов доставчик на плащания е техническо, но показването на това кои опции приемате е значка или икона на чекаута — територия на маркетинга. Политика за връщане: ясна и честна политика за връщане е текстово съдържание, а линкът към нея може да бъде преместен от всеки, който може да редактира страница.

За момент се върнете към компанията за екипировка за открито. Политиката за връщане е заровена в долния колонтитул и клиентите, които се притесняват да купят, никога не я намират. Шефът ви предполага, че корекцията означава „изграждане наново на долния колонтитул и шаблона“. Но действителната корекция е добавяне на един ред текст под бутона „Добави в количката“: „Връщане до 30 дни, без въпроси — вижте нашата политика.“ Линкът води към страница, която вече съществува. Това е редакция в CMS, а не спринт.

Точката за настройките също е важна. Ако вашата платформа има опция за гостуващ чекаут, отварянето ѝ не е промяна в кода; това е промяна в конфигурацията. Може да се наложи да намерите настройката, да прочетете документацията и да я тествате веднъж — но това е следобедна работа, а не спринт на разработчик. Ако нямате достъп до страницата с настройки, поискайте достъп веднъж. Първият път разработчик може да ви преведе през процеса; вторият път можете да го направите сами.

Още една категория: страницата за потвърждение на поръчката и имейлът. Ако потвърждението е общо или не задава очаквания за доставка, това е друга повърхност, притежавана от маркетинга. Можете да го пренапишете, без да докосвате системата за поръчки. Клиентите, които знаят какво ще се случи по-нататък, е по-малко вероятно да пишат на поддръжката, а обемът на имейлите до поддръжката е показател, който шефът ви ще разбере.

Уговорката си струва да бъде изказана ясно: някои корекции наистина изискват код и да се преструвате обратното ще ви струва доверие. Но възражението често се появява, защото заявката е формулирана като „поправете чекаута“ вместо „променете това изречение на страницата на количката“. Формулирайте я достатъчно малка, за да принадлежи на маркетинга, и половината съпротива изчезва. Когато наистина имате нужда от разработчик, ще имате много по-силна позиция, ако можете да кажете „всичко в този списък е текст и настройки — само този елемент изисква код“.

„Вече опитахме опростяване“ означава, че сте поправяли грешната причина

Преди шест месеца някой от екипа ви премахна три полета от формуляра на чекаута. Шефът посочи това като доказателство, че „вече сме опитвали CRO“. Поръчките не се промениха. Сега предлагате корекция, свързана с доверието, и шефът казва: „Защо това би било различно?“

Причината, поради която би било различно, е че опростяването на формуляр и изграждането на доверие решават различни проблеми. Изследванията и ежедневният опит предполагат, че хората изоставят количките, когато не вярват на магазина — когато политиката за връщане е неясна, възможностите за плащане изглеждат оскъдни или домейнът изглежда непознат. Ако това е основната причина, по-краткият формуляр не помага. Представете си, че купувате скъпа раница от магазин, за който никога не сте чували. Чекаутът е с три полета, чист колкото може да бъде. Вие все пак се колебаете, защото рискът не е формулярът — а дали нещото ще пристигне и дали можете да го върнете, ако не го направи. Това колебание не е UX проблем; то е проблем на убеждаването.

Как разбирате дали доверието е причината? Погледнете конкретните неща. Вашите продукти скъпи ли са в сравнение с това, което импулсивният клиент би рискувал? Магазинът ви нов ли е или домейнът изглежда необичаен? Няма ли политика за връщане близо до бутона за купуване? Няма ли отзиви или има много малко? Ако сте отговорили с „да“ на няколко от тези, доверието вероятно е по-голям фактор от дължината на формуляра. Ако формулярът ви е наистина дълъг — десет или повече полета, с незадължителни, които не се отнасят — тогава сложността може да е проблемът. Въпросът е, че трябва да проверите, а не да гадаете.

Практичен начин да проверите дали доверието или сложността е основната причина: добавете само един елемент на доверие — линка към политиката за връщане близо до бутона „Добави в количката“ — и оставете формуляра недокоснат. Ако въпросите към поддръжката за връщания или поведението при напускане се подобрят, доверието вероятно е било проблемът. Ако нищо не се промени, тогава погледнете сложността.

Тук има и полезна контрапункт. Добавянето на сигнали за доверие не е автоматична победа. Ако поставите уиджет за отзиви на продуктовата страница и нямате никакви отзиви, току-що сте показали на клиентите „0 отзива“ — което е по-лошо, отколкото изобщо да не показвате отзиви. Прост, конкретен ред за гаранция, подкрепен от реална политика за връщане, е по-честен и не струва нищо. По същия начин „опростяването“ на формуляр не е същото като скриването на необходими полета. Ако имате нужда от адрес за доставка, имате нужда от него; премахването му, за да направите формуляра по-кратък, просто ще доведе до грешни доставки и връщания. Опростяването трябва да премахва ненужното бреме, а не да го прехвърля другаде.

Този нюанс е същата логика зад защо подходът „опростете всичко“ към чекаута е заблуда. Не че опростяването е лошо; а че опростяването е един лост сред няколко, и ако го дръпнете, без да знаете коя причина адресирате, може да загубите тримесечие.

„Първо ни трябва план“ всъщност е искане за процес

Шефът ви казва: „Добре, убедихте ме, че има проблем. Сега ми напишете план.“ Вие замръзвате, защото си представяте дългогодишна програма от експерименти със статистическа значимост и пътна карта. Знаете, че нямате трафик или бюджет за това, така че се бавите.

Планът не трябва да е амбициозен. Той може да бъде единичен цикъл: изберете една причина от контролния списък за изоставяне, намерете екрана, където тя се проваля, направете една промяна и следете един показател. След това преминете към следващата причина.

Нека направим това конкретно с компанията за екипировка за открито. Вашият одит установи, че доставката изненадва хората на страницата за плащане. Вашият план за този месец е: добавете ред на страницата на количката, който казва, че доставката се изчислява при чекаута и че винаги ще я показвате преди плащането. Показателят, който следите, е броят имейли до поддръжката с въпроси за доставка плюс прост сравнителен анализ „преди и след“ на това колко хора, които достигат до страницата за плащане, всъщност завършват поръчката. Това е. Ако имейлите до поддръжката намалеят и завършването на чекаута не спадне, вие сте подобрили изживяването. Следващия месец ще извадите на показ линка към политиката за връщане. Следващия месец след това, ако платформата ви позволява, ще включите гостуващия чекаут. Това е план.

Конкретно, планът може да изглежда така. Първа седмица: извършвате одита и показвате на шефа екранните снимки. Втора седмица: редактирате страницата на количката, за да споменете доставката, и молите отдела за поддръжка да започне да отбелязва въпросите за доставката. Трета седмица: проверявате настройката на платформата за гостуващ чекаут и я включвате, или подготвяте текста за подкана за акаунт. Четвърта седмица: преглеждате бележките на поддръжката и гледате числото на завършените чекаути. Това е план, който шефът ви може да постави в календара, което е точно това, което думата „план“ означава за нетехнически ръководител.

Уговорката тук е да не променяте твърде много неща наведнъж. На малък сайт трябва да знаете коя промяна е довела до резултата. Една промяна на седмица или на месец е бавна за хвалене, но бърза за учене. A/B тестовете са лукс; за очевиден проблем, сравнението „преди и след“ на показателя, който ви интересува, често е достатъчно, за да оправдае следващата стъпка. Ако искате по-формална версия на този цикъл, нашето ръководство за изграждане на повтаряем CRO процес за клиенти в електронната търговия описва стъпките.

Още едно нещо: изберете показател за процеса, а не общите приходи. Приходите варират по сто причини. Показател за процеса — като „колко често поддръжката споменава доставката“, „докъде стига средният клиент, преди да напусне“ или „колко гледания на страницата на чекаута се превръщат в поръчки“ — ви казва дали конкретната промяна е свършила работата си. Ако нямате анализи за това, използвайте човешка обратна връзка: помолете отдела за поддръжка да отбелязва всеки път, когато клиент спомене изненада с доставката. Това също са данни.

„Това не е работа на маркетинга“ изчезва, когато притежавате посланието

На среща разработчикът казва, че чекаутът е наред. Продуктовият човек казва, че това е проблем на работния процес. Шефът ви казва, че някой трябва да го притежава, и всички гледат в пода. Вие се притеснявате, че маркетингът няма власт над чекаута, така че мълчите.

Ето преосмислянето: чекаутът е мястото, където вашето маркетингово обещание преминава теста си. Ако продуктовата страница казва „безплатна доставка над определена сума“, а чекаутът таксува доставка без обяснение, това е провал на посланието. Маркетингът притежава формулировката на гаранциите, прозрачността на разходите и разположението на сигналите за доверие — което е по-голямата част от контролния списък за изоставяне. Пикселното оформление е територия на разработчика; историята, която клиентът чете, докато стои на ръба на чекаута, е ваша.

Така че не ви трябва власт над кодовата база, за да промените нещата. Трябва ви списък на посланията, които в момента се провалят, и точно това произвежда одитът на фунията. Когато го представите, вие не искате разрешение да промените архитектурата; вие докладвате, че маркетинговото послание се прекъсва в конкретна точка. Полезна фраза, която да кажете на шефа: „Не искам да притежавам чекаута. Искам да притежавам думите върху него.“ Това разграничение е малко, но мощно — то прави заявката да звучи по-малко като териториална претенция и повече като въпрос на чистота.

Има по-дълбока версия на това възражение, която си струва да се назове. Ако вашата компания третира CRO като нещо, което прави специалист, малкият вътрешен екип често се чувства неквалифициран. Но не ви трябва да сте статистик, за да забележите провал на посланието. Трябва да сте човекът, който забелязва, че страницата на количката обещава едно, а страницата за плащане доставя друго. Това е маркетингово умение, а не диплома по наука за данни. Ако се притеснявате от процеса, започнете с статията за скрития теч, която е написана за екипи точно в тази позиция.

Референтна таблица за следващата среща за бюджета

Дотук моделът трябва да е ясен: всяко възражение е различна заявка — покажи ми доказателство, покажи ми, че е малко, покажи ми, че не е повторение на миналия път, покажи ми плана, покажи ми, че е наше. Ето ги едно до друго, с отговора, който обикновено уцелва.

Възражението	Какво всъщност се казва	Какво да кажете или направите
„Нямаме данни“	„Трябва да го видя, за да повярвам.“	Направете еднодневен одит и споделете екранни снимки на точната точка на провал.
„Не можем да получим време от разработчици“	„Страхувам се от голям проект.“	Предложете първо промени в текста, настройките и политиката; оставете кода настрана.
„Опитахме опростяване“	„CRO не проработи преди.“	Покажете, че опростяването и доверието решават различни причини, и назовете коя причина целите.
„Първо ни трябва план“	„Искам процес, не пожелание.“	Предложете едномесечен цикъл: една причина, една промяна, един показател.
„Това не е работа на маркетинга“	„Имам нужда от собственик, на когото вярвам.“	Донесете екранни снимки на маркетингови послания, които се провалят в чекаута.

„Ами ако стане по-лошо?“ заслужава директен отговор

Последното възражение е това, което спира хората на място, защото е умно. Шефът ви казва: „Ако включим гостуващия чекаут, ще загубим всичките си редовни клиенти.“ Чувствате се притиснат, защото това е правдоподобен резултат.

Честният отговор е, че гостуващият чекаут не е всичко или нищо. Компромисът е реален, но можете да го проектирате така: оставете хората да завършат поръчката като гости и след това ги подканете да създадат акаунт след поръчката с предимство, което те наистина ценят — проследяване на поръчката, по-бързо повторно поръчване, точки за лоялност. Така запазвате повечето от ползите за конверсия, като същевременно давате на клиентите причина да се регистрират.

Можете също да го представите като пилотен проект: „Нека пуснем гостуващия чекаут за две седмици и да видим какво ще се случи със създаването на акаунти. Ако акаунтите спаднат и приходите не се променят, можем да го върнем обратно.“ Обратимият пилотен проект превръща промяна, която звучи постоянно, в тест с нисък риск.

По-дълбоката точка е, че всяка корекция за конверсия е размяна и размяната зависи от вашия бизнес модел. Ако управлявате услуга с абонамент, която зависи от акаунтите, генералният гостуващ чекаут може наистина да ви навреди. Правилният въпрос не е „гостуващият чекаут добър ли е?“, а „какво сме готови да разменим и какво можем да направим вместо това?“ Това е нюансът, който общите списъци с най-добри практики пропускат, и затова преценката на малкия екип е по-важна от контролния списък.

Същата логика на размяна важи и за методите на плащане. Ограничените възможности за плащане са честа причина за изоставяне — но добавянето на повече опции не е безплатно. Всеки допълнителен метод добавя настройка, такси, риск от измами и въпроси към поддръжката. Ако повечето от клиентите ви вече плащат по един начин, дълъг списък от лога може да изглежда впечатляващо, без да промени поведението. Ходът е да проверите какво всъщност използват клиентите ви, а не да копирате най-големия магазин, който можете да намерите.

Това важи и за скоростта. Бавната доставка е в списъка за изоставяне, но обикновено не можете да я поправите с настройка. Това, което можете да направите, е да зададете точни очаквания: ако знаете, че даден продукт се доставя за седмица, кажете „доставка в рамките на 5 работни дни“, вместо да го криете. Клиент, който знае за времето за изчакване, е клиент, който може да реши; клиент, който разбере след плащането, е връщане.

Заключение: направете следващата промяна достатъчно малка, за да можете да кажете „да“

Работата с възражения не е меко умение. Тя е приоритизиране. Когато шефът ви поиска данни, той ви казва, че проектът е твърде абстрактен. Когато каже, че няма време от разработчици, той ви казва, че проектът звучи твърде голям. Когато каже, че не е работило преди, той ви казва, че причината никога не е била потвърдена. Назовете реалния блокер и решението става по-малко, по-видимо и по-обратимо.

Едностраничен одит, едно изречение на страницата на количката, гостуващ чекаут като настройка, линк към политиката за връщане, преместен с едно кликване по-близо до решението — нито едно от тези неща няма да ви накара да се чувствате така, сякаш правите „истински“ CRO. Но те са промените, които ще преживеят разговор с нетехнически шеф, защото струват малко, отнемат дни и могат да бъдат отменени, ако не работят. Започнете с единия теч, за който вече знаете, дайте на шефа си нещо, върху което да кликне, и оставете резултата да води следващия спор.

Последна уговорка: нищо от това не гарантира повишение на конверсията. Възможно е да направите промените и да не видите разлика, защото реалният блокер е нещо, което не можете да видите отвътре в магазина. Именно поради тази възможност трябва да държите промените малки и обратими. Цената на грешката е ниска; цената на бездействието, докато чакате перфектни доказателства, е тримесечие на пропуснати продажби.