CRM для дропшипінгу: замовлення, постачальники і маржа
Дропшипінг виглядає простим, поки замовлень десять на тиждень. Далі починається справжня робота: одне замовлення пішло до одного постачальника, друге до іншого, третє скасували, а четверте зависло без трек-номера. Заявки лежать у Direct, оплати в банківському застосунку, залишки в чужому прайсі. CRM для дропшипінгу потрібна не для краси - вона збирає ці розрізнені шматки в один список, де видно кожне замовлення і скільки ви на ньому заробили.
Чим CRM для дропшипінгу відрізняється від звичайної
Класична CRM побудована навколо угоди з клієнтом: контакт, переговори, оплата. У дропшипінгу центр ваги інший - у вас немає складу, і половина процесу відбувається на боці постачальника. Тому картка замовлення тут має тримати два ланцюжки одразу: що ви пообіцяли клієнту і що реально зробив постачальник.
Звідси перша вимога: у кожному замовленні має бути поле «постачальник» і власний статус його частини процесу. Клієнт бачить «замовлення прийнято», а всередині системи це може означати «ще не передано» або «передано, чекаємо відправки». Коли ці два статуси злиті в один, менеджер починає перевіряти все вручну по чатах.
Друга відмінність - товар. У звичайному магазині товар ваш, і залишок ви контролюєте. У дропшипінгу залишок чужий і змінюється без попередження. Тому система має зберігати не лише назву позиції, а й посилання на неї в постачальника, його ціну і дату останнього оновлення. Інакше ви продасте те, чого вже немає.
Третя - гроші. Ви отримуєте оплату від клієнта і окремо платите постачальнику, часто в іншій валюті і за іншим графіком. Система, яка не тримає ці дві суми поруч у межах одного замовлення, показує обіг, а не прибуток.
Картка замовлення: від заявки до трек-номера
Основна одиниця обліку в дропшипінгу - замовлення, а не клієнт. Мінімальний набір полів такий: що замовили і скільки, контакт і адреса доставки, постачальник, закупівельна ціна, ціна продажу, статус оплати, статус у постачальника і трек-номер. Цього вистачає, щоб закрити майже всі щоденні питання не відкриваючи листування.
Статуси варто описати один раз і не плодити. Робочий набір: нове, підтверджено, передано постачальнику, відправлено, доставлено, оплачено, скасовано, повернення. Вісім станів покривають усе, і за кожним стоїть конкретна дія - або хтось має щось зробити, або замовлення справді чекає.
Окремо фіксуйте час, коли замовлення перейшло в «передано постачальнику». Це головна точка, де все зависає. Якщо через добу трек-номера немає, система має підсвітити замовлення сама, а не чекати, поки напише клієнт.
Трек-номер має жити в картці, а не тільки в повідомленні клієнту. Тоді на питання «де моє замовлення» відповідає бот або менеджер за кілька секунд, і не треба піднімати листування двотижневої давнини.
Кілька постачальників в одній системі
Один постачальник - це початковий етап. Далі зʼявляється другий з кращою ціною на частину позицій, третій зі швидшою відправкою по своєму регіону, четвертий під конкретну категорію. І тут таблиця перестає працювати: у кожного свій прайс, свій формат вивантаження і свої правила.
У CRM це вирішується довідником постачальників. Для кожного зберігаються умови: як передавати замовлення, за скільки годин відправляє, які дні вихідні, яка мінімальна сума, як рахує доставку і що робить з поверненнями. Ці дані потрібні не для звіту, а щоб система сама ставила в замовленні реальний строк, а не оптимістичний.
Коли одна позиція є у двох постачальників, зафіксуйте пріоритет: основний і запасний. Тоді при відсутності товару менеджер не шукає альтернативу заново, а бачить готовий варіант із ціною і строком. Плюс потрібен простий зріз по постачальниках: скільки відправлено вчасно, скільки скасовано через відсутність товару, скільки повернень. Через два-три місяці стає очевидно, з ким працювати далі.
Маржа по кожному замовленню, а не «в середньому»
Найчастіша помилка дропшиппера - рахувати націнку у відсотках і вважати це прибутком. Реальна маржа замовлення - це ціна продажу мінус закупівля, мінус доставка, мінус комісія платіжної системи, мінус вартість реклами на це замовлення, мінус втрати на поверненнях. Кожен з цих пунктів окремо виглядає дрібницею, а разом вони зʼїдають половину.
Тому в картці замовлення тримайте всі складові: закупівельну ціну, доставку і комісії. Реклама рахується не на замовлення, а на канал за період, і потім розподіляється, - але навіть груба оцінка краща за її відсутність.
Коли маржа рахується по кожній позиції, зʼявляються неочевидні речі. Частина товарів дає гарний обіг і майже нульовий прибуток. Окремі категорії мають високий відсоток повернень, який зʼїдає всю націнку. Один напрямок доставки стабільно збитковий через відмови на пошті. Саме цей звіт відповідає, що прибрати з асортименту, а що масштабувати рекламою.
Коли таблиць уже мало і що обрати
Google Таблиці чесно тримають перші сто замовлень. Ознаки, що межа пройдена: ви відкриваєте кілька вкладок, щоб зібрати одне замовлення; двоє людей правлять один файл і затирають рядки; ви не памʼятаєте, які замовлення чекають трек-номера; звіт по маржі збирається руками наприкінці місяця і тому не збирається взагалі.
Готові CRM закривають частину задач, але майже всі побудовані під класичні продажі. Поля постачальника, закупівельної ціни і статусу відправлення туди доводиться доліплювати кастомними полями, а автоматичну передачу замовлення постачальнику - взагалі писати збоку.
Практичний шлях - рухатися кроками: спершу єдиний список замовлень із повним набором полів, потім бот або форма прийому, далі автоматична передача постачальнику і трекінг, наостанок звіт по маржі. Кожен крок закриває конкретний біль і окупається окремо. Devlly збирає такі системи під конкретну схему роботи: ваші постачальники, ваші статуси і ваш розрахунок прибутку, без модулів, які в дропшипінгу ніколи не відкриють.