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