Запись без подтверждения
Слот существует в расписании, но пациент не получил ясного следующего шага или сообщение ушло не по тому каналу.
Запись → подтверждение → визит
Меньше пустых окон — без давления на пациента
Неявку нельзя свести к «забывчивости». Иногда пациент не понял подготовку, не смог перенести время, не дозвонился или получил противоречивые сообщения. Мы строим проверяемый маршрут подтверждения, переноса и листа ожидания — с человеком в спорной точке.
Граница роли
Этот контур начинается после записи
Сайт создаёт понятный вход, SEO и реклама приводят спрос, ИИ-регистратура принимает первичное обращение, а маркетинг-автоматизация отвечает за более широкие повторные коммуникации. «Нулевая неявка» работает с уже созданной записью: подтверждает, помогает перенести и возвращает статус в рабочий контур.
Перенос слишком сложен
Чтобы изменить время, нужно снова дозваниваться и повторять контекст. Пациент просто не приходит.
Подготовка разошлась
Сайт, администратор и сообщение дают разные инструкции. Это операционный дефект, а не проблема мотивации пациента.
Лист ожидания отдельно
Окно освободилось, но очередь ведётся в таблице или блокноте без актуального статуса и владельца.
Причина не фиксируется
Отмена, перенос, техническая ошибка и неявка смешаны в одном статусе, поэтому руководитель лечит не ту проблему.
Системы спорят
В МИС запись отменена, а автоматическая цепочка продолжает напоминать. Нужны приоритет источника и стоп-условие.
Маршрут
Шесть статусов вместо одного обещания «напомним всем»
Порядок и интервалы определяются клиникой под услугу, подготовку и доступные каналы. Универсальной цепочки нет.
Создано
Есть услуга, врач, время и источник записи.
Доставлено
Организационная информация ушла допустимым каналом.
Подтверждено
Пациент явно подтвердил визит.
Нужен человек
Вопрос или исключение переданы сотруднику.
Перенесено
Старый слот освобождён, новый зафиксирован.
Завершено
Визит, отмена или иная причина подтверждены источником.
Решение
Инструмент выбирается после процесса
Администратор, контакт-центр, МИС, CRM и цифровой ассистент решают разные части задачи. Иногда достаточно изменить инструкцию и статус, иногда нужна интеграция.
| Участник | Сильная сторона | Граница | Что проверить |
|---|---|---|---|
| Администратор | Понимает контекст и нестандартный вопрос | Не может одновременно вести очередь, звонки и ручные напоминания | Приоритеты, нагрузку и резервный сценарий |
| МИС | Хранит расписание и рабочие статусы | Не каждая система управляет коммуникациями и исключениями | API, актуальность и приоритет статуса |
| CRM | Организует задачи и историю обращения | Может дублировать МИС и требовать лишнего ручного ввода | Владельца карточки и правила синхронизации |
| ИИ-регистратура | Принимает типовой вход и собирает контекст | Не должна принимать клинические решения или скрывать спорный случай | Сценарии передачи человеку и журнал |
| Автоматизация | Исполняет повторяемые правила без пропусков | Тиражирует ошибку, если статус или правило неверны | Стоп-условия, тесты и аварийное отключение |
Проверяемый пилот
Сначала синтетическая неделя расписания
Создайте вымышленные записи с подтверждением, переносом, отказом, недоставленным сообщением, дублем и вопросом к человеку. Проверьте, что статусы меняются один раз, старый слот освобождается, а исключение не получает повторное сообщение. Это проверяет маршрут, но не обещает будущий процент снижения неявок.
Если проблема начинается ещё до записи, сначала исследуйте приём обращений и сквозную аналитику.
ВходСинтетические записи без данных пациентов.
КонтрольЖурнал статусов и ручных передач.
ВыходСписок ошибок и решение о пилоте.
FAQ
Вопросы о подтверждении и переносах
Параметры конкретного контура зависят от МИС, услуг, расписания, согласий и правил клиники.
Можно ли полностью исключить неявки?
Нет. Болезнь, планы пациента и внешние обстоятельства невозможно контролировать. Задача системы — сделать подтверждение и перенос удобными, вовремя освободить слот, предложить его листу ожидания и накопить проверяемые причины, а не обещать нулевой показатель.
Чем эта страница отличается от ИИ-регистратуры?
ИИ-регистратура принимает первичное обращение и передаёт его сотруднику по заданным правилам. Контур неявок начинается после записи: подтверждение, подготовка, перенос, отмена, лист ожидания и анализ фактического визита.
Нужна ли интеграция с МИС?
Для устойчивой работы полезно получать актуальные статусы расписания из разрешённого источника, но глубина интеграции зависит от возможностей МИС и правил клиники. Если API ограничен, сначала проектируют безопасный промежуточный маршрут и ручной резервный сценарий.
Какие данные нужны для пилота?
Достаточно обезличенной карты процесса и синтетических записей: тип услуги, интервал до визита, разрешённые каналы, статусы и ответственные. Реальные сведения пациентов не нужны для проверки логики маршрута.
Что должно быть в отчёте руководителю?
Количество записей по согласованному определению, подтверждения, переносы, отмены, фактические визиты, незакрытые статусы, время реакции и причины исключений. Отчёт должен позволять перейти от агрегата к журналу события без раскрытия лишних данных.
Название решения описывает целевой процесс, а не гарантированный нулевой показатель. Материал не заменяет юридическую или медицинскую экспертизу и не подтверждает готовность конкретной интеграции без технической проверки.