Вернуться к статьям Агентство и заказчик нередко работают в разных порталах Битрикс24. У каждой стороны свои проекты, сотрудники, права доступа и внутренняя отчётность. Переносить всё в один портал в такой ситуации неудобно: одна команда теряет привычный рабочий контур, другая получает доступ шире, чем нужно для конкретного проекта.
Для совместной работы не обязательно объединять порталы. Можно связать отдельные задачи: в портале клиента остаётся постановка с бизнес-контекстом, а в портале агентства появляется задача для исполнения. Пользователи работают в обычной карточке задачи своего портала и не получают прямого доступа ко всему чужому порталу. Фактическая видимость зависит от настроенных прав. Такой сценарий поддерживает приложение «Межпортальные задачи и коллабы», которое связывает задачи двух независимых порталов Битрикс24.
До настройки стоит определить границы обмена. Для агентского проекта обычно нужны бриф, ответственный, срок, материалы, комментарии и понятный порядок согласования. Остальные процессы обоих порталов остаются независимыми.
Как связанные задачи работают в паре агентства и клиента
Связанные задачи не превращают два портала в одно общее пространство. На каждой стороне остаются своя карточка, собственные права и локальные участники. Клиент ведёт задачу в своём проекте, агентство включает её в собственный производственный процесс.
В актуальном интерфейсе Битрикс24 группы, коллабы и проекты объединены в формат «Проекты AI». Для нового сценария совместной работы внутри одного портала используется проект с гостями. Экстранет остаётся наследуемым форматом для уже созданных групп. Межпортальные задачи решают другую задачу: участники работают в разных самостоятельных порталах, а не в одном проекте с внешними гостями.
Связь создают один раз. Партнёр формирует ключ приглашения, клиент активирует его, затем администратор партнёра сохраняет сопоставление и правила. Одной активации ключа недостаточно: до сохранения сопоставления обмен не начнётся. Приложение должно быть установлено и активно на обоих порталах.
Для старта выбирают область обмена: проект, рабочую группу, существующую коллабу или список ответственных. В актуальном интерфейсе Битрикс24 такие рабочие пространства относятся к формату «Проекты AI». Не стоит сразу включать все задачи двух компаний. Лучше начать с ограниченной области и проверить, как в ней устроены постановка, состав участников и согласование материалов.
Если отбор задан по ответственным, приложение учитывает назначенного ответственного, а не автора задачи. Это удобно, когда менеджер клиента создаёт заявки для выделенной команды агентства. Для зеркальной задачи можно указать проект-приёмник. Без него задача на второй стороне создаётся без проекта.
Брифы в задачах клиента и агентства: что фиксировать в постановке
Бриф лучше хранить в описании задачи, а не собирать из отдельных сообщений. В стандартном обмене передаются название, описание, крайний срок, плановые даты начала и окончания, приоритет, теги и оценка времени. Очистка поддерживаемого значения тоже считается изменением.
В описании полезно зафиксировать ожидаемый результат, исходные данные, ограничения и критерий приёмки. Формулировка «подготовить макет» ничего не говорит о формате, согласующем сотруднике и расположении исходников. Чем точнее исходная постановка, тем реже её приходится одновременно править на двух сторонах.
Пользовательские поля можно сопоставить вручную, если процессу нужны отдельные поля для типа материала, канала публикации или статуса согласования. По названию и смыслу поля автоматически не подбираются. Перед запуском стоит создать тестовую задачу и проверить тип поля, доступные значения и права участников. Несовместимый тип или недостаточный доступ могут помешать переносу.
Типовой процесс: бриф на посадочную страницу
Маркетолог клиента создаёт задачу в выбранном проекте: указывает продукт, целевую аудиторию, обязательные блоки и дату готовности. В портале агентства появляется связанная задача. Исполнитель назначается по общему правилу или по персональному сопоставлению сотрудников.
После уточнения брифа клиент меняет описание в своей карточке. Чтобы не получить две разные версии текста, стороны заранее распределяют ответственность: исходное описание редактирует клиент, а вопросы к брифу пишут новыми сообщениями в чате задачи. Рабочие заметки агентства остаются в его внутреннем процессе.
Ответственные и сроки в задачах агентства и клиента
Для зеркальных задач на каждой стороне задают ответственного и постановщика по умолчанию. При необходимости можно вручную сопоставить конкретного сотрудника клиента с конкретным сотрудником агентства. Персональная пара имеет приоритет над общим правилом.
Это правило нужно для назначения участников в локальной карточке. Оно не создаёт общую структуру сотрудников, не синхронизирует учётные записи и не меняет права доступа.
Полезно заранее разделить роли. Клиентский менеджер отвечает за полноту брифа и решение по результату. Со стороны агентства один сотрудник ведёт задачу и распределяет внутреннюю работу команды. Срок должен означать одно и то же в обеих карточках: например, дату передачи результата на согласование, а не внутреннюю дату первого черновика.
Состояние задачи обрабатывается отдельно. Поэтому порядок приёмки лучше описать в регламенте: кто сообщает о готовности, кто принимает работу, как оформляется возврат на доработку. Для сложного согласования одного изменения статуса может не хватить.
Условная ситуация: согласование рекламных материалов
Клиент ставит задачу на пакет баннеров и указывает крайний срок получения версии на согласование. Руководитель проекта агентства назначает дизайнера и ведёт внутренний план в своей карточке. Когда макеты готовы, руководитель пишет новое сообщение с перечнем файлов и просьбой подтвердить вариант. Клиент отвечает в своей задаче, если для обратного направления включено разрешение на новые сообщения чата.
Если клиент переносит срок, изменение передаётся в связанную задачу после сохранения сопоставления и при включённом направлении клиент → агентство. Синхронизация находится в бета-версии и может работать с задержкой. При критичном переносе срока участники дополнительно связываются через согласованный канал, а не ждут появления новой даты в другой карточке.
Комментарии в задачах для согласований
В связанной задаче передаются новые пользовательские сообщения чата, созданные после включения синхронизации. Старая переписка не импортируется, системные сообщения не передаются. На второй стороне текст появляется как копия с указанием автора, но автор не действует в чужом портале от своего имени.
Решение по согласованию лучше оформлять отдельным новым сообщением: «Согласовано, используем вариант B» или «Возврат на доработку: заменить первый экран и обновить файл». Правка или удаление исходного сообщения не изменит уже доставленную копию. Связь ответа с первоначальным сообщением тоже может не сохраниться.
Для длинного обсуждения помогает простое правило: вопрос формулируют отдельным сообщением, решение фиксируют следующим сообщением, а ссылку на актуальный материал добавляют рядом с ним. Так участникам проще отслеживать ход согласования, хотя ответы в двух карточках могут отображаться иначе. Особенности переписки разобраны в статье о синхронизации чатов задач между порталами.
Типовой процесс: правки к тексту
Клиент получает черновик и пишет новые правки в чате, не редактируя старое сообщение. Редактор агентства отдельным сообщением отвечает, какие пункты приняты, а где требуется уточнение. После обновления файла руководитель проекта публикует следующую версию и просит подтвердить именно её.
Такой порядок не объединяет две параллельные редакции документа. Зато участники не путают версию на согласовании с устаревшим вложением. Существенные решения лучше фиксировать новыми сообщениями, а не исправлениями старого текста.
Файлы в задачах агентства и клиента: правила обмена материалами
Файлы, прикреплённые к связанной задаче и доступные приложению, копируются на другой портал. На передачу влияют права, размер, тип и доступность файла. Если файл отсоединили от одной карточки, его копия на второй стороне автоматически не удаляется. Очистку материалов нужно отдельно согласовать и проверить в обеих задачах.
Материалам нужны понятные имена: номер или дата версии, назначение файла, отметка «на согласование» либо «утверждено». Название вроде финал_новый_точно не помогает понять, какая редакция актуальна. В сообщении к вложению лучше указать, что изменилось и какого решения ждёт отправитель.
Содержимое параллельно отредактированных файлов не объединяется. Если клиент и агентство могут менять один исходник, заранее выбирают владельца редактирования или порядок передачи версий. Другая сторона оставляет замечания в задаче и получает следующую редакцию, а не правит ту же копию одновременно.
Условная ситуация: обмен исходниками и утверждёнными версиями
Агентство прикрепляет к задаче исходный макет и PDF для просмотра, затем сообщает, какая версия отправлена на согласование. Клиент скачивает PDF, оставляет замечания новым сообщением и не меняет исходник на своей стороне. После доработки агентство прикладывает файл со следующим номером версии.
Когда заказчику нужно передать брендбук или фотографии, он добавляет их в клиентскую задачу с понятным описанием назначения. До запуска обмена стоит проверить на тестовых материалах, какие типы и размеры файлов доступны в конкретной связке порталов.
Направления обмена между задачами двух порталов
Направление клиент → агентство начинает работать после сохранения сопоставления. Обратный поток агентство → клиент включается отдельными разрешениями: для изменений задачи и полей, файлов, а также новых сообщений чата.
Так можно настроить процесс, в котором клиент ставит задачи, а агентство передаёт согласованные материалы и комментарии. При необходимости разрешают обмен в обе стороны. Само направление не заменяет правила работы: сторонам всё равно нужно определить владельца спорных полей и порядок действий при срочных изменениях. Общие принципы разобраны в статье о синхронизации задач между порталами.
Односторонняя схема подходит, когда агентство получает брифы, но не должно менять клиентскую постановку. Двусторонняя схема нужна, если агентство должно обновлять срок, прикладывать материалы или отвечать в чате. Для каждого действия включают отдельное разрешение, а клиент принимает результат в своей карточке.
Типовой процесс: поддержка сайта в двух порталах Битрикс24
После сохранения сопоставления клиент создаёт в своём проекте задачу на изменение страницы и прикладывает материалы. На стороне агентства появляется связанная задача. После настройки связи агентство получает связанную задачу, назначает разработчика и уточняет детали в чате, если для этого направления разрешены новые сообщения. После проверки исполнитель прикладывает результат и сообщает, что работа передана на приёмку, если для обратного направления разрешён обмен файлами и сообщениями. Клиент проверяет её в своей карточке и публикует решение отдельным сообщением.
Если задача больше не относится к обслуживаемому проекту или её ответственный вышел из наблюдаемого списка, обмен существующей пары останавливается после обработки изменения. На зеркальной задаче появляется заметная пометка. При возврате задачи в разрешённую область приложение продолжит прежнюю пару, если обе карточки доступны, и не создаст новый дубль.
Правила совместного редактирования задач: что закрепить до старта
Параллельные изменения одного поля могут конфликтовать. Содержимое не объединяется, а позже обработанное изменение способно заменить другое. Строгий порядок при неоднозначных временных отметках не гарантируется. Для брифа, срока и описания лучше ещё до первой задачи закрепить владельца каждого поля.
Регламент может включать такие правила:
- клиент меняет исходное описание и критерии приёмки;
- агентство ведёт внутренние рабочие заметки в своей задаче, если клиенту они не нужны;
- перенос срока сопровождают новым сообщением с причиной и новой датой;
- решение о приёмке или возврате фиксируют отдельным сообщением;
- файлам присваивают номера версий, а копии на другом портале не считают удалёнными автоматически;
- удаление задачи и остановку обмена рассматривают как разные действия.
Удаление или недоступность одной задачи не удаляет её пару на другом портале. При завершении проекта стоит проверить обе карточки, прикреплённые материалы и необходимость сохранить переписку. Если задача временно вышла за границы обмена, не нужно сразу создавать дубликат вручную: после возврата в разрешённую область прежняя пара может продолжить работу.
Частые вопросы о межпортальных задачах агентства и клиента
- Можно ли связать задачи, если агентство и клиент используют разные порталы Битрикс24?
Да. Приложение рассчитано на два самостоятельных портала: каждый сохраняет свои карточки задач и права доступа. Его нужно установить и оставить активным на обеих сторонах, а связь настраивается через приглашение и сохранённое сопоставление.
- Увидит ли агентство весь портал клиента?
Нет. Сотрудники агентства работают со связанной задачей в своём портале и не получают прямой доступ ко всему порталу клиента. Права внутри конкретной карточки, проекта или рабочей группы задаёт владелец соответствующего портала.
- Какие поля брифа передаются между задачами?
Стандартно передаются название, описание, крайний срок, плановые даты, приоритет, теги и оценка времени. Пользовательские поля можно настроить вручную, но перед запуском нужно проверить тестовой задачей совместимость типов, значений и прав доступа.
- Передаются ли старые комментарии и можно ли исправить отправленный комментарий?
Старая история чата не переносится. Передаются новые пользовательские сообщения, созданные после включения синхронизации. Правка или удаление исходного сообщения не изменит уже доставленную копию, поэтому уточнение лучше отправить новым сообщением.
- Что происходит с файлами, если удалить их из задачи на одной стороне?
Копия файла на другом портале автоматически не удаляется. Для очистки нужно проверить обе карточки и права на материалы. Параллельные изменения содержимого одного файла приложение не объединяет.
- Можно ли вести обмен только от клиента к агентству?
Да. Направление клиент → агентство работает после сохранения сопоставления. Обратные изменения задачи, файлы и новые сообщения чата включаются отдельными разрешениями, поэтому схему можно настроить под правила конкретного проекта.
Вывод
Связанные задачи подходят агентствам, подрядчикам и клиентам, которым нужны два независимых портала Битрикс24 и общая цепочка работ по отдельным задачам. До запуска стоит проверить область обмена, ответственных и постановщиков по умолчанию, владельцев полей, порядок работы с файлами и правила срочных согласований.