CRM для клиники: как мы внедрили Битрикс24 в закрытом контуре и сделали карточку пациента удобной для медперсонала

Система работы с пациентами не подходила для обработки заявок и активных продаж услуг клиники – данные были разрознены, процессы зависели от людей, а не от системы.

Клиенту требовалась управляемая среда, где можно контролировать конверсию, скорость обработки и повторные продажи.

О клиенте

ЦКБ — Московская клиническая больница с поликлиникой.

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

Цель проекта

Внедрить коробочную CRM для клиники на базе Битрикс24 в закрытом контуре заказчика и адаптировать систему под работу отдела по взаимодействию с пациентами: от первичной заявки до госпитализации, амбулаторной программы, обратной связи и повторного обращения.
Ключевая цель была не просто перенести процессы в CRM, а сделать систему удобной для ежедневной работы медицинского персонала и менеджеров. Для этого нужно было стандартизировать обработку заявок, сократить время на заполнение карточек пациентов, автоматизировать рутинные действия и дать руководству прозрачную аналитику по продажам коммерческих медицинских услуг.

Задачи проекта

• Развернуть коробочную версию Битрикс24 на сервере заказчика в закрытом контуре, без зависимости от облачных сервисов и приложений из Маркета
• Перенести в CRM историческую базу пациентов и сделок за 2022–2025 годы, предварительно очистив и нормализовав данные 
• Настроить единую воронку продаж для коммерческих госпитализаций и амбулаторных комплексных программ
• Стандартизировать работу менеджеров на всех этапах: от новой заявки и консультации до согласования, принятия решения, завершения и повторного обращения
• Сократить время обработки заявок за счет автоматических задач, напоминаний, контроля сроков и стандартов обслуживания для экстренных и стандартных обращений
• Настроить автоматическое движение сделок по воронке, включая пропуск нерелевантных этапов и перенос отложенных заявок в парковочную воронку «Ожидание»
• Автоматизировать формирование документов, шаблонов и служебных записок в зависимости от типа услуги и этапа работы с пациентом
• Настроить контроль обязательного заполнения ключевых данных, включая причины отказов значимые параметры
• Реализовать механизм повторных продаж, чтобы система автоматически возвращала пациентов в работу через 11 месяцев после завершения программы
• Создать кастомные отчеты и дашборды для руководства, так как стандартный BI-конструктор был недоступен в закрытом контуре

На бумаге задача выглядела как классическое внедрение CRM для медицинской клиники. Есть заявки, есть менеджеры, есть этапы сделки, есть база пациентов, есть документы и отчеты. Но в процессе стало понятно: обычной настройки коробочного Битрикс24 здесь недостаточно. У клиники был закрытый контур, сложная медицинская логика и большое количество данных, которые нельзя показывать сотруднику все сразу.

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

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

Зачем клинике понадобилась CRM для медицинских клиник

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

До внедрения данные частично жили в Excel. Историческая база за 2022–2025 годы содержала около 12 тысяч строк. Информация велась в свободном формате: в одной ячейке могли оказаться ФИО, телефон, комментарий и пояснение родственной связи. Например, не отдельный контакт «Александр», а запись в духе «сын Александр» рядом с телефоном и другими данными.

Для руководства это создавало несколько проблем:

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

Поэтому цель проекта была шире, чем «внедрить Битрикс24». Нужно было построить рабочую систему для медицинского отдела, где CRM помогает сотруднику двигаться по процессу, а не просто хранит данные.

Что нужно было автоматизировать в CRM для клиники

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

В проект вошли следующие задачи:

• развернуть коробочную версию Битрикс24 на сервере заказчика в закрытом контуре
• импортировать существующую базу клиентов из Excel
• настроить воронки продаж и карточки сделок
• реализовать зависимые поля, где содержимое одних полей зависит от выбора других
• реализовать динамические поля, где набор полей в карточке меняется в зависимости от стадии сделки
• настроить автоматизацию задач, напоминаний, документов и движения сделок
• создать отчеты и дашборды для руководства
• стимулировать повторные продажи через автоматические приглашения пациентов на ежегодные программы

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

Главное ограничение проекта – закрытый контур

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

В обычном проекте часть задач можно закрыть готовыми решениями:

• поставить приложение из Маркета Битрикс24
• использовать внешний BI-конструктор
• подключить облачные сервисы
• быстро протестировать готовый модуль зависимых полей

Здесь такой возможности не было. Портал работал в закрытом контуре, от подписки на Маркет отказались, стандартный BI-конструктор использовать было нельзя. Поэтому все нестандартные требования пришлось закрывать кастомной разработкой внутри коробочной версии Битрикс24.

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

