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

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

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

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

🔔Начало уже через 10 минут! Сегодня в 12:00 по Москве на вебинаре разберём, как перейти от модели «обработать обращение» к модели «решить задачу клиента» и как объединить ИИ, людей и каналы в одну систему, которая реально работает. Подключайтесь по ссылке https://my.mts-link.ru/j/Webim/webim27. До встречи на вебинаре! 🤓

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

В программе: 1️⃣ Почему 70% российских компаний уже используют GenAI, но кейсов с автономными агентами почти нет и что мешает перейти эту грань 2️⃣ Автоматизация ради хайпа осталась в 2025 году: как заставить ИИ не заменять людей, а делать их в разы эффективнее 3️⃣ Омниканальность остаётся базой, но ценность сегодня в маршрутизации: как перераспределять клиентский поток между каналами, AI и человеком без потери контекста 4️⃣ Главный вопрос 2026 года: какую клиентскую задачу вы готовы доверить агенту прямо сейчас?

Спикеры: ▪️ Илья Стрекаловский, Webim ▪️Александра Давыдова, Targetai Дата: 16 сентября 12:00 (Мск) ➡️ Регистрация

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

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

— какие причины появились после релиза; — как они меняются по неделям; — сколько обращений заканчиваются повторным контактом; — сколько пользователей функции приходится на одно обращение.

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

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

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

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

Поэтому при росте нагрузки полезно начинать не с вопроса «что сломалось?», а с более простого: что именно выросло – количество клиентов, число операций, определённый тип обращений, конкретный канал или повторные контакты? Так причина обычно находится гораздо быстрее. Мы в МАХ

Сокращение времени ответа выглядит как очевидная цель. Но если команда начинает измерять только скорость, можно довольно быстро получить обратный эффект. Представим, что среднее время первого ответа снизилось с 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