Все операторы заняты

Разработчики проектируют продукт под определённый сценарий. Пользователь видит интерфейс, решает свою задачу и иногда приходит к совсем другому результату.

Для поддержки это особенно заметно: именно сюда попадают вопросы вроде «А можно сделать вот так?», «Почему нельзя использовать эту функцию для…?» или «Мы делаем это иначе, потому что…».

Не каждый такой случай означает, что пользователь не разобрался.

1️⃣ Пользователь ищет самый короткий путь к результату
му не обязательно важно, как задумана функция. Если вместо пяти шагов можно сделать три, он будет использовать три — даже если разработчики рассчитывали на другой сценарий.

2️⃣ Один инструмент начинают использовать для нескольких задач
Функцию создавали для одного процесса, а клиенты находят ей другое применение. Если такой сценарий повторяется у разных компаний, это уже не просто «нестандартное использование». Возможно, продукт решает более широкую задачу, чем предполагалось.

3️⃣ Люди обходят часть интерфейса
Например, не используют предусмотренный путь, а каждый раз делают действие через чат с оператором, API или другой раздел системы. Такой обходной путь может быть сигналом, что основной сценарий слишком сложный или плохо подходит под реальную работу.

4️⃣ Пользователь достраивает логику продукта сам
Название кнопки, порядок действий или текст подсказки могут сформировать ожидание, которого функция на самом деле не поддерживает. В такой ситуации клиент не обязательно «не понял интерфейс» — интерфейс мог подсказать ему другое.

5️⃣ Один и тот же нестандартный сценарий повторяется
Вот это уже особенно полезно отслеживать. Единичный необычный кейс можно оставить как исключение. Но если десятки клиентов используют функцию одинаковым способом, стоит задать вопрос: почему этот сценарий оказался настолько естественным для пользователей?

Поэтому обращения поддержки полезно анализировать не только как список проблем. Иногда они показывают, какие задачи пользователи на самом деле решают с помощью продукта. И эти сценарии могут отличаться от тех, которые команда закладывала на этапе разработки.

Мы в МАХ

Сильный оператор не всегда сразу становится сильным руководителем. Работа меняется: теперь нужно не самому хорошо закрывать обращения, а выстраивать систему, в которой хорошо работает вся команда.

На этом переходе часто возникают одни и те же ошибки:

Пытаться контролировать всё самостоятельно. Новый руководитель начинает читать больше диалогов, проверять каждую мелочь и лично подключаться к сложным обращениям. В итоге команда привыкает согласовывать решения, а руководитель быстро становится самым загруженным человеком в поддержке.

Сразу менять процессы. Желание «навести порядок» понятно, но первые недели лучше потратить на поиск причин. Почему именно так распределяются обращения? Откуда берутся эскалации? Какие правила уже пытались изменить? Без этого легко исправить не проблему, а её симптом.

Оценивать всех по одним показателям. Один оператор может быстро закрывать большое количество типовых обращений, другой — брать сложные кейсы и тратить на них больше времени. Сравнивать их только по скорости обработки не очень полезно. Метрики должны учитывать характер работы.

Считать вопросы сотрудников признаком слабой компетенции. Новому руководителю может казаться, что команда должна самостоятельно находить ответы. Но постоянные вопросы иногда показывают другое: не хватает полномочий, понятной базы знаний или нормального процесса принятия решений.

Оставлять лучшие практики внутри команды. Опытные операторы постепенно находят более удобные формулировки, способы работы с нестандартными обращениями и обходят лишние шаги. Если это остаётся только на уровне личного опыта, команда продолжает зависеть от нескольких сильных сотрудников.

📌 Главная сложность для нового руководителя — перестать быть самым сильным оператором и начать строить систему, которая работает без постоянного ручного контроля.

Мы в МАХ

Клиенты сегодня ждут не просто вежливого ответа: они хотят быстро понять, что произошло, что будет дальше и нужно ли что-то делать.

