напоминания и дедлайны в битрикс24: как настроить

уведомление — это не дедлайн

В Битрикс24 по умолчанию напоминание работает обычным уведомлением: система один раз толкает push или письмо, пользователь его видит или не видит, и дальше ничего не происходит. Никакой ответственности, никакой эскалации, никакого следа в отчёте, если человек просто закрыл уведомление не глядя.

На моих проектах это первая вещь, которую я проверяю на аудите: как выглядит цепочка событий после того, как срок задачи прошёл. В 7 из 10 компаний — никак. Задача просто переходит в статус «просрочена» и висит там неделями, потому что никто, кроме самого исполнителя, об этом не узнаёт.

Дедлайн в смысле управления, а не в смысле календарной даты — это связка из трёх вещей: срок, ответственный и последствие при нарушении срока. Управлять сроком с реальной ответственностью, а не просто уведомлением, в Битрикс24 можно — все три части есть технически, но по умолчанию система настраивает только первую. Остальные две приходится собирать руками — и именно об этом статья.

крайний срок и плановая дата — в чём путаница

В карточке задачи есть два разных поля с датой, и их путают почти всегда: «Срок постановки» (крайний срок, до которого задачу нужно закрыть) и плановая дата завершения — «Начать не раньше» или дата в планировщике, если задача привязана к проекту. Система шлёт напоминание именно по крайнему сроку, и если менеджер двигает его вручную при переносе звонка на пару часов — вместе со сроком уезжает и вся логика заблаговременных напоминаний.

Конкретный сценарий с моих проектов: крайний срок задачи стоит один в один с плановым временем звонка клиенту. Звонок переносится на два часа позже — менеджер, недолго думая, двигает и крайний срок задачи на эти же два часа. Формально задача больше не просрочена. Фактически система перестаёт присылать «скоро дедлайн», потому что этот триггер считается от текущего крайнего срока, а не от исходного плана.

Правило, которое я ставлю на сопровождении: крайний срок в задаче должен быть с запасом от реального времени, когда работа нужна клиенту, — минимум на несколько часов, а для многодневных задач на день-два. Смещать его вручную при любом переносе — плохая практика, которая ломает всю цепочку напоминаний.

умные дела — автонапоминания по полям crm

Умные дела (Smart Activities) — механизм, которым в Битрикс24 закрывается большинство сценариев «напомнить самому, а не полагаться на менеджера». Умное дело создаётся автоматически по правилу, привязанному к полю карточки CRM, а не выставляется человеком вручную каждый раз.

В одном проекте на сопровождении я настроил умное дело на поле «дата следующего контакта» в сделке: вместо того чтобы менеджер сам ставил себе напоминание после каждого звонка, система сама создаёт дело за 2 дня до этой даты, а если контакт состоялся раньше срока — переносит или закрывает его автоматически. Просроченные контакты в этой воронке упали с 18 в месяц до 3 уже за первый месяц работы правила.

Отличие от обычного дела в том, что умное дело живёт по логике поля, а не по разовой команде: изменилось поле в карточке — пересчиталось и напоминание. Ручное дело при этом не пересчитывается никогда, оно жёстко привязано к моменту создания.

ручные напоминания vs роботы на стадии воронки

Ручное напоминание уместно там, где решение принимает человек и заранее неизвестно, когда именно нужно напомнить: «уточнить у бухгалтерии», «перезвонить, если клиент не ответит на письмо». Это разовые, непредсказуемые по времени вещи, и создавать под них автоматизацию не имеет смысла.

Робот на стадии воронки уместен там, где правило можно сформулировать заранее и оно повторяется в каждой сделке: «если сделка находится на стадии «Выставлен счёт» дольше 3 дней — поставить задачу ответственному» или «если сделка не двигалась 5 дней — уведомить руководителя отдела». Такие правила один раз настраиваются в бизнес-процессах или роботах CRM и дальше работают без участия менеджера.

Ошибка, которую вижу часто: компания пытается закрыть предсказуемые, повторяющиеся ситуации ручными напоминаниями, которые менеджер должен помнить поставить сам. Это надёжно работает первую неделю после внедрения, а дальше рассыпается — про постановку напоминания тоже нужно не забыть, и это точно такая же память человека, от которой мы изначально пытались уйти. Подробный разбор конкретных сценариев для роботов и триггеров я собрал отдельно — в статье про роботов и триггеры в Битрикс24.

эскалация просроченных задач — не только исполнителю

Стандартное поведение Битрикс24 при просрочке — повторное напоминание тому же самому человеку, который уже пропустил первое. Если он игнорирует уведомления системно, это никак не меняется само собой: постановщик и руководитель узнают о просрочке, только если сами зайдут и посмотрят отчёт.

