CRM для продавців на маркетплейсах: своя, готова чи таблиці

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

Де ламаються таблиці

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

• Замовлення переносять вручну. З кожного майданчика — у свій аркуш, потім у загальний. Що більше замовлень, то більше помилок у номерах і сумах.
• Залишки не збігаються. Товар продали на одному майданчику, а на іншому він досі «в наявності».
• Собівартість невідома. Партії закуповувалися за різними цінами, а в таблиці стоїть одна цифра.
• Статуси живуть окремо. Накладну створили, а на майданчику замовлення досі «нове», і покупець не знає номера відправлення.
• Немає історії. Хто змінив рядок і коли, з’ясувати важко.
• Доступи «все або нічого». Оператор бачить фінанси, бухгалтер випадково править замовлення.

Жодна з цих проблем не критична сама по собі. Критично, коли на звірку таблиць іде більше часу, ніж на продажі.

Таблиці, готова CRM і власна система: порівняння

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

Що має вміти система для маркетплейсів

Ось перелік, із яким варто йти і на демо готової CRM, і до розробника:

1. Імпорт замовлень з усіх майданчиків в один список.
2. Зворотна передача статусу. Змінили статус у системі — він оновився на майданчику.
3. Склад із залишками по складах, резервом під замовлення та обліком партій.
4. Доставка. Створення накладної з картки замовлення, відстеження статусу, передача трек-номера покупцеві.
5. Фінанси. Взаєморозрахунки з постачальниками, витрати, прибуток за період.
6. Каталог. Робота з фідами постачальників, правила відбору товарів, розрахунок ціни з урахуванням комісії майданчика.
7. Ролі. Оператор, бухгалтер і рекламник бачать лише свої розділи.
8. Сповіщення про нові замовлення та збої.

Якщо готова система закриває шість пунктів із восьми, а два інших вам некритичні, власна розробка не потрібна.

Що таке FIFO і навіщо він продавцю

FIFO — «першим прийшов, першим пішов». Товар списується з найстарішої партії, і собівартість береться саме з неї.

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

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

ШІ в каталозі: де він допомагає

Картки товарів для маркетплейсів — окрема рутина. Кожен майданчик має власний довідник категорій і характеристик, вимоги до назв і описів. Заповнювати це вручну для тисяч позицій довго.

ШІ тут корисний за однієї умови: він працює лише з тим, що є у вихідних даних постачальника. Модель може переписати назву за правилами майданчика, розкласти характеристики по полях довідника, скласти опис. Але додавати властивості, яких немає у фіді, вона не повинна — інакше в картці з’явиться матеріал чи розмір, якого товар не має, і це закінчиться поверненням.

Той самий принцип — модель оформлює, а факти беруться з даних — ми застосовуємо і в спілкуванні з покупцями: про це стаття про ШІ-чат для інтернет-магазину.

З нашої практики: Orders CRM

Магазин продавав на кількох маркетплейсах, а товар відвантажували постачальники. Замовлення оброблялися в самописній системі на чистому PHP, а склад, фінанси й каталог велися окремо — у Google-таблицях. Потрібна була одна система, де замовлення проходить увесь шлях: від надходження з майданчика до обліку грошей і собівартості.

Ми замінили стару систему на Orders CRM — панель на Laravel із Filament. Що вона робить:

• імпортує замовлення з Prom, Rozetka та Horoshop в один список і повертає зміну статусу на майданчик;
• веде залишки по складах і партіях за FIFO: резерв робиться переміщенням між складами, собівартість фіксується в момент відвантаження;
• створює накладну Нової Пошти з картки замовлення з автопідбором міста й відділення, відстежує доставку у фоні та сама передає трек-номер на майданчик і клієнту;
• читає фіди постачальників, відбирає товари за правилами й рахує ціну від маржі з урахуванням комісії майданчика;
• готує назви, описи й характеристики карток під Prom і Rozetka за довідником майданчика, не вигадуючи фактів, яких немає у вихідних даних;
• веде рахунки, взаєморозрахунки з постачальниками, зарплати та звіт про прибутки і збитки.

У системі чотири ролі: адміністратор, оператор, рекламник і бухгалтер — кожен працює зі своїми розділами. Завдання та сповіщення в Telegram зібрані в тій самій панелі.

Крім CRM, ми робимо й інші робочі інструменти для команд: платформа Drip Tools для обробки фото товарів і панель SEO Monitor. Про другу ми написали окремо — це той самий вибір «платити за підписку чи зробити своє», тільки для відстеження позицій сайту.

Висновок

Залишайтеся на таблицях, поки вони не забирають час. Беріть готову CRM, якщо ваш процес типовий. Замовляйте власну, коли облік складу, постачальників і грошей має працювати саме так, як влаштований ваш бізнес, а готові системи змушують підлаштовуватися.

Перший крок однаковий у всіх трьох випадках: описати шлях замовлення від майданчика до грошей на рахунку. Якщо хочете пройти його разом, подивіться, як ми робимо CRM та внутрішні панелі, або напишіть нам.