CRM для стоматологии: МИС, отраслевая программа или своя система

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

Что такое CRM для стоматологии и чем она отличается от МИС?

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

МИС (медицинская информационная система) - это программа для медицинской части работы: электронная карта пациента, зубная формула, протоколы приёма, назначения, документы и передача сведений в государственную систему ЕГИСЗ.

Когда владелец клиники ищет «crm для стоматологии», он чаще всего ищет обе вещи сразу. Выдача это подтверждает: в сентябре 2026 года я проверил первую десятку Яндекса по этому запросу, и больше половины мест в ней заняли страницы самих программ и услуг, остальные - подборки и статьи. Большинство программ на этих страницах называют себя и CRM, и МИС одновременно.

Если вы только начинаете разбираться, чем CRM вообще отличается от таблицы и от учётной программы, прочитайте сначала наш общий разбор о том, что такое CRM-система. Здесь мы говорим о том, как это устроено именно в стоматологии.

Какие задачи клиники должна закрывать CRM?

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

Путь пациента через клинику выглядит так:

1. Обращение. Пациент звонит, пишет в мессенджер, оставляет заявку на сайте. Вечером и в выходные ответить ему часто некому, а с острой болью он запишется туда, где ответили первыми.
2. Запись. Администратор подбирает врача, кабинет и время. Нужно не записать двоих в одно кресло и оставить время на сложный приём.
3. Приход. Напоминание накануне, подтверждение, перенос, если планы поменялись. Пустое окно без замены - прямая потеря дня.
4. План лечения. После консультации пациент получает план на несколько этапов. Часть пациентов проходит первый этап и пропадает.
5. Повторный визит. Профилактический осмотр и гигиена по графику, который назначил врач. Без напоминания пациент вспоминает о клинике, только когда снова заболит.

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

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

Где вы сейчас

• Запись в тетради или таблице, медицинские карты на бумаге. Вам почти наверняка хватит готовой отраслевой системы, где CRM и МИС уже вместе. Начните с таблицы классов решений и раздела о законе.
• Стоит МИС, но заявки из мессенджеров и сайта живут отдельно. Ваш раздел - про связку бота записи с системой клиники и про вопросы вендору об API.
• Есть универсальная CRM для заявок и отдельная МИС. Проверьте, обмениваются ли они данными. Если администратор переносит записи руками, смотрите раздел о доработке.
• Сеть клиник или своя программа лояльности. Проверьте признаки, по которым готовой системы становится мало, прежде чем покупать лицензии на все филиалы.

Какие бывают готовые системы для стоматологии?

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

Отраслевые системы для стоматологии. DentalPRO, Sycret Dent, SQNS, Future IT Dent, Dentist Plus и похожие программы. На своих сайтах они описывают близкий набор. Sycret Dent перечисляет рабочее место врача, электронную медкарту, передачу данных в ЕГИСЗ, план лечения и зубную формулу. SQNS пишет, что у системы уже есть интеграции с ЕГИСЗ, онлайн-кассой и Честным знаком. Future IT Dent связывает CRM с записью и МИС, чтобы работа с пациентом после записи шла в той же системе. Dentist Plus описывает приём заявок из телефонии, мессенджеров и онлайн-записи с сайта. Сильная сторона класса в том, что медицинская логика уже заложена: зубная формула, план лечения и медицинская карта здесь базовые понятия.

Универсальные CRM. Битрикс24, amoCRM, Мегаплан и другие системы для продаж. Они хорошо ведут заявки, переписку из мессенджеров, задачи администраторам и воронку первичных пациентов. Медицинскую карту, зубную формулу и передачу сведений в ЕГИСЗ они не ведут, поэтому рядом всё равно нужна МИС. Такой путь выбирают клиники, у которых много рекламы и первичных обращений, а медицинская часть уже живёт в отдельной программе.

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

Названия в таблице - примеры, рейтинга здесь нет. Условия и тарифы вендоров меняются, сверяйте их на сайте производителя на дату выбора.

Что закон требует от программы стоматологии?

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

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

Та же логика относится к нейросетям. Если администратор копирует переписку с пациентом в публичный чат-бот, чтобы быстрее ответить, он передаёт персональные данные третьей стороне. Как устроен этот риск и что с ним делать, мы разбирали в статье про персональные данные клиентов в нейросети.

Когда хватает готовой отраслевой системы?

Ниже пять признаков типовой клиники. Узнали себя почти во всех - смело берите отраслевую систему и вкладывайте силы в её настройку.

1. Одна клиника или несколько с одинаковыми правилами. Прайс, порядок записи и нормы времени на приём везде одни.
2. Пациенты в основном частные. Нет сложных договоров с компаниями, где лимиты и согласование каждого этапа лечения идут через работодателя пациента.
3. Типовые услуги. Терапия, гигиена, хирургия, ортопедия, ортодонтия по обычной схеме записи.
4. Стандартные интеграции. Телефония, мессенджеры, касса и ЕГИСЗ есть в списке готовых подключений вендора.
5. Нет своих цифровых продуктов. Своего приложения, сложной программы лояльности и бота с собственной логикой пока нет и не планируется.

