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