Почему стандартной карточки Битрикс24 не хватило

В Битрикс24 можно создавать пользовательские поля, настраивать стадии сделки, роботов, обязательность заполнения. Но в стандартном функционале нет удобной возможности менять состав карточки пациента «на лету» в зависимости от этапа воронки и выбранных параметров.

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

В одной карточке пациента могут быть поля для разных сценариев:

• госпитализация
• амбулаторная программа
• взрослый чекап
• детский чекап
• программа прикрепления
• экстренное обращение
• согласование с врачом
• отказ пациента
• обратная связь
• повторное приглашение

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

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

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

Как работает модуль динамических полей

Мы разработали кастомный модуль, который меняет отображение полей в карточке сделки в зависимости от условий. По сути, это отдельный слой логики поверх стандартного интерфейса Битрикс24.

Модуль учитывает несколько параметров:

• тип услуги
• категорию пациента
• выбранную программу
• текущий этап воронки
• медицинские и организационные условия сделки

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

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

Это решает сразу несколько задач:

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

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

Чем динамические поля отличаются от зависимых полей

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

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

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

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

Мы сделали так, чтобы логика процесса была встроена в интерфейс. Это снижает когнитивную нагрузку на администратора и менеджера. Человек не вспоминает регламент каждый раз, а идет по форме, которая показывает нужные поля в нужный момент.

Почему это критично именно для медицины

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

Если интерфейс перегружен, появляются типичные риски:

• сотрудник долго ищет нужное поле во время разговора с пациентом
• важная информация попадает в комментарии вместо структурированного поля
• разные менеджеры заполняют карточки по-разному
• руководитель видит неполную аналитику, потому что данные внесены не в те места
• пациенту приходится повторять информацию
• отложенные заявки и повторные продажи зависят от ручного контроля

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

Это не косметическая доработка интерфейса. Это способ защитить процесс от ошибок и потери времени.

Как мы подготовили историческую базу пациентов

Отдельной сложностью стал импорт исторических данных. Клиника передала базу за 2022–2025 годы примерно на 12 тысяч строк. Стандартный импорт Битрикс24 здесь не подходил, потому что данные были неструктурированы.

В Excel могли встречаться смешанные записи, где в одной ячейке находились:

• ФИО пациента
• телефон
• дата рождения
• контактное лицо
• родственная связь
• текстовый комментарий

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

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

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

Как устроили единую воронку для госпитализаций и амбулаторных программ

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

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

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

Так система может:

• показывать разные поля для госпитализации и амбулаторной программы
• пропускать лишние этапы, если они не нужны
• генерировать разные документы
• ставить разные дела ответственному
• по-разному запускать обратную связь
• создавать повторные сделки только для нужных программ

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

Как CRM контролирует скорость обработки заявок

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

Мы настроили контроль SLA на этапе «Новая заявка». Система отслеживает, сколько времени заявка находится без движения, и отправляет уведомления ответственным.

Логика разная для разных категорий услуг:

• для экстренных услуг, если статус не изменился, через 20 минут уведомление получает ответственный
• если экстренная заявка не обработана через 50 минут, уведомление уходит руководителю
• для остальных услуг уведомление ответственному приходит, если заявка провисела больше 2 часов

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

Как работает парковочная воронка «Ожидание»

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

Для этого мы спроектировали парковочную воронку «Ожидание».

Механика такая:

• менеджер выбирает статус «Перезвонить»
• указывает дату отложенного решения
• сделка уходит из основной активной воронки
• в назначенную дату робот возвращает ее обратно на этап «Принятие решения»
• ответственный менеджер сохраняется

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

Как CRM помогает менеджеру не забывать действия

На каждом этапе воронки роботы ставят дела ответственному сотруднику. Это нужно не для формального контроля, а чтобы сделка не зависала из-за человеческого фактора.

Мы настроили автоматическую постановку дел:

• на этапе «Новая заявка» создается дело «Связаться с пациентом» со сроком 20 минут
• на этапе «Консультация» система рассчитывает возраст пациента и, если ему 70 лет или больше, ставит дело «Проверить договор»
• на этапе «Согласование» создается дело «Согласовать результат»
• на этапе «Принятие решения» ставится дело на контроль изменения статуса со сроком 1 день
• после успешного завершения создаются отложенные дела для сбора обратной связи
• для госпитализаций обратная связь ставится через 10 дней
• для амбулаторных программ – через 5 дней

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

То есть CRM не просто хранит дату рождения. Она использует ее для управленческого действия.

Как настроили автоматические повторные продажи

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

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

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

