Как анализировать поток звонков: причины обращений и проверка изменений

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

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

Сначала выберите вопрос к звонкам

«Хотим анализировать всё» обычно заканчивается папкой красивых отчётов. Начните с вопроса, влияющего на работу:

• Почему клиенты повторно обращаются по одной теме?
• Какое обещание чаще остаётся без следующего шага?
• Где менеджерам не хватает данных для предложения?
• Какие вопросы нужно добавить в инструкцию?

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

В документации Zendesk о Voice QA расшифровки и краткие итоги рассматриваются как способ быстрее находить разговоры для подробного разбора. Это полезная идея организации работы: текст помогает выбрать значимый эпизод, а не отменяет необходимость его понимать.

Определите единицу анализа

Звонок, обращение и клиент — разные единицы. Один человек может позвонить трижды по одному вопросу; один разговор может содержать две проблемы. Если посчитать упоминания, получится число фраз, а не число обращений.

Для начала заведите внешний рабочий реестр или используйте принятую в компании систему:

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

Учебный пример: «клиенты не понимают инструкцию»

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

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

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

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

Рабочая матрица:

Это не измерение распространённости проблемы на всём потоке. Это разбор ограниченной серии, который помогает выбрать проверяемое изменение.

Один кейс, несколько причин и повторный звонок

Вымышленный кейсК-07 начинается со звонкаЗ-09: клиент не понимает, какой документ подходит. После уточнения выбирает правильный файл, но обнаруживает превышение размера. Основная причина первого звонка — выбор документа; размер — дополнительное затруднение. Не удаляйте его, чтобы таблица красиво складывалась в 100%.

В звонкеЗ-10 клиент возвращается с уменьшенным файлом: загрузка прошла, но статус не обновился. Это новая запись разговора по прежнему кейсу, а не второй независимый клиент. ЗвонокЗ-11 подтверждает появление статуса и закрывает кейс. Результат кейса обновляется, однако причины и ответы каждого звонка сохраняются в истории.

Допустим, остальные девять разговоров относятся к девяти разным кейсам. Тогда в 12 звонках — 10 кейсов. Один из 10 кейсов потребовал повторного контакта: 10% кейсов с повтором. Дополнительных звонков сверх первых — 2 из 12, то есть 16,7% звонков. Это два разных показателя с разными знаменателями. Если связь записей неизвестна, показатель повторов по кейсам посчитать достоверно нельзя.

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

Постройте маршрут одной записи

Получите файл из разрешённого источника и сохраните его связь с рабочим кейсом. Убедитесь, что слышны обе стороны и разговор не обрезан. Загрузите в Текстослав, подпишите участников и исправьте существенные ошибки текста до анализа.

Для отдельного обращения откройте «Аналитика» → «Новый отчёт» → «По одной записи» → «Разбор обращения клиента». Проверьте, что документ отличает исходную проблему, действия сотрудника и результат разговора.

Уточняющий запрос:

«На каком шаге клиент остановился? Что он уже пробовал? Какое действие предложил сотрудник и подтвердил ли клиент результат? Отдельно перечисли сведения, которые нужно получить для продолжения».

Так вы получаете материал для передачи следующему специалисту, а не абстрактную оценку качества общения.

Перейдите к серии без потери структуры

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

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

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

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

Кто и что проверяет

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

Для приоритизации используйте последствия ошибки:

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

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

Превратите находки в изменение процесса

В шаблоне планирования эксперимента Atlassian гипотеза и показатель задаются до оценки результата. Для звонков это означает заранее описать, что именно вы улучшаете.

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

Второй учебный расчёт: до и после добавления примера документа отобраны по 100 входящих звонков по одной услуге, за одинаковые дни недели и по одному правилу включения. Затруднение выбора документа отмечено в 16 звонках до и 10 после:16% и 10%, изменение −6 процентных пунктов. Это наблюдение о выбранных звонках. Оно не доказывает, что правка инструкции вызвала снижение: могли измениться состав клиентов, нагрузка, другие подсказки или работа сотрудников. Если отбирали только жалобы, вывод относится к жалобам; чтобы говорить обо всех посетителях процесса, нужен отдельный знаменатель пользователей.

В Текстославе создайте отчёт «По базе проекта» по выбранным записям: наблюдение, примеры, различия, предлагаемое изменение и неизвестное. Этот документ фиксирует выборку на дату; новые разговоры требуют обновлённого результата.

Ошибки, которые делают поток бесполезным

Нет единого названия темы. «Не грузится», «загрузка», «файл» могут обозначать разные этапы. Опишите категории через действия клиента.

Число находок принимают за число людей. Учитывайте единицу анализа и повторы.

Все разговоры оцениваются одним скриптом. Первое обращение и повторная диагностика требуют разных действий.

Отчёт не имеет владельца. Назначьте, кто принимает решение по каждой обнаруженной проблеме.

Вывод слишком общий. Вместо «улучшить сервис» выберите изменение конкретного шага и способ его проверить.

Для продаж используйте отдельный разбор звонков по сделке, а для передачи фактов коллеге — заметку в CRM. Расшифровка становится полезной, когда сокращает путь от клиентского опыта до конкретного действия команды.