Зачем вам речевая аналитика – вопрос, который меняет всё

Диалог, который у нас происходит примерно в семи случаях из десяти:

— Мы бы хотели речевую аналитику, можете сделать?
— Конечно. Скажите, а зачем вам речевая аналитика?
— [пауза]

Человек на той стороне не растерян. Он профессионал, который принял осознанное решение прийти к нам. Просто вопрос застаёт врасплох — потому что ответ на него предполагает немного другой уровень разговора, к которому большинство переговоров о технологиях не добираются.

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

Мы начали пост с цитаты Генри Форда — «если бы я спросил клиентов, чего они хотят, они бы сказали: “более быструю лошадь”». Это хрестоматийный пример того, что клиент видит инструмент там, где нужно смотреть на задачу.

Но пока статья готовилась, мы полезли проверить атрибуцию — и нашли кое-что интересное. Сайт Quote Investigator и Snopes установили: нет достоверных свидетельств, что Форд когда-либо произносил или писал эти слова. Первое известное упоминание цитаты в связке с именем Форда датируется 2001 годом — в письме в британский журнал Marketing Week. Harvard Business Review ещё в 2011 году вышел с материалом под прямым заголовком «Henry Ford Never Said the Famous “Faster Horses” Quote».

Сам музей Генри Форда ведёт верифицированный список из более чем 200 цитат автомобильного магната. Этой фразы там нет.

Что здесь важно: цитата стала вирусной, потому что она точно описывает реальный механизм — люди формулируют желаемое через знакомые решения, а не через задачи, которые эти решения должны закрыть. Механизм реален. Автор — нет.

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

Мысль о том, что запрос на инструмент прячет под собой задачу, которую ещё нужно найти — вот что нам здесь важно.

Это не ошибка клиента. Это то, как работает человеческое мышление.

В начале 2000-х годов Клейтон Кристенсен вместе с коллегами из Гарвардской школы бизнеса работал над консалтинговым проектом для McDonald’s. Компания хотела продавать больше молочных коктейлей, традиционные маркетинговые рычаги не давали эффекта. Исследовательская группа стала изучать, кто и в какое время покупает коктейли.

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

Этот кейс стал основой концепции Jobs-To-Be-Done, которую Кристенсен описал в статье для HBR в 2005 году под названием «The Cause and the Cure of Marketing Malpractice». Позднее он популяризировал её в книге «The Innovator’s Solution» (2003). Сегодня Christensen Institute описывает теорию так: люди не покупают продукты — они нанимают их для выполнения определённой работы.

Идея проста и неочевидна одновременно. Клиент, который говорит «нам нужна речевая аналитика», точно так же называет инструмент, а не работу. Работу ещё предстоит найти — и она может быть совершенно разной.

Именно поэтому у нас в imot.io существует отдел проектного внедрения. Технология без понимания задачи — это дорогостоящий способ ничего не изменить.

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

Первый шаг — Цель. Что конкретно должно измениться? Какая метрика, в каком направлении, за какой срок? Без ответа на этот вопрос любое внедрение — это эксперимент без контрольной группы.

Второй шаг — Люди. Кто будет работать с данными? Каков их навык, мотивация, загруженность? Речевая аналитика — это не коробочное ПО, которое само принимает решения. Это инструмент команды. Если команда не готова работать с результатами аналитики, платформа будет стоять как красивый дашборд.

Третий шаг — Процессы. Как изменится рабочий процесс? Кто будет разбирать инциденты, как будет устроена обратная связь, как результаты аналитики войдут в регулярный менеджмент? Речевая аналитика — это «слой данных», который должен встроиться в существующий контур управления. Если этого контура нет — его придётся создать.

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

Большинство переговоров о технологических внедрениях начинаются с четвёртого шага. Демо продукта, сравнение функций, вопросы про API. Это нормально — так устроен рынок. Но для нас это сигнал вернуться к первому шагу.

McKinsey в своей статье «In digital and AI transformations, start with the problem, not the technology» прямо пишет: «когда преобразование начинается с технологии — оно заканчивается дорогими экспериментами, которые не двигают показатели компании».

Формула четырёх — это не бюрократия и не консалтинговое усложнение. Это страховка от разочарования.

