Настройка уведомлений в Битрикс24 обычно проходит в два этапа. Сначала включают всё подряд, чтобы точно ничего не пропустить. Через неделю сотрудники отключают всё подряд, потому что телефон звенит каждые три минуты и работать невозможно. После этого важное начинают пропускать по-настоящему.
Разберём, как выбраться из этой ловушки: какие уведомления в Битрикс24 бывают, что действительно должно доходить до менеджера и до руководителя, а что нужно выключить в первый же день.
Почему уведомления перестают работать
Три причины, и ни одна из них не техническая.
Их слишком много. Человек способен реагировать на десяток сигналов в день. Когда их сотня, мозг перестаёт различать важное и начинает игнорировать всё подряд — включая то единственное, ради чего система и настраивалась.
Они приходят не тем. Уведомление о новой заявке улетает всему отделу. Каждый видит и каждый думает, что возьмётся кто-то другой. Классическая история, которая заканчивается «я думал, этим занимается Саша».
На них нельзя ответить. Уведомление «сделка изменена» не содержит ни того, что изменилось, ни того, что теперь делать. Такое сообщение можно только закрыть, и через неделю его закрывают не читая.
Хорошее уведомление отвечает на три вопроса сразу: что случилось, к кому это относится и что нужно сделать. Всё остальное — шум, который обесценивает и полезные сигналы тоже.
Какие каналы уведомлений есть в Битрикс24
Один и тот же повод может прийти разными путями, и путать их не стоит: у каналов разная срочность.
Уведомления внутри портала. Счётчики и колокольчик в интерфейсе. Видит только тот, кто сидит в системе. Годятся для всего, что не требует реакции в минуту.
Мобильные пуши. Приходят на телефон, вырывают из любого занятия. Именно поэтому в них должно попадать только по-настоящему срочное — иначе их отключат, и вместе с ними отключат всё.
Чат и чат-боты. Сообщение в рабочий чат от бота. Удобно для командных событий: «пришла заявка на сложный проект» в чат отдела.
Почта. Медленный канал, зато с историей и удобный для сводок: дневная или недельная выжимка руководителю.
СМС и мессенджеры клиенту. Отдельная история — это уже не внутренние уведомления, а коммуникация с клиентом: подтверждение заявки, напоминание о встрече.
Правило простое: чем срочнее событие, тем «громче» канал. Заявка, на которую нужно ответить за пятнадцать минут, — это пуш. Отчёт за неделю — это письмо. Перепутать их — верный способ приучить людей игнорировать телефон.
Что действительно должно уведомлять менеджера
Короткий список. Если он длиннее — вы уже создаёте шум.
Новое обращение, за которое он отвечает. Персонально, а не всему отделу. Заявка с сайта, звонок, сообщение в мессенджере — всё, что требует ответа.
Просроченная задача или сделка без движения. Сделка неделю висит на этапе — значит, о ней забыли. Такое напоминание приходит одному человеку и не требует ничьих решений.
Комментарий коллеги по его клиенту. Когда руководитель или смежник написал в карточку, это нужно увидеть.
Приближение дедлайна. За день до обещанного клиенту срока, а не в день.
Всё. Остальное менеджер посмотрит сам, когда откроет систему.
Что нужно выключить сразу
Список того, что чаще всего звенит зря.
Любые изменения в чужих сделках. Если человек не ответственный и не наблюдатель, его это не касается.
Уведомления о собственных действиях. Система иногда сообщает вам о том, что вы только что сделали сами. Это чистый шум.
Дублирование по всем каналам разом. Одно событие — один канал. Когда одна заявка приходит пушем, письмом и в чат, раздражение растёт втрое, а внимания не прибавляется.
Массовые рассылки по компании. Новости портала, дни рождения, объявления — оставьте их в ленте, не выводите в пуши.
Автоматические сообщения от роботов, которые никто не читает. Роботы удобны, но каждое их сообщение должно иметь адресата и смысл. Подробнее о том, как настраиваются роботы и триггеры, — в отдельной статье; здесь важно другое правило: если робот пишет «в никуда», его уведомление нужно выключить, а не терпеть.
Уведомления руководителю: другая логика
Ошибка, которую делают почти все: руководитель подписывается на то же, что и менеджеры, только по всему отделу. В результате он получает всё и не читает ничего.
Руководителю нужны не события, а отклонения. Разница принципиальная.
Событие: «менеджер Иванов перевёл сделку на этап "Согласование"». Такое приходит десятками в день и ни о чём не говорит.
Отклонение: «сделка на 400 000 ₽ не двигается пятый день», «за утро пропущено шесть звонков», «клиент написал второй раз, ответа не было». На такое можно и нужно реагировать.
Практический набор для руководителя отдела:
- сделки крупнее определённой суммы — при создании и при потере;
- сделки без движения дольше нормативного срока;
- отказы клиентов с указанной причиной;
- пропущенные обращения, которые никто не взял за час;
- дневная сводка утром: сколько пришло, сколько в работе, что зависло.
Крупные суммы и нормативные сроки — это ваши цифры, их нужно определить до настройки. Универсальных нет: для одной компании крупная сделка — сто тысяч, для другой — миллион.
Собственнику обычно хватает недельной сводки на почту и уведомлений о потерянных крупных сделках. Всё остальное — работа руководителя отдела, и вмешательство в неё через уведомления только мешает.
Как настроить: порядок действий
Шаг 1. Выпишите события, на которые кто-то обязан реагировать. На бумаге, до того как открывать настройки. Обычно получается пять-семь пунктов на менеджера и три-четыре на руководителя. Если получилось двадцать — вы описываете не реакции, а всё подряд.
Шаг 2. Для каждого события определите адресата. Конкретного человека или роль, а не «отдел». У события без адресата не будет и реакции.
Шаг 3. Выберите канал по срочности. Пуш — только для того, что требует ответа в течение часа. Остальное — в портал и почту.
Шаг 4. Отключите лишнее в общих настройках. Персональные настройки уведомлений есть у каждого сотрудника, но базовую конфигурацию задаёт администратор портала. Начинать нужно с неё, иначе каждый будет разгребать шум самостоятельно и по-своему.
Шаг 5. Настройте напоминания через роботов. Автоматические напоминания о зависших сделках и приближающихся сроках делаются в настройках воронки — там же, где настраиваются этапы сделок.
Шаг 6. Проверьте, что видно только своё. Уведомление не должно раскрывать сотруднику данные, к которым у него нет доступа. Это регулируется правами доступа, а не настройками уведомлений, но проверять надо вместе.
Шаг 7. Через две недели пересмотрите. Соберите обратную связь: что звенело зря, что не пришло вовремя. Первая настройка почти никогда не бывает точной, и это нормально.
Готовые наборы под разные типы бизнеса
Универсальной схемы нет, но есть три типовые ситуации, к которым сводится большинство компаний. Возьмите ближайшую как отправную точку.
Услуги с быстрым откликом: ремонт, доставка, срочные заявки
Здесь всё решает скорость: клиент пишет троим и работает с тем, кто ответил первым.
Менеджеру: пуш на новое обращение сразу, повторный пуш, если через десять минут ответа нет, пуш на входящее сообщение от клиента в работе. Руководителю: пуш на любое обращение без ответа дольше пятнадцати минут, дневная сводка по скорости ответа. Всё остальное — в портал.
Ключевая настройка — эскалация: если менеджер не отреагировал, сигнал уходит выше. Без неё быстрый отклик держится только на дисциплине конкретных людей.
B2B с длинным циклом: проекты, оборудование, внедрения
Сделка идёт месяцами, срочность не в минутах, а в том, чтобы не забыть о клиенте на три недели.
Менеджеру: напоминание о запланированном контакте, сигнал о сделке без движения дольше недели, уведомление о приближении обещанного срока. Руководителю: сделки крупнее пороговой суммы при создании и при потере, отказы с причиной, еженедельная сводка по зависшим.
Пуши здесь почти не нужны — хватает портала и почты. Зато критично, чтобы у каждой сделки была следующая запланированная активность, иначе напоминать будет не о чем.
Интернет-магазин и поток заказов
Заказов много, каждый по отдельности не событие. Уведомлять о каждом — гарантированно приучить людей игнорировать сигналы.
Менеджеру: только проблемные случаи — заказ с комментарием клиента, отказ от оплаты, возврат. Руководителю: отклонения в потоке — заказов за час меньше обычного, всплеск отказов, сбой оплаты. Клиенту при этом уведомлений нужно больше, чем сотрудникам: подтверждение, оплата, отгрузка.
Уведомления клиенту, а не только сотрудникам
Половина смысла настройки лежит на другой стороне: часть сигналов лучше отправлять не менеджеру, а сразу клиенту. Это снимает нагрузку с отдела и уменьшает число звонков «а что там с моим заказом».
Что обычно автоматизируют: подтверждение принятой заявки с указанием, когда с человеком свяжутся; напоминание о встрече или замере за сутки; сообщение о смене статуса заказа; запрос отзыва после закрытия сделки.
Два правила, которые стоит соблюдать. Первое: сообщение должно нести факт, а не вежливость — «ваша заявка принята, ответим до 12:00 завтра» работает, «спасибо за обращение» не работает. Второе: у клиента должна быть возможность ответить в том же канале, иначе вы получите поток входящих на номер, с которого рассылаете.
Технически это те же роботы на этапах воронки. Настраивается один раз и дальше работает само, но текст сообщений стоит написать самим, а не оставлять шаблоны по умолчанию.
Как понять, что настройка работает
Три проверки, которые можно сделать самому.
Спросите менеджера, что он делает с уведомлением. Если ответ «закрываю не глядя» — канал мёртв, событие нужно выключать или менять формулировку.
Посмотрите на время реакции. Между появлением заявки и первым действием по ней. Если после настройки оно не изменилось, уведомления не дошли или пришли не тем.
Проверьте пропущенные. Обращения, оставшиеся без ответа дольше суток, — прямой показатель того, что сигнальная система не работает. Эти цифры видны в отчётах.
Если уведомлений уже слишком много
Ситуация, в которой оказывается большинство компаний через год после внедрения. Разбирать её проще, чем кажется, — за один вечер.
Соберите факты за неделю. Попросите двух-трёх сотрудников неделю не удалять уведомления и просто посмотрите объём. Обычно выясняется, что три четверти приходится на два-три типа событий — их и надо чинить в первую очередь.
Разделите на три кучи. По каждому типу события ответьте: на это реагируют действием, это читают для сведения или это закрывают не глядя. Первое оставить, второе перевести в портал или сводку, третье выключить совсем.
Начните с выключения, а не с настройки. Соблазн велик сделать «умнее»: добавить условия, разнести по каналам. Но чем сложнее схема, тем меньше шансов, что её кто-то поймёт через полгода. Сначала уберите лишнее, а потом смотрите, чего не хватает.
Проверьте роботов. Частая причина лавины — роботы, настроенные когда-то под процесс, которого уже нет. Они исправно шлют сообщения в пустоту, потому что их никто не выключил вместе с изменением воронки.
Договоритесь, кто отвечает за конфигурацию. Без хозяина настройки снова расползутся: каждый новый процесс добавит своих уведомлений, а убирать их будет некому.
Обычная цифра после такой чистки — сокращение потока в три-четыре раза. Пропускать при этом начинают меньше, а не больше, потому что оставшиеся сигналы снова читают.
Частые ошибки
Настроили уведомления вместо процесса. Если непонятно, кто отвечает за заявку, никакое уведомление это не решит: оно придёт всем и не сделает ответственным никого.
Пуши на всё подряд «на всякий случай». Через неделю сотрудник отключает уведомления в телефоне целиком, и вы об этом не узнаете.
Не проверили мобильное приложение. Настройки в веб-версии и в приложении могут расходиться, а работают люди чаще с телефона.
Забыли про отпуска и выходные. Уведомления уходят человеку, которого нет на месте, и повисают. Замещающий об этом не знает.
Никто не отвечает за настройки. Через полгода в компании новые процессы, новые люди и старые уведомления. Пересматривать конфигурацию стоит хотя бы раз в полгода — обычно это делают вместе с ревизией воронок.
Частые вопросы
Можно ли настроить уведомления по-разному для разных отделов?
Да. Настройки задаются и на уровне портала, и на уровне групп и отделов, и персонально. Разумная схема: базовый набор задаёт администратор, руководитель отдела уточняет под свои процессы, сотрудник может отключить только то, что не критично.
Почему уведомления приходят с задержкой?
Чаще всего дело не в системе, а в устройстве: экономия батареи в телефоне отключает фоновую работу приложения. Проверьте настройки энергосбережения и разрешения для приложения. Если задержка есть и на компьютере — это повод обратиться в поддержку.
Что делать, если сотрудники отключают уведомления сами?
Сначала выяснить, почему. Обычно причина одна: шума больше, чем пользы. Запрещать бесполезно — человек просто отключит звук на телефоне. Работающий путь — сократить список событий до тех, на которые действительно нужно реагировать, и вернуть доверие к каналу.
Можно ли уведомлять клиента, а не только сотрудников?
Да, это делается теми же роботами: подтверждение заявки, напоминание о встрече, сообщение о смене статуса заказа. Только помните, что для клиента правило то же самое: одно сообщение по делу лучше пяти по любому поводу.
Чем уведомление отличается от задачи?
Уведомление сообщает и исчезает — за ним никто не следит, отчёта по нему нет. Задача живёт до закрытия, у неё есть ответственный и срок, и её невыполнение видно руководителю. Правило простое: если событие требует работы дольше пары минут или за него кто-то отвечает — это задача, а не уведомление. Пропущенный звонок, который надо разобрать, должен становиться задачей; сообщение «коллега прокомментировал вашу сделку» — обычным уведомлением. Путаница между этими двумя вещами и рождает ощущение, что «в системе всё теряется».
Нужны ли уведомления, если в компании три человека?
В таком составе почти всё решается голосом через стол. Полезны будут два-три: новая заявка, просроченная задача, зависшая сделка. Остальное только отвлекает.
Итог
Уведомления — это не про «не пропустить», а про «отреагировать». Сигнал, на который нельзя ответить конкретным действием, работает против вас: он приучает людей игнорировать систему.
Начните не с настроек, а с листа бумаги: выпишите пять событий, на которые в вашей компании обязаны реагировать в течение часа. Настройте только их, а через две недели посмотрите, что реально пришло и что с этим сделали. Это займёт меньше времени, чем разбор потерянной заявки.