Скрипты клиентской поддержки: как избежать распространенных ошибок
6 мин читать
Скрипты для общения с клиентами помогают специалистам поддержки быстрее решать возникающие вопросы. Однако применять такие готовые сценарии разговора нужно по принципу «не навреди». Нередко возникают распространенные ошибки, из-за которых скрипты лишь затягивают коммуникацию или вовсе раздражают клиента. В статье расскажем, что это за ошибки и как их не допустить.
Ошибка 1. Скрипт не содержит точной информации или понятного алгоритма действий для клиента
Зачастую клиенты обращаются в службу поддержки с вопросами, которые не решить сразу. Например, клиент уточняет у сотрудника первой линии, как выполнить сложную настройку — перенести сайт со стороннего хостинга. Такой запрос выполняет вторая линия, что займет время. Иногда заявка не сразу берется в работу, т.к. вопрос формально не считается срочным. Допустим, по условиям SLA это до одного рабочего дня.
В подобных случаях клиент слышит дежурную отбивку: «Спасибо за обращение. Мы займемся вашей задачей». Далеко не всегда конкретизируется, в какие сроки будет выполнен запрос и что для этого планируется сделать. В итоге клиент остается в неопределенности.
Решение. Важно сразу описать дальнейший ход действий: сколько времени предположительно займет задача, когда будет первая обратная связь, кому передадут заявку, у кого узнать детали. Если вопрос клиента несрочный, не стоит открыто указывать на это или игнорировать обращение. Лучше дать короткий комментарий и сориентировать собеседника по предстоящим шагам.
Ошибка 2. Слепое следование скрипту
Бывает, что запрос уникален или непростой, чтобы выполнить по заранее продуманному алгоритму. Допустим, клиент спрашивает, как в ИТ-системе настроить нетиповой способ учета трудозатрат. Даже если обычно применяется скрипт, по которому первым делом нужно предложить собеседнику ознакомиться с инструкцией в базе знаний, в этот раз так действовать не стоит. Клиент явно «подкован» и уже разобрался, что есть, а чего нет в базовых возможностях системы. Попытка отправить изучить онлайн-документацию повторно вызовет недовольство.
Решение. Следует донести до специалистов поддержки, для каких тематик обращений не обойтись без скрипта и в каких ситуациях оправдано отойти от него. Например, если на основе преднастроенного сценария не решить проблему за отведенное время. Или когда применение скрипта явно приведет к негативной реакции клиента.
Ошибка 3. Скрипт не соответствует целевой аудитории
Если применять одинаковые скрипты к разным типам клиентов, то общение покажется фальшивым и натянутым. Могут возникнуть и конфликтные ситуации. Так, излишний формализм и обилие деталей бывают неуместными при коммуникации с клиентами в B2C-поддержке. При обслуживании компаний из B2B-сферы, напротив, стоит отвечать максимально детализировано и обращать внимание на этику делового общения. Иногда свои скрипты требуются при обслуживании клиентов из определенных отраслей и сегментов бизнеса.
Решение. Следует проанализировать, когда допустимо использовать скрипты, а когда стандартизированные подходы будут мешать. Например, если это VIP-клиент, желательно выделить закрепленных сервисных менеджеров и персонализировать взаимодействие через них.
Если скрипты все же уместны, необходимо адаптировать tone of voice к специфике конкретной целевой аудитории. Чтобы выявить ожидания различных групп клиентов от коммуникации с поддержкой, можно провести CustDev. Другой вариант — организовать опрос клиентов через email-рассылку. Для получения наиболее полной информации лучше задавать открытые вопросы. К примеру, вместо формулировки «Критичен ли для вас быстрый ответ саппорта?» спрашивать «Какое время ответа будет для вас оптимальным?».
Ошибка 4. В скрипте нет сценария, чтобы переключить клиента на другого специалиста
Клиентам нужна уверенность, что вопросом занимаются компетентные исполнители. Если все замыкается на диспетчере, который только регистрирует заявки, это с большой вероятностью добавит стрессовый фактор в коммуникацию.
Решение. Следует предусмотреть способы «перенаправлять» клиентов к более компетентным специалистам. Например, у клиента перестали работать интеграции между различными корпоративными ИТ-системами. Клиент звонит в службу поддержки разработчика ПО. Далее оператор переключает клиента на вторую линию, чтобы тот напрямую коммуницировал с конечным исполнителем, кто будет разбираться в инциденте. Другой вариант — инженер сразу назначает заявку на нужного специалиста, и дальнейшее общение будет происходить через комментарии в системе service desk, если такая применяется для управления запросами.
Ошибка 5. Скрипт не дает признать ошибку
Ошибки неизбежны в работе любой службы поддержки. Вот почему скрипты должны учитывать, как действовать в подобных ситуациях, чтобы свести к минимуму негатив у получателей услуг.
Решение. Если произошла ошибка или нарушены договоренности, лучше избегать дежурных фраз, которые не содержат полезной информации. Иначе у клиента сложится впечатление, будто вопрос пытаются замять. Не будет лишним быстро «поднять» предыдущую коммуникацию по заявке. Это даст понимание, что именно выполнено неправильно и чего ожидал клиент. Далее сообщить, что предполагается предпринять для устранения проблемы.
К выводам
Скрипты должны облегчать работу специалистам поддержки, но не «превращать в роботов». Чтобы готовые сценарии разговоров помогали, а не мешали, лучше учесть следующее:
- Четко объяснять клиенту, что происходит с его запросом.
- Отклоняться от заданного скрипта, если этого требует ситуация.
- Адаптировать скрипты под целевую аудиторию.
- Предоставлять клиентам простые способы переключаться на более квалифицированных в исходном вопросе специалистов.
- Не перекладывать ответственность за ошибки на обстоятельства и информировать клиентов, что будет сделано.
Если следовать описанным принципам и не воспринимать скрипты как непреложный закон, то службе поддержки удастся предложить лучший сервис клиентам.