Вернёмся к кейсу из исходного поста. Главврач сети клиник говорит: «Нам нужна офлайн-аналитика приёмов».

Один запрос. Но за ним — два принципиально разных запроса.

История про документацию

Терапевт на приёме работает с пациентом 15–20 минут. За это время он должен собрать анамнез, зафиксировать жалобы, провести осмотр, поставить диагноз, дать рекомендации — и занести всё это в медицинскую информационную систему. Десятки полей. Часть из них — клинически значимая, часть — административная рутина.

Результат предсказуем: врач смотрит в экран. Пациент сидит и слушает стук клавиш.

Это не российская специфика. По данным исследования, опубликованного в Journal of the American Medical Informatics Association (JAMIA), на каждые восемь запланированных часов приёма врачи тратят в среднем 5,8 часа на активную работу в электронной медицинской карте. Иными словами, почти три четверти рабочего времени уходит на документирование, а не на контакт с пациентом.

Исследование PMC (NCBI) 2024 года, изучавшее 2022–2023 годы, зафиксировало: по сравнению с периодом до пандемии первичные терапевты проводят в ЭМК на 28 минут больше за восемь часов приёма. Рост — на 7,8%.

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

Медицина — это бизнес доверия. Доверие строится через контакт. Когда контакт прерывается необходимостью одновременно вести приём и заполнять карту — страдает и качество документации, и оценки приёма.

Метрика здесь прямая и быстрая: время на заполнение МИС, количество ошибок в карте, оценки пациентов после приёма, процент возврата на повторный визит.

Продукт, который решает эту задачу — imotio.DOC. Стационарный USB-микрофон на столе врача записывает приём, транскрибирует речь и автоматически предзаполняет поля медицинской карты в браузерной МИС клиники. Врач проверяет и корректирует, а не набирает с нуля. Контакт с пациентом восстанавливается.

История про содержание приёмов

Второй запрос за теми же словами главврача — совсем другой.

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

Здесь задача — не снять нагрузку с врача, а понять, что происходит внутри приёма как медицинского и коммуникативного события.

Это классическая задача речевого анализа: чек-листы по протоколу ведения приёма, сегментация разговоров по специальностям и врачам, анализ ключевых моментов (сбор жалоб, обсуждение плана лечения, ценообразование), разбор инцидентов. Доказательная база при жалобах и претензиях — тоже отсюда.

Это работа основной платформы imot.io: загрузка аудио, транскрибация, прогон через чек-листы и теги, количественная статистика по параметрам ведения приёма.

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

Если главврач формулирует запрос как «нам нужно снять нагрузку с врачей» — проект начинается с imotio.DOC и метрики заполнения МИС. Если запрос звучит как «хочу понять, что происходит на приёмах» — проект начинается с платформы, чек-листов и аналитики содержания.

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

Вернёмся к статистике.

McKinsey исследовал цифровые трансформации в сотнях компаний. Данные показывают: около 70% подобных инициатив не достигают заявленных целей. При этом только 20% компаний из исследования 600+ организаций достигли более трёх четвертей ожидаемого прироста выручки, а 17% — более трёх четвертей ожидаемой экономии затрат.

Среди причин неудач — не только технические проблемы. McKinsey последовательно указывает: культурные и организационные факторы перевешивают технологические в 5,3 раза. Но есть и более фундаментальная причина, которую легко не заметить в статистике: многие проекты начинаются с неправильно сформулированной задачи.

Тот же McKinsey в уже упомянутом материале прямо называет генеративный ИИ «технологией в поисках задачи» — и это наблюдение про весь класс технологических внедрений, не только про ИИ. Продукт покупается потому, что «рынок говорит, что это надо», а не потому что есть конкретный бизнес-вопрос, на который продукт должен ответить.

Что происходит дальше — предсказуемо. Через 3–6 месяцев команда фиксирует, что «система работает, но непонятно что с этим делать». Разочарование списывается на технологию. Технология оказывается «не подошедшей».

Это самый надёжный способ разочаровать себя в любом инструменте — попробовать его не на той задаче.

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

Речевая аналитика, внедрённая ради «контроля качества», когда реальная задача — снизить нагрузку на врача — не даст ни того ни другого. Ни контроль не будет системным (команда не понимает, зачем), ни нагрузка не снизится (инструмент не тот).

