Припиніть сперечатися про покинуті кошики: отримайте схвалення на виправлення оформлення замовлення

Summary

Більшість порад щодо покинутих кошиків припускає, що перешкода — це ваше оформлення замовлення: форми, кнопки, кількість кроків. Якщо ви працюєте в невеликій внутрішній маркетинговій команді, справжня перешкода зазвичай внутрішня: нетехнічний керівник, який хоче доказів, беклог розробників, попередній невдалий експеримент або нечітке відчуття, що «це не робота маркетингу». Ця стаття розглядає ці заперечення як проблеми CRO самі по собі. Вона показує, як перетворити «покажіть мені дані» на аудит за один вечір, як відокремити зміни коду від змін у текстах і налаштуваннях, і чому спрощення без довіри не зрушить справу з місця. Ви також отримаєте таблицю п'яти найпоширеніших заперечень і пряму відповідь на компроміс щодо гостьового оформлення замовлення. Мета — зробити ваш наступний запит настільки конкретним і малим, щоб він перестав бути дискусією і став планом.

Більшість порад щодо покинутих кошиків написана для людей, які вже можуть змінювати своє оформлення замовлення. Вони радять спростити форму, додати гостьове оформлення, показати вартість доставки до останнього кроку, ніби єдине, що відділяє вас від кращої конверсії, — це знання, що робити. Якщо ви в невеликій внутрішній маркетинговій команді, це рідко є проблемою. Ви вже знаєте, які виправлення потрібні. Проблема в тому, що кожне виправлення має пройти розмову з нетехнічним керівником, який хоче доказів, термінів і оцінки вартості, перш ніж вам дозволять щось чіпати.

Насправді працює не довший список тактик. Це ставлення до процесу затвердження як до частини проблеми оптимізації конверсії. Опір, який ви чуєте — «у нас немає даних», «ми не можемо отримати час розробників», «ми вже це пробували», «це не наша робота» — це не шум. Кожне заперечення говорить вам, яку частину проєкту ви ще не зробили конкретною. Відповідайте на заперечення — і зміна перестає бути запитом і стає планом.

У цій статті розглядаються п'ять заперечень, які найчастіше зупиняють виправлення оформлення замовлення, на наочному прикладі, а в кінці наведено таблицю, яку можна взяти на наступну бюджетну зустріч. Основна думка проста: найкращий крок CRO, який ви можете зробити цього кварталу, — це не редизайн. Це зробити наступну зміну достатньо малою, щоб ваш керівник міг сказати «так», не відчуваючи, що ризикує.

«Покажіть мені дані» означає покажіть мені воронку

Скажімо, ви працюєте в невеликій компанії з продажу спорядження для активного відпочинку. Ваш керівник щойно сказав вам, що вартість доставки вбиває замовлення. Вона відкидається на спинку крісла і каже: «Це сміливе твердження. Чи є в нас дані?» У вас немає інструменту, який показує, де покупці йдуть. Ви починаєте говорити про записи сесій і відстеження подій, і її очі скляніють. Проєкт помирає на зустрічі.

Помилка тут — припускати, що «дані» обов'язково означають панель інструментів, якої у вас немає. Для більшості ранніх виправлень потрібні дані вже існують у вашому магазині — ви просто не проходили через нього так, як це зробив би покупець. Посібники з електронної комерції послідовно вказують на невеликий набір причин, чому люди відмовляються: несподівані витрати, складний процес оформлення, примус до створення облікового запису, брак довіри, обмежені платіжні опції та повільна доставка. Цей список — ваш контрольний список для аудиту.

Ось що з цим робити. Відкрийте вікно в режимі інкогніто та перейдіть на сторінку власного товару. Додайте рюкзак у кошик. Тепер повільно прокручуйте та робіть скріншот на кожному кроці. Коли покупець вперше бачить загальну вартість, включаючи доставку? Порахуйте екрани між «додати в кошик» і «вас буде списано цю суму». Спробуйте оформити замовлення без створення облікового запису та занотуйте точний момент, коли вас заблоковано. Знайдіть свою політику повернення та занотуйте, скільки кліків потрібно, щоб її прочитати. Зробіть усе це знову на телефоні, де макет завжди поводиться інакше.

У результаті ви отримаєте п'ятнадцять-двадцять скріншотів і набір спостережень, які виглядають так: «На сторінці кошика немає жодної згадки про доставку. На сторінці оплати плата за доставку з'являється вперше. Оформлення вимагає обліковий запис до того, як оплата стане можливою. Посилання на політику повернення знаходиться у підвалі, шість абзаців нижче». Це доказ, і з ним важко сперечатися, тому що ваш керівник може відтворити його за дві хвилини.