Тогда своя разработка съест время и не даст клинике ничего нового. У отраслевого вендора за плечами то, о чём владелец обычно вспоминает поздно: медицинские шаблоны, зубная формула, обмен с ЕГИСЗ, обновления после каждого изменения закона.

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

Когда нужна доработка или своя система?

Своя система в стоматологии почти никогда не означает «написать всё с нуля». Медицинскую часть с ЕГИСЗ и документами разумно оставить отраслевой МИС. Своим обычно делают то, что вокруг неё:

• Доработка поверх готовой системы. Если у вендора есть открытое API, к нему подключают свои модули: бот записи, личный кабинет пациента, отчёты для владельца.
• Своя CRM для первичных пациентов. МИС ведёт лечение, а своя система - рекламу, заявки, колл-центр и возврат пациентов, и две системы обмениваются данными.
• Свой модуль для отдельного участка. Например, работа с корпоративными клиентами или программа лояльности сети.

Признаки, что пора смотреть в эту сторону:

• Сеть клиник с разными правилами. В одном филиале детское отделение, в другом имплантация, в третьем только терапия. Каждому нужна своя логика записи, а владельцу - сводная картина по сети.
• Корпоративные пациенты. Договоры с компаниями, согласование этапов лечения, счета раз в месяц. В большинстве программ это делается обходными путями.
• План лечения как отдельный процесс. Координатор ведёт пациентов с большими планами, согласует этапы, считает рассрочку и возвращает тех, кто остановился. Готовые системы хранят план, но процесс вокруг него часто остаётся в таблице.
• Свои цифровые продукты. Бот записи, сайт с онлайн-записью, приложение и программа лояльности должны работать с одной базой пациентов. Когда у бота, сайта и учёта три отдельные копии базы, они быстро перестают совпадать.

Два совпадения и больше - повод сесть и расписать процесс клиники на бумаге, а потом проверить, сколько из него готовая система закрывает настройкой. Писать код стоит только для того, что настройкой не решается. Как устроен такой проект, от аудита процесса до прототипа ключевого сценария, описано на странице о разработке и внедрении CRM.

Как связать бот записи с CRM и МИС?

Частая картина: бот стоит в мессенджере, расписание живёт в МИС, а между ними администратор, который вручную переписывает каждую запись. Клиника платит за бота и всё равно держит человека на копировании.

Как выглядит связанная цепочка:

1. Обращение. Пациент пишет вечером в мессенджер. Бот уточняет, первичный это визит или продолжение лечения, и какая услуга нужна.
2. Поиск в базе. Бот находит пациента по телефону в системе клиники и видит, к какому врачу он ходит и есть ли у него незакрытый план лечения.
3. Запись. Бот предлагает свободное время у нужного врача и ставит запись прямо в расписание.
4. Напоминание и подтверждение. Накануне приёма бот напоминает о визите и принимает подтверждение или перенос. Освободившееся время сразу видно администратору.
5. Возврат. Когда пациенту пора на следующий этап плана или на профилактический осмотр, напоминание уходит из той же системы, которая знает дату последнего визита.

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

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

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

Как вернуть пациентов с незакрытым планом лечения?

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

Что для этого нужно в системе:

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

Отдельная история - пациенты, которые записываются и не приходят. Напоминание накануне и подтверждение записи через бота разобраны в том же материале про ИИ-администратора записи.

Что спросить у вендора до переноса базы?

На демо вендор показывает красивые экраны. Каково будет клинике через пару лет с этой программой, видно по ответам на шесть вопросов.

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

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

Где хранятся данные. Сведения о здоровье - особая категория персональных данных. Спросите, где расположены серверы и как вендор выполняет требования закона о персональных данных, если на сайте об этом не сказано.

Права доступа. Может ли администратор видеть запись и контакты без медицинской части карты, а маркетолог - только обезличенные отчёты. Есть ли журнал, кто и когда открывал карту.

ЕГИСЗ. Есть ли подключение, кто его настраивает и поддерживает, что происходит при изменениях требований.

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

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

Какие ошибки делают при выборе CRM для стоматологии?

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

Универсальная CRM вместо МИС. Битрикс24 или amoCRM закроют заявки, но медицинская карта, зубная формула и ЕГИСЗ в них не живут. Если выбираете универсальную CRM, заранее решите, с какой МИС она будет обмениваться данными и кто эту связку сделает.

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

Разработка с нуля без проверки рынка. Обратная крайность - заказать свою систему там, где готовая программа закрыла бы почти всё. Прогоните через две-три отраслевые системы свои реальные случаи и запишите, где они не справились. Этот список пригодится и для настройки, и как основа задания на разработку.

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

Чек-лист

• Описан путь пациента через вашу клинику: обращение, запись, приход, план лечения, повторный визит.
• Понятно, какой класс решения вам нужен: отраслевая система, универсальная CRM с МИС, сервис записи или доработка.
• Две-три системы проверены на ваших данных: пациенты, план лечения на несколько этапов, запись с переносом.
• Вендор ответил про выгрузку данных, открытый API, хранение данных, права доступа и ЕГИСЗ.
• Шаблоны договора сверены с новыми правилами платных медицинских услуг.
• Бот записи, сайт и система клиники работают с одной базой пациентов, медицинские подробности в переписке не собираются.
• Назначен ответственный за список пациентов с незакрытым планом лечения.