Прежде чем переходить к выбору инструмента, мы в imot.io задаём четыре вопроса. Они взяты из методологии JTBD — именно в той интерпретации, которую использовал Кристенсен при работе с корпоративными клиентами.

Первый вопрос: какую работу вы хотите выполнить? «Контроль качества» — это слишком широко. «Понять, почему конверсия первичного обращения в запись на приём ниже 40%» — это уже работа. «Снизить время заполнения карты с 8 до 3 минут» — тоже работа. Задача должна быть специфичной и измеримой.

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

Третий вопрос: что уже пробовали? Это один из признаков «истинной работы» в JTBD-методологии. Если клиент уже что-то пробовал — значит задача реальна и срочна. Это также даёт информацию о том, какие решения не подошли и почему.

Четвёртый вопрос: что изменится, когда работа будет выполнена? Хороший ответ на этот вопрос — конкретный и измеримый: «врачи перестанут задерживаться после смены на заполнение карт», «мы будем знать, на каком этапе разговора теряем пациента», «у нас появится доказательная база для разбора инцидентов». Плохой ответ: «станет лучше», «появится прозрачность».

Без ответов на эти четыре вопроса любой разговор об инструментах — это разговор про лошадь, которую клиент хочет сделать быстрее, не зная, куда и зачем едет.

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

Один и тот же технический контур может одновременно обслуживать несколько направлений: - отдел продаж: конверсия, работа с возражениями, соблюдение этапов воронки; - сервис: причины обращений, негативные инциденты, удовлетворённость; - маркетинг: Voice of Customer — что клиенты говорят о продукте своими словами; - операционный блок: загруженность, соблюдение регламентов, обучение.

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

Начать с хорошо сформулированной задачи — значит получить первые результаты за 2–4 недели (базовая аналитика по конверсии, причинам отказов, качеству звонков) и убедительно обосновать расширение на другие направления.

Начать с неправильно сформулированной задачи — значит потратить первые 3 месяца на то, чтобы понять, что что-то пошло не так.

Мы организуем работу с клиентом в пять этапов: Замысел, Планирование, Исполнение, Окончание внедрения, Поддержка и развитие.

Этап «Замысел» — это именно то, о чём шла речь выше. Совместное определение целей, ключевых метрик и ожиданий. Он занимает 1–2 недели и является обязательным. Мы не пропускаем его ради ускорения сроков — и объясняем клиенту почему.

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

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

Сроки до ценности у нас устроены так: за первые 1–2 недели работы клиент получает 60–70% заявленной ценности — базовую аналитику по ключевым метрикам. Полная настройка под специфику бизнеса занимает 3–8 недель. Дальнейшая калибровка и точная настройка продолжается 3–6 месяцев, но система уже работает и даёт результаты.

Прежде чем запросить демо или коммерческое предложение, стоит ответить себе на несколько вопросов.

Сформулируйте задачу конкретно. «Нам нужна речевая аналитика» — это не задача. Задача — это то, что должно измениться: конкретная метрика, конкретное направление, конкретный срок. Чем точнее формулировка, тем быстрее пройдёт этап Замысла и тем скорее вы увидите результат.

Спросите себя, кто будет работать с данными. Если ответа нет — это сигнал начать с меньшего объёма внедрения и сначала подготовить команду. Аналитика без человека, который на неё реагирует, — это дашборд для красоты.

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

Уточните, что именно вы хотите контролировать. Содержание разговоров (что говорят?) или процесс (как организована работа?). Это разные задачи с разными метриками и разными структурами чек-листов.

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

Речевая аналитика — один из самых информационно плотных инструментов в управлении коммуникациями. Компании, которые правильно диагностировали задачу перед стартом, получают от него принципиально другую отдачу, чем те, кто начинал «посмотреть, что получится».

Разница не в технологии. Разница в том, с какого вопроса начинается проект.

Если вы думаете о внедрении речевой аналитики и хотите начать с диагностики задачи — мы проводим бесплатные стратегические сессии для команд. Формат: 60 минут, четыре вопроса из JTBD, конкретный план первого шага. Напишите нам.