Стас Ломаносов · продюсер и аналитик AI-продуктов · Белград, работа удалённо
Три вывода, если читать только их.
1. В разобранном звонке робот нарушает прямой запрет клиента и закон о рекламе. Главный риск не потерянный лид, а штраф и отзыв проекта.
2. Юнит-экономика проекта «Автосервис» сходится не полностью: по балансу израсходовано 8 900 ₽, по тарифу должно быть 7 600 ₽. Расхождение 1 300 ₽, это 17 процентов, и без его закрытия себестоимость лида считается с той же погрешностью.
3. База не выжжена. Узкое место наверху воронки: автоответчики съедают до 21% оплаченных минут. Отсечение их даёт примерно +29% лидов на том же бюджете.
Разделил по типу, потому что закрываются они разными средствами: часть промптом, часть настройками проекта, часть интеграцией. В колонке «цена ошибки» то, чем это оборачивается для нас как для подрядчика.
| № | Что сделал робот | Почему это ошибка | Цена ошибки для нас |
|---|---|---|---|
| 1 | Назвал цену имплантации «19 900 рублей» | Клиент прямо запретил называть цены | Нарушение договорённости на первой же реплике. Основание для претензии и отказа от услуги |
| 2 | Назвал цену удаления «500 рублей» | Тот же запрет, повторно | Показывает, что запрет не зашит в промпт, а был разовой правкой. Системная проблема, не случайность |
| 3 | Заявил «скидку 50%» | Скидок у клиники нет, факт выдуман | Пациент придёт с ожиданием цены, которой не существует. Конфликт на ресепшене и репутационный ущерб клинике |
| № | Что сделал робот | Почему это ошибка | Цена ошибки для нас |
|---|---|---|---|
| 4 | Проигнорировал «я просил мне не звонить», причём абонент говорит это повторно | Отказ от рекламных звонков должен исполняться немедленно. Реклама по сетям связи допускается только с согласия абонента (ст. 18 ФЗ «О рекламе»), согласие можно отозвать (ФЗ-152) | Прямое основание для жалобы в ФАС. Штраф на юрлицо по ст. 14.3 КоАП, и отвечает распространитель рекламы, то есть мы |
| 5 | Не поставил статус «не звонить», контакт остался в базе | Осталось ещё до двух попыток дозвона по этому же номеру | Нарушение повторится автоматически. Повторный звонок после явного отказа это отягчающее обстоятельство при жалобе |
| 6 | Сообщил недостоверные сведения о цене и скидке | Признаки недостоверной рекламы (ст. 5 ФЗ «О рекламе») | Второе самостоятельное основание для претензии, независимое от пункта 4 |
| 7 | Реклама медуслуги без предупреждения о противопоказаниях и необходимости консультации | Ст. 24 ФЗ «О рекламе» предъявляет к рекламе медицинских услуг отдельные требования | Отраслевой риск, который на стоматологии возникает всегда. Должен быть закрыт шаблонно, а не решаться на каждом проекте заново |
| № | Что сделал робот | Почему это ошибка | Цена ошибки для нас |
|---|---|---|---|
| 8 | Не отработал «Я не Андрей» | Личность собеседника не подтверждена, а оффер уже прозвучал | Персональное обращение ушло постороннему человеку. Плюс минуты тратятся на нецелевой контакт |
| 9 | Ответил «Отлично!» на отказ и на просьбу не звонить | Реакция не связана со смыслом реплики: негатив не распознан | Самый заметный для человека признак «тупого робота». Именно такие фрагменты попадают в соцсети |
| 10 | Записал на приём, хотя согласия не было | Действие выполнено без подтверждения абонента | Фантомная запись: окно в расписании занято, пациент не придёт |
| 11 | Назвал адрес «Ленинский проспект, 88», клиника у метро Сокол | Адрес не из карточки проекта, то есть выдуман | Реальный пациент уехал бы в другой конец Москвы. Проверяемая фактическая ошибка |
| 12 | Сам назначил «завтра на 9 утра» | По задаче робот должен спросить удобное время, а не назначать его | Даже при согласии абонента такой лид почти гарантированно не дойдёт |
| 13 | Навязал выбор «виниры или брекеты» | Ложная дилемма, не связанная с репликой абонента | Усиливает ощущение скрипта и провоцирует сброс |
| 14 | Ни разу не предложил бесплатную консультацию | Целевое действие звонка не прозвучало вообще | Звонок не мог закончиться результатом ни при каком поведении абонента. Минуты списаны впустую по определению |
| 15 | Не собрал имя и удобное время | Оба обязательных поля лида отсутствуют | Даже успешный звонок дал бы непередаваемый лид |
| 16 | Завершил разговор первым, сразу после вопроса абонента | Абонент задал вопрос, робот попрощался | Единственный момент интереса за весь диалог был оборван роботом |
| № | Что сделал робот | Почему это ошибка | Цена ошибки для нас |
|---|---|---|---|
| 17 | Сказал абоненту, что тот записан, но лид в CRM не передал | Состояние в разговоре и состояние в системе разошлись | Худший из сценариев: администратор не знает о записи, клиника не видит проблему, а мы не видим потерю |
| 18 | Не проставлен фактический статус звонка (отказ, не тот человек, do-not-call) | Результат звонка не зафиксирован | Аналитика проекта получает пустое значение вместо сигнала. Такие звонки искажают конверсию и мешают увидеть выгорание базы |
Что здесь главное. Из восемнадцати пунктов бизнес-критичны четыре: игнор отказа от обзвона (4 и 5), выдуманная скидка (3) и рассинхрон записи с CRM (17). Остальное портит конверсию, а эти четыре создают риск потерять клиента целиком и получить штраф. В приоритет исправлений я поставил бы именно их.
Пишу так, чтобы каждая строка закрывала конкретный пункт из таблицы выше. Номера закрываемых ошибок указаны в комментариях справа.
РОЛЬ: оператор стоматологии «Дента-Люкс», Москва, метро Сокол.
ЦЕЛЬ ЗВОНКА одна: пригласить на бесплатную консультацию, записать имя и удобное время. # 14, 15
ИСТОЧНИК ФАКТОВ: только карточка проекта (адрес, услуги, часы работы). Чего в карточке
нет, того не существует: отвечаю «это уточнит администратор». Придумывать адрес,
время, услуги и акции запрещено. # 3, 11
ЦЕНЫ: не называю никогда: ни точную, ни примерную, ни диапазон, ни «от».
На вопрос о цене отвечаю дословно: «Стоимость зависит от осмотра, назвать её может
только врач. Консультация бесплатная, давайте я вас запишу». # 1, 2
СКИДКИ: у клиники их нет. Слова «скидка», «акция», «спецпредложение», «процентов»
не использую ни в каком контексте. # 3
ИДЕНТИФИКАЦИЯ: первая реплика «Здравствуйте! Стоматология Дента-Люкс. Подскажите,
я говорю с {ИМЯ}?». До подтверждения имени оффер не произношу. Ответ «нет» или
«вы ошиблись» -> «Извините за беспокойство», статус wrong_number, завершение. # 8
ОТКАЗ ОТ ЗВОНКОВ: фразы «не звоните», «я просил не звонить», «уберите номер»,
«отпишите» обрабатываю немедленно и без исключений: «Понял вас, извините.
Удаляю номер из списка, больше мы вам не позвоним». Ставлю статус do_not_call
и завершаю разговор. Никаких уточнений, офферов и попыток удержать. Это требование
закона, спорить здесь нельзя. # 4, 5
НЕГАТИВ: на возражение не отвечаю «Отлично» и не хвалю. Признаю позицию словом
«Понимаю», далее одна короткая реплика по сути. # 9
ЗАПИСЬ: оформляю только после явного согласия («да», «записывайте», «давайте»).
Порядок: спрашиваю удобный день и время -> уточняю имя -> повторяю итог вслух.
Дату и время сам не назначаю. # 10, 12
УТОЧНЯЮЩИЕ ВОПРОСЫ: не предлагаю выбор из услуг, которые абонент не называл. # 13
МЕДИЦИНА: не ставлю диагноз, не обещаю результат и сроки, не сравниваю с другими
клиниками. Формула: «Это определит врач на осмотре». # 7
ЗАВЕРШЕНИЕ: не прощаюсь, пока не ответил на заданный мне вопрос. # 16
ПЕРЕДАЧА ЛИДА: лид создаю только при статусе «согласие на запись» и только с полями
имя, телефон, желаемые дата и время. Во всех прочих случаях лид не создаю, а ставлю
фактический статус: refusal, do_not_call, wrong_number, no_answer, voicemail.
Не сообщаю абоненту о записи, если лид не ушёл. # 17, 18
Прод-версия промпта помимо этого фрагмента содержит блок приветствия, карточку проекта переменными и примеры диалогов на few-shot. Здесь я оставил только правила, закрывающие найденные ошибки.
Каждый сценарий проверяет свою группу ошибок. По каждому указан критерий провала: без него тест это прослушивание, а не проверка.
| № | Что проверяем | Что делает тестировщик | Пройден / провален |
|---|---|---|---|
| 1 | Идентификация и отказ от обзвона (ошибки 4, 5, 8, 9) | Отвечает «Это не Андрей». Через реплику добавляет «И вообще не звоните мне больше». Дальше молчит. | Пройден: робот извиняется, не произносит оффер, завершает разговор, в системе стоит do_not_call, номер исчез из очереди на оставшиеся попытки. Провален: прозвучал оффер, робот задал ещё вопрос, статус не проставлен либо номер остался в очереди. Последнее проверяю не на слух, а в базе. |
| 2 | Запрет на цены, три формы вопроса (ошибки 1, 2, 3, 14) | Три захода подряд: «Сколько стоит имплант?», затем «Ну хотя бы примерно, порядок цен?», затем «У конкурентов 30 тысяч, а у вас дешевле?». | Пройден: ни одной цифры, ни одного слова про скидку, все три раза перевод на бесплатную консультацию, формулировка не разваливается на третьем заходе. Провален: любая цифра, «от», «в районе», «примерно», а также согласие сравнивать себя с конкурентами по цене. |
| 3 | Запись и передача лида (ошибки 10, 11, 12, 15, 17) | Соглашается, но называет неудобное время: «Давайте, только в воскресенье поздно вечером». Затем меняет решение на будний день. | Пройден: робот не выдумывает слот и не подтверждает нерабочее время, спрашивает альтернативу, называет адрес строго из карточки, проговаривает итог, лид приходит в CRM с полями имя, телефон, дата и время. Провален: подтверждено нерабочее время, назван чужой адрес, время назначено роботом, либо абонент услышал «вы записаны», а лида в CRM нет. |
Автоответчик. Тестовый номер с включённой голосовой почтой. Проверяю, за сколько секунд робот кладёт трубку и какой ставит статус. Причина добавить его видна в задании 2: на проекте «Автосервис» автоответчики забрали до 21 процента оплаченных минут. Это не качество диалога, это прямые деньги, и ловится такой дефект только целевым тестом.
| Показатель | Расчёт | Значение |
|---|---|---|
| Стоимость минуты в пакете | 7 200 / 2 000 | 3,60 ₽ |
| Минуты сверх пакета | 2 100 − 2 000 | 100 мин |
| Доплата сверх пакета | 100 × 4 | 400 ₽ |
| Себестоимость списанных минут | 7 200 + 400 | 7 600 ₽ |
| Фактическая средняя минута | 7 600 / 2 100 | 3,62 ₽ |
| Себестоимость одного лида | 7 600 / 48 | 158,33 ₽ |
| Цена лида для клиента (наценка х4) | 158,33 × 4 | 633,33 ₽ |
| Цена минуты для клиента | 3,62 × 4 | 14,48 ₽ |
| Выручка с проекта за неделю | 7 600 × 4 | 30 400 ₽ |
| Валовая маржа за неделю | 30 400 − 7 600 | 22 800 ₽ (75%) |
Отмечу для точности: пакет 2 000 минут оплачивается целиком независимо от того, сколько из него израсходовано. Поэтому 3,60 ₽ это не переменная цена минуты, а результат деления фиксированной суммы. При недоборе минут фактическая себестоимость минуты растёт, при переборе стремится к 4 ₽. На это опирается вывод в разделе 2.3.
Не сходится.
| Источник | Сумма | Как получено |
|---|---|---|
| Израсходовано по движению баланса | 8 900 ₽ | 10 000 − 1 100 |
| Должно быть по тарифу | 7 600 ₽ | расчёт из 2.1 |
| Расхождение | 1 300 ₽ | 17,1% от расчётной себестоимости |
Допущение, без которого сверка некорректна. Во входных данных нет остатка на начало недели. Я считаю его нулевым. Если на понедельник на балансе что-то лежало, расхождение меняется ровно на эту сумму. Это первое, что я бы уточнил, и до уточнения вывод про 1 300 ₽ считается предварительным.
Версии причин, по убыванию вероятности:
Что запрошу, чтобы закрыть вопрос за один заход: детализацию списаний по каждому звонку (дата, длительность, тариф, проект), выписку по балансу с входящим остатком, перечень проектов, привязанных к этому балансу, и прайс на всё, что тарифицируется помимо минут. Пока расхождение открыто, себестоимость лида корректно писать как диапазон 158-185 ₽, а не как точное число.
В долях звонков картина считается прямо: 300 автоответчиков из 900 дозвонов это 33,3%. Каждый третий дозвон уходит в никуда.
В минутах прямых данных нет, поэтому считаю по двум сценариям и явно помечаю это как оценку:
| Сценарий | Минуты | Доля списанных | Деньги |
|---|---|---|---|
| A. Робот кладёт трубку через 30 секунд | 150 | 7,1% | 543 ₽ |
| B. Робот проговаривает скрипт целиком, около 1,5 минут | 450 | 21,4% | 1 629 ₽ |
Судя по диалогу из задания 1, робот не распознаёт даже прямой отказ живого человека. Значит сценарий B ближе к реальности, чем A.
Ключевое наблюдение. При сценарии B без автоответчиков расход составил бы 1 650 минут вместо 2 100, то есть проект вообще не вышел бы за пакет и не было бы доплаты 400 ₽. Иначе говоря, за пределы пакета проект вытолкнули именно автоответчики.
Но экономия здесь не в снижении затрат, а в высвобождении ёмкости. Пакет на 2 000 минут оплачен целиком в любом случае, поэтому сэкономленные минуты не возвращают деньги, а дают дополнительные разговоры внутри уже оплаченного пакета. Считаю эффект:
Что предлагаю сделать:
| Переход | Расчёт | Значение |
|---|---|---|
| Дозвон на одну попытку | 900 / 3 600 | 25,0% |
| Автоответчики от дозвонов | 300 / 900 | 33,3% |
| Разговор дольше 30 секунд от дозвонов | 400 / 900 | 44,4% |
| Сброс раньше 30 секунд | 900 − 300 − 400 | 200 (22,2%) |
| Разговор в лид | 48 / 400 | 12,0% |
| Контакт базы в лид | 48 / 1 200 | 4,0% |
| Звонок в лид | 48 / 3 600 | 1,33% |
Вывод: база рабочая, а не выжженная. Обоснование строится на том, где именно проседает воронка.
Чего не хватает для окончательного вывода. В данных нет числа уникальных контактов, до которых дозвонились: 900 дозвонов могут приходиться и на 900 человек, и на 400, если один и тот же номер отвечал на разных попытках. От этого зависит реальный охват базы. Также нет распределения по попыткам: если дозвон резко падает со второй на третью попытку, это признак того, что база начинает выгорать, и это видно раньше, чем по числу лидов.
Последовательность выстроена по принципу «сначала то, что дороже всего переделывать». Юридическая чистота базы и запреты клиента идут до написания скрипта, потому что переписывать скрипт из-за них дороже, чем сразу узнать ограничения.
| № | Этап | Шаг |
|---|---|---|
| 1 | Вводные | Зафиксировать письменно цель и метрику успеха: сколько записей в неделю нужно клиенту и что именно мы считаем лидом. Без этого нечего сдавать на приёмке. |
| 2 | Собрать карточку проекта по трём филиалам: адреса, ближайшее метро, часы работы, перечень услуг, чем филиалы отличаются между собой. | |
| 3 | Получить базу и проверить её техническое качество: формат номеров, дубли, полнота полей, дата последнего визита. | |
| 4 | Проверить базу юридически: откуда контакты, есть ли согласие на рекламные звонки, получить действующий стоп-лист клиента. | |
| 5 | Подготовка | Разделить базу на сегменты: «уснувшие» (были в салоне, знают бренд) и остальные. Это два разных разговора, объединять их в один скрипт нельзя. |
| 6 | Согласовать запреты: можно ли называть цены, есть ли действующие акции, какие услуги нельзя продвигать (всё, что относится к медицинским процедурам, требует отдельной осторожности). | |
| 7 | Написать скрипт и системный промпт под каждый сегмент, включая обработку отказа, do-not-call, «не тот человек» и вопрос о цене. | |
| 8 | Определить правило маршрутизации по филиалам: спрашиваем у человека, ведём по прошлому визиту или по ближайшему адресу. | |
| 9 | Настройка | Согласовать скрипт с клиентом письменно и зафиксировать номер версии. Все дальнейшие правки идут поверх согласованной версии. |
| 10 | Настроить телефонию: номер с местным кодом, AMD, число попыток и интервалы, окна обзвона в рамках закона и по местному времени. | |
| 11 | Настроить интеграцию с Telegram: бот, целевой чат, формат карточки лида, обязательные поля (имя, телефон, услуга, желаемое время, филиал). | |
| 12 | Договориться о зоне ответственности на стороне клиента: кто отвечает на лиды, в какие часы, за какое время реагирует, кто подменяет. | |
| 13 | Проверка | Внутреннее тестирование: 10-15 звонков по сценариям, обязательно включая отказ от обзвона, автоответчик, «не тот человек» и вопрос о цене. |
| 14 | Проверить сквозную доставку лида: карточка дошла в Telegram, поля заполнены, дублей нет, администратор её видит и понимает. | |
| 15 | Прогнать пилот на 50-100 контактах, начиная с сегмента «уснувшие» как с самого тёплого. | |
| 16 | Разобрать пилот вместе с клиентом: прослушать 10 записей, снять метрики, собрать правки скрипта. Это же встреча, на которой мы согласуем ожидания по цифрам. | |
| 17 | Бой | Внести правки, зафиксировать финальную версию скрипта и стоп-правила: при какой доле жалоб или отказов обзвон останавливается автоматически. |
| 18 | Запустить обзвон на объём с ограниченной скоростью в первый день, чтобы поймать проблему на сотне контактов, а не на всей базе. | |
| 19 | Настроить мониторинг первого дня: остаток баланса, доля дозвона, доля отказов, число лидов, время реакции клиента на лид. | |
| 20 | Назначить дату первого еженедельного разбора и формат отчёта до того, как отчёт понадобится. |
Вопросы отобраны по одному критерию: ответ меняет настройку. То, что можно узнать позже, сюда не попало.
| № | Вопрос | Что меняется от ответа |
|---|---|---|
| 1 | Что считаем результатом: запись на конкретные дату и время или согласие на звонок администратора? | Определяет скрипт, длительность разговора, себестоимость лида и то, за что клиент нам платит |
| 2 | Откуда база и есть ли согласие на рекламные звонки? Есть ли стоп-лист тех, кто уже просил не звонить? | Юридический допуск к запуску. Без ответа проект не стартует |
| 3 | Как давно «уснувшие» были в салоне, по каким услугам и к каким мастерам? | Персонализация («вы были у нас на окрашивании») даёт другую конверсию, чем холодный оффер |
| 4 | Есть ли те, кому звонить нельзя: конфликтные клиенты, возвраты, жалобы? | Один такой звонок способен закрыть проект целиком |
| 5 | Можно ли называть цены? Если нет, какой формулировкой заменяем? | Прямо из разбора в задании 1: это самая частая и самая дорогая ошибка |
| 6 | Как распределяем по трём филиалам и что делать, если человеку удобен филиал, где нет нужного мастера? | Правило маршрутизации и обязательное поле в карточке лида |
| 7 | Какая сейчас загрузка филиалов и на какие окна записывать можно, а на какие нельзя? | Робот не должен генерировать записи туда, где нет мест: это создаёт негатив вместо выручки |
| 8 | Кто обрабатывает лиды из Telegram, в какие часы и за какое время? Что делать роботу с человеком, который согласился в 22:00? | Самая частая причина провала первой недели, см. риск 1 |
| 9 | Сколько записей в неделю нужно и сколько администраторы физически способны обработать? | Задаёт объём обзвона. Лиды, которые некому обработать, это сожжённый бюджет и испорченная база |
| 10 | Кто на вашей стороне согласует скрипт и за какой срок? | Определяет реальную дату запуска. Чаще всего сроки срывает согласование, а не настройка |
| № | Риск | Как проявляется | Что делаю заранее |
|---|---|---|---|
| 1 | Лиды приходят, но их никто не берёт | Карточки падают в Telegram, администраторы заняты в зале, человек ждёт звонка час и остывает. Клиент видит «лиды плохие», хотя проблема на его стороне | До запуска: назначенный ответственный и подменный, договорённость о времени реакции, отдельный чат только под лиды. С первого дня: ежедневная сводка «сколько лидов и сколько без реакции». Она снимает спор о качестве лидов, потому что показывает факт |
| 2 | Номер помечается как спам | Дозвон падает в середине недели, объём лидов проседает без изменения скрипта | Номер с местным кодом, прогрев на малом объёме, пул номеров с ротацией, проверка в популярных определителях до старта, ежедневный контроль доли дозвона как раннего сигнала |
| 3 | База холоднее, чем заявлено, идут жалобы | Высокая доля резкого негатива и просьб не звонить в первые сотни контактов | Проверка происхождения базы до старта, жёсткая обработка do-not-call в промпте, пилот на 50-100 контактах, заранее согласованное стоп-правило: при превышении порога жалоб обзвон встаёт автоматически и мы идём к клиенту с данными |
| 4 | Записи на несуществующие слоты | Робот подтверждает время, которого нет в расписании. Администратор перезванивает и отменяет, человек получает негативный опыт | Робот не назначает время сам, а собирает пожелание с формулировкой «администратор подтвердит запись». В идеале интеграция с реальным расписанием, но до неё правило снимает риск полностью |
| 5 | Путаница между филиалами | Человека записали не в тот салон. Он приезжает и уходит. Это худший тип негатива, потому что клиент уже был лоялен | Филиал обязательное поле карточки лида, вопрос про удобный адрес в скрипте, отдельные тест-звонки именно на маршрутизацию, разные метки лидов по филиалам с первого дня |
Шестой риск, который стоит держать в виду: баланс заканчивается в середине недели из-за автоответчиков и лишних попыток, обзвон встаёт молча. Закрывается порогом оповещения по остатку и включённым AMD ещё до старта. Разбор в задании 2 показывает, что это не гипотетический сценарий.
Собрал в одном месте всё, что при решении пришлось достроить. На реальном проекте это первые вопросы, которые я задаю, а не догадки, которые оставляю в отчёте.
| Где | Что достроено | Что запрошу |
|---|---|---|
| Задание 2.2 | Остаток баланса на начало недели принят нулевым | Выписку по балансу с входящим остатком. От этого напрямую зависит вывод про 1 300 ₽ |
| Задание 2.3 | Длительность одного автоответчика: 0,5 мин и 1,5 мин как границы сценариев | Детализацию звонков со статусом voicemail и их фактической длительностью |
| Задание 2.3 | Средняя длительность сброса раньше 30 секунд принята 0,4 мин | То же самое из детализации биллинга |
| Задание 2.4 | Число уникальных контактов, до которых дозвонились, неизвестно | Отчёт по попыткам: сколько контактов охвачено и как падает дозвон с первой попытки к третьей |
| Задание 2.1 | Наценка х4 применена к себестоимости минут, а лид посчитан производной от неё | Подтверждение схемы: клиент платит за минуты или за лиды. Если за лиды, вся модель считается иначе |
| Задание 1 | Правовые нормы указаны как основание риска, а не как юридическое заключение | На реальном проекте формулировки согласуются с юристом, у меня здесь роль аналитика, который риск обнаружил и передал |
Как я подошёл к заданию. Каждое из трёх заданий про одно и то же с разных сторон: между тем, что робот говорит, и тем, что попадает в систему, есть разрыв, и деньги теряются именно в нём. В первом задании это фантомная запись, о которой не знает CRM. Во втором это минуты, которые списаны, но не превратились ни в один разговор с человеком. В третьем это лид, который дошёл до Telegram и остался без ответа. Поэтому в промпте, в рекомендациях и в чек-листе запуска у меня всюду одна и та же логика: фиксировать фактический статус, считать потери отдельной метрикой и назначать ответственного за каждый переход между системами.