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

Сильный оператор не всегда сразу становится сильным руководителем. Работа меняется: теперь нужно не самому хорошо закрывать обращения, а выстраивать систему, в которой хорошо работает вся команда. На этом переходе часто возникают одни и те же ошибки: Пытаться контролировать всё самостоятельно. Новый руководитель начинает читать больше диалогов, проверять каждую мелочь и лично подключаться к сложным обращениям. В итоге команда привыкает согласовывать решения, а руководитель быстро становится самым загруженным человеком в поддержке. Сразу менять процессы. Желание «навести порядок» понятно, но первые недели лучше потратить на поиск причин. Почему именно так распределяются обращения? Откуда берутся эскалации? Какие правила уже пытались изменить? Без этого легко исправить не проблему, а её симптом. Оценивать всех по одним показателям. Один оператор может быстро закрывать большое количество типовых обращений, другой — брать сложные кейсы и тратить на них больше времени. Сравнивать их только по скорости обработки не очень полезно. Метрики должны учитывать характер работы. Считать вопросы сотрудников признаком слабой компетенции. Новому руководителю может казаться, что команда должна самостоятельно находить ответы. Но постоянные вопросы иногда показывают другое: не хватает полномочий, понятной базы знаний или нормального процесса принятия решений. Оставлять лучшие практики внутри команды. Опытные операторы постепенно находят более удобные формулировки, способы работы с нестандартными обращениями и обходят лишние шаги. Если это остаётся только на уровне личного опыта, команда продолжает зависеть от нескольких сильных сотрудников. 📌 Главная сложность для нового руководителя — перестать быть самым сильным оператором и начать строить систему, которая работает без постоянного ручного контроля. Мы в МАХ

Клиенты сегодня ждут не просто вежливого ответа: они хотят быстро понять, что произошло, что будет дальше и нужно ли что-то делать. Говорили об этом на совместном вебинаре с ServiceUp — как писать сообщения, которые не перегружают клиента и помогают быстрее закрывать обращения. Листайте карточки — собрали главные идеи. А если хотите посмотреть вебинар целиком – запись уже доступна в нашей группе VK Мы в МАХ

Передача обращения на вторую линию – нормальная часть работы поддержки. Не все вопросы можно решить сразу, и это не должно быть целью. Проблема начинается в тот момент, когда первая линия передаёт то, что могла бы закрыть самостоятельно – и чаще всего проблема не в сотрудниках, а в процессах: У операторов не хватает полномочий. Со временем появляются новые ограничения: часть действий требует согласования, часть — доступа, которого у первой линии нет. В итоге даже простые запросы уходят дальше, хотя раньше решались за несколько минут. Обучение не успевает за изменениями продукта. После релизов появляются новые сценарии, но инструкции и обучение обновляются позже. Для оператора безопаснее передать обращение специалисту, чем рисковать и искать решение самостоятельно. База знаний не помогает принять решение. Если статья отвечает только на вопрос «что это за функция?», но не объясняет, что делать в конкретной ситуации клиента, оператору проще создать эскалацию, чем искать ответ в нескольких документах. KPI подталкивают к передаче обращений. Когда скорость ответа важнее, чем решение вопроса на первой линии, передача становится самым быстрым способом уложиться в показатели. Это проблема не команды, а системы оценки. Никто не анализирует причины эскалаций. Само по себе количество передач мало о чём говорит. Намного полезнее регулярно смотреть, какие обращения чаще всего уходят на вторую линию и почему. Иногда оказывается, что проблему можно решить одним изменением в процессе, обновлением базы знаний или дополнительным доступом для первой линии. Поддержка становится эффективнее не тогда, когда эскалаций нет совсем, а когда на вторую линию попадают только те обращения, которые действительно требуют её участия. Именно поэтому полезно анализировать не только количество передач, но и их причины. Мы в МАХ

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

Если один оператор меняет скрипт, это может быть ошибкой. Если так начинает делать вся команда – стоит проверить сам скрипт. Во многих контакт-центрах отклонения от сценария используют как источник обратной связи: они помогают понять, какие процессы пора пересмотреть. Операторы перестают задавать один и тот же вопрос Иногда оказывается, что ответ почти никогда не влияет на дальнейший сценарий. Если сотрудники массово пропускают этот этап, стоит проверить, действительно ли он нужен. Возможно, вопрос остался в скрипте после старого процесса или уже дублирует данные из CRM. Операторы меняют порядок диалога Например, сначала решают проблему клиента, а уже потом уточняют данные или рассказывают о дополнительных возможностях. Такое поведение может говорить о том, что реальный ход разговора отличается от сценария, который описан в инструкции. Операторы используют свои формулировки Это не всегда попытка «говорить по-своему». Иногда сотрудники находят объяснение, которое клиенты понимают быстрее. Если похожие формулировки начинают использовать разные операторы независимо друг от друга, это хороший повод пересмотреть текст скрипта. Скрипт перестаёт работать после изменений в продукте Поддержка обычно сталкивается с новыми вопросами раньше, чем обновляются инструкции. В результате сотрудники начинают дополнять сценарий самостоятельно. Если это происходит регулярно, проблема, скорее всего, в процессе обновления базы знаний и скриптов, а не в работе команды. Сценарий рассчитан на «идеальный» диалог На практике клиенты перескакивают между вопросами, возвращаются к предыдущим темам или сообщают новую информацию в середине разговора. Если скрипт не оставляет пространства для таких ситуаций, операторы всё равно будут адаптировать его под реальность. 📌 Скрипт – это не стандарт, который однажды написали и больше не меняют. Если сотрудники массово отходят от сценария одинаковым способом, это хороший повод пересмотреть сам сценарий, а не только напомнить о регламентах. Мы в МАХ

Поддержка постоянно меняется: появляются новые функции, меняются сценарии, растёт нагрузка, обновляются ожидания клиентов. Но многие процессы при этом годами остаются без изменений, потому что «и так работает». В результате команда тратит время на лишние действия, а проблемы начинают повторяться. Ниже – несколько процессов, которые полезно пересматривать хотя бы раз в квартал: Шаблоны ответов. Хороший шаблон постепенно устаревает. В продукте появляются новые функции, меняются формулировки, а операторы начинают дописывать текст вручную. Если один и тот же шаблон постоянно редактируют перед отправкой, это повод обновить его целиком. Маршрутизацию обращений. Со временем меняется не только количество обращений, но и их структура. Темы, которые раньше требовали участия второй линии, могут успешно закрываться на первой. И наоборот. Периодический пересмотр маршрутов помогает сократить количество переводов между сотрудниками. Базу знаний. Один из самых простых способов найти устаревшие статьи — посмотреть, по каким темам клиенты продолжают обращаться после того, как получили ссылку на инструкцию. Если вопрос всё равно возвращается, проблема может быть не в пользователе, а в самой статье. Причины повторных обращений. Считать их недостаточно. Гораздо полезнее раз в квартал выбрать несколько самых частых сценариев и посмотреть, почему клиенты возвращаются. Иногда достаточно изменить одно уведомление, добавить информацию в ответ оператора или скорректировать процесс, чтобы количество повторных обращений заметно снизилось. Правила оценки качества. То, что было важно полгода назад, не всегда остаётся актуальным. Например, если команда активно использует ИИ-помощников или обновила базу знаний, стоит проверить, отражают ли критерии оценки текущую работу операторов или по-прежнему ориентированы на старые процессы. Причины эскалаций. Если обращения регулярно передают другой команде по одним и тем же вопросам, полезно разобраться, почему это происходит. Возможно, сотрудникам первой линии не хватает полномочий, информации или доступа к нужным инструментам. 📌 Не каждый процесс требует изменений каждый квартал. Но регулярный пересмотр помогает заметить то, что постепенно стало нормой: лишние согласования, устаревшие инструкции, повторяющиеся действия и обращения, которых можно было избежать. Мы в МАХ

💬 Вебинар Понятные сообщения в чате: как снизить информационную нагрузку клиента и закрывать обращения быстрее Разберём, как делать сообщения в чате простыми и понятными с первого прочтения, и на живых примерах увидим, как лёгкие правки превращают тяжёлый текст в однозначный и убедительный. В программе: 1️⃣ Как мозг клиента читает сообщения в чате и за что цепляется взгляд в первые секунды 2️⃣ Почему одинаковый по объему текст может восприниматься как простой или перегруженный 3️⃣ Информационный шум: какие слова и конструкции увеличивают нагрузку, но не добавляют смысла 4️⃣ Как управлять плотностью текста и структурой сообщения, чтобы клиент быстрее находил главное 5️⃣ Как сокращать сообщения без потери смысла, эмпатии и естественного стиля общения Спикеры: ▪️ Илья Стрекаловский, Webim ▪️Татьяна Кузнецова, ServiceUP Дата: 30 июля Время: 12:00 (Мск) ➡️ Регистрация по ссылке