Автоматизация сервисной службы: заявки, исполнители и статусы

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

Какие статусы заявок использовать

Возьмём условную компанию, обслуживающую торговое оборудование. Диспетчер получает описание неисправности, уточняет модель и контакт, затем назначает сотрудника. Исполнитель принимает задачу, связывается с клиентом и фиксирует результат.

Для начала достаточно статусов «Новая», «Назначена», «В работе», «Ожидает данных», «Завершена». Каждому статусу нужно дать определение. Например, «Назначена» означает, что выбран исполнитель, но он ещё не подтвердил начало работы. Без общего смысла сотрудники будут использовать одинаковые названия по‑разному.

Отдельно определите, кто вправе закрывать обращение и в каких случаях его возвращают на доработку.

Что входит в учёт сервисных заявок

Минимальная карточка должна помогать выполнить работу:

• номер заявки и дата поступления;
• клиент, контакт и адрес объекта;
• оборудование и описание проблемы;
• ответственный и текущий статус;
• согласованное следующее действие;
• комментарии и необходимые вложения.

Если данных недостаточно, это должно быть видно. Поле «модель не установлена» полезнее выдуманного значения. По фотографии или короткому описанию нельзя обещать точную диагностику до проверки специалистом.

Не превращайте первую карточку в анкету на несколько десятков обязательных полей. Сначала соберите сведения, без которых обращение нельзя принять и передать исполнителю.

Как разделить доступы

Диспетчеру нужен общий список и возможность назначать исполнителей. Мастеру обычно достаточно собственных задач и необходимых контактов. Руководителю полезны просроченные обращения и история изменений.

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

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

Что входит в первую рабочую версию

Реалистичный стартовый объём: один способ приёма, общий список обращений, карточка, две или три роли и история статусов. Уведомления подключают в одном согласованном канале после проверки его возможностей.

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

ИИ может помочь выделить модель и описание из текста, но сотрудник подтверждает сведения. Решение о ремонте остаётся за специалистом.

Что происходит, если мастер не принял заявку

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

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

Работу можно организовать в существующем инструменте: Битрикс24 поддерживает стадии, поля, права и роботов смарт‑процесса. Отдельный продукт нужен там, где проверенная настройка не закрывает маршрут службы.

ИИ в карточке: пример вместо обещания диагностики

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

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

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

Что проверить перед запуском

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

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

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

Смежные разборы: Личный кабинет для клиентов: как показывать статус заказа; Эффективность автоматизации: как проверить результат внедрения.