ИИ помогает превращать записи разговоров в структурированные данные: о чём звонил клиент, чем закончился разговор и какой шаг договорились сделать дальше. Сопоставляя звонки с заявками и продажами, можно замечать обращения, которые не попали в работу, и повторяющиеся причины отказа. Начинать лучше с одного типа звонков и заранее согласованного списка итогов. Результаты анализа нужно проверять на записях, а не принимать за безошибочный вердикт.
Коротко — и что с этим делать
Выберите звонки по новым заявкам, опишите возможные причины потери клиента и проверьте, какие сведения уже сохраняются в телефонии и CRM. Затем проведите небольшой пилот: сравните выводы ИИ с выборочно прослушанными записями и оцените, помогает ли анализ находить конкретные сбои.
Записаться на бесплатный аудит →Система сначала преобразует речь в текст, а затем классифицирует разговор по заданным правилам. Она может определить тему звонка, причину обращения, итог, следующий шаг и вопросы, которые часто повторяются. Например, в автосервисе это может быть запись на ремонт, уточнение цены или вопрос о наличии детали. Для клиники — запись на приём, перенос визита или запрос о подготовке к процедуре.
Полезно заранее договориться, что именно означает каждый результат. «Заявка обработана» — это не обязательно успешная запись: возможно, клиент только спросил цену и решил подумать. «Отказ» тоже слишком широкая отметка. Лучше разделить причины: не подошла стоимость, нет нужной услуги, неудобное время, не смогли связаться повторно, клиент выбрал другого поставщика. Такая классификация помогает увидеть не только факт потери, но и возможное место, где стоит менять процесс.
В отчёте могут быть собраны, например:
Это не означает, что ИИ сам знает, кто «на самом деле» собирался купить. Он ищет признаки в словах и сопоставляет их с заданными правилами и доступными данными. Поэтому качество результата зависит от понятной классификации, разборчивости записей и связи телефонии с учётной системой. О вариантах внедрения и интеграции можно прочитать на странице услуг KM2B.
Обращение может пропасть на любом участке между звонком и следующим действием. Сотрудник мог не создать карточку клиента, забыть перезвонить, записать неверный номер или не отметить, что клиент ждёт расчёт. Бывает и обратная ситуация: в системе стоит отметка «обработано», а разговор показывает, что клиенту предложили связаться позже — и договорённость не была выполнена.
Чтобы найти такие случаи, анализ звонков нужно сопоставлять с данными о последующих действиях. Например, если в разговоре сотрудник обещает отправить расчёт, а в системе нет ни задачи, ни отправленного предложения, это повод проверить заявку. Если человек спрашивает о конкретной услуге, но обращение помечено как «общий вопрос» и дальше не движется, возможно, причина в правилах маршрутизации или в том, как сотрудники заполняют карточки.
Часто повторяющиеся вопросы тоже важны. Если клиенты регулярно уточняют одну и ту же стоимость, условия записи или наличие товара, возможно, эту информацию трудно найти на сайте или в сообщениях. А если одни и те же сомнения возникают после озвучивания цены, полезно проверить, понятно ли объясняется состав услуги. Сам по себе частый вопрос ещё не доказывает проблему — он показывает, где стоит проверить путь клиента.
Для начала достаточно связать три вещи: звонок, заявку и итог. Если такой связи нет, можно начать с ручной выборки и простого журнала: дата, номер обращения, тема, итог, следующий шаг. Не требуется сразу менять всю телефонию или перестраивать учёт. На странице решений KM2B можно посмотреть, какие варианты автоматизации подходят для разных задач бизнеса.
Сводить разбор звонков к рейтингу сотрудников — рискованный старт. Система может ошибиться в расшифровке, не понять отраслевое выражение или принять спокойный тон за отсутствие интереса. На результат влияют шум, качество связи, перебивания и то, насколько полно заполнены данные после разговора. Кроме того, сотрудник может следовать правилам, но не иметь возможности решить вопрос клиента из-за отсутствия товара или свободных окон записи.
Поэтому ответ на вопрос «Можно ли оценивать сотрудника только по ИИ?» — нет. Вывод системы стоит использовать как повод разобраться, а не как автоматический вердикт. Если отчёт показывает, что сотрудник не предложил следующий шаг, сначала выборочно прослушайте записи, проверьте контекст и выясните, одинаково ли команда понимает стандарт обслуживания. Только после этого можно обсуждать изменения в обучении или рабочем процессе.
Полезнее анализировать не личность, а ситуацию: на каком этапе клиенту не дали нужную информацию, где не назначили повторный контакт, почему заявка не получила статус. Прослушивание выборки звонков помогает отличить реальную закономерность от ошибки распознавания. При этом важно не превращать проверку в скрытое наблюдение за каждым разговором: заранее объясните сотрудникам цель анализа и правила работы с данными.
Начните с одного типа звонков, например обращений новых клиентов, и ограниченного периода наблюдения. Выберите понятный список причин потери клиента и определите, какие действия считаются следующим шагом. Если категорий будет слишком много, сотрудники и система начнут по-разному трактовать похожие ситуации. Если слишком мало — отчёт не подскажет, что именно исправлять.
На старте не обязательно включать все звонки и все отделы. Небольшой пилот позволяет проверить качество данных и понять, есть ли у команды возможность отрабатывать найденные случаи. Его стоимость рассчитывается после аудита: она зависит от числа источников, объёма записей, интеграций и требований к хранению данных. Обычно окупаемость пилота оценивают в пределах 2–4 месяцев, но это ориентир, а не гарантия — результат зависит от исходного количества потерянных обращений и того, какие изменения удастся внедрить.
Сначала проверьте, где теряются обращения
На бесплатном аудите можно определить подходящий тип звонков для пилота, обсудить доступность записей и составить первичный список причин отказа. После этого проще оценить объём работ и понять, какие данные понадобятся.
Бесплатный аудит за 30 минут →Считать нужно не количество расшифровок, а изменения в работе с заявками. До пилота зафиксируйте исходный порядок обработки: сколько новых звонков превращается в заявку, сколько обращений ждут обратного звонка, как отмечаются причины отказа. Затем смотрите, появляются ли найденные случаи в работе и исправляет ли команда конкретные сбои.
Для оценки можно использовать простую логику: сколько обращений ИИ отметил для проверки, сколько из них подтвердилось при прослушивании, сколько заявок удалось вернуть в работу и какие изменения процесса были сделаны. Не каждую обнаруженную заявку получится превратить в продажу. Человек мог обратиться не по адресу, изменить решение или выбрать другого исполнителя. Поэтому отдельно учитывайте подтверждённые ошибки обработки и обычные отказы клиентов.
Пилот имеет смысл продолжать, если выводы помогают сотрудникам действовать: перезвонить клиенту, поправить маршрут заявки, обновить информацию об услуге или изменить порядок передачи обращения. Если система просто выдаёт длинные списки без ответственного и срока, пользы будет мало. Перед запуском лучше определить, кто разбирает спорные случаи и как отмечается результат повторного контакта.
| Подход | Что показывает | Ограничение |
|---|---|---|
| Ручное прослушивание отдельных записей | Контекст конкретного разговора и детали общения | Сложно быстро заметить повторяющиеся причины по большому числу звонков |
| Автоматический анализ звонков | Темы, итоги и повторяющиеся признаки в выбранной совокупности разговоров | Требует проверки точности и качественных данных |
| Анализ вместе с данными о заявках | Связь между разговором, записью в системе и последующим действием | Нужны корректная интеграция и единые правила учёта |
Если нужна оценка экономического эффекта, можно сравнить затраты на пилот и обработку звонков с ценностью подтверждённых возвращённых заявок и сэкономленного времени. В расчёте важно не приписывать системе все продажи, которые произошли после её запуска: на результат влияют сезонность, загрузка сотрудников, цены и другие изменения. Подход к расчёту можно посмотреть в разделе оценки окупаемости.
Записи звонков могут содержать персональные данные: имя, номер телефона, сведения о заказе, здоровье или оплате. До запуска нужно определить правовые основания обработки, сообщить клиентам необходимые сведения и проверить, как используются записи. Требования зависят от конкретного процесса и содержания разговоров, поэтому формулировки уведомлений и порядок хранения стоит согласовать с ответственным за персональные данные или юристом.
При работе с такими данными учитывайте 152-ФЗ. Ограничьте доступ к записям теми сотрудниками, которым он действительно нужен, установите срок хранения и порядок удаления. Не передавайте в анализ сведения, которые не требуются для поставленной задачи. Если используется внешний сервис, заранее проверьте условия обработки, размещение данных, меры защиты и порядок взаимодействия сторон. Для отдельных случаев может быть уместна обработка внутри инфраструктуры компании, но это тоже нужно оценивать с учётом технических и правовых требований.
Если звонки используют для рекламных сообщений или последующих предложений, проверьте и требования 38-ФЗ, а также законность выбранного способа связи. Анализ разговора сам по себе не даёт автоматического разрешения на рекламное обращение. Для соблюдения правил важно разделять цель обработки данных, информирование клиента и дальнейшую коммуникацию.
Не загружайте записи в случайные сервисы, не проверив условия хранения и доступа. В пилоте можно использовать ограниченную выборку, маскировать ненужные сведения и отдельно согласовать, кто сможет видеть исходную запись, а кто — только итоговые категории. Безопасность здесь не отдельная задача «после запуска»: её нужно учитывать при проектировании процесса.
Первая ошибка — пытаться сразу анализировать все обращения компании. Для автосервиса звонок по новой записи и звонок поставщику требуют разных правил; для клиники вопросы о расписании отличаются от обращений по качеству обслуживания. Когда задачи смешаны, отчёт становится менее понятным и труднее проверить выводы.
Вторая — считать автоматическую расшифровку точной записью разговора. Названия услуг, фамилии и шумная речь могут распознаваться неверно. Если отчёт указывает на важную потерянную заявку, проверьте исходную запись, прежде чем менять статус или поручать сотруднику повторный звонок.
Третья — собирать причины отказа, но не менять процесс. Если выяснилось, что клиентам часто не подходят доступные часы, нужен ответственный за расписание; если они не понимают состав услуги — понятное объяснение и актуальная информация. Без таких решений аналитика превращается в отчёт ради отчёта.
Четвёртая — ставить сотрудникам оценку по одному показателю. Отсутствие фразы из речевого стандарта не всегда означает плохое обслуживание, а нужная фраза не гарантирует, что клиент получил помощь. Используйте показатели для поиска закономерностей, а отдельные случаи проверяйте в контексте.
В результате первого этапа у бизнеса должны появиться не только расшифровки, но и рабочие правила. Например: список причин потери клиента, порядок проверки спорных результатов, ответственный за возврат обращения и срок, за который команда реагирует на найденную заявку. Для повторяющихся вопросов можно подготовить изменения на сайте, в памятке сотрудника или в описании услуги.
Если анализ помогает находить обращения, которые раньше оставались без следующего шага, имеет смысл расширить его на другие типы звонков. Если подтверждений мало или система часто ошибается, стоит пересмотреть категории, качество записи и связь телефонии с CRM, а не увеличивать объём данных. В каталоге решений для бизнеса можно найти примеры задач, которые автоматизируются поэтапно.
Практичный старт — один поток звонков, небольшой перечень причин отказа и ручная проверка выводов. Такой подход помогает понять, где теряется заявка, не превращая ИИ в единственного судью качества работы. А уже после проверки можно решить, стоит ли подключать новые отделы и автоматизировать следующий участок.
Обсудим разбор звонков для вашей компании
Команда KM2B поможет определить участок для пилота, оценить качество исходных данных и подготовить план проверки результатов с учётом процесса продаж и требований к персональным данным.
Записаться на бесплатный аудит →