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