У більшості компаній сповіщення налаштовані навпаки. Про кожну нову заявку приходить повідомлення в три канали одночасно, а про замовлення, яке зависло на четвертий день, не дізнається ніхто. Через місяць команда вимикає звук у робочому чаті — і тепер не бачить уже нічого.
Сповіщення — це найдешевший інструмент контролю, який є в бізнесу: він не вимагає ні нової системи, ні наймання людини. Але працює він лише тоді, коли налаштований за подіями, а не за принципом «повідомляти про все, що можемо».
Правило одне: сповіщення = дія
Перевірка, чи потрібне сповіщення, зводиться до одного питання: що конкретна людина зробить, отримавши його? Якщо відповідь «нічого» або «просто буде в курсі» — сповіщення не потрібне. Для «бути в курсі» існують звіти, і їх дивляться раз на день, а не смикають людину щохвилини.
Ця перевірка одразу відсіює більшість типових налаштувань «з коробки»: клієнт відкрив лист, змінено картку товару, створено новий запис. Це події, а не приводи діяти.
І навпаки — вона підсвічує те, про що зазвичай не повідомляють: невдале списання оплати, збій обміну з сайтом, замовлення без руху третій день. Тут дія очевидна, а от повідомлення немає.
Що справді варте сповіщення
Нова заявка або замовлення. Класика, і вона потрібна — але з умовою: сповіщення має йти конкретному відповідальному, а не в загальний чат. Коли повідомлення бачать усі, реагує зазвичай ніхто. Механіка розподілу описана в матеріалі про автоматизацію обробки заявок.
Застій. Найкорисніший тип: замовлення без зміни статусу N годин, заявка без відповіді, рахунок без оплати після строку. Саме тут ховаються гроші, які втрачаються тихо. Про сам ланцюжок статусів — у матеріалі про обробку замовлень.
Гроші. Невдалий платіж, повернення, розбіжність в оплаті, борг, що перевищив ліміт.
Склад. Критичний залишок за позиціями, які реально продаються, а не за всім асортиментом; про пороги — у матеріалі про складський облік.
Клієнтський негатив. Низька оцінка в опитуванні, скарга, різкий відгук. Реагувати на це треба годинами, а не тижнями; збір оцінок — у розборі опитувань клієнтів.
Технічні збої. Сайт недоступний, форма не відправляється, обмін із маркетплейсом зупинився. Про це часто дізнаються від клієнта — тобто найдорожчим способом; що робити далі, описано в матеріалі що робити, якщо сайт не працює.
Кому й куди
Адресність. У кожного сповіщення має бути один отримувач або мала група з зрозумілою відповідальністю. «Усім у загальний чат» — найпоширеніша помилка: розмита відповідальність гарантує, що не відреагує ніхто.
Канал за строковістю. Те, на що треба реагувати за хвилини, — месенджер або пуш. Те, що потребує обмірковування і зберігання, — пошта. Дублювати одне й те саме в обидва канали не варто: це найшвидший спосіб привчити людей ігнорувати обидва. Як звести всі клієнтські канали в одне місце — у матеріалі про інтеграцію месенджерів.
Ескалація. Для критичних подій — правило другого кола: якщо на сповіщення не відреагували за N хвилин, воно йде керівнику. Це те, що перетворює сповіщення з інформування на робочий механізм.
Як не потонути в шумі
Групуйте однотипне. Двадцять окремих повідомлень про нові замовлення за годину — це шум. Одне зведення «12 нових замовлень, 3 без відповіді понад 2 години» — інформація.
Розділяйте термінове й фонове. Терміновому — окремий канал, який реально читають. Фоновому — щоденне зведення зранку.
Дотримуйтеся робочих годин. Сповіщення о другій ночі про подію, якою займуться о девʼятій ранку, лише псує сон і поступово знецінює канал.
Переглядайте раз на квартал. Дивіться, на що ніхто не реагував три місяці, і вимикайте. Кількість сповіщень має тільки скорочуватися; вона природно росте сама, бо кожне нове здається корисним.
Технічно все це збирається без розробки — правилами в CRM або звʼязками між сервісами, як описано в матеріалі про no-code автоматизацію. А різницю між сповіщеннями команді й повідомленнями клієнтам розібрано в матеріалі про автоматичні нагадування клієнтам — це різні механіки, і плутати їх не варто.
Коротко
Сповіщення потрібне лише тоді, коли на нього є конкретна дія; «просто бути в курсі» закривають щоденним зведенням, а не смикають людину. Найкорисніший тип — не про появу нової заявки, а про застій: замовлення без руху, заявка без відповіді, рахунок без оплати після строку — саме тут гроші втрачаються тихо. Обовʼязкові теми: гроші (невдалий платіж, борг), критичні залишки за ходовими позиціями, клієнтський негатив, технічні збої. Кожне сповіщення має адресата, а не «загальний чат»; термінове йде в месенджер, несрочне — на пошту, дублювати в обидва не варто. Для критичного налаштовують ескалацію: немає реакції за N хвилин — повідомлення керівнику. Проти шуму працюють групування однотипного у зведення, розділення термінового й фонового, повага до робочих годин і щоквартальний перегляд із вимкненням неробочих правил. Що ще варто автоматизувати першим — у матеріалі про автоматизацію складу.
Ми в Obliko впроваджуємо автоматизацію для бізнесу і починаємо саме зі сповіщень про застій — це найшвидший спосіб побачити, де процес зупиняється, ще до того, як міняти саму систему.
Які події справді варті сповіщення?
Ті, що вимагають дії людини й мають строк. Нова заявка, зависле замовлення без руху кілька годин, невдалий платіж, критичний залишок, скарга клієнта, збій інтеграції. Не варті сповіщення події, які нічого не змінюють у поведінці: «клієнт відкрив лист», «змінено опис товару», «створено новий запис». Просте правило перевірки: якщо на сповіщення ніхто ніколи не реагує дією — воно не потрібне, і його треба вимкнути, а не терпіти.
Куди краще слати сповіщення — на пошту чи в месенджер?
Залежить від строковості. Термінове — те, на що треба відреагувати за хвилини, — у месенджер або пуш: пошту перевіряють раз на кілька годин. Несрочне й таке, що потребує обмірковування, — на пошту, вона краще зберігає історію та вкладення. Найгірший варіант — слати все й туди, і туди: дублювання швидко привчає ігнорувати обидва канали, і разом із шумом губиться справді важливе.
Як не перетворити канал сповіщень на шум?
Три правила. Перше — адресність: сповіщення йде конкретній людині або невеликій групі, а не в загальний чат «усім». Друге — щільність: часті однотипні події групують у зведення раз на годину або на день замість окремих повідомлень. Третє — регулярний перегляд: раз на квартал вимикайте те, на що ніхто не реагував. Канал, у якому 90% повідомлень не потребують дії, перестає працювати повністю — його просто перестають читати.
Що важливіше — сповіщення про нову заявку чи про зависле замовлення?
Про зависле. Нову заявку зазвичай і так помічають — вона видима, вона приємна, і за нею стежать. А от замовлення, яке лежить у статусі «очікує уточнення» третій день, не помічає ніхто: воно не нове, воно ніде не блимає, і саме воно тихо перетворюється на втрачені гроші й негативний відгук. Сповіщення про застій дає більше користі, ніж сповіщення про появу.
Потрібен сайт або застосунок?
Розробляємо під ключ — від дизайну до запуску. Порахуємо ваш проєкт безкоштовно.