Одна деталь, яка робить аудит гострішим: зробіть це з колегою, який ніколи не бачив вашого сайту. Вас здивує, що ви не помічаєте, коли звикли до системи. Нехай він говорить уголос, намагаючись щось купити. Ви не проводите лабораторне дослідження зручності використання; ви прислухаєтесь до моментів, коли звичайна людина каже «стоп, що?» Саме в ці моменти живуть причини відмов.

Коли ви представляєте аудит, не починайте з виправлення. Почніть з відтворення: «Додайте цей товар, перейдіть у кошик і пошукайте доставку. Тепер спробуйте оформити замовлення без облікового запису». Дайте керівнику відчути розчарування самому. Людина, яку роздратувало ваше оформлення, — вже не скептик; вона союзник.

Загальний принцип: перш ніж просити про зміну, дайте своєму менеджеру щось, що він може побачити і перевірити, а не твердження, яке потрібно прийняти на віру. Скріншот коштує більше, ніж прогноз. Такий аудит також допомагає уникнути найпоширенішої помилки CRO в невеликих командах — пропонувати виправлення для проблеми, існування якої ви насправді не підтвердили. Якщо ви сумніваєтеся, чи ваша проблема саме в оформленні замовлення, чи в чомусь раніше у воронці, попередня стаття про діагностику справжньої причини відмов буде корисним наступним кроком.

«У нас немає часу розробників» зазвичай означає, що ви не відокремили налаштування від коду

Ваш керівник чує «оптимізація оформлення замовлення» і уявляє розробника, який працює два тижні. Ви знаєте, що беклог розрахований на три місяці, тому навіть не турбуєтеся з питаннями. Але більшість виправлень зі стандартного списку відмов не потребують розробника взагалі.

Візьмемо чотири найважливіші. Прозоре ціноутворення: показ вартості доставки або повідомлення «безкоштовна доставка від певної суми» — це часто одне речення, яке можна додати на сторінку кошика або налаштувати у вашій платформі. Гостьове оформлення: у багатьох платформах електронної комерції це перемикач у налаштуваннях, а не кастомна розробка. Платіжні опції: додавання нового платіжного провайдера — технічна задача, але відображення того, які опції ви приймаєте, — це бейдж або іконка в оформленні, територія маркетингу. Політика повернення: чітка та чесна політика повернення — це текст, і посилання на неї може перемістити будь-хто, хто вміє редагувати сторінку.

Повернемося на секунду до вашої компанії з продажу спорядження. Політика повернення захована у підвалі, і покупці, які нервували через покупку, ніколи її не знаходять. Ваш керівник вважає, що виправлення означає «перебудувати підвал і шаблон». Але насправді виправлення полягає в додаванні одного рядка тексту під кнопкою «Додати в кошик»: «Повернення протягом 30 днів без запитань — дивіться нашу політику». Посилання веде на сторінку, яка вже існує. Це редагування CMS, а не спринт.

Момент з налаштуваннями теж важливий. Якщо ваша платформа має опцію гостьового оформлення, її ввімкнення — це не зміна коду; це зміна конфігурації. Можливо, вам доведеться знайти налаштування, прочитати документацію та один раз протестувати — але це робота на один вечір, а не спринт розробників. Якщо у вас немає доступу до сторінки налаштувань, попросіть доступ один раз. Першого разу розробник може вам допомогти; другого разу ви зможете зробити це самі.

Ще одна категорія: сторінка підтвердження замовлення та електронний лист. Якщо підтвердження загальне або не задає очікувань щодо доставки, це ще одна поверхня, якою володіє маркетинг. Ви можете переписати його, не торкаючись системи замовлень. Клієнти, які знають, що буде далі, рідше пишуть у підтримку, а обсяг листів до підтримки — це метрика, яку ваш керівник зрозуміє.

Застереження варто висловити прямо: деякі виправлення справді потребують коду, і вдавання, що це не так, коштуватиме вам довіри. Але заперечення часто виникає через те, що запит формулювався як «виправте оформлення замовлення», а не «змініть це речення на сторінці кошика». Сформулюйте його достатньо малим, щоб він належав маркетингу, і половина опору зникне. Коли вам справді знадобиться розробник, у вас буде набагато сильніший аргумент, якщо ви зможете сказати: «Усе в цьому списку — тексти та налаштування, лише цей пункт потребує коду».

