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