Говорили об этом на совместном вебинаре с ServiceUp — как писать сообщения, которые не перегружают клиента и помогают быстрее закрывать обращения. Листайте карточки, в них собрали главные идеи.

А если хотите посмотреть вебинар целиком – запись уже доступна в нашей группе VK

Мы в МАХ

Передача обращения на вторую линию – нормальная часть работы поддержки. Не все вопросы можно решить сразу, и это не должно быть целью.

Проблема начинается в тот момент, когда первая линия передаёт то, что могла бы закрыть самостоятельно – и чаще всего проблема не в сотрудниках, а в процессах:

У операторов не хватает полномочий. Со временем появляются новые ограничения: часть действий требует согласования, часть — доступа, которого у первой линии нет. В итоге даже простые запросы уходят дальше, хотя раньше решались за несколько минут.

Обучение не успевает за изменениями продукта. После релизов появляются новые сценарии, но инструкции и обучение обновляются позже. Для оператора безопаснее передать обращение специалисту, чем рисковать и искать решение самостоятельно.

База знаний не помогает принять решение. Если статья отвечает только на вопрос «что это за функция?», но не объясняет, что делать в конкретной ситуации клиента, оператору проще создать эскалацию, чем искать ответ в нескольких документах.

KPI подталкивают к передаче обращений. Когда скорость ответа важнее, чем решение вопроса на первой линии, передача становится самым быстрым способом уложиться в показатели. Это проблема не команды, а системы оценки.

Никто не анализирует причины эскалаций. Само по себе количество передач мало о чём говорит. Намного полезнее регулярно смотреть, какие обращения чаще всего уходят на вторую линию и почему. Иногда оказывается, что проблему можно решить одним изменением в процессе, обновлением базы знаний или дополнительным доступом для первой линии.

Поддержка становится эффективнее не тогда, когда эскалаций нет совсем, а когда на вторую линию попадают только те обращения, которые действительно требуют её участия. Именно поэтому полезно анализировать не только количество передач, но и их причины.

Мы в МАХ

Перегрузка команды не начинается с жалоб клиентов или падения оценок: обычно первые сигналы появляются внутри процессов. Меняется поведение операторов, команды и руководителей.

Собрали несколько признаков, которые помогают заметить проблему раньше, чем она отразится на метриках.

Мы в МАХ

Если один оператор меняет скрипт, это может быть ошибкой. Если так начинает делать вся команда – стоит проверить сам скрипт.

Во многих контакт-центрах отклонения от сценария используют как источник обратной связи: они помогают понять, какие процессы пора пересмотреть.

Операторы перестают задавать один и тот же вопрос
Иногда оказывается, что ответ почти никогда не влияет на дальнейший сценарий. Если сотрудники массово пропускают этот этап, стоит проверить, действительно ли он нужен. Возможно, вопрос остался в скрипте после старого процесса или уже дублирует данные из CRM.

Операторы меняют порядок диалога
Например, сначала решают проблему клиента, а уже потом уточняют данные или рассказывают о дополнительных возможностях. Такое поведение может говорить о том, что реальный ход разговора отличается от сценария, который описан в инструкции.

Операторы используют свои формулировки
Это не всегда попытка «говорить по-своему». Иногда сотрудники находят объяснение, которое клиенты понимают быстрее. Если похожие формулировки начинают использовать разные операторы независимо друг от друга, это хороший повод пересмотреть текст скрипта.

Скрипт перестаёт работать после изменений в продукте
Поддержка обычно сталкивается с новыми вопросами раньше, чем обновляются инструкции. В результате сотрудники начинают дополнять сценарий самостоятельно. Если это происходит регулярно, проблема, скорее всего, в процессе обновления базы знаний и скриптов, а не в работе команды.

Сценарий рассчитан на «идеальный» диалог
На практике клиенты перескакивают между вопросами, возвращаются к предыдущим темам или сообщают новую информацию в середине разговора. Если скрипт не оставляет пространства для таких ситуаций, операторы всё равно будут адаптировать его под реальность.

