Оценка качества чатов начинается с задачи клиента и полной цепочки сообщений. Проверьте, верно ли сотрудник ответил, сохранил ли условия, выполнил ли обещанное и оставил ли понятный следующий шаг. Скорость ответа и факт продажи фиксируйте отдельно. Для первого разбора подойдёт таблица; ниже - стартовый чек-лист, который вы можете адаптировать под свой отдел.
Что считать одним диалогом
Возьмите за единицу проверки одно обращение по конкретной задаче клиента. В переписке эта задача может переходить между сотрудниками, продолжаться после ночной паузы или завершаться звонком. Если оценить только последнее сообщение, часть действий останется за пределами разбора.
Перед проверкой запишите:
- задачу клиента: что он просил узнать, получить или изменить;
- начало обращения и дату, на которую вы оцениваете результат;
- сообщения всех участников, относящиеся к этой задаче;
- связанные файлы, условия предложения и подтверждения действий, доступные проверяющему.
Это предлагаемое правило для ручного разбора. Система чатов может делить историю иначе, например по сессиям или закрытым обращениям. Сначала согласуйте правило внутри команды, затем используйте его одинаково во всех проверках.
Новую самостоятельную просьбу того же клиента можно оценить отдельно. Продолжение прежней просьбы после паузы сохраните вместе с предыдущими сообщениями. Например, «Где мой заказ?» и последующее «Обещали уточнить вчера» относятся к одной незавершённой задаче.
Разделяйте качество всей цепочки и действия конкретного сотрудника. Если первый менеджер передал вопрос без контекста, а второй исправил ситуацию, финальный ответ не отменяет ошибку передачи. Но второй сотрудник не отвечает за сообщение, которое отправил первый.
Чек-лист оценки переписки с клиентом
Для каждого пункта нужны наблюдаемое действие и подтверждение: сообщение, файл или запись о выполненной операции. Формулировка «общался профессионально» оставляет слишком много места личному впечатлению. В таблице - авторский стартовый шаблон, а не обязательный стандарт для всех компаний.
| Что проверить | Когда пункт выполнен | Когда нужна отдельная оговорка |
|---|---|---|
| Понял задачу | Ответ касается просьбы клиента; недостающие сведения уточнены | Если всё уже написано, повторные вопросы не нужны |
| Ответил правильно | Ответ соответствует актуальным условиям компании и данным по обращению | Без доступа к этим данным правильность может остаться непроверенной |
| Сохранил существенные условия | Указаны ограничения, от которых зависит решение клиента: срок, состав услуги, условия предложения | Проверяйте только условия, значимые для этой задачи |
| Написал понятно | Клиенту ясно, что предлагается и что делать; термины пояснены, нужная ссылка ведёт к нужному материалу | Не снижайте оценку за отсутствие любимой фразы из скрипта |
| Объяснил паузу | При необходимости проверки сообщил, что выясняет и когда вернётся с ответом | Если вопрос решён сразу, пункт не применяется |
| Передал контекст | Следующий сотрудник получил задачу, уже известные сведения и договорённости | Применяется только при передаче обращения |
| Выполнил обещанный шаг | Отправил обещанное, создал обращение или сделал другое согласованное действие; есть подтверждение | Если срок ещё не наступил, итоговую проверку этого действия отложите |
| Зафиксировал исход | По истории понятно: вопрос решён, ожидаются сведения клиента или есть следующий шаг с ответственным и сроком | Закрытый статус в системе сам по себе не подтверждает решение |
Добавьте к таблице примеры выполнения и ошибки из разрешённых для внутреннего разбора материалов. Если оценка требует увидеть вложение, проверяющий должен получить его. Сообщение «файл отправлен» не позволяет проверить, тот ли это файл и открывается ли он у клиента.
Для звонков нужен свой набор наблюдаемых признаков: его можно собрать по статье про чек-лист оценки звонка менеджера. В текстовом чате интонация недоступна для оценки. При разборе паузы проверьте рабочий график, обещанный срок и то, чьё действие ожидалось.
Если вы выстраиваете контроль сразу нескольких каналов, отдельно определите, как ошибки будут разбираться с командой. На демонстрации Точки СУТИ можно посмотреть контроль звонков и работу с повторяющимися ошибками менеджеров. Описанный здесь чек-лист переписки вы можете использовать вручную в своей таблице.
Как ставить оценки и считать балл
Начните с четырёх статусов: «выполнено», «не выполнено», «не применимо» и «нет данных». У каждого статуса должна быть причина. Иначе одинаковый прочерк будет обозначать и отсутствие ошибки, и отсутствие проверки.
«Выполнено» - действие требовалось, и есть свидетельство его выполнения. «Не выполнено» - действие требовалось, срок уже наступил, а доступная история показывает ошибку или пропуск. Например, менеджер обещал прислать условия к согласованному времени, но в полной истории отправки их нет.
«Не применимо» - в этом обращении не было повода для действия. Если клиент сразу сообщил все нужные сведения, дополнительные вопросы ради балла не нужны. Сам пункт «Понял задачу» остаётся применимым: проверьте, соответствует ли ответ просьбе клиента. Если передачи между сотрудниками не было, пункт о передаче исключается.
«Нет данных» - проверить пока нельзя: отсутствует вложение, выгружена только часть истории или ещё не наступил обещанный срок. Зафиксируйте, чего не хватает и когда вернуться к проверке. Не записывайте неизвестность как выполненный пункт или ошибку сотрудника.
Для завершённого разбора с одинаковым весом пунктов используйте формулу:
Балл качества = число выполненных пунктов / число применимых пунктов × 100%.
Из знаменателя исключаются только пункты «не применимо». Если по применимому пункту стоит «нет данных», отметьте разбор как неполный и пока не выводите итоговый балл. Такой порядок не позволяет неполной выгрузке искусственно улучшить результат. Если применимых пунктов нет, процент не рассчитывается.
Условный расчёт: из восьми пунктов один не применим, шесть выполнены, один не выполнен. Балл равен 6 / 7 × 100% = 85,7%. Это иллюстрация формулы, не рекомендуемый проходной порог. Порог и вес критериев определяйте по последствиям ошибок в своём процессе.
Критические ошибки отмечайте отдельно от процента. Например, неверное существенное условие предложения должно попасть в разбор, даже если остальные пункты выполнены. Заранее запишите перечень таких ошибок и правило реакции: кто проверяет ситуацию, что исправляет и как подтверждает исправление.
Механика зависит от инструмента. В документации Intercom по оценочным листам есть исключение критерия из расчёта и отдельное правило для критического провала. В чек-листах аналитики чатов Roistat используются веса и доли тегов; отчёт различает сообщения и чаты. Поэтому при переносе своей таблицы в систему проверьте, что именно она считает. Наша формула выше описывает ручную оценку одного обращения и не воспроизводит расчёт этих сервисов.
Пример разбора паузы и передачи обращения
Следующий диалог вымышлен и показывает применение критериев. Клиент спрашивает о сроке доставки; менеджеру нужно уточнить его у логиста. Даты и реплики приведены только для примера.
Клиент: «Нужна доставка к пятнице. Сможете?»
Менеджер: «Уточню срок у логиста и вернусь сегодня до 16:00».
В 15:50 менеджер: «Передал ваш вопрос коллеге».
На следующий день другой сотрудник: «Добрый день. Что вас интересует?»
По этой цепочке видно, что первый менеджер обозначил паузу и срок ответа. Но сообщение о передаче не содержит ответа о доставке и не согласует новый срок. Если полная история на следующий день подтверждает отсутствие обещанного ответа, пункт о выполнении следующего шага не выполнен.
Повторный общий вопрос второго сотрудника - повод проверить передачу контекста. Посмотрите внутреннюю запись передачи: был ли там срок доставки, вопрос клиента и обещание вернуться до 16:00. По одной внешней реплике нельзя уверенно решить, кто потерял информацию. Если записи передачи у проверяющего нет, поставьте «нет данных» и запросите её.
Правильность ответа о доставке здесь пока оценить нельзя: самого ответа нет. Не придумывайте результат и не начисляйте балл за вежливый тон. В карточке разбора зафиксируйте незавершённость обращения и проверьте его снова после ответа клиенту.
Исправление должно касаться конкретного пропуска. Сотруднику, который продолжает обращение, нужны вопрос клиента, уже проверенные сведения и обязательство по следующему ответу. Если прежний срок сорван, нужно сообщить клиенту текущий статус и новый срок, который команда сможет подтвердить.
Как запустить проверку в отделе
Сначала проверьте, одинаково ли команда понимает критерии, затем используйте оценки для регулярного разбора. Для начала выберите один сценарий, например входящие вопросы о доставке. Переписку по возвратам или сложным претензиям можно добавить после того, как правила для первого сценария станут понятны.
- Подготовьте материал. Соберите полные цепочки по выбранному сценарию за один период. Используйте разрешённое корпоративное хранилище и доступы; для примеров, которые увидят другие сотрудники, уберите ненужные персональные сведения.
- Проверьте крайние случаи. Включите быстрый ответ, паузу, передачу, незавершённое обращение и неполную выгрузку. Это набор для проверки правил, не репрезентативная оценка всего отдела.
- Сравните трактовки. Пусть два проверяющих независимо разберут одни и те же цепочки. По каждому расхождению уточните условие применения и требуемое свидетельство. Затем проверьте обновлённое правило на других обращениях.
- Запишите исправление. В карточке оставьте задачу клиента, дату среза, критерий, ссылку на сообщение, статус, нужное действие, ответственного и срок проверки.
- Вернитесь к результату. Убедитесь, что обещанное действие выполнено и похожий пропуск не повторяется в новых переписках того же сценария. Если ошибка сохраняется, проверьте доступность информации и сам порядок передачи, прежде чем делать вывод о навыке сотрудника.
Для регулярного отчёта отделите случайно выбранные обращения от специально отобранных проблемных. Целевая подборка просрочек полезна для поиска причин, но её долю ошибок нельзя переносить на весь поток. Не смешивайте разные сценарии, версии чек-листа и неполные проверки в одном сравнительном балле.
Рядом с качеством держите отдельные поля: время первого ответа, время следующего ответа, текущий исход обращения и результат продажи, если он относится к задаче. Для временных показателей заранее определите рабочие часы, момент начала отсчёта и учёт ожидания клиента. Например, справка Intercom о метриках отдельно описывает первый ответ, последующие ответы и ответ после назначения. Единую норму секунд из этих названий вывести нельзя.
Что проверить перед автоматической оценкой чатов
Автоматизацию имеет смысл обсуждать после того, как ручные правила выдержали реальные примеры. Начните с полноты входных данных: видит ли система всю цепочку, вложения, смену сотрудника и действия в связанной системе. Если проверяющему нужна информация о выполнении обещания, один текст сообщения может оказаться недостаточным.
Попросите показать, на какие сообщения опирается оценка и как система обрабатывает неприменимый пункт, нехватку данных и незавершённый диалог. Отдельно проверьте, можно ли исправить ошибочную оценку и сохранить причину изменения. Эти вопросы подходят для демонстрации любого оценщика; они не означают, что перечисленные функции есть у каждого продукта.
Если отдел уже проверяет голосовые разговоры, порядок испытания автоматических оценок разобран в статье о точности ИИ-оценки звонков. Для чатов потребуется свой набор примеров с паузами и передачами. До таких испытаний оставьте спорные выводы на ручной проверке.
Источники
- Intercom: создание и настройка оценочных листов - критерии, шкалы и правила расчёта; возможности конкретного продукта, не универсальная методика.
- Roistat: чек-листы в аналитике чатов - веса тегов и различие отчётов по сообщениям и чатам. Раздел аналитики чатов отмечен как открытое бета-тестирование.
- Intercom: определения метрик отчётности - границы расчёта временных показателей.
Источники проверены 13 октября 2026 года. Чек-лист, четыре статуса и пример переписки в статье предложены для ручной проверки; это не описание функций Точки СУТИ.
Посмотрите, как это работает на ваших звонках
Разберём реальный сценарий вашего отдела продаж и покажем платформу за 30–40 минут.
