CRM для інтернет-магазину: як керувати клієнтами і замовленнями
Поки магазин обробляє 5-10 замовлень на день, вистачає таблиці і памʼяті менеджера. На 50 замовленнях починаються втрачені заявки, подвійні дзвінки одному клієнту і повна відсутність розуміння, звідки беруться гроші. CRM для інтернет-магазину - це не «ще одна програма», а місце, де живуть замовлення, історія покупок і вся комунікація з клієнтом.
Облік замовлень: статуси, відповідальні і строки
Основа будь-якої CRM для інтернет-магазину - це воронка статусів замовлення. Мінімальний робочий набір виглядає так: новий, підтверджений, в комплектації, відправлений, доставлений, оплачений, повернення, скасовано. Кожен статус повинен мати відповідального і граничний час перебування. Якщо замовлення висить у статусі «новий» більше двох годин, система має підсвітити його або передати іншому менеджеру.
Другий обовʼязковий елемент - історія змін. Ви маєте бачити, хто і коли перевів замовлення в скасування, який коментар залишив і чи дзвонив клієнту. Без цього розбір конфліктних ситуацій перетворюється на суперечку. Логи змін також показують реальні вузькі місця: часто виявляється, що між оплатою і відправленням проходить не 4 години, як усі думали, а півтора дня.
Окремо варто продумати роботу з частковими замовленнями і резервом товару. Якщо один із трьох товарів не в наявності, менеджеру потрібен зручний спосіб розділити замовлення, а не переписувати його вручну. Такі дрібниці економлять кілька хвилин на кожному замовленні, а на обсязі 1000 замовлень на місяць це десятки робочих годин.
Клієнтська база: одна картка замість пʼяти джерел
Типова проблема магазину: клієнт написав у Instagram, потім подзвонив, потім оформив замовлення на сайті. У результаті в системі три різні записи, і жоден менеджер не бачить повної картини. Клієнтська база має обʼєднувати ці контакти за телефоном або email в одну картку з усіма замовленнями, зверненнями і коментарями.
У картці клієнта корисно тримати не тільки контакти, а й розрахункові поля: сума всіх покупок, кількість замовлень, дата останньої покупки, середній чек, відсоток повернень. Менеджер бачить це до того, як почне розмову, і поводиться відповідно. Клієнту з десятьма замовленнями і нульовими поверненнями можна відправити товар без передоплати, новому з міста, звідки часто не забирають посилки, краще запропонувати оплату наперед.
На базі цих полів будується сегментація, з якої і починаються повторні продажі. Робочі сегменти прості: купували один раз більше 90 днів тому, купували три і більше разів, брали конкретну категорію, залишили замовлення неоплаченим. Для кожного сегмента потрібен свій сценарій: комусь нагадування про витратний матеріал, який уже мав закінчитися, комусь ранній доступ до нової колекції. Повернути покупця, який уже купував, зазвичай коштує в кілька разів дешевше, ніж привести нового з реклами, і сегментована база - єдиний спосіб це робити системно.
Аналітика продажів: середній чек, повторні покупки, топ товарів
Мінімальний набір звітів, який реально впливає на рішення: середній чек по місяцях, частка повторних покупців, топ-20 товарів за виручкою і за маржею, відсоток викупу посилок, конверсія з нового замовлення в оплачене. Останні дві цифри для українського ринку критичні: різниця між 70 і 90 відсотками викупу змінює прибутковість магазину сильніше, ніж будь-яка рекламна кампанія.
Важливо рахувати виручку в розрізі каналів і менеджерів. Часто виявляється, що канал із найбільшою кількістю замовлень дає найнижчий середній чек і найбільше повернень, а нібито «слабкий» канал приносить основну маржу. Без такої аналітики продажів бюджет розподіляється навмання.
Звіти мають бути доступні власнику без запиту до розробника. Достатньо кількох дашбордів, які оновлюються самі, і вивантаження в таблицю для глибшого розбору. Якщо для отримання цифри потрібно писати комусь у чат, нею не будуть користуватися.
Автоматичні сповіщення для клієнтів і команди
Автоматичні сповіщення знімають з менеджерів найнуднішу частину роботи. Клієнт отримує підтвердження замовлення, номер накладної, нагадування про оплату і повідомлення про прибуття посилки у відділення. Найкраще це працює в Telegram і Viber: доставка дешевша за SMS, а прочитання вище. Одне нагадування за день до закінчення терміну зберігання посилки помітно піднімає відсоток викупу.
Внутрішні сповіщення не менш важливі. Робочий чат команди отримує сигнал про замовлення на велику суму, про заявку, яку ніхто не взяв за 30 хвилин, про товар, залишок якого впав нижче порогу. Такі повідомлення мають бути точковими: якщо їх занадто багато, команда перестає реагувати вже через тиждень.
Технічно всі сповіщення варто будувати на шаблонах з підстановкою даних замовлення, а не писати текст руками в коді. Тоді контент-менеджер змінює формулювання без розробника. Обовʼязково передбачте резервний канал: якщо клієнт не має Telegram, повідомлення йде в SMS або на email. Ще одна деталь, про яку часто забувають, - тихі години. Повідомлення, відправлене о другій ночі, дратує сильніше, ніж допомагає, тому чергу сповіщень краще відкладати до ранку.
Вибір і налаштування: готове рішення чи власна система
Готові CRM закривають стандартний сценарій швидко і коштують передбачувано. Вони підходять, якщо ваші процеси схожі на процеси більшості магазинів: один склад, звичайна доставка, проста схема оплат. Проблеми починаються там, де є специфіка: виробництво під замовлення, дропшипінг з кількома постачальниками, товар з розмірною сіткою або серійними номерами, робота в двох країнах з різними правилами.
Перед вибором корисно виписати обовʼязкові інтеграції: сайт або маркетплейс, служби доставки, платіжний провайдер, бухгалтерія, месенджери, складський облік. Якщо для потрібної інтеграції в готовій CRM немає готового модуля, ви все одно платитимете за доробку, і часто дорожче, ніж коштувала б власна логіка з самого початку. Окремо перевірте, чи можна вивантажити свою базу клієнтів і замовлень у зрозумілому форматі: якщо дані заблоковані всередині сервісу, будь-який переїзд у майбутньому обійдеться в кілька місяців роботи.
Налаштування будь-якої системи варто починати з одного процесу, а не з усіх одразу. Спочатку перенесіть облік замовлень і клієнтську базу, дайте команді два-три тижні попрацювати, зберіть зауваження, і лише потім додавайте аналітику, сповіщення і сегментацію. У Devlly ми будуємо такі системи під конкретний магазин: збираємо реальні процеси, робимо робочу першу версію і поступово нарощуємо її навколо того, що вже приносить результат.