В отчёте заявка находится на этапе «оценка автомобиля». Отдел продаж считает, что передал клиента специалисту trade-in. Специалист не видит подтверждённого запроса и ждёт дополнительных данных. Несколько дней карточка формально остаётся в правильном статусе, хотя ни один сотрудник не отвечает за продолжение.
Этап начинает работать только после назначения владельца результата перехода. Он подтверждает, что обращение принято, контекст достаточен и следующий шаг назначен. Новые статусы здесь не помогут: сначала нужно описать сам момент передачи и право вернуть неполную заявку.
Статус показывает место, но не принятую работу
Название этапа говорит, где должна находиться заявка, однако не доказывает, что новый владелец действительно начал действие.
Смена значения в системе может выполняться автоматически или предыдущим сотрудником. Принимающая команда узнаёт о ней позже, а иногда не получает уведомление или нужные сведения. Отчёт считает переход завершённым раньше, чем он произошёл в реальной работе.
Особенно заметны пограничные случаи. Клиент просит одновременно рассчитать новый автомобиль и оценить прежний. Каждое подразделение видит свою часть, но никто не отвечает за общий следующий шаг. Один статус не способен описать такую договорённость без владельца координации.
Для анализа нужно разделить нахождение на этапе и факт принятия. Эти события могут совпадать по времени, но имеют разный смысл. Первое меняет классификацию карточки, второе подтверждает, что конкретный сотрудник получил достаточно контекста и продолжает разговор.
Владелец отвечает за результат передачи
Ответственный за переход должен довести заявку до состояния, в котором принимающая роль может работать без повторного выяснения основы.
Владельцем может быть передающий сотрудник, координатор или принимающий специалист. Выбор зависит от процесса, но правило должно быть однозначным. Если обе стороны считают, что подтверждение делает другая, обращение остаётся между отделами при любом количестве уведомлений.
Результат передачи описывают простыми признаками. Назван вопрос клиента, приложены нужные сведения, выбран канал и согласован ближайший шаг. Не каждый переход требует полного досье. Достаточность определяется тем, сможет ли новый сотрудник продолжить разговор без возврата к началу.
Принимающая сторона имеет право вернуть заявку с конкретной причиной. Формальное «не хватает информации» снова размывает ответственность. Причина должна указывать отсутствующее поле или действие, а предыдущий владелец получает задачу дополнить контекст либо пересмотреть маршрут.
Зависание видно по отсутствующему следующему шагу
Пограничную заявку находят не по возрасту статуса, а по отсутствию принятого действия после передачи.
Срок полезен только вместе с ожидаемым событием. Для одной заявки ответ нужен сразу, другая ждёт согласованного звонка клиента. Общий таймер смешивает задержку и нормальное ожидание. Проверка начинается с того, назначен ли владелец и сохранена ли договорённость.
Отчёт по переходам показывает карточки без подтверждения, возвраты из-за неполного контекста и случаи, где действие назначено прежнему отделу. Эти группы требуют разных решений. Среднее время на этапе не объясняет, какой именно участок процесса нужно изменить.
Повторяющиеся зависания разбирают по типу передачи. Если проблема возникает между продажами и trade-in, команда проверяет набор входных сведений и право координации. Добавлять новый статус стоит только тогда, когда появляется действительно отдельное состояние, а не попытка заметить старую ответственность.
Переход закрывается подтверждённым продолжением
Завершением считается не перемещение карточки, а назначенный следующий шаг с новым владельцем.
Принимающий сотрудник подтверждает заявку и выбирает действие: связаться с клиентом, подготовить расчёт или запросить конкретное уточнение. В системе остаются время и результат принятия. Предыдущий владелец видит, что его часть завершена, и не дублирует контакт.
Если клиентский вопрос требует нескольких отделов, один координатор сохраняет ответственность за общий ответ. Исполнители закрывают свои задачи, но не отправляют человеку несколько несвязанных сообщений. Так переход между внутренними этапами остаётся незаметным для клиента и понятным для команды.
Руководитель проверяет долю переходов без владельца и причины возврата. Эти наблюдения помогают исправлять правила, обучение и состав обязательных сведений. Этапы остаются простой картой процесса, а ответственность появляется там, где работа действительно меняет руки.
Чтобы проверить новую схему, возьмите несколько недавних заявок, которые переходили между ролями. Для каждой отметьте последнее выполненное действие, имя принимающего сотрудника и обещанный клиенту шаг. Если карточка сменила статус, но нового действия нет, переход ещё не завершён. Такой просмотр быстро показывает спорные границы между маркетингом, контакт-центром и отделом продаж. После уточнения ролей повторите проверку на свежих обращениях: число ручных уточнений должно сокращаться, а история каждой передачи должна оставаться понятной без отдельного звонка автору. В отчёте такие переходы показывают отдельной очередью, без добавления десятков новых статусов. Руководитель видит время до принятия и долю карточек без назначенного действия. Эти наблюдения помогают менять границу ответственности, а не просто требовать быстрее перемещать заявки по воронке.
Кто должен быть владельцем перехода заявки?
Это может быть передающий сотрудник, координатор или принимающий специалист. Главное, чтобы одна роль отвечала за подтверждённый результат передачи и была названа заранее.
Нужно ли создавать новый статус для каждой передачи?
Нет. Сначала добавьте подтверждение принятия, владельца и следующий шаг. Новый статус нужен только для самостоятельного состояния, а не для компенсации неясной ответственности.
