Як автоматизувати обробку замовлень для інтернет-магазину
Поки замовлень п’ять на день, магазин чудово живе на Excel і телефоні. Проблеми починаються на тридцятому: менеджер фізично не встигає передзвонити всім, ТТН оформлюються до півночі, а клієнт пише «де моє замовлення?», бо статус ніхто не оновив. Власник при цьому впевнений, що потрібно наймати ще одну людину. Насправді у більшості магазинів 60-70% дій із замовленням — це механічне перенесення тих самих даних із однієї системи в іншу. Саме ці дії й забирає на себе автоматизація обробки замовлень. Нижче — де конкретно втрачається час, що можна закрити технічно й скільки годин це реально повертає.
Де насправді втрачається час на обробці замовлень
Візьміть одне замовлення й чесно розпишіть його шлях. Заявка приходить на пошту або в адмінку сайту — менеджер відкриває її, копіює ім’я, телефон, товар і адресу в робочу таблицю. Це дві-три хвилини й перше місце, де народжуються помилки: переплутана цифра в номері телефону, загублена літера в прізвищі, не той варіант товару. Далі дзвінок на підтвердження. Клієнт не бере, менеджер передзвонює, клієнт передзвонює сам через дві години — усе це ще п’ять-сім хвилин чистого часу й розірваний фокус. Потім ручне створення ТТН у кабінеті Нової пошти: знову ті самі ПІБ, телефон, відділення, вага, оголошена вартість — ще три-чотири хвилини й ще одна нагода помилитися. Наприкінці менеджер вручну проставляє статус у таблиці, а ще краще — забуває це зробити.
Порахуйте: 12-15 хвилин рутини на замовлення. При тридцяти замовленнях на день це шість-сім годин — повний робочий день людини, яка нічого не продає, а лише переносить дані. При п’ятдесяти замовленнях у пікові дні магазин просто фізично не встигає, і замовлення починають «протухати»: клієнт не дочекався дзвінка і купив у конкурента. Показово, що жодна з цих операцій не потребує людського рішення. Скопіювати дані з форми, надіслати повідомлення, створити ТТН за шаблоном, оновити статус — це чиста механіка, яку алгоритм виконає за секунду й без помилок. Людина потрібна там, де є нестандарт: клієнт хоче замінити товар, просить нестандартну доставку, скаржиться. Усе інше — робота для системи.
Автопідтвердження замовлення: перший крок автоматизації обробки замовлень
Дзвінок на підтвердження — найдорожча звичка українських магазинів. Він з’явився тоді, коли форми на сайтах були сирі й клієнти помилялися в даних. Сьогодні у 80-90% випадків підтверджувати нічого не треба: людина свідомо обрала товар, вказала відділення й натиснула «купити». Замість дзвінка система одразу після оформлення надсилає повідомлення у Viber, Telegram або SMS: склад замовлення, сума, спосіб доставки, відділення та дві кнопки — «підтверджую» і «хочу змінити». Клієнт відповідає за десять секунд у зручний йому момент, а не тоді, коли він за кермом чи на нараді. Ті, хто натиснув «хочу змінити», потрапляють до менеджера в чергу — і саме на них він витрачає час.
Ефект видно вже першого тижня. Менеджер робить не тридцять дзвінків, а три-п’ять. Підтвердження приходять уночі й на вихідних, коли магазин не працює, тож у понеділок вранці частина замовлень уже готова до відправки. Типова помилка на цьому кроці — надсилати сухе «Ваше замовлення прийнято» без деталей. Таке повідомлення не знімає тривогу клієнта, і він усе одно телефонує. Перелічіть у тексті товари, суму й відділення: людина бачить, що система її правильно зрозуміла, і питання відпадає саме собою. Другий нюанс: якщо клієнт мовчить дві години, має спрацювати нагадування, а якщо мовчить добу — тоді вже дзвінок менеджера. Автоматизація не скасовує телефон, вона просто залишає його для тих випадків, де він справді потрібен.
Інтеграція з Новою поштою: ТТН і трек-номер без ручної роботи
У Нової пошти є відкритий API, і це найшвидша перемога в усій історії з автоматизацією. Щойно клієнт підтвердив замовлення, система сама формує експрес-накладну: підставляє отримувача, телефон, місто й відділення з картки замовлення, рахує вагу та оголошену вартість за товарами, обирає платника й тип доставки за правилами магазину. ТТН створюється за секунду, номер одразу записується в замовлення й тим самим повідомленням летить клієнту разом із посиланням на відстеження. Далі система раз на кілька годин опитує статус посилки й повідомляє клієнту ключові події: «відправлено», «прибула у відділення», «очікує 3 дні», «повертається до відправника». Менеджер не заходить у кабінет Нової пошти взагалі — він лише друкує маркування пачкою в кінці дня.
Інтеграція з Новою поштою закриває ще дві болючі речі. Перша — довідник відділень і поштоматів завжди актуальний, бо тягнеться з API, а не з вручну вбитого списку трирічної давності. Клієнт обирає відділення прямо у формі на сайті чи в боті, і воно гарантовано існує. Друга — контроль «зависань». Система бачить посилки, які лежать у відділенні п’ятий день, і сама надсилає клієнту нагадування, а менеджеру — сигнал у Telegram. Це прямо зменшує кількість повернень, кожне з яких коштує магазину подвійної доставки й замороженого товару. Ще одна деталь, про яку часто забувають: у ТТН варто одразу зашивати правильний опис вкладення й оголошену вартість — це рятує в спірних ситуаціях із пошкодженням посилки.
Синхронізація залишків — основа автоматизації інтернет-магазину
Найгірший сценарій для магазину — продати те, чого немає. Клієнт оплатив, менеджер дзвонить вибачатися, репутація й гроші летять разом. Виникає це тоді, коли залишки живуть у трьох місцях одночасно: на сайті, на маркетплейсі та у складській таблиці, і зводяться вручну раз на день. Розв’язання — один спільний склад як єдине джерело правди й двостороння синхронізація. Продали одиницю на Rozetka — залишок миттєво зменшився на сайті. Оприбуткували постачання на складі — товар з’явився в усіх каналах. Резерв ставиться в момент оформлення замовлення, а не в момент відвантаження, тож два клієнти не можуть купити останню одиницю одночасно. Технічно це синхронізація через API кожного майданчика з інтервалом у кілька хвилин, а не вивантаження файлів руками.
Разом із залишками автоматизується й рух статусів. Замовлення проходить шлях «нове — підтверджене — комплектується — відправлене — отримане — оплачене», і на кожному переході спрацьовує своя дія: клієнту летить повідомлення, складу — завдання на збірку, бухгалтерії — запис про оплату. Ключове правило: статус має змінюватися подією, а не людиною. Створили ТТН — замовлення саме стало «відправленим». Нова пошта віддала статус «отримано» — замовлення саме закрилося. Коли статуси проставляють руками, вони завжди відстають від реальності, і власник дивиться на цифри, яким не можна вірити. Коли їх ставить система, панель замовлень показує справжню картину в будь-яку секунду, а клієнт перестає писати в директ із питанням, де його посилка.
Кинуті кошики, повернення і ранкове зведення продажів
Коли базова обробка замовлень працює сама, звільняється ресурс на речі, до яких раніше не доходили руки. Кинуті кошики: людина додала товар, дійшла до оплати й зникла. Через годину система надсилає ненав’язливе нагадування з посиланням на кошик, ще через добу — друге, іноді з невеликою знижкою. У середньому це повертає 8-15% таких кошиків, і це чистий дохід із трафіку, за який уже заплачено. Повернення теж варто прогнати через сценарій: клієнт заповнює коротку форму або відповідає боту, отримує інструкцію та ТТН на зворотну відправку, а менеджер бачить заявку вже структурованою й не витрачає двадцять хвилин на з’ясування, що саме й чому повертають. Заодно накопичується статистика причин повернень — а це прямий натяк, який товар чи опис треба виправити.
Останній штрих — щоранку о дев’ятій власник отримує в Telegram коротке зведення: скільки замовлень за вчора, на яку суму, середній чек, скільки відправлено, скільки зависло без підтвердження, які товари закінчуються на складі. Тридцять секунд читання замість години копирсання у звітах. Разом усі описані кроки прибирають ті самі 12-15 хвилин рутини з кожного замовлення й повертають магазину при 30-50 замовленнях на день близько шести-восьми годин щодня — фактично ставку менеджера, яку не треба наймати. Саме такі системи ми в Devlly і будуємо: зв’язку сайту, складу, Нової пошти й Telegram під конкретні процеси магазину. Починати варто з найдорожчого болю — зазвичай це підтвердження й ТТН, — а не намагатися автоматизувати все одразу.