Статусы заявки нужны для понимания следующего действия и ответственности. Небольшому бизнесу полезнее короткая понятная последовательность, чем десятки похожих состояний.
Опишите реальные этапы
Начните с различий, которые меняют работу: запрос получен, нужен контакт, задача обсуждается, предложение отправлено, решение ожидается или работа завершена. Названия должны иметь одинаковый смысл для всех участников. Полученное уведомление не равно принятой сотрудником задаче.
Условный пример: «в работе» одновременно означает попытку дозвониться и уже подготовленное предложение. Такой статус скрывает следующее действие. Разделите эти ситуации или добавьте понятную запись о текущем шаге.
Добавьте ответственного и срок действия
Для незавершённого обращения нужны человек, следующий шаг и согласованное время проверки. Срок не обязательно является обещанием клиенту: это может быть внутренний контроль очереди. Отдельно храните причину отказа, не превращая её в десятки статусов.
Не используйте «плохой клиент» вместо наблюдаемой причины. Записи «не подходит территория» или «не продаём нужный продукт» помогают улучшать предложение и рекламу. Если решение ещё не принято, не закрывайте запрос как проигранный только ради порядка в таблице.
Проверьте правила переходов
Уточните, кто меняет статус и каким событием он подтверждается. Оплата, отправка предложения и ответ сотрудника требуют разных оснований. Автоматическое изменение должно сохранять историю и не подменять бизнес-решение предположением.
Периодически смотрите незавершённые запросы и места задержки. Если статус не помогает назначить действие или оценить результат, пересмотрите его необходимость. Система должна быть понятна владельцу и новому сотруднику без отдельного словаря из сотни терминов.
- Смысл каждого этапа.
- Ответственный.
- Следующее действие.
- Причина завершения.
- История переходов.
