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