Эскалация настраивается бизнес-процессом: если задача просрочена больше суток — уведомление уходит постановщику, если больше трёх дней — руководителю отдела с прямой ссылкой на задачу. Это не встроенная функция «из коробки», её собирают через конструктор бизнес-процессов на объекте «Задача», с условием по дате крайнего срока и статусу.

На практике одной этой настройки хватает, чтобы количество хронически просроченных задач упало в разы — не потому что появилось наказание, а потому что сама вероятность, что просрочку никто не заметит, исчезла. Люди в 8 из 10 случаев перестают затягивать задачи, когда знают, что просрочка видна не только им самим.

напоминания для повторных продаж

Отдельный класс напоминаний — не про текущую сделку, а про контакт с клиентом, который уже купил и с которым нужно связаться повторно: продлить услугу, предложить сопутствующий товар, узнать, как всё работает через месяц. Здесь ручные напоминания проигрывают почти всегда, потому что горизонт — недели или месяцы, и менеджер физически не держит это в голове среди текущих задач.

Логика та же, что и с умными делами из предыдущего раздела: правило привязывается к дате последней покупки или последнего контакта, а не к разовой команде человека. Например, «через 25 дней после закрытия сделки создать дело на повторный контакт» — и это правило работает одинаково для каждой новой сделки, без участия менеджера в момент постановки.

Подробно механику автоматизации повторных обращений — с примерами полей и условий — я разбирал в статье про автоматизацию повторных продаж в Битрикс24. Здесь важно другое: без правильно настроенных напоминаний даже готовая воронка повторных продаж просто не запускается вовремя.

групповые задачи — кому реально приходит напоминание

В задаче с несколькими ответственными или соисполнителями напоминание о приближающемся сроке уходит только основному ответственному — остальным из списка ответственных системные напоминания о дедлайне не приходят, даже если они добавлены в задачу. На аудитах это регулярно всплывает как причина «мы все думали, что кто-то другой сделает».

Групповая задача без явно выделенного главного ответственного — почти гарантированный способ получить именно такую ситуацию. Правило, которое ставлю клиентам: если работу реально выполняет несколько человек, лучше завести отдельную задачу на каждого с понятным результатом, а не одну общую с длинным списком соисполнителей.

Есть смежный вопрос — чем групповая задача отличается от смарт-процесса с несколькими стадиями и участниками, если у вас регулярно повторяющийся многошаговый процесс. Я отдельно сравнивал эти инструменты в статье про проекты, задачи и смарт-процессы в Битрикс24 — для процессов с чёткой последовательностью шагов смарт-процесс обычно управляемее, чем задача с длинным списком участников.

почему сотрудники выключают push — и как это чинить

Частая причина, почему напоминания не работают, — банальная: сотрудник выключил push-уведомления на телефоне, потому что их приходило слишком много и они мешали. Это не саботаж, а рациональная реакция на систему, где 80% уведомлений не требуют немедленного действия — комментарии в чатах, обновления ленты, уведомления о задачах других людей.

Запрещать отключать push — не решение, потому что контролировать личные настройки телефона сотрудника технически нельзя и не нужно. Решение — сократить шум: в настройках профиля отключить уведомления по низкоприоритетным событиям и оставить push только по действительно критичным — просроченный крайний срок своей задачи, упоминание, назначение ответственным.

Отдельно стоит завести привычку проверять email-канал напоминаний, если push всё же отключён: он реже раздражает и попадает в почту, которую сотрудник читает в своём темпе, а не дёргает телефон каждые пять минут. Комбинация «минимум push плюс email-дублирование по критичным событиям» на практике приживается лучше, чем попытка заставить людей терпеть весь поток уведомлений.

отчёт по просроченным делам — на что смотреть руководителю

Стандартный отчёт по просроченным задачам в Битрикс24 показывает список и количество — этого недостаточно для управленческого вывода. Смотреть стоит на три вещи: динамику числа просрочек по неделям (растёт или падает после ваших изменений в правилах напоминаний), концентрацию по конкретным сотрудникам (системная проблема у одного человека — это не то же самое, что редкие просрочки у всех) и среднее время между наступлением срока и фактическим закрытием задачи.

Последний показатель — самый информативный и реже всего смотрят именно на него. Если просроченные задачи закрываются в среднем через час после срока — это не критично, скорее особенность планирования. Если через 3-5 дней — сигнал, что эскалация либо не настроена, либо не работает, и стоит вернуться к разделу про эскалацию просроченных задач выше.

Календарь и напоминания живут не изолированно — если у сотрудников личный календарь синхронизирован с внешними сервисами криво, часть напоминаний вообще может проходить мимо привычного канала. Эту настройку я разбирал отдельно в статье про синхронизацию календаря Битрикс24 — стоит свериться, если отчёт по просрочкам не сходится с тем, что говорят сами сотрудники.

частые вопросы