Перенос сроков дел в Битрикс24: разбор Крест-НН

Почему срок в сделке менялся, а дело оставалось на прежнее время. Как BYstudio исправила синхронизацию и проверила перенос на технической сделке.

Посмотреть до и после Проверить свою настройку

Новый срок в карточке, старый срок у дела

В Крест-НН уже работал Битрикс24. BYstudio дорабатывала отдельную B2C-воронку V1: стадии заказа, обязательные данные, дела и контроль следующего действия. Разбираем один конкретный дефект этой настройки, обнаруженный 16 октября 2026 года.

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

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

Что изменилось на проверенном примере

До исправления: 16 октября на технической сделке следующий срок меняли с 17:38 на 17:40 и затем на 17:55 без смены стадии. У существующего дела оставалось 17:38. Запись исполнителя и журнал отладчика фиксируют отсутствие нового ожидания контроля.
После исправления: В серверной проверке 16 октября у автоматически созданного дела запланированный срок 19 октября 10:15 перенесли на 10:45 через поле сделки. Срок дела изменился следом. Дата 19 октября здесь является назначенным сроком, а не датой выполнения проверки.
Дополнительный проход: В той же технической проверке зафиксированы переносы вперед и назад, а также распознавание нового дела вместо прежнего. Проверку завершили закрытием технической записи и завершением дел.

Это сравнение конкретной настройки внутри проекта. Полная схема работы компании до проекта не восстановлена, поэтому мы не изображаем этот эпизод как переход от отсутствия CRM к автоматизации.

Синхронизация с четкими границами

Сначала проверили вариант с триггером на изменение поля. В этой конфигурации он не перенес срок существующего дела; временный триггер убрали. С учетом ограничения конструктора на действующем тарифе согласовали и разместили отдельную службу синхронизации. Внешнего бота обработки обращений не меняли.

Область работы: четыре согласованные стадии V1 после квалификации. Служба сопоставляет срок следующего действия с распознанным незавершенным делом робота.
Если срок в поле изменился, соответствующее дело переносится. При появлении нового дела служба должна распознать его вместо прежнего.
Ручные и завершенные дела исключены. Завершенное действие нельзя снова открыть только потому, что в карточке сохранилось поле срока.
При переключении отключили четыре прежних нативных уведомления следующего срока. Первичный контроль 15 минут и 2 часа сохранили: это отдельный сценарий.

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

Что подтверждено и где заканчивается проверка

Техническая сделка: Архивная запись размещения от 16 октября подтверждает перенос срока существующего дела и распознавание автоматически созданной замены. Это наблюдение на технической записи в рабочем портале.
Автономные тесты: Отчет от 16 октября содержит 35 успешных локальных проверок всей службы. Среди них: перенос вперед и назад, отсутствие сигнала по прежнему сроку, исключение ручных и завершенных дел, смена стадии и границы рабочего календаря. Это имитации API, а не 35 заказов клиента.
Рабочие уведомления: Фактический сигнал просрочки после переноса в рабочие часы и получение push на телефонах сотрудников в переданном архиве не подтверждены. Локальная проверка логики не заменяет проверку доставки.
Эффект для бизнеса: Нет сопоставимого измерения просрочек, скорости ответа или продаж до и после. Успешный технический перенос не является доказательством роста выручки или полного освоения процесса отделом.

Как принять подобное исправление в своей CRM

Ниже рекомендуемый сценарий приемки для другого проекта. Он шире подтвержденного результата Крест-НН. Работайте на согласованной технической записи, с тестовыми адресатами и без отправки сообщений покупателям.

Зафиксируйте исходное состояние: стадию, поле следующего срока, связанное дело, его срок и признак завершения. Укажите часовой пояс и допустимую задержку обновления.
Не меняя стадию, перенесите срок вперед, затем назад. После каждого изменения проверьте поле и дело. Убедитесь, что не появилось лишнее дело.
Завершите старое дело и создайте новую согласованную активность. Проверьте распознавание замены и отсутствие повторного открытия завершенной.
Добавьте отдельное ручное дело. Смена следующего срока не должна менять его, если оно исключено из области синхронизации.
Проверьте смену стадии и закрытие сделки. Сохраните результат: какие дела завершились, какие остались и почему.
Отдельно дождитесь реального контрольного события в согласованном рабочем окне. Сопоставьте серверную запись, событие CRM и получение сообщения тестовым адресатом. Проверьте отсутствие устаревшего сигнала и ненужных повторов.
Укажите владельца службы, место проверки состояния и порядок восстановления. Согласуйте, кто проверит работу после изменения полей, роботов, тарифа или прав доступа.

Если совпали только даты в карточке, примите синхронизацию отдельно, а доставку уведомлений оставьте открытой. Такой протокол дает точный результат вместо общего «все работает».

Полный список проверок при приемке CRM

На чем основан разбор

Проектная часть сверена с закрытым пакетом Крест-НН: журналом дефекта и экспериментом 16 октября, записью размещения и технического прохода того же дня, отчетом 35 автономных тестов и обезличенной конфигурацией на 19 октября. Исходные журналы и реквизиты доступа не публикуются. Новых изменений или тестовых обращений в CRM ради статьи не выполняли.

Общая справка Битрикс24 описывает настройку срока при планировании дела, время выполнения роботов и учет рабочего графика. Эти возможности сами по себе не доказывают, что конкретная существующая настройка правильно обрабатывает перенос срока. Справка проверена 22 октября 2026 года.

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

Почему изменение срока в сделке не изменило срок дела?

В проверенной конфигурации поле следующего действия, уже созданное дело и отложенный контроль не обновлялись как единое целое. Это наблюдение о конкретной версии настройки Крест-НН, а не универсальное ограничение Битрикс24. Причину в другой CRM нужно воспроизвести отдельно.

Для такого исправления всегда нужна внешняя служба?

Нет. Сначала проверьте штатные инструменты вашего тарифа и существующую автоматизацию. В проекте Крест-НН эксперимент с триггером не перенес срок существующего дела, а доступ к конструктору был ограничен тарифом. Отдельную службу согласовали для этой конфигурации.

Можно переносить все незавершенные дела сделки?

В этом проекте так не делали. Синхронизация ограничена распознанным делом робота в согласованных стадиях V1. Ручные и завершенные дела исключены. Для другого процесса границы надо определить до изменения данных.

Проверка переноса доказывает доставку уведомления?

Нет. Совпадение времени в поле и деле подтверждает синхронизацию. Исполнение контроля в рабочее время, получение сообщения адресатом и мобильный push проверяются отдельно. В архиве проекта эти рабочие уведомления после переноса не подтверждены.

Посмотреть проект целиком

Сроки дел были одной частью доработки: в кейсе показаны стадии V1, обязательные данные и ручная сверка оплаты. Для похожей задачи начните с описания одного расхождения и результата, который нужно проверить.