Разработка AI-автообзвона для напоминания клиентов о записи

AI-автообзвон: где ломается напоминание клиентов о записи

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

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

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

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

Все четыре сбоя — про отсутствие единого состояния записи. Разбираем, как это закрывается обзвоном с понятными правилами дозвона и одним источником правды по статусам визита.

Меньше неявок и ручной работы: эффект автоматических звонков

Звонок за сутки и контрольный — за пару часов до визита: робот уточняет, придёт ли клиент, и сразу пишет ответ в систему записи. Голосовой канал сложнее пропустить, чем сообщение в мессенджере, поэтому доля подтверждённых визитов вырастает с половины до 85–90%.

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

Если клиент не может прийти, сценарий не заканчивается отказом: робот называет ближайшие свободные слоты и оформляет перенос записи. Так потенциальная неявка превращается в перенесённый визит, а не в пустое время у специалиста.

Разгрузка администраторов — вторая половина эффекта. Обзвон списка на завтра занимает у человека часы смены и всё равно идёт выборочно; робот проходит весь список за один прогон и не устаёт к вечеру. Администратор подключается только к нестандартным случаям.

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

Форматы AI-автообзвона: голос, сценарии и интеграции

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

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

Этапы внедрения: от разбора базы записей до запуска

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

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

2. Схема разговора. Фиксируем ветки — подтверждение, перенос, отказ, недозвон, просьба соединить с человеком. Для каждой определяем, что робот говорит и куда передаёт запрос, чтобы клиент не оставался в тупике.

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

4. Пилотная группа. Запускаем на ограниченном срезе записей с ручной прослушкой выборки. Смотрим долю подтверждений, недозвонов и обращений к оператору, разбираем случаи, где клиент не понял вопрос.

5. Приёмка результата. Сверяем с согласованными критериями: точность распознавания ответа, корректность переданных переносов, отсутствие звонков тем, кто просил не беспокоить. Правки вносим до выхода на полный поток.

6. Регламент эскалации и передача. Описываем, при каких фразах робот сразу соединяет с администратором, как фиксируются сбои и кому идёт уведомление. Передаём настройки, схему веток и инструкцию по правке реплик.

Что передаём на руки: сценарии звонков и регламенты

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

• Сценарии звонков и ветки диалога — приветствие, подтверждение записи, перенос, отказ, просьба перезвонить позже, передача живому администратору. Для каждой ветки указано, чем она заканчивается и какой статус уходит в систему.
• Карта переменных подстановки — какие поля берутся из журнала записи в момент набора (имя, дата и время приёма, адрес точки, специалист) и что подставляется, если поле пустое.
• Правила доступа к базе — роли на чтение и выгрузку, маскирование контактов, срок хранения, порядок согласования выгрузки и запрет на использование данных вне обзвона.
• Журнал звонков — запись разговора, расшифровка, итоговый статус (подтвердил, перенёс, отказался), причина отказа и число попыток дозвона по каждому номеру.
• Схема связки с журналом записи — направление и частота обмена, обработка конфликтов (запись отменили вручную во время обзвона), повторная постановка в очередь.
• Инструкция для администраторов — как исключить клиента из обзвона, как вернуть запись в работу, что смотреть при расхождении статусов, куда писать при сбое.
• Регламент эскалации — кому уходит сигнал о сбое, время реакции дежурного, порядок остановки кампании целиком.
• Чек-лист приёмки — набор контрольных сценариев, которые прогоняются на реальных данных перед подписанием передачи.

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

Кейс: как сеть салонов снизила неявки после запуска

Как было

До запуска сеть салонов обзванивала клиентов вручную — в основном в утренние часы, когда параллельно открывалась смена. Доля подтверждений держалась около 40%: часть номеров не отвечала, повторные попытки съедали время стойки, а занятый слот оставался за клиентом до самого визита.

Что изменили

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

После запуска доля подтверждений выросла до 78%, неявки сократились примерно на треть, а отмены в последний момент стали заметно реже: клиент подтверждает запись накануне, а не вспоминает о ней утром. Нагрузка на стойку в утренние часы упала — администраторы разбирают только исключения, а не набирают список вручную.

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

Чем робот-подтверждение отличается от ручного обзвона?

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

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

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

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

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

Технические сомнения: дозвон, отказы, повторные записи

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

Что будет с дублями и устаревшими номерами в базе?

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

Можно ли звонить вечером?

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

Что делать, если распознавание не разобрало ответ?

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

Как подтверждается повторная запись?

Статус робот не проставляет сам: результат звонка сверяется с расписанием, и только после этого создаётся или переносится слот. Дубль по тому же времени и специалисту не появляется, а отменённый слот возвращается в расписание.

Обсудим задачу: план запуска и точки контроля

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

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

• Схема запуска напоминаний: какие события инициируют звонок, за сколько времени до визита, что происходит при недозвоне и отказе.
• Сценарии диалога под ваши типы записей — первичный приём, повторный визит, перенос, неявка — с отдельной логикой подтверждения и перезаписи.
• Точки контроля на каждом этапе: согласование сценариев, проверка на тестовой выборке, приёмка по метрике дозвона и доли подтверждённых визитов.
• Проверка сценариев на реальных, но обезличенных данных вашей базы — до старта массовых звонков вы видите, как система ведёт себя на сложных случаях.
• Регламент передачи результата в вашу систему записи: как фиксируется статус визита и что видит администратор.
• План сопровождения после запуска: правки формулировок, расширение сценариев, разбор записей звонков и контроль качества на постоянной основе.
• Границы ответственности и порядок действий при отклонениях — кому и как эскалируется сбой в потоке звонков.

Опишите задачу: объём базы, типы визитов, вашу систему записи и желаемый режим работы. Вернёмся с оценкой и планом работ по этапам — с теми же точками контроля, что перечислены выше.