«Ми вже пробували спрощення» означає, що ви виправляли не ту причину

Шість місяців тому хтось із вашої команди прибрав три поля з форми оформлення замовлення. Керівник вказав на це як на доказ того, що «ми вже пробували CRO». Замовлення не змінилися. Тепер ви пропонуєте виправлення, пов'язане з довірою, а керівник каже: «Чому це має бути інакше?»

Причина, чому це мало б бути інакше, полягає в тому, що спрощення форми та побудова довіри вирішують різні проблеми. Дослідження та повсякденний досвід свідчать, що люди покидають кошики, коли не довіряють магазину — коли політика повернення нечітка, платіжні опції виглядають мізерними або домен здається незнайомим. Якщо це коренева причина, коротша форма не допоможе. Уявіть, що ви купуєте дорогий рюкзак у магазині, про який ніколи не чули. Оформлення — це три поля, чисті як сльоза. Ви все одно вагаєтесь, бо ризик не у формі — а в тому, чи прибуде товар, і чи зможете ви його повернути, якщо ні. Це вагання — не проблема UX; це проблема переконання.

Як дізнатися, чи довіра є причиною? Подивіться на деталі. Чи є ваші товари дорогими порівняно з тим, на що готовий ризикнути імпульсивний покупець? Чи ваш магазин новий або домен виглядає незвично? Чи немає політики повернення біля кнопки покупки? Чи немає відгуків або їх дуже мало? Якщо ви відповіли «так» на кілька з цих питань, довіра, ймовірно, є більшим фактором, ніж довжина форми. Якщо ваша форма справді довга — десять і більше полів, включно з необов'язковими, які не застосовуються — тоді проблема може бути у складності. Суть у тому, що ви повинні перевірити, а не гадати.

Практичний спосіб перевірити, чи довіра чи складність є кореневою причиною: додайте лише один елемент довіри — посилання на політику повернення біля кнопки «Додати в кошик» — і залиште форму без змін. Якщо питання до підтримки про повернення або поведінку виходу покращаться, ймовірно, проблема була в довірі. Якщо нічого не зміниться, тоді подивіться на складність далі.

Тут також є корисна контраргументна думка. Додавання сигналів довіри — не автоматичний виграш. Якщо ви розмістите віджет відгуків на сторінці товару, але у вас немає відгуків, ви просто покажете клієнтам «0 відгуків» — це гірше, ніж не показувати відгуки взагалі. Проста, конкретна гарантійна фраза, підкріплена реальною політикою повернення, є більш чесною і нічого не коштує. Так само «спрощення» форми не означає приховування необхідних полів. Якщо вам потрібна адреса доставки, вона потрібна; видалення її, щоб зробити форму коротшою, лише призведе до неправильних доставок і повернень. Спрощення має прибирати непотрібний тягар, а не перекладати його кудись.

Цей нюанс є тією ж логікою, що й у статті чому підхід «спрости все» до оформлення замовлення є хибним. Спрощення — це не погано; просто воно є одним із кількох важелів, і якщо ви тягнете за нього, не знаючи, яку причину усуваєте, можна втратити квартал.

«Нам спочатку потрібен план» — це насправді запит на процес

Ваш керівник каже: «Гаразд, ви переконали мене, що є проблема. Тепер напишіть мені план». Ви завмираєте, бо уявляєте річну програму експериментів із статистичною значущістю та дорожньою картою. Ви знаєте, що у вас немає ані трафіку, ані бюджету на це, тому ви зупиняєтесь.

План не обов'язково має бути амбітним. Це може бути один цикл: виберіть одну причину зі списку відмов, знайдіть екран, де вона проявляється, внесіть одну зміну та слідкуйте за однією метрикою. Потім переходьте до наступної причини.

Зробимо це конкретним на прикладі компанії з продажу спорядження. Ваш аудит виявив, що доставка дивує людей на сторінці оплати. Ваш план на цей місяць: додайте рядок на сторінку кошика, який каже, що вартість доставки розраховується при оформленні, і що ви завжди показуєте її перед оплатою. Метрика, за якою ви слідкуєте, — це кількість листів до підтримки з питаннями про доставку плюс просте порівняння до/після того, скільки людей, які дістаються до сторінки оплати, насправді завершують замовлення. Це все. Якщо листи до підтримки зменшаться, а завершення оформлення не впаде, ви покращили досвід. Наступного місяця ви виведете посилання на політику повернення. Через місяць, якщо ваша платформа дозволяє, ви ввімкнете гостьове оформлення. Це план.

