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