Ситуация: что было до внедрения
Сеть клиник из нескольких филиалов работала в классической «лоскутной» схеме: каждое подразделение вело свою базу пациентов — в электронных таблицах или локальной МИС — и отдельно управляло расписанием врачей. Итог предсказуем:
- Пациент, посетивший два разных филиала, числился в системе как два разных человека.
- Администраторы не видели загрузку коллег из соседнего филиала и не могли перенаправить пациента к свободному специалисту.
- Руководство получало отчёты по источникам обращений раз в месяц, вручную сводя данные из нескольких файлов.
- Входящие обращения фиксировались «на бумаге»: звонок по телефону, сообщение в WhatsApp, заявка с сайта — всё в разных местах.
По нашему опыту, такая разрозненность — типичная точка входа для клиник, которые выросли до двух и более филиалов без централизованной CRM.
Задачи, которые предстояло решить
Перед стартом проекта был зафиксирован перечень задач:
- Единая база пациентов — один контакт в CRM, независимо от того, в какой филиал обратился пациент.
- Общее расписание врачей по филиалам — с видимостью загрузки и возможностью записи из любой точки.
- Онлайн-запись — форма с сайта и мессенджеры (WhatsApp) сразу попадают в CRM.
- Права доступа по филиалам — администратор одного филиала не видит пациентов другого; руководство видит всю сеть.
- Аналитика — загрузка специалистов, источники обращений, конверсия записей в визиты.
- Автоматические напоминания — подтверждение записи и напоминание перед приёмом.
Архитектура решения на Битрикс24
На схеме ниже показано, как устроен поток данных от первого обращения пациента до фиксации итогов приёма. Заявки из разных каналов попадают в единую воронку лидов, затем конвертируются в сделки-записи; МИС и Битрикс24 обмениваются данными об оказанных услугах.
flowchart LR
SITE[Сайт / форма] --> B24[Битрикс24 CRM]
WA[WhatsApp] --> B24
PHONE[IP-телефония] --> B24
B24 --> SCHED[Расписание врачей]
B24 --> RIGHTS[Права по филиалам]
B24 <--> MIS[МИС / медицинская\nинформационная система]
B24 --> ANALYTICS[Аналитика и отчёты]
MIS --> B24
Единая база пациентов
Контакт в CRM создаётся один раз: при повторном обращении система сопоставляет телефон или e-mail и не создаёт дубль. Для медицинской специфики карточка контакта дополнена пользовательскими полями:
- дата рождения и полных лет (для контроля дееспособности);
- законные представители — привязка контактов для несовершеннолетних;
- страховая компания, номер и срок действия полиса ДМС;
- плательщик по корпоративному или групповому договору;
- анамнез болезни и жизни, диагноз, назначения, оказанные услуги.
Воронки и стадии
Для работы используются три воронки сделок:
| Воронка | Назначение | Ключевые стадии |
|---|---|---|
| Регистратура | Приём и запись пациентов | Новое обращение → Принят в работу → Записан → Пришёл |
| Приём врача | Учёт визитов и медицинских данных | Записан → Приём начат → Приём завершён |
| Сдача анализов | Ведение лабораторных исследований | Направление → В лаборатории → Готово → Выдано |
Между воронкой «Регистратура» и «Приём врача» настроена полная синхронизация стадий: когда администратор фиксирует запись, врач автоматически видит её в своём расписании. По завершении приёма регистратура получает уведомление о необходимости проконтролировать оплату.
Расписание специалистов по филиалам
Встроенное приложение расписания позволяет:
- просматривать загрузку в дневном виде — все специалисты филиала на один день;
- переключаться в недельный вид по конкретному специалисту;
- видеть цветовые подсказки о наиболее загруженных днях;
- создавать сделку прямо из слота расписания;
- видеть историю предыдущих визитов пациента в момент записи.
Права доступа по филиалам
Настроены роли пользователей: администратор филиала работает только со своим подразделением — сделками, контактами и лидами своего филиала. Руководитель сети и аналитики видят данные по всем филиалам. Это исключает ситуацию, когда персонал одного филиала случайно меняет записи другого.
Автоматизация напоминаний
Настроены роботы в воронке:
- Оповещение о созданной записи — пациент получает сообщение сразу после бронирования.
- Напоминание за несколько часов до приёма — автоматическое сообщение в WhatsApp или SMS.
- Сбор обратной связи — после завершения приёма пациенту автоматически отправляется запрос на оценку; повторная отправка — не чаще одного раза в 6 месяцев.
- Уведомление руководителя о негативной обратной связи.
Подробнее о механике автоматических цепочек — в статье про роботы и триггеры в Битрикс24.
Интеграция с МИС
Для синхронизации с медицинской информационной системой использован модуль односторонней интеграции. Данные обновляются с заданной периодичностью (типовая частота — 1 раз в 5 минут):
- контактные данные пациентов;
- сделки-записи: дата/время, специалист, филиал, статус (Записался / Подтвердил / Пришёл / Отменил);
- перечень оказанных услуг со стоимостью после завершения приёма;
- сохранение источника сквозной аналитики по каждому пациенту.
Решение не передаёт персональные данные первой категории (историю болезни, врачебную тайну) и не хранит данные на сторонних серверах. Данные Битрикс24 хранятся на серверах на территории РФ в соответствии с № 152-ФЗ.
Интеграция возможна с любой МИС, имеющей открытый API или работающей на базе 1С (Первый Бит Стоматология, Медицина, Больница, Поликлиника и др.), а также с Медодс, Архимед, МедОфис, Дентал Про и другими системами.
Что настраивали: чек-лист работ
Ниже — типовой перечень настроек, которые реализуются в проекте подобного масштаба:
- [ ] Структура портала: филиалы, подразделения, роли пользователей
- [ ] Пользовательские поля карточки пациента (возраст, ДМС, плательщик, анамнез и др.)
- [ ] Три воронки сделок: Регистратура, Приём врача, Сдача анализов
- [ ] Воронка лидов со стадиями первичной обработки обращений
- [ ] Приложение «Расписание специалистов» с привязкой к филиалам
- [ ] Права доступа: роли администратора, врача, руководителя, аналитика
- [ ] Подключение форм с сайта (автоматическое создание лида/сделки)
- [ ] Подключение WhatsApp через открытую линию
- [ ] Подключение IP-телефонии
- [ ] Роботы: напоминания о записи, подтверждение, сбор обратной связи
- [ ] Модуль интеграции с МИС (настройка обмена сделками и контактами)
- [ ] Настройка сквозной аналитики по источникам обращений
- [ ] Дашборды загрузки специалистов и конверсии записей
- [ ] Обучение администраторов и руководителей работе с системой
Перед стартом такого проекта полезно пройти аудит текущего состояния портала — это позволяет избежать дублирования настроек и точнее оценить объём доработок.
Таблица «было → стало»
| Параметр | До внедрения | После внедрения |
|---|---|---|
| База пациентов | Разрозненная, по каждому филиалу отдельно | Единая CRM, один контакт на пациента |
| Расписание врачей | Локальное, без видимости между филиалами | Общее расписание с разграничением по подразделениям |
| Обработка входящих | Телефон, мессенджеры, сайт — в разных местах | Все каналы в единой воронке лидов |
| Напоминания пациентам | Вручную или отсутствовали | Автоматически за несколько часов до приёма |
| Права доступа | Не разграничены | По роли: администратор видит только свой филиал |
| Аналитика по источникам | Ручная сводка раз в месяц | Сквозная аналитика в реальном времени |
| Синхронизация с МИС | Отсутствовала | Автоматический обмен каждые 5 минут (оценочно) |
| Сбор обратной связи | Не автоматизирован | Автоматическая отправка после каждого визита |
Результаты
По итогам внедрения сеть клиник получила:
- Устранение дублей пациентов — единая идентификация по телефону/e-mail исключает повторное заведение карточек при обращении в разные филиалы.
- Видимость загрузки в реальном времени — администраторы перенаправляют пациента к свободному специалисту в другом филиале, не переспрашивая коллег по телефону.
- Управляемая аналитика — руководство видит источники обращений, конверсию из лида в визит и загрузку по каждому специалисту без ручных отчётов.
- Автоматические коммуникации — напоминания и сбор обратной связи работают без участия администраторов.
- Соответствие требованиям по данным — персональные данные хранятся на серверах в РФ; врачебная тайна через интеграционный модуль не передаётся.
Конкретные числовые показатели роста выручки или снижения потерь пациентов в данном кейсе не фиксировались формально — поэтому приводим их в формате «оценочно»: количество необработанных обращений, по оценке команды, снизилось существенно за счёт единой очереди лидов и автоматических напоминаний.
Нюансы и типичные сложности
Из опыта подобных проектов:
Дубли пациентов при миграции. Если до внедрения каждый филиал вёл свою таблицу, при импорте неизбежно возникают дубли контактов. Их нужно объединять до или сразу после миграции. Подробнее — в материале про дублирование лидов в Битрикс24.
Сопротивление персонала. Администраторы привыкли к локальному расписанию. Важно провести обучение не «по кнопкам», а по сценариям работы. О форматах обучения читайте в статье базовое vs расширенное обучение Битрикс24.
Готовность МИС к интеграции. Интеграция возможна только при наличии открытого API у МИС или при работе на базе совместимых платформ. Это нужно уточнять до подписания ТЗ.
Персональные данные пациентов. Медицина — одна из отраслей с повышенными требованиями к хранению данных. Коробочная версия Битрикс24 даёт дополнительный контроль над размещением данных; облачная версия хранит данные на серверах в РФ по 152-ФЗ.
Если вы только планируете проект — рекомендуем сначала заполнить опросный лист клиента перед внедрением: это сэкономит несколько итераций согласования.