Конкретно план може виглядати так. Тиждень перший: ви проводите аудит і показуєте керівнику скріншоти. Тиждень другий: ви редагуєте сторінку кошика, щоб згадати доставку, і просите службу підтримки почати позначати питання про доставку. Тиждень третій: ви перевіряєте налаштування платформи для гостьового оформлення та вмикаєте його або готуєте формулювання для підказки облікового запису. Тиждень четвертий: ви переглядаєте нотатки підтримки та дивитеся на кількість завершених оформлень. Це план, який ваш керівник може внести в календар, і саме це означає слово «план» для нетехнічного менеджера.

Застереження тут про те, щоб не змінювати занадто багато одночасно. На невеликому сайті ви повинні знати, яка зміна дала результат. Одна зміна на тиждень або місяць — це повільно для хвастощів, але швидко для навчання. A/B-тести — це розкіш; для очевидної помилки погляд до/після на метрику, яка вас хвилює, часто достатній, щоб виправдати наступний крок. Якщо ви хочете більш формальної версії цього циклу, наш посібник із побудови повторюваного процесу CRO для клієнтів електронної комерції описує кроки.

Ще одна річ: оберіть процесну метрику, а не загальний дохід. Дохід коливається зі сотні причин. Процесна метрика — як-от «як часто підтримка згадує доставку», «як далеко середній покупець доходить перед виходом» або «скільки переглядів сторінки оформлення перетворюються на замовлення» — показує вам, чи виконала конкретна зміна свою роботу. Якщо у вас немає аналітики для цього, використовуйте зворотний зв'язок від людей: попросіть службу підтримки почати фіксувати, коли клієнт згадує несподівану доставку. Це теж дані.

«Це не робота маркетингу» зникає, коли ви володієте повідомленням

На зустрічі розробник каже, що оформлення в порядку. Продуктовий менеджер каже, що це проблема робочого процесу. Ваш керівник каже, що хтось має цим володіти, і всі дивляться в підлогу. Ви хвилюєтеся, що маркетинг не має повноважень над оформленням, тому мовчите.

Ось переосмислення: оформлення замовлення — це місце, де ваша маркетингова обіцянка проходить випробування. Якщо на сторінці товару написано «безкоштовна доставка від певної суми», а при оформленні стягується плата за доставку без пояснень, це провал повідомлення. Маркетинг володіє формулюванням гарантій, прозорістю витрат і розміщенням сигналів довіри — а це більша частина списку відмов. Піксельна верстка — це сфера розробника; історія, яку читає клієнт, стоячи на межі оформлення, — ваша.

Отже, вам не потрібна влада над кодовою базою, щоб щось змінити. Вам потрібен список повідомлень, які зараз не спрацьовують, і саме це дає аудит воронки. Коли ви його представляєте, ви не просите дозволу змінювати архітектуру; ви повідомляєте, що маркетингове повідомлення розривається в конкретній точці. Корисна фраза для керівника: «Я не прошу володіти оформленням. Я прошу володіти словами на ньому». Ця відмінність невелика, але потужна — вона робить запит менш схожим на територіальну претензію і більш схожим на питання чистоти.

Існує глибша версія цього заперечення, яку варто назвати. Якщо ваша компанія ставиться до CRO як до справи спеціаліста, невелика внутрішня команда часто відчуває себе некомпетентною. Але вам не потрібно бути статистиком, щоб помітити провал повідомлення. Вам потрібно бути людиною, яка помічає, що сторінка кошика обіцяє одне, а сторінка оплати дає інше. Це маркетингова навичка, а не диплом з науки про дані. Якщо ви нервуєте через процес, почніть зі статті про прихований витік, яка написана саме для команд у такій ситуації.

Довідкова таблиця для наступної бюджетної зустрічі

До цього моменту закономірність має бути зрозумілою: кожне заперечення — це різний запит — покажіть мені докази, покажіть мені, що це мало, покажіть мені, що це не повторення минулого, покажіть мені план, покажіть мені, що це наше. Ось вони поруч із відповіддю, яка зазвичай спрацьовує.

Заперечення	Що насправді мається на увазі	Що сказати або зробити
«У нас немає даних»	«Мені потрібно побачити, щоб повірити»	Проведіть однополудневий аудит і поділіться скріншотами точного моменту збою.
«Ми не можемо отримати час розробника»	«Я боюся великого проєкту»	Спочатку запропонуйте зміни в текстах, налаштуваннях і політиці; залиште код поза цим.
«Ми пробували спрощення»	«CRO раніше не спрацював»	Покажіть, що спрощення та довіра вирішують різні причини, і назвіть, яку причину ви цілите.
«Нам спочатку потрібен план»	«Я хочу процес, а не побажання»	Запропонуйте місячний цикл: одна причина, одна зміна, одна метрика.
«Це не робота маркетингу»	«Мені потрібен власник, якому я довіряю»	Принесіть скріншоти маркетингових повідомлень, які не спрацьовують у процесі оформлення.

«А якщо стане гірше?» заслуговує на пряму відповідь

Останнє заперечення — те, що зупиняє людей на місці, бо воно розумне. Ваш керівник каже: «Якщо ми ввімкнемо гостьове оформлення, ми втратимо всіх постійних клієнтів». Ви відчуваєте себе загнаним у кут, тому що це ймовірний результат.

Чесна відповідь полягає в тому, що гостьове оформлення — це не все або нічого. Компроміс реальний, але ви можете обійти це: дозвольте людям оформлювати замовлення як гостям, а потім запропонуйте їм створити обліковий запис після замовлення з перевагою, яку вони справді цінують — відстеження замовлення, швидше повторне замовлення, бонусні бали. Таким чином ви зберігаєте більшу частину вигоди для конверсії, водночас даючи клієнтам привід зареєструватися.

Ви також можете представити це як пілот: «Давайте запустимо гостьове оформлення на два тижні та подивимося, що станеться зі створенням облікових записів. Якщо облікові записи впадуть, а дохід не зміниться, ми можемо повернути все назад». Зворотний пілот перетворює зміну, яка звучить як постійна, на низькоризиковий тест.

Глибша думка полягає в тому, що кожне виправлення конверсії — це компроміс, і компроміс залежить від вашої бізнес-моделі. Якщо ви керуєте підпискою, яка залежить від облікових записів, суцільне гостьове оформлення може справді нашкодити. Правильне питання не «чи добре гостьове оформлення?», а «чим ми готові поступитися і що ми можемо зробити натомість?» Це нюанс, який загальні списки найкращих практик пропускають, і саме тому думка невеликої команди важливіша за контрольний список.

Та сама логіка компромісу застосовується до платіжних методів. Обмежені платіжні опції — поширена причина відмов, але додавання більшої кількості опцій не безкоштовне. Кожен додатковий метод додає налаштування, комісії, ризик шахрайства та питання до підтримки. Якщо більшість ваших клієнтів уже платять одним способом, довгий список логотипів може виглядати вражаюче, але не змінить поведінку. Рішення — перевірити, що насправді використовують ваші клієнти, а не копіювати найбільший магазин, який ви можете знайти.

Це також стосується швидкості. Повільна доставка є у списку відмов, але зазвичай ви не можете виправити швидкість доставки налаштуванням. Що ви можете зробити — встановити точні очікування: якщо ви знаєте, що товар відправляється тиждень, скажіть «відправка протягом 5 робочих днів» замість того, щоб приховувати це. Клієнт, який знає про очікування, може вирішити; клієнт, який дізнається після оплати, — це повернення.

Висновок: зробіть наступну зміну достатньо малою, щоб можна було сказати «так»

Робота із запереченнями — це не м'яка навичка. Це пріоритизація. Коли ваш керівник просить дані, він каже вам, що проєкт надто абстрактний. Коли він каже, що немає часу розробників, він каже, що проєкт звучить надто великим. Коли він каже, що раніше не спрацювало, він каже, що причину так і не підтвердили. Назвіть справжнього блокера — і рішення стане меншим, більш видимим і більш зворотним.

Односторінковий аудит, одне речення на сторінці кошика, гостьове оформлення як налаштування, посилання на політику повернення, переміщене на один клік ближче до рішення — жодне з цих не змусить вас відчувати, що ви робите «справжній» CRO. Але це зміни, які переживуть розмову з нетехнічним керівником, тому що вони коштують мало, займають дні і можуть бути скасовані, якщо не спрацюють. Почніть з одного відомого вам витоку, дайте своєму керівнику щось, на що можна натиснути, і нехай результат несе наступний аргумент.

Останнє застереження: ніщо з цього не гарантує зростання конверсії. Можливо, ви внесете зміни і не побачите різниці, бо справжній блокер — це те, чого ви не бачите зсередини магазину. Саме тому ви тримаєте зміни малими та зворотними. Ціна помилки низька; ціна бездіяльності, тому що ви чекали на ідеальні докази, — це квартал втрачених продажів.