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