В компании описывают процесс обработки клиентского обращения.

На схеме маршрут обычно короткий: клиент написал ➡️ менеджер принял обращение ➡️ специалист разобрался ➡️ проблему решили ➡️ клиента уведомили.

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

Но реальные обращения редко идут одной прямой линией.

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

На схеме всё это часто не появляется.

Там есть основной маршрут.

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

Руководитель потом открывает CRM и видит десятки обращений в промежуточных состояниях. Формально они не потеряны. По ним даже что-то происходит. Но чтобы понять, где каждое обращение застряло, приходится открывать карточку, читать комментарии, искать переписку, спрашивать менеджера и выяснять, кто последний разговаривал с клиентом.

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

Все эти ситуации нормальны.

Ненормально, когда для процесса они как будто не существуют.

Если на схеме есть только happy path (он же в переводе на старославянский «счастливый маршрут»), компания описала не весь бизнес-процесс. Она описала ту его часть, где всё пошло так, как хотелось.

Остальная работа при этом никуда не исчезает. Она просто становится менее управляемой.

Проблема не в том, что работа может идти по разным сценариям. Это как раз обычная жизнь. Проблема начинается, когда эти сценарии не признаны частью процесса.

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

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

Иначе компания управляет только основной дорогой.

А все развилки обслуживает вручную.

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

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

Это не лишние детали для красивой схемы. Это те места, где процесс либо становится управляемым, либо снова проваливается в ручное управление.

Я бы проверял такие процессы не вопросом «какой у нас основной маршрут?»

Основной маршрут обычно все как-то помнят.

Лучше спросить иначе: что происходит, когда работа уходит с основной дороги?

Если для ответа приходится поднимать переписку и искать человека, который «помнит, как обычно делаем», схема описывает не реальный процесс.

Она описывает ожидание, что всё закончится хорошо.

Ещё больше обо мне | sergey-suslov.ru