Как CRM контролирует причины отказов

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

Мы настроили контроль заполнения поля «Причина отказа». Если менеджер переводит сделку в статус «Наш отказ» или «Отказ пациента», система блокирует дальнейшее движение, пока причина не будет выбрана из справочника.

В справочнике могут быть разные причины:

• нет мест
• пациент умер
• стоимость пребывания
• отказ по медицинским или организационным причинам
• другие утвержденные варианты

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

Как автоматизировали документы и шаблоны

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

Мы настроили автогенерацию документов и скриптов по этапам.

На этапе «Предложение» робот генерирует персонализированные файлы для отправки пациенту. Шаблон выбирается в зависимости от типа программы. В документы подставляются нужные данные: ФИО, депозит, палата, даты и другие параметры.

На этапе «Подтверждение» формируются итоговые шаблоны для пациента и отдельная служебная записка для коммерческого отдела по госпитализациям.

На этапе завершения робот выводит в таймлайн карточки скрипт-подсказку с темой «ТРЕБУЕТСЯ ОБРАТНАЯ СВЯЗЬ». Текст подсказки меняется в зависимости от того, была ли это госпитализация или обследование.

Это снимает с менеджера часть рутинной работы и делает коммуникацию более стандартизированной.

Почему мы сделали кастомные отчеты вместо BI-конструктора

В закрытом контуре стандартный BI-конструктор использовать было нельзя. Но задача по аналитике оставалась: руководству нужны были дашборды и отчеты по работе отдела.

Поэтому отчеты реализовали как кастомную разработку. Это позволило не зависеть от внешних сервисов и при этом собрать нужную управленческую картину внутри инфраструктуры заказчика.

Для руководителя такая аналитика важна не сама по себе. Она отвечает на практические вопросы:

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

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

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

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

Для удобства операторов мы разработали кастомный компонент поиска. Он перекрывает штатный поиск Битрикс24 и позволяет искать пациента не только по телефону, но и по дате рождения.

Например, сотрудник может ввести дату «03.10.1948» и найти пациента в базе. Это особенно полезно, когда номер телефона изменился, звонит родственник или в заявке указаны неполные данные.

Такой поиск снижает риск дублей и помогает сохранить единую историю пациента.

Как медицинские опросники перенесли в CRM

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

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

Такой комментарий удобно скопировать и передать лечащему врачу. При этом данные не живут в хаотичной переписке, а собираются по единой форме.

Что получилось в результате

По итогам проекта клиника получила коробочную CRM в закрытом контуре, адаптированную под реальные процессы отдела по работе с пациентами. Это не типовая установка Битрикс24, а кастомизированная система, где интерфейс, автоматизация и аналитика подчинены медицинской логике.

Реализованы ключевые блоки:

• коробочная версия Битрикс24 развернута на серверах больницы
• заведены пользователи и настроена структура компании
• импортированы исторические контакты и сделки за 2022–2025 годы
• выполнена программная нормализация неструктурированной Excel-базы
• настроена единая воронка для госпитализаций и амбулаторных программ
• реализован модуль динамического отображения полей
• настроена логика зависимых полей
• запущены базовые автоматизации по задачам, срокам и этапам
• настроено автоматическое наименование сделок
• реализован расчет возраста пациента по дате рождения
• создана парковочная воронка для отложенных решений
• настроены автодокументы и скрипты обратной связи
• реализованы кастомные отчеты и дашборды
• настроены механики повторных продаж через 11 месяцев

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

Почему этот проект важен для внедрения CRM в клинике

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

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

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

Именно поэтому модуль динамических полей стал центральной частью проекта. В стандартном Битрикс24 такой возможности нет ни в облаке, ни в коробке. В открытом контуре ее можно было бы частично закрыть приложениями из Маркета. Но в инфраструктуре заказчика портал работал без доступа к интернету, поэтому решение пришлось создавать с нуля.

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

 

Вывод

Хорошая CRM для медицинских клиник – это не самая заполненная карточка пациента. Это система, в которой сотруднику понятно, что делать на каждом этапе.
В проекте для Центральной клинической больницы с поликлиникой мы сделали именно такую логику. Битрикс24 стал не складом полей, а рабочим инструментом отдела по работе с пациентами. Карточка меняется под этап и тип услуги, заявки контролируются по срокам, отложенные пациенты возвращаются в работу автоматически, документы формируются по шаблонам, а руководство получает данные для анализа.
Главное решение проекта – кастомный модуль динамических полей. Он убрал из карточки лишнее, оставил сотрудникам только нужное и помог превратить сложный медицинский процесс в понятный маршрут внутри CRM.