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