Небольшой интернет-магазин редко упирается в трафик. Он упирается в руки: заказы приходят с сайта, из Instagram и Telegram, менеджер сводит их в таблицу, звонит подтвердить, проверяет на складе, есть ли товар, вручную пишет клиенту трек-номер, а потом разбирается с возвратом, по которому никто не помнит, что обещали. При 10 заказах в день это терпимо, при 40 — команда работает на пределе, а ошибки «отправили не тот размер» становятся регулярными.
Автоматизация интернет-магазина — не про замену платформы и не про большой ИИ-проект. Это про четыре участка, где ручная работа и ошибки концентрируются: обработка заказов, остатки, уведомления и возвраты. Разберём каждый: что автоматизируется, как, и где человек по-прежнему нужен.
Участок 1. Заказы из всех каналов в одном месте
Первая проблема малого магазина — заказы живут в трёх–пяти местах. Сайт пишет в админку, Instagram — в Direct, Telegram — в личку менеджера, маркетплейс — в свой кабинет. Пока менеджер сводит их в одну таблицу, заказ из Direct теряется между сторис.
Решение — единая точка сбора. Это может быть CRM с модулем заказов, учётная система или даже хорошо устроенная таблица на первом этапе. Важно, чтобы каждый канал автоматически создавал в ней заказ со статусом «новый»: заявки с сайта по вебхуку, сообщения из Telegram через бота, Instagram и WhatsApp — через их бизнес-API. Менеджер больше не собирает заказы, он их обрабатывает.
Сюда же — автоматическая проверка: совпадает ли товар с номенклатурой, есть ли остаток, заполнен ли адрес и телефон. Неполные заказы получают пометку, а клиенту уходит уточняющий вопрос без участия менеджера. Если заказов из мессенджеров много и клиенты пишут свободным текстом, уточнять и собирать заказ может Telegram-бот с ИИ, который понимает «хочу те кроссовки из последнего поста, 42 размер».
Участок 2. Остатки, которые не врут
Продать товар, которого нет, — самая дорогая ошибка магазина: клиент ждал, деньги возвращать, отзыв отрицательный. Причина почти всегда в том, что остатки обновляются с задержкой или в разных системах по-разному.
Что автоматизируется:
- Синхронизация остатков между складом или учётной системой и всеми витринами: сайт, маркетплейсы, каталог в Telegram. Обновление раз в несколько минут, а не раз в день. Для 1С это решается через обмен или API — подводные камни разобраны в статье об интеграции с 1С и учётными системами.
- Резервирование при оформлении заказа, чтобы два клиента не купили последнюю единицу одновременно.
- Сигналы о низких остатках ответственному за закупки — в Telegram, с учётом скорости продаж: «этого товара осталось на четыре дня».
- Снятие с витрины товаров с нулевым остатком и возврат, когда поставка оприходована.
Где это не сработает: если склад ведётся «на глаз» и приход не оприходуется день в день. Автоматизация честно покажет цифры, которых нет. Порядок на складе — предварительное условие, а не результат автоматизации.
Участок 3. Уведомления клиенту на каждом шаге
Большая часть вопросов в поддержку магазина — одна фраза в разных формах: «где мой заказ». Клиент спрашивает не потому, что ему нужен ответ, а потому, что он не знает, что происходит. Автоматические уведомления закрывают эту потребность до того, как возник вопрос.
Минимальная цепочка: заказ принят — оплата получена — передан в сборку — отправлен с трек-номером — прибыл в пункт выдачи — получен. Каждый статус автоматически порождает сообщение в канал, откуда пришёл заказ: Telegram, WhatsApp, email или SMS. Статусы доставки берутся из API службы доставки, менеджер их не вводит.
Что стоит добавить, когда базовая цепочка работает:
- напоминание о неоплаченном заказе через час и через сутки;
- напоминание, что заказ лежит в пункте выдачи и срок хранения заканчивается;
- просьба об отзыве через несколько дней после получения — один раз, не три;
- сообщение о поступлении товара, которого не было в наличии, клиентам, которые о нём спрашивали.
Граница: уведомления — не рассылки. Если к статусам заказа добавляются акции и подборки, клиенты начинают блокировать канал, и статусы перестают доходить. Промо — отдельная история с отдельным согласием, об этом статья про Telegram-бот для программы лояльности.
Участок 4. Возвраты без хаоса
Возвраты в малом магазине обрабатываются хуже всего, потому что они редкие, неприятные и у каждого свои обстоятельства. Клиент пишет менеджеру, менеджер обещает разобраться, потом уточняет у склада, потом у бухгалтера, клиент пишет повторно. Автоматизация здесь не принимает решения, а ведёт процесс.
Что можно сделать:
- Заявка на возврат по форме в боте или на сайте: номер заказа, товар, причина, фото при необходимости. Заявка создаётся в системе со своим статусом, клиент получает подтверждение и сроки.
- Автоматическая проверка условий: прошёл ли срок возврата, категория товара, был ли заказ оплачен. Простые случаи получают готовое решение и инструкцию, сложные — уходят менеджеру с собранной информацией.
- Статусы возврата с уведомлениями: получили товар, проверили, деньги отправлены. Клиенту не нужно спрашивать.
- Учёт причин. Если из возвратов по одному товару половина с причиной «не соответствует размеру», это сигнал поправить описание или размерную таблицу, а не бесконечно обрабатывать возвраты.
Что остаётся за человеком: спорные случаи, претензии к качеству, конфликтные клиенты. Автоматизация должна распознавать такие обращения по признакам — повторное сообщение, негативные формулировки, слово «претензия» — и быстро передавать менеджеру, а не пытаться закрыть шаблонным ответом.
Как это собирается и во что обходится
Для магазина с десятками заказов в день не нужна тяжёлая ERP. Рабочая связка выглядит так: платформа магазина или CRM как центр, учётная система или таблица для остатков, n8n или Make как клей между ними и каналами, Telegram Bot API и WhatsApp Business API для общения с клиентами, API службы доставки для статусов. Если платформа магазина имеет встроенные уведомления и интеграции, часть сценариев закрывается ею без дополнительной сборки — это стоит проверить первым.
По срокам: сбор заказов в одно место и базовые уведомления — первые две недели. Синхронизация остатков — зависит от учётной системы, от нескольких дней до пары недель. Возвраты — ещё одна–две недели, когда предыдущее работает. Расходы на инфраструктуру для такого объёма ориентировочно десятки долларов в месяц; основная стоимость — разработка и интеграции, и она сильно зависит от того, насколько платформа магазина и учётная система открыты для подключения.
Пример: магазин детской одежды
Сайт плюс Instagram, 25–40 заказов в день в сезон, две сотрудницы на обработке и склад в том же помещении. Главные боли: заказы из Direct терялись, «где мой заказ» занимало половину переписки, возвраты по размеру тянулись неделями.
Сделали в три этапа. Сначала — все заказы в одну CRM с автоматической проверкой полноты и статусы доставки клиенту в тот канал, откуда пришёл заказ. Вопросы «где заказ» почти исчезли из переписки за первые недели. Затем — синхронизация остатков с витриной каждые десять минут и сигналы о низких остатках. Третьим этапом — форма возврата в Telegram-боте с автоматическим решением по простым случаям и учётом причин. Учёт причин показал, что два артикула возвращаются непропорционально часто из-за размерной сетки — поправили описание, возвраты по ним упали.
Что не автоматизировали: подтверждение заказов на крупные суммы — там по-прежнему звонит менеджер, потому что доля ошибок в адресах и телефонах у таких заказов оказалась выше, а цена ошибки — тоже.
С чего начать
Посчитайте, сколько сообщений за неделю — это вопросы о статусе заказа, и сколько заказов за месяц потерялось или ушло с ошибкой. Эти две цифры обычно и определяют первый шаг: если первая большая — начинать с уведомлений, если вторая — со сбора заказов в одно место. Остатки и возвраты — следующими.
Мы в AiKrok начинаем такие проекты с одного дня разбора: какие каналы, какая платформа, где лежат остатки, что умеет текущая система без доработок. Нередко выясняется, что половина нужного уже есть в платформе магазина и просто не включена. Остальное собирается за две недели первой версией, и дальше дорабатывается по тому, что показывает реальный поток заказов.