Товар закончился, а магазин об этом не знает. Реклама на него крутится, менеджер принимает заказы, покупатель ждет – и через день узнает, что позиции нет. Это не гипотетическая проблема, а ежедневная реальность любого магазина, который работает с чужим складом.
Клиент пришел именно с этим: “хочу получать уведомления в Telegram, когда товар закончился”. Дальше задача выросла в небольшой, но очень полезный сервис, который в поддержке стоит меньше, чем одна потерянная доставка. Расскажу, как это устроено и почему в итоге получилась группа, а не личный бот.
Почему группа, а не просто бот
Изначальная формулировка – “бот, который мне пишет”. Я предложил другое: бот в группе. Разница кажется косметической, а на практике решающая.
- Уведомление нужно не одному человеку. Об окончании товара должен знать и тот, кто ведет рекламу, и тот, кто принимает заказы, и закупщик. В личном чате это знает один человек, который потом пересылает скриншоты.
- Состав команды меняется. Пришел новый сотрудник – владелец сам добавил его в группу. Ушел – убрал. Меня беспокоить не надо.
- История остается. Видно, какой товар и когда заканчивался. Это само по себе полезные данные: если позиция исчезает еженедельно, с ней что-то не так в закупке.
- Обсуждение рядом с поводом. Прилетело уведомление – тут же в ветке договорились, кто звонит поставщику.
Эту схему я теперь предлагаю почти в каждом проекте, где есть регулярные уведомления или запуск по запросу.
Как это работает
Источник данных
Данные об остатках берутся из учетной системы клиента и из его прайса. Раз в пятнадцать минут сервис забирает актуальный срез и сохраняет его у себя.
Сравнение состояний
Вся суть в сравнении. Сервис держит предыдущее состояние каталога и сверяет с новым:
- товар был в наличии, а теперь его нет – уведомление “закончился”;
- товара не было в каталоге вообще, а теперь он появился – уведомление “новый товар”;
- товар отсутствовал и снова появился – отдельный тип события, это не то же самое, что новый.
Последний пункт – типичная ошибка в таких системах. Если не различать “новый” и “вернулся в наличие”, команда начнет получать уведомления о новых товарах, которых на самом деле нет, и быстро перестанет на них реагировать.
Уведомление
В группу приходит короткое сообщение: что за товар, артикул, ссылка на карточку, какой был остаток. Без лишнего текста. Сообщение должно читаться за две секунды с телефона.
Продолжение: уведомления о новых товарах
Примерно через неделю после запуска клиент попросил добавить обратное событие: сообщать, когда у поставщика появился новый товар. Логика простая и очень практичная – на новую позицию надо сразу запускать рекламу, пока конкуренты ее еще не завели.
Это один из лучших примеров того, как работает автоматизация на практике. Сначала закрывается боль (“мы продаем то, чего нет”), а потом та же механика начинает приносить деньги (“мы первыми видим новинки”). Технически это была та же проверка, только в другую сторону.
Почему каждые пятнадцать минут, а не постоянно
Частоту проверки всегда надо обосновывать, а не ставить максимальную “на всякий случай”.
- Реагировать быстрее, чем человек способен ответить, нет смысла. Если менеджер видит сообщение раз в час, проверка каждую минуту ничего не изменит.
- Частые проверки – это нагрузка на источник и на сервер, а значит деньги.
- Слишком частые уведомления перестают читать. Это главная причина смерти любой системы алертов.
Пятнадцать минут – разумный компромисс для розничного магазина. Для оптовика с редкими изменениями хватит часа. Для мониторинга дефицитных позиций бывает нужно чаще.
О чем обычно забывают
Защита от лавины сообщений
Поставщик выгрузил кривой прайс, в котором половина каталога вдруг оказалась “не в наличии”. Без защиты в группу прилетит несколько сотен сообщений подряд, и люди просто выключат уведомления. Поэтому есть порог: если разом изменилось подозрительно много позиций, вместо потока приходит одно сводное сообщение “изменилось столько-то позиций, похоже на сбой выгрузки”.
Молчание – тоже информация
Если источник перестал отдавать данные, сервис не должен тихо молчать. Отсутствие уведомлений легко перепутать с “все стабильно”. Поэтому отдельно контролируется сам факт успешного получения данных.
Повторные уведомления
Товар, который мигает туда-сюда между наличием и отсутствием, не должен генерировать десять сообщений в день. Такие позиции приглушаются и попадают в отдельный список для разбора.
Что входит в ежемесячную поддержку
Поддержка – это гарантия, что уведомления приходят каждый день и без пропусков. Я слежу за работой сервиса, обновляю его, когда меняется источник данных, и добавляю новые события, если они нужны команде. Вы об этом не думаете, вы просто получаете сообщения.
Стоимость зависит от источника данных, количества событий и частоты проверок. Назову ее после короткого разговора о вашем процессе.
Побочный эффект: сервис, который просто работает, создает доверие. После него клиенты обычно возвращаются со следующими задачами – например, контролировать остатки средств на счетах.
Кому это подойдет
- магазинам, работающим со складом поставщика, а не со своим;
- тем, кто крутит рекламу на конкретные товары и не хочет сливать бюджет на позиции, которых нет;
- командам, где за наличие, рекламу и закупку отвечают разные люди;
- тем, кто хочет первым видеть новинки у поставщика.
Источником может быть что угодно: учетная система с API, прайс по ссылке, выгрузка из личного кабинета или даже обычный сайт. Разница только в том, насколько сложно с него регулярно брать данные.
Если у вас есть что-то, за чем приходится следить руками и о чем вы регулярно узнаете с опозданием, – опишите задачу. Скорее всего, она решается небольшим сервисом с ежемесячной поддержкой. Смежное направление описано на странице интеграция CRM и сервисов через API.