📌 Скрипт – это не стандарт, который однажды написали и больше не меняют. Если сотрудники массово отходят от сценария одинаковым способом, это хороший повод пересмотреть сам сценарий, а не только напомнить о регламентах.

Мы в МАХ

Поддержка постоянно меняется: появляются новые функции, меняются сценарии, растёт нагрузка, обновляются ожидания клиентов. Но многие процессы при этом годами остаются без изменений, потому что «и так работает».

В результате команда тратит время на лишние действия, а проблемы начинают повторяться. Ниже – несколько процессов, которые полезно пересматривать хотя бы раз в квартал:

Шаблоны ответов. Хороший шаблон постепенно устаревает. В продукте появляются новые функции, меняются формулировки, а операторы начинают дописывать текст вручную. Если один и тот же шаблон постоянно редактируют перед отправкой, это повод обновить его целиком.

Маршрутизацию обращений. Со временем меняется не только количество обращений, но и их структура. Темы, которые раньше требовали участия второй линии, могут успешно закрываться на первой. И наоборот. Периодический пересмотр маршрутов помогает сократить количество переводов между сотрудниками.

Базу знаний. Один из самых простых способов найти устаревшие статьи — посмотреть, по каким темам клиенты продолжают обращаться после того, как получили ссылку на инструкцию. Если вопрос всё равно возвращается, проблема может быть не в пользователе, а в самой статье.

Причины повторных обращений. Считать их недостаточно. Гораздо полезнее раз в квартал выбрать несколько самых частых сценариев и посмотреть, почему клиенты возвращаются. Иногда достаточно изменить одно уведомление, добавить информацию в ответ оператора или скорректировать процесс, чтобы количество повторных обращений заметно снизилось.

Правила оценки качества. То, что было важно полгода назад, не всегда остаётся актуальным. Например, если команда активно использует ИИ-помощников или обновила базу знаний, стоит проверить, отражают ли критерии оценки текущую работу операторов или по-прежнему ориентированы на старые процессы.

Причины эскалаций. Если обращения регулярно передают другой команде по одним и тем же вопросам, полезно разобраться, почему это происходит. Возможно, сотрудникам первой линии не хватает полномочий, информации или доступа к нужным инструментам.

📌 Не каждый процесс требует изменений каждый квартал. Но регулярный пересмотр помогает заметить то, что постепенно стало нормой: лишние согласования, устаревшие инструкции, повторяющиеся действия и обращения, которых можно было избежать.

Мы в МАХ

💬 Вебинар Понятные сообщения в чате: как снизить информационную нагрузку клиента и закрывать обращения быстрее

Разберём, как делать сообщения в чате простыми и понятными с первого прочтения, и на живых примерах увидим, как лёгкие правки превращают тяжёлый текст в однозначный и убедительный.

В программе:
1️⃣ Как мозг клиента читает сообщения в чате и за что цепляется взгляд в первые секунды

2️⃣ Почему одинаковый по объему текст может восприниматься как простой или перегруженный

3️⃣ Информационный шум: какие слова и конструкции увеличивают нагрузку, но не добавляют смысла

4️⃣ Как управлять плотностью текста и структурой сообщения, чтобы клиент быстрее находил главное

5️⃣ Как сокращать сообщения без потери смысла, эмпатии и естественного стиля общения

Спикеры:
▪️ Илья Стрекаловский, Webim
▪️Татьяна Кузнецова, ServiceUP

Дата: 30 июля
Время: 12:00 (Мск)

➡️ Регистрация по ссылке

Повторное обращение не всегда означает, что поддержка плохо ответила. Иногда клиент возвращается с новым вопросом, иногда не смог воспользоваться решением, а иногда сама причина проблемы осталась незамеченной.

Чтобы понять, что именно произошло, полезно смотреть не только на количество повторных обращений, но и на их причины.

Собрали вопросы, которые помогают разобраться в ситуации 👀

Мы в МАХ