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