CRM для медицинской клиники

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

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

Отсюда правило, которое стоит держать в голове весь проект: верх воронки видит веб-аналитика, низ — только CRM вместе с МИС. Разрыв проходит ровно по четвёртому шагу. Без CRM клиника считает стоимость заявки и уверена, что считает стоимость пациента, — а это разные величины, и расходятся они тем сильнее, чем хуже работает колл-центр.

Отраслевые публикации по медмаркетингу называют ориентиры переходов между шагами: визит на сайт → обращение 2–6%, обращение → запись — цель около 70%, запись → приход 70–90%. Это не норматив и не наше обещание: цифры взяты из открытых отраслевых материалов, первичных исследований по рынку РФ нет. Пользоваться ими стоит ровно для одного — понять, какой шаг у вас проседает заметнее прочих, а дальше считать по своим данным.

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

Вопрос честный, и отвечать на него «МИС — это не CRM» недостаточно. У Клиентикса коммерческий модуль встроен в продукт, у ArchiMed+ и IDENT есть свои CRM-блоки, у 1С:Медицины — тоже. Небольшой клинике этого действительно хватает, и продавать ей вторую систему нечестно.

Что встроенный модуль МИС закрывает

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

Где он упирается

• Обращение без записи. В МИС пациент появляется в момент записи. Человек, который позвонил, не дозвонился или передумал, для МИС не существует — а это самая дорогая часть рекламного бюджета.
• Источник обращения. МИС не знает, из какого канала пришёл пациент, и не может сопоставить его с расходом на рекламу.
• Несколько филиалов. Сводная коммерческая отчётность по сети и сравнение филиалов между собой — задача, под которую производственная система не проектировалась.
• Сегментация и согласия. Правило «в этот сегмент попадают только те, у кого есть действующее согласие на продвижение» встроенным фильтром обычно не выражается.
• Права маркетолога. Чтобы считать эффективность, маркетологу нужен доступ к данным. Доступ к медицинской части ему давать нельзя — значит, нужен контур, где медицинских данных просто нет.

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

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

Об этом честнее договариваться до подписания, а не после. CRM клинике не нужна, если верно хотя бы одно:

• Один-два кабинета и один врач. Администратор помнит пациентов по именам, а вся «сегментация» помещается в голове. Система здесь добавит кликов, а не денег.
• Нет платного трафика. Поток идёт из сарафана и с карт. Считать стоимость привлечения нечего, а без этой задачи половина смысла CRM отпадает.
• Рекламный бюджет меньше стоимости внедрения. Тогда те же деньги, вложенные в рекламу и в нормальный сайт, дадут больше.
• Нет владельца системы. Если в клинике нет человека с полномочиями и временем, который будет отвечать за CRM после запуска, проект умрёт за три месяца независимо от качества настройки.
• Не закрыт нулевой уровень. Нет виртуальной АТС с записью разговоров, расписание в МИС ведётся как придётся, часть записей живёт в тетради. Сначала это, потом CRM — иначе автоматизируется беспорядок.

Внедрить CRM в клинику, где нет ни платного трафика, ни колл-центра, — значит продать работу, которая не окупится. За такой проект браться не стоит. Вместо него обычно имеет смысл сделать три более дешёвые вещи: подключить виртуальную АТС с записью разговоров, привести в порядок расписание и справочник услуг в МИС и поставить на сайт онлайн-запись, которая попадает в это расписание. Через полгода данные, накопленные этими инструментами, сами покажут, нужна ли следующая система.

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

Первый — 152-ФЗ. Данные о состоянии здоровья относятся к специальной категории персональных данных (ст. 10), их обработка допускается по закрытому перечню оснований.

Второй — 323-ФЗ. Врачебной тайной, согласно ч. 1 ст. 13, признаются сведения о самом факте обращения гражданина за оказанием медицинской помощи, о состоянии здоровья и диагнозе. Практическое следствие пропускают почти все: карточка «Иванов записан на 14:00» — это уже сведения, составляющие врачебную тайну. Не когда вы выгрузите диагнозы, а с первого дня. Разглашение запрещено (ч. 2), а перечень случаев, когда согласие не требуется (ч. 4), закрытый — маркетинга в нём нет.

Отдельное согласие на продвижение. По ст. 15 152-ФЗ обработка персональных данных для продвижения услуг путём прямых контактов допускается только с предварительного согласия, причём обработка считается совершённой без согласия, пока оператор не доказал обратное. Бремя доказывания лежит на клинике. Отсюда вывод, неприятный для многих отделов маркетинга: реактивация «спящих» пациентов на основании согласия, подписанного для оказания медицинской помощи, этим согласием не покрывается.

Что изменилось с 1 сентября 2025 года. Федеральный закон № 156-ФЗ от 24.06.2025 дополнил ст. 9 152-ФЗ: согласие оформляется отдельным документом. Его нельзя спрятать внутри договора, оферты или анкеты и нельзя объединять с согласием на рекламные рассылки. Обратной силы у нормы нет — согласия, подписанные раньше, переподписывать не требуется.

Инженерный ответ — минимизация. В CRM передаём: идентификатор пациента из МИС, контакты, факт и статус записи, направление или категорию услуги, врача, филиал, сумму, источник обращения. Не передаём: диагнозы, анамнез, результаты исследований, протоколы приёма, назначения. База с персональными данными граждан РФ размещается на серверах в России (ч. 5 ст. 18 152-ФЗ).

Подрядчик, который настраивает такую систему, становится лицом, обрабатывающим данные по поручению оператора: ст. 6 ч. 3 требует договора-поручения с перечнем данных и операций, а по ч. 5 ответственность перед пациентом остаётся на клинике. Поэтому договор-поручение мы подписываем всегда, а не по запросу. Это не юридическая консультация: нормы менялись в 2024–2025 годах, и подробный разбор с датой актуализации вынесен на отдельную страницу — CRM и персональные данные пациентов.

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

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

• Есть ли у вашей МИС штатный API. У Renovatio и Клиентикса он документирован публично. У Инфоклиники доступ платный и открывается заявкой у вендора под конкретное приложение. По ряду систем публичной документации нет вовсе, и интеграция превращается в отдельную разработку.
• Направление обмена. При одностороннем API данные можно только забирать: запись, созданная в CRM, слот в расписании МИС не займёт, и администратор продолжит работать в двух окнах.
• Ключ сопоставления пациента. Телефон, связка ФИО с датой рождения или идентификатор из МИС — выбирается до старта. Если этого не сделать, заметная часть базы через полгода окажется дублями, пришедшими из разных каналов записи.

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

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

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

Направление внедрения CRM мы открыли в 2026 году и говорим об этом прямо, вместо того чтобы рисовать счётчик «400+ проектов». Портфолио именно по CRM будем публиковать по мере завершения проектов.

Что за нами стоит уже сейчас: маркетинг в медицине — клиники, стоматологии, диагностика, косметология, — и опубликованные кейсы продвижения, которые можно открыть и проверить. Мы приходим в CRM со стороны маркетинга: нас интересует не «настроить карточки», а замкнуть контур «реклама → обращение → запись → визит → выручка», потому что именно на нём клиника теряет деньги.

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

Для клиник мы предлагаем начинать с пилота: две недели, фиксированная цена, одна воронка — обычно первичная запись. Этого достаточно, чтобы увидеть, приживается ли инструмент у администраторов, и не увязнуть в долгом проекте.

Перед стартом подписываем договор-поручение на обработку персональных данных: для клиники это не формальность, а зона её собственной ответственности по 152-ФЗ.