За роки роботи з сайтами ми звикли до однієї дивної картини.
Замовник приходить із завданням зробити інтернет-магазин. Є товари, фотографії, логотип, приблизно зрозумілий асортимент. Ми обговорюємо каталог, картку товару, оплату, доставку, мобільну версію. Потім сайт запускається — і всі начебто задоволені.
А через кілька тижнів починаються зовсім інші розмови.
«А де менеджеру дивитися замовлення?»
«А чому залишки на сайті не збігаються зі складом?»
«А можна зробити, щоб постачальник сам передавав нам наявність?»
І ще одне: «Ми запустили рекламу. Чому замовлень більше, а роботи стало втричі більше?»
Ось тут і стає зрозуміло, що інтернет магазин — це не сторінки з товарами. Це маленький бізнес-механізм, у якому сайт є лише однією деталлю.
Сайт може працювати нормально. І все одно заважати продавати
На одному з проєктів ми працювали з магазином, який продавав товари для дому. Каталог був приблизно на 1800 позицій. Сам сайт не можна було назвати поганим: нормальний пошук, фільтри, адаптив, зрозуміла корзина.
Проблема знаходилася зовсім в іншому місці.
Менеджер отримував замовлення з сайту, окремо перевіряв залишок у таблиці, потім писав постачальнику в месенджер і тільки після цього передзвонював клієнту. Якщо замовлень приходило десять за день — ще можна було жити. Коли після рекламної кампанії їх стало 35–40, процес просто почав сипатися.
Одне замовлення зависло майже на добу. У другому менеджер підтвердив товар, якого вже не було. У третьому клієнту назвали неправильну ціну, тому що постачальник змінив її вранці.
Ми спочатку теж дивилися на сайт. І це була наша помилка.
Після розмови з менеджерами стало зрозуміло: їм потрібен був не черговий блок на головній сторінці, а нормальний зв'язок між замовленням, товаром, складом і людиною, яка це замовлення обробляє.
Хороший інтернет-магазин — це не той, де клієнт легко натискає «Купити». Це той, де після цього натискання не починається ручна робота на пів дня.
Навіщо магазину CRM, якщо замовлень поки небагато?
Це питання нам ставлять регулярно.
Якщо замовлень десять на тиждень, CRM справді може виглядати як зайва конструкція. Менеджер і так пам'ятає, кому передзвонити, де лежить замовлення і хто ще не оплатив.
Але пам'ять людини — ресурс не дуже надійний. Особливо в п'ятницю о 17:40, коли одночасно телефонують два клієнти, приходять нові заявки, а кур'єр уже чекає біля складу.
Тому ми дивимося на crm для интернет магазина не як на модний додаток, а як на місце, де зберігається історія взаємодії з покупцем. Хто замовляв. Що саме. На якому етапі заявка. Чи була оплата. Чи потрібно передзвонити.
І тут є нюанс.
Не кожному магазину потрібна величезна система з десятками модулів. Іноді достатньо набагато простішої схеми. Якщо компанії продають 50 товарів і мають 20 замовлень на місяць, впроваджувати складний корпоративний комплекс тільки тому, що «так правильно», — сумнівне рішення.
А от коли кількість замовлень росте, менеджерів стає двоє-троє, з'являються повторні продажі, телефонні звернення та різні канали реклами, питання вже звучить інакше: як зробити так, щоб інформація не розповзалася по різних місцях?
CRM-система для інтернет-магазину: де проходить межа між користю і зайвою складністю
Ми не раз бачили протилежну ситуацію.
Компанія купує дорогу CRM. Налаштовує десятки статусів. Створює складні воронки. Додає автоматичні повідомлення. Через місяць менеджери все одно ведуть частину замовлень у Google-таблиці.
Чому?
Тому що систему будували навколо можливостей програми, а не навколо реального процесу продажу.
Коли ми проєктуємо crm система для интернет магазина, спочатку розбираємо саме шлях замовлення: звідки воно приходить, хто його бачить, хто перевіряє залишок, хто змінює статус, як передається інформація на склад і в який момент покупець отримує повідомлення.
Тільки після цього вирішуємо, які інтеграції потрібні.
Іноді це CRM та сайт. Іноді ще складська програма, служба доставки, платіжна система, телефонія й сервіс розсилок. А іноді половина цього списку взагалі не потрібна.
А тепер склад. Точніше, те, що відбувається між складом і дверима клієнта
На сайті все красиво.
Клієнт бачить «В наявності», додає товар у корзину, оформлює замовлення. Далі починається найцікавіше.
Хтось має взяти товар із полиці. Перевірити комплектацію. Упакувати. Надрукувати накладну. Передати перевізнику. Відстежити відправлення. А якщо клієнт змінив адресу? А якщо одного товару немає? А якщо в замовленні сім позицій із трьох різних складів?
Саме тому в певний момент бізнес починає дивитися на фулфилмент для интернет магазинов.
Тут теж немає універсальної відповіді. Для магазину з 30 відправленнями на місяць власний склад може бути цілком нормальним варіантом. Для проєкту, який відправляє сотні посилок щотижня, ситуація вже інша.
Ми працювали з магазином, де власник спочатку сам пакував замовлення. Нічого незвичайного — приміщення невелике, асортимент контрольований. Але за кілька місяців кількість відправлень виросла приблизно в чотири рази. Власник витрачав на склад більше часу, ніж на розвиток компанії.
І ось тут економіка змінюється. Платити за зовнішній процес спочатку здається дорого. Поки не порахуєш власний час, оренду, пакувальні матеріали, зарплату людини на складі та помилки, які виникають у поспіху.
Постачальник може зламати каталог швидше, ніж поганий програміст
Звучить жорстко.
Але ми бачили випадки, коли сайт був зроблений акуратно, а товарна база перетворювалася на проблему через дані від постачальника.
Назви різного формату. Фотографії з дивними іменами. Ціни в одному файлі, залишки — в іншому. Артикул сьогодні один, завтра вже інший. Частина товарів позначена як «є», хоча фактично їх немає.
Тому запит поставщики для интернет магазина украина на практиці означає трохи більше, ніж просто пошук компаній, у яких можна купувати товар.
Потрібно ще зрозуміти, у якому вигляді постачальник віддає інформацію. Чи є API. Чи можна отримувати залишки автоматично. Як часто оновлюється ціна. Чи передаються характеристики, фотографії, штрихкоди. Що відбувається, якщо товар зникає з асортименту.
Одного разу ми отримали файл із товарами, у якому було понад 6000 позицій. Здавалося б, завантажуємо — і готово. Не готово. У 400 позицій були дублікати артикулів, приблизно сотня товарів мала однакові фотографії, а в частини назв випадково потрапили службові позначки постачальника.
Можна було просто імпортувати все.
Ми не стали.
Спочатку почистили дані й визначили правила імпорту. Це зайняло додатковий час на старті, зате менеджерам потім не довелося вручну виправляти каталог по одному товару.
Реклама теж має свою ціну — і вона не завжди написана в рекламному кабінеті
Є цікава помилка.
Підприємець бачить вартість кліка, бюджет, кількість переходів і думає, що цього достатньо для оцінки реклами.
Насправді магазин може отримувати багато переходів і майже не заробляти.
Коли нас запитують про продвижение интернет магазина стоимость, ми не намагаємося назвати одну цифру без контексту. Це було б красиво, але мало корисно. На ціну впливають ніша, конкуренція, географія, середній чек, маржа, стан самого магазину, якість фіду товарів і навіть те, наскільки швидко менеджер відповідає на заявку.
Наприклад, реклама привела 100 потенційних покупців. З них 20 залишили замовлення. Але п'ять заявок ніхто не обробив вчасно. Ще три клієнти отримали відповідь через шість годин. І два замовлення зірвалися через відсутність товару.
У рекламному кабінеті це може виглядати як проблема конверсії.
Хоча проблема взагалі не в рекламі.
Іноді найкраще рішення — не додавати ще одну функцію
Ми звикли думати, що розвиток магазину означає постійне додавання чогось нового.
Новий фільтр. Ще один спосіб оплати. Ще одна інтеграція. Ще п'ять автоматичних повідомлень.
Але буває навпаки.
У старому магазині можна прибрати два непотрібні екрани менеджера, скоротити кількість статусів замовлення з одинадцяти до шести й автоматично передавати дані про покупця в CRM. І результат буде відчутнішим, ніж після додавання чергового красивого блоку на головну.
Ми самі не завжди влучаємо з першої спроби. Буває, закладаємо функцію, яка на папері виглядає логічно, а після тижня роботи менеджери кажуть: «Ми цим не користуємося».
І це нормально.
Сайт живе разом із бізнесом. Якщо процес змінився, його не потрібно захищати тільки тому, що колись ми його так спроєктували.
У який момент магазин перестає бути просто сайтом
Мабуть, тоді, коли його вже не можна розглядати окремо від інших процесів.
Клієнт бачить картку товару. Менеджер бачить замовлення. Склад бачить список на відбір. Постачальник передає залишки. CRM зберігає історію. Служба доставки отримує дані для відправлення. Реклама приводить нових людей.
І все це має сходитися в одній точці — без нескінченних копіювань із таблиці в месенджер, із месенджера в CRM, а потім назад на сайт.
Тому під час розробки магазину ми дивимося не тільки на те, що побачить покупець. Нам цікаво, що відбувається за цією сторінкою через п'ять хвилин після оформлення замовлення.
Хто його отримав?
Що змінилося на складі?
Чи актуальна ціна?
Чи знає менеджер, що клієнт уже купував раніше?
І головне — чи витримає цей процес не 15 замовлень, а 150?
Ось це ми вважаємо нормальною точкою відліку. Не красивий запуск заради самого запуску, а магазин, який можна навантажувати роботою і поступово розширювати, не перебудовуючи все з нуля кожні кілька місяців.
0 Коментарі