Когда два портала Битрикс24 связаны между собой, поле «крайний срок» в задаче синхронизируется автоматически. Это удобно — пока не сталкиваешься с ситуацией, в которой дата в карточке уже другая, а договорённости об этом не было.
Новая дата сама по себе ничего не значит. Исполнитель мог переоценить оставшийся объём, клиент — сдвинуть внутренний календарь, а обмен между порталами просто передал последнее поддерживаемое изменение. Если не разграничить автоматику и деловую договорённость, синхронизация начнёт тихо подменять переговоры.
У срока должен быть владелец
Первое правило — назначить человека, который вправе менять согласованную дату. Это не обязательно исполнитель: чаще роль удобнее дать руководителю проекта на стороне клиента или менеджеру подрядчика. Владелец не выполняет работу, а проверяет влияние переноса, собирает решения уполномоченных людей и обновляет поле один раз, после договорённости.
Остальные участники могут предложить изменение новым сообщением в общей задаче, но не правят дату параллельно.
Что должно быть в запросе на перенос
Размытое «надо подвинуть срок» провоцирует лишние вопросы. Рабочий запрос содержит:
- текущий срок — чтобы обе стороны обсуждали одну исходную договорённость, а не две разные версии;
- предлагаемый срок — чтобы было что согласовывать;
- причину — нехватка материалов и изменение объёма работы требуют разных решений;
- влияние — что происходит с зависимыми работами и ожиданиями клиента;
- варианты — перенос, сокращение объёма или поэтапная передача.
Живой пример сообщения: «Для завершения проверки нужны исходные материалы. Предлагаем перенести передачу с 12 на 14 число. Если сохранить прежнюю дату, можем передать только уже проверенную часть. Просим подтвердить выбранный вариант».
Порядок действий
- Инициатор описывает изменение новым сообщением в общей задаче.
- Уполномоченная сторона подтверждает дату или предлагает другой вариант.
- Владелец срока фиксирует решение отдельной репликой и меняет поле.
- Вторая сторона проверяет дату в своей карточке после обработки обмена.
- Руководители обновляют зависимые договорённости в своих процессах.
Последний шаг легко пропустить: перенос срока одной задачи не пересчитывает автоматически внешние обязательства и графики. Это отдельная работа, которую приложение без специальной настройки не выполняет.
Смотрите на направление передачи
Если срок меняет партнёр, а перенос «партнёр → клиент» в приложении отключён, клиентская карточка не получит новую дату — и это нормально. Администраторы должны заранее проверить, что выбранная организационная схема соответствует направлениям обмена. Отдельно настраивается передача сообщений: бывает, что обсуждение дошло, а изменение поля запрещено, или наоборот.
Если обе стороны уже поменяли дату
Самое опасное — пытаться «перебить» чужую правку своей. Такая гонка создаёт новые события и усложняет проверку того, какая реплика была последним соглашением. Приложение не различает деловые договорённости и случайные правки.
Правильный порядок: остановить параллельное редактирование, согласовать итоговую дату в переписке и внести её один раз с разрешённой стороны. Сначала договорённость, затем одно действие и проверка второй карточки.
Срочные случаи и часовые пояса
Для срочных переносов заранее определите контакт и порядок решения. Если дата включает время, указывайте часовой пояс прямо в сообщении — формулировка «до вечера» бесполезна, когда команды в разных регионах. И помните: синхронизация не гарантирует мгновенной доставки, поэтому критичное решение подтверждает участник процесса, а не только факт редактирования поля.
Итог
Начните с короткого правила: кто предлагает, кто согласует и кто меняет дату. С «Межпортальными задачами и коллабами» перенос поддерживаемых данных становится частью этого правила, а ответственность за решение остаётся у людей.
Top comments (0)