Статусы превращают общий список заказов в управляемый процесс. По ним администратор понимает, что сказать клиенту, мастер — какие работы выполнять, а руководитель — где возникла задержка.
Какую задачу должен решать статус
Каждый статус должен отражать реальное состояние заявки и вести к конкретному следующему действию. Если два статуса означают почти одно и то же, сотрудники будут выбирать их случайно.
- у кого сейчас находится ответственность;
- ожидается действие сервиса или клиента;
- можно ли уже выполнять ремонт;
- готово ли устройство к выдаче;
- нужно ли руководителю вмешаться.
Базовая цепочка статусов
1. Новая
Обращение создано, но ещё не принято в работу. Статус подходит для заявок с сайта, по телефону или из другого входящего канала.
2. Принята
Устройство находится в сервисе, основные данные и комплектность зафиксированы, документы оформлены.
3. Диагностика
Мастер определяет причину неисправности, требуемые работы, детали и предварительную стоимость.
4. Согласование
Результат диагностики готов, но ремонт ещё нельзя начинать: сервис ожидает решение клиента.
5. Ремонт
Работы согласованы и выполняются. Здесь фиксируются мастер, использованные запчасти, комментарии и фотографии процесса.
6. Готово
Ремонт завершён, итоговая сумма определена, устройство ожидает выдачи. «Готово» и «Выдано» — разные состояния.
7. Выдано
Устройство передано клиенту, документы оформлены, заявка завершена и остаётся в истории.
8. Отменено
Работа не выполнялась или была прекращена. Полезно сохранять причину отмены.
Для большинства небольших сервисов этих восьми статусов достаточно. Добавляйте новый только тогда, когда отдельный этап действительно требует контроля.
Не превращайте статус во всё сразу
Частая ошибка — создавать отдельный статус для каждого свойства заявки: «Срочная», «Гарантийная», «Ждём деталь», «Клиент недоступен». Эти признаки относятся к разным измерениям.
- статус — этап работы;
- приоритет — срочность;
- тип ремонта — обычный или гарантийный;
- комментарий — конкретная ситуация;
- уведомление — необходимость внимания.
Как контролировать сроки
Сам статус не показывает проблему, пока не учитывается время. Полезно контролировать дату создания заявки и дату последнего изменения. Первая показывает общий срок, вторая — длительность текущего этапа.
Кто должен менять статус
- администратор фиксирует приём, согласование, готовность и выдачу;
- мастер переводит заявку в диагностику и ремонт;
- руководитель контролирует исключения и ошибки.
Если статус меняет «кто вспомнил», данные быстро перестают отражать реальность.
Пять распространённых ошибок
- слишком много почти одинаковых статусов;
- нет отдельного этапа согласования;
- объединены «Готово» и «Выдано»;
- статусы меняются задним числом;
- не контролируется время последнего изменения.
Статусы и история в ServiceHub
В ServiceHub заявка хранит текущий статус, приоритет, назначенного мастера, комментарии, фотографии и историю действий. Руководитель может перейти от сводных показателей к конкретным заказам.
Пройдите этапы заявки в демо
Откройте карточку заказа, диагностику, детали и документы.