Когда сервисной сети достаточно системы заявок, а когда нужен партнёрский портал

Компания, которая обслуживает оборудование, обычно начинает с системы заявок: диспетчер принимает обращение, назначает исполнителя, исполнитель закрывает работу. Для простой внутренней службы этого может хватать, если нет дополнительных требований к гарантиям, доступам и расчётам. Когда в сети появляются внешние партнёры, гарантия производителя и расчёты между компаниями, требования меняются. Разберём, где проходит граница.

Что умеет система заявок

Система заявок решает задачу внутренней сервисной службы. Готовые продукты этого класса предлагают приём и распределение заявок, контроль работ, а для исполнителей мобильное приложение, которое работает и без связи. Для своей службы это решённая задача, и разрабатывать собственную систему ради неё обычно нет смысла.

Признаки того, что системы заявок достаточно:

• все исполнители работают в одной компании;
• гарантийные решения принимает та же компания;
• расчётов с внешними исполнителями нет или они редкие;
• клиенту достаточно узнать статус и получить акт.

Что меняется с внешними партнёрами

Когда работы выполняют партнёры, появляются три новых требования.

Разделение данных. Партнёр видит только свои заявки. Он не должен видеть клиентов других партнёров и их условия. Внутри одной компании это не требовалось.

Назначение по правилам. Партнёра выбирают по региону, квалификации на конкретное оборудование и загрузке. Если правила не записаны, назначение превращается в звонки диспетчера.

Квалификацию при этом ведут по моделям оборудования. Одной отметки на партнёра мало. Партнёр может уверенно работать с котлами одной серии и не иметь допуска к другой. Если квалификация записана одной галочкой, диспетчер будет назначать заявки, которые партнёр не сможет закрыть с первого выезда.

Отчётность перед владельцем сети. Производитель или головная компания хочет видеть сроки и качество по каждому партнёру, а партнёр хочет видеть свои начисления.

Что меняется с гарантией производителя

Если гарантию оплачивает производитель, а работу выполняет партнёр, нужно решение одной компании внутри процесса другой. Партнёр запрашивает замену, производитель решает по каждому узлу, партнёр продолжает. Если производитель отказал по части узлов, клиенту предлагают платную смету.

Здесь система заявок одной компании часто упирается в границы. Решение производителя приходит письмом и переносится вручную, смешанные случаи разбираются по телефону.

Что меняется с расчётами

Расчёт с партнёрами требует оснований: что именно сделано, по какой ставке, после чьей приёмки. Каждое основание начисляется один раз. Клиент видит свою часть, партнёр свою, производитель всё. Если эти суммы считаются в отдельной таблице, сверка в конце периода становится отдельной работой.

Расчёт также зависит от приёмки. Пока клиент не принял работу, вознаграждение не начисляется. Если приёмка затягивается, партнёр ждёт денег, и это видно в его отношении к следующим заявкам. Поэтому у приёмки должен быть срок и понятный порядок на случай, если клиент не отвечает.

Критерии выбора

Сведём признаки в проверку. Отметьте, что верно для вашей сети:

1. Больше трёх внешних партнёров в разных регионах.
2. Гарантийные решения принимает другая компания.
3. Бывают смешанные случаи: часть по гарантии, часть платно.
4. Вознаграждение партнёра зависит от вида работ и считается по правилам.
5. Партнёр не должен видеть заявки и клиентов других партнёров.
6. Клиенту нужен акт без внутренних сумм.

Если отмечено один‑два пункта, разумно начать с готовой системы заявок и проверить, как она настраивается под ваши правила. Если отмечено четыре и больше, стоит рассматривать партнёрский портал: готовый продукт с доработкой или собственную разработку поверх существующей системы заявок.

Три пункта посередине означают, что решение зависит от планов. Если сеть растёт и партнёров станет больше, лучше заранее проверить, как готовая система справится с разделением данных и расчётами. Если сеть стабильна, можно жить с ручными операциями и пересматривать вопрос раз в год.

Честно о вариантах

Готовая система заявок быстро закрывает работу диспетчера и исполнителей, мобильное приложение и статусы. Её стоит проверить на ваших правилах: разделение партнёров, решение по узлам, расчёт. Если настройки хватает, разработка не нужна.

Собственный портал оправдан, когда правила сети сложнее того, что настраивается. При этом его не обязательно строить с нуля: учёт заявок и мобильная работа могут остаться в готовом продукте, а портал берёт на себя гарантийные решения, партнёров и расчёты. Как разделить функции, решается при внедрении.

В любом варианте стоит начать с записи правил сети: кто решает по гарантии, как назначается партнёр, как считается вознаграждение, что видит каждая сторона. Эта запись нужна и для настройки готовой системы, и для разработки. Без неё сравнивать варианты бессмысленно: каждый поставщик покажет то, что умеет его продукт, и неизвестно, совпадёт ли это с нуждами вашей сети.

В демонстрационном сценарии можно проследить цепочку, которая выходит за пределы одной компании: гарантия, назначение партнёра, диагностика, решение производителя, приёмка и вознаграждение.

Посмотреть сценарий

Связанная статья: Кто отвечает за ремонт, если оборудование продаёт одна компания, а обслуживает другая.

Источники и границы примера

• Работа сервисной службы
• Мобильное рабочее место

Источники подтверждают описанные функции готовых продуктов, а не спрос или окупаемость собственной разработки. Сценарии и суммы учебные. Демонстрации работают с вымышленными данными; реальные интеграции, ИИ, платежи и внешняя публикация в них не подключены.