Напоминания о записи: как ИИ снижает забытые визиты без спама

Команда KM2B · 10 октября 2026 · чтение ~7 минут

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

Коротко — и что с этим делать

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

Записаться на бесплатный аудит →

Почему клиент пропускает запись — и при чём здесь напоминание

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

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

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

Что поручить ИИ, а что оставить простым правилом

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

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

Подход	Что делает	Когда подходит	Что контролирует человек
Ручное напоминание	Администратор сам пишет или звонит клиенту	Мало записей, много индивидуальных условий	Текст, время отправки, ответ и перенос
Правило в программе	Отправляет заданное сообщение по расписанию	Процесс повторяется и сценарий почти всегда одинаков	Настройки, ошибки доставки, исключения
Сценарий с ИИ	Разбирает свободный ответ и предлагает разрешённый следующий шаг	Много переписки и типовых вариантов ответа	Деньги, нестандартные условия и окончательное изменение записи

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

С чего начать: один процесс и понятные границы

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

До настройки опишите путь записи от начала до конца. Откуда берутся имя, время и канал связи? Кто меняет расписание? Что считается подтверждением? Куда попадает просьба о переносе? Кто увидит нераспознанный ответ? Такие вопросы кажутся простыми, но без них автоматическое сообщение может уйти после отмены или предложить уже занятое время.

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

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

Как проверить пользу пилота, а не ориентироваться на впечатления

Как проверить пользу? До запуска зафиксируйте время, ошибки и потери, затем сравните те же показатели после пилота. Выберите сопоставимый период и похожую группу записей: например, одну услугу и одинаковые дни недели. Если одновременно менять расписание, цены и порядок приёма, будет сложнее понять, что именно повлияло на результат.

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

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

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

Расчёт окупаемости зависит от стоимости свободного окна, частоты пропусков и затрат времени сотрудников. В KM2B обычно рекомендуют начинать с недорогого пилота на узком участке; окупаемость пилота часто оценивают в горизонте 2–4 месяцев, но это ориентир, а не обещание. Подход к расчёту можно посмотреть на странице оценки окупаемости.

Сначала оценим процесс и ограничения

На бесплатной встрече разберём, где ведётся расписание, какие ответы обрабатывает администратор и какие данные нужны для напоминания. После этого можно определить объём пилота и показатели, по которым сравнить результат.

Бесплатный аудит за 30 минут →

Как настроить напоминания без лишних сообщений

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

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

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

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

Перенос записи и исключения: когда нужен администратор

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

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

До запуска определите и другие границы:

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

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

Данные клиентов и требования 152-ФЗ

Напоминания могут содержать персональные данные, поэтому до внедрения нужно определить, какие сведения используются, с какой целью и кто имеет к ним доступ. Обработка должна соответствовать требованиям 152-ФЗ, а организация — проверить свои основания для работы с данными и порядок взаимодействия с выбранными сервисами. Это задача не только разработчика: подключите ответственного за персональные данные или юриста, если не уверены в основаниях и документах.

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

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

Как понять, что можно расширять пилот

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

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

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

Источники

Начните с одного участка

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