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

Сокращение времени ответа выглядит как очевидная цель. Но если команда начинает измерять только скорость, можно довольно быстро получить обратный эффект. Представим, что среднее время первого ответа снизилось с 5 минут до 2. Метрика улучшилась, но одновременно выросло количество повторных обращений. Операторы чаще передают диалоги коллегам, и клиенты снова объясняют проблему после первого ответа. Получается парадокс: поддержка стала отвечать быстрее, но клиенту стало дольше получать решение. Такое происходит, когда скорость превращается в самостоятельную цель. Оператору важно как можно быстрее отправить первый ответ, поэтому вместо решения он даёт шаблон, задаёт формальный вопрос или закрывает диалог сразу после минимально необходимой информации. Поэтому время первого ответа лучше смотреть вместе с другими показателями:

— сколько времени проходит до решения; — сколько обращений требуют повторного контакта; — как часто диалог передают другому сотруднику;

— меняется ли удовлетворённость клиентов. Особенно показательно сравнивать скорость первого ответа и время до решения. Если первая сокращается, а второе растёт, команда просто быстрее начинает диалог – но не быстрее решает проблему. Цель поддержки – не ответить как можно скорее. Цель – как можно быстрее довести клиента до результата. Мы в МАХ

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

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

1️⃣ Пользователь ищет самый короткий путь к результату му не обязательно важно, как задумана функция. Если вместо пяти шагов можно сделать три, он будет использовать три — даже если разработчики рассчитывали на другой сценарий. 2️⃣ Один инструмент начинают использовать для нескольких задач Функцию создавали для одного процесса, а клиенты находят ей другое применение. Если такой сценарий повторяется у разных компаний, это уже не просто «нестандартное использование». Возможно, продукт решает более широкую задачу, чем предполагалось. 3️⃣ Люди обходят часть интерфейса Например, не используют предусмотренный путь, а каждый раз делают действие через чат с оператором, API или другой раздел системы. Такой обходной путь может быть сигналом, что основной сценарий слишком сложный или плохо подходит под реальную работу. 4️⃣ Пользователь достраивает логику продукта сам Название кнопки, порядок действий или текст подсказки могут сформировать ожидание, которого функция на самом деле не поддерживает. В такой ситуации клиент не обязательно «не понял интерфейс» — интерфейс мог подсказать ему другое. 5️⃣ Один и тот же нестандартный сценарий повторяется Вот это уже особенно полезно отслеживать. Единичный необычный кейс можно оставить как исключение. Но если десятки клиентов используют функцию одинаковым способом, стоит задать вопрос: почему этот сценарий оказался настолько естественным для пользователей?

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

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

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

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

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

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

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

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

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

🔔Начало уже через час! В 12:00 по Москве на вебинаре расскажем, как операторам общаться в чате, чтобы повысить CSAT. Подключайтесь по ссылке https://my.mts-link.ru/j/Webim/webim26. До встречи на вебинаре! 🤓

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

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

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

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

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

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

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

В программе: 1️⃣ Как мозг клиента читает сообщения в чате и за что цепляется взгляд в первые секунды 2️⃣ Почему одинаковый по объему текст может восприниматься как простой или перегруженный 3️⃣ Информационный шум: какие слова и конструкции увеличивают нагрузку, но не добавляют смысла 4️⃣ Как управлять плотностью текста и структурой сообщения, чтобы клиент быстрее находил главное 5️⃣ Как сокращать сообщения без потери смысла, эмпатии и естественного стиля общения

Спикеры: ▪️ Илья Стрекаловский, Webim ▪️Татьяна Кузнецова, ServiceUP Дата: 30 июля Время: 12:00 (Мск) ➡️ Регистрация по ссылке

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

⚡ Начало уже через час! В 12:00 по Москве на вебинаре расскажем, как анализировать чаты и диалоги на базе LLM. ➡️ Подключайтесь по ссылке https://my.mts-link.ru/j/Webim/webim25

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

• Проблему решили, но клиенту пришлось несколько раз повторять одно и то же Каждый новый оператор без контекста возвращает клиента в начало разговора. Для компании это несколько сообщений в разных диалогах, а для клиента – ощущение, что его никто не слушает. • Ответ дали, но клиенту пришлось самому разбираться дальше Например, оператор отправил ссылку на инструкцию – вроде информация есть. Но если клиент не понимает, какой шаг сделать первым, вопрос все равно остаётся открытым. • Решение заняло больше времени, чем ожидалось Иногда клиент готов ждать, но ему нужно понимать, что происходит. Отсутствие информации часто раздражает сильнее, чем сама задержка. • Компания исправила ошибку, но не объяснила причину После сбоя клиенту важно не только снова получить доступ к сервису. Ему нужно понять, что ситуация под контролем.

📌 Закрытое обращение это не всегда решённая проблема. Хороший показатель поддержки – не только сколько вопросов команда закрыла, но и насколько легко клиент получил результат.

📢 Вебинар Анализ чатов и диалогов на базе LLM: от сырых данных до детальной статистики по операторам Мы пригласили наших партнёров из 3iTech, чтобы они рассказали, как анализировать чаты и диалоги с помощью LLM, а также показали на кейсах, как не допустить ошибок.

В программе: 1⃣ Ключевые слова работают, но они не различают «плохо» и «не плохо», оператор сказал «проблема» — триггер, а клиент сказал «это не проблема» — тот же набор слов, а смысл обратный. Расскажем, когда стоит подключать LLM для анализа чатов, а когда достаточно фильтров. 2⃣ Секретный промт, который вытащит из диалогов возражения, о которых вы не подозревали, и подсветит, почему клиенты уходят к другим. 3⃣ От разговора к стратегии — не просто «что сказал», а «почему сказал». Разберём, как проанализировать все свободные ответы и формы одним запросом. 4⃣ Как LLM меняет подход к обучению операторов: LLM прочитает 500 диалогов и выдаст не цифры, а готовую рекомендацию для каждого оператора.

📍16 июля, 12:00 по МСК ➡ Регистрируйтесь

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

– Короткие сообщения чаще встречаются у пользователей, которые привыкли решать вопросы в чатах Они ожидают, что оператор сам уточнит недостающие детали и быстро перейдёт к решению. – Подробные обращения помогают понять контекст Если клиент описывает всю последовательность действий, не стоит сразу сокращать разговор. Иногда именно одна деталь помогает найти причину проблемы. – Одни и те же формулировки могут скрывать разные сценарии Сообщение «не работает» почти никогда не означает одно и то же. Полезнее уточнить, на каком шаге возникла сложность, чем просить описать проблему ещё раз. – Стиль сообщения не всегда говорит об отношении клиента Кто-то пишет коротко, кто-то — развёрнуто. Для одних привычны эмодзи и несколько сообщений подряд, для других — одно длинное письмо. Это особенности общения, а не показатель настроя. – Понятный ответ работает для всех Простые формулировки, один следующий шаг и минимум внутренних терминов обычно помогают быстрее решить вопрос независимо от возраста клиента.

📌 Универсального сценария общения для разных поколений нет. Гораздо полезнее обращать внимание на то, как человек общается в текущем диалоге, и подстраивать ответ под этот формат. Мы в МАХ

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

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

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

📌 Хорошая инструкция – это не длинный документ с полным описанием процесса. Это ответ, который пользователь нашёл за несколько секунд и сразу применил. Именно такие инструкции действительно снижают количество обращений. Мы в МАХ

Недавно вместе с командой MAX провели вебинар о том, как использовать новый мессенджер для поддержки клиентов, автоматизации и продаж. Во время вебинара вы задали много вопросов. Собрали самые интересные из них и ответы команды MAX — в карточках👀 ➡️ Следите за новыми возможностями платформы в канале MAX для бизнеса, а полная запись вебинара уже доступна в нашем боте @WebimEvents_bot Webim в МАХ

Компании и клиенты по-разному оценивают один и тот же сервис. Внутри команды обсуждают время ответа, соответствие SLA и ошибки в интерфейсе, а клиент оценивает другое: сколько усилий ему пришлось потратить, чтобы решить свой вопрос. Вот где эта разница заметна сильнее всего ⬇️

🕣Ответ пришёл на две минуты позже Для поддержки это может выглядеть как нарушение KPI, но для клиента намного важнее, пришлось ли ему писать повторно. Если вопрос решили с первого раза, небольшую задержку часто даже не замечают. ☑️Всё работает по регламенту Бизнес считает такой процесс правильным, а клиенту приходится пять раз переключаться между отделами или заново объяснять ситуацию каждому сотруднику. Формально ошибки нет. Для клиента — есть. 🛠Сбой быстро устранили Компания фиксирует время восстановления. Клиент запоминает другое: пришлось ли ему самому искать информацию о сбое или компания предупредила заранее. 👨‍💻Оператор дал правильный ответ С точки зрения компании задача выполнена. Но если ответ написан так, что клиенту пришлось задавать ещё три уточняющих вопроса, проблему нельзя считать решённой. ⚙️Добавили новую функцию Команда оценивает количество пользователей, которые её открыли. Клиенты оценивают другое: стало ли проще выполнять привычную задачу. Если нет — новая функция редко воспринимается как улучшение.

Хороший клиентский опыт складывается не из отсутствия ошибок, а из отсутствия лишних усилий со стороны клиента. Поэтому полезно измерять не только скорость, соблюдение SLA и количество закрытых обращений, но и то, сколько действий пришлось сделать человеку, чтобы получить результат. Мы в МАХ