CRM для стоматологии: как выбрать и не переплатить

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

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

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

Что клиника должна получить от CRM

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

• Журнал заявок. Каждое обращение - из WhatsApp, Telegram, телефона, сайта или стойки администратора - попадает в один список с датой, каналом и ответственным. Обращение, не попавшее в журнал, считается потерянным, и это видно сразу, а не «как-то потом».
• Расписание и запись. Окна врачей, переносы, лист ожидания - в одном месте, без трёх тетрадей и снимков экрана в чате администраторов.
• Карта пациента. История визитов, план лечения, документы и переписка - так, чтобы новый администратор за минуту понял, с кем говорит и что обещали.
• Контроль касаний. Напоминания о визите, подтверждения, работа с теми, кто давно не приходил. Этот контур чаще всего живёт «в голове у Марины» и уходит вместе с ней в отпуск.

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

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

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

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

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

Поэтому единственная корректная единица сравнения - стоимость владения за год:

(лицензии × рабочие места × 12 месяцев) + внедрение + планируемые доработки + часы команды на перенос данных и обучение.

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

Подход первый: коробочная CRM для клиник

Коробочные системы - тяжёлые платформы, которые продаются медицинскому рынку «как больничная информационная система»: расписание, карта пациента, склад, лаборатория, бухгалтерия, интеграции с кассами и страхованием.

Сильные стороны

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

Слабые стороны

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

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

Подход второй: конструктор из кубиков

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

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

Слабых сторон три, и все они проявляются со временем:

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

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

Подход третий: ИИ-платформа с готовыми сценариями

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

Как ИИ-сотрудник работает именно в стоматологии, мы описывали в материале «ИИ-сотрудник в стоматологии»; чем такой подход отличается от классической CRM, разобрано в статье «CRM или ИИ-сотрудник».

Сильные стороны

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

Слабые стороны

• Каталог сценариев ограничен: очень нестандартный процесс либо не автоматизируется, либо потребует участия вендора.
• Глубина медицинских протоколов ниже коробочных систем: полноценную карту лечения со всеми ограничениями такие платформы обычно не ведут.
• Требует честного разговора на входе: вопрос «чего мы НЕ делаем» не менее важен, чем демо возможностей.

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

Сравнение трёх подходов

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

Читайте строки таблицы как вопросы к вендору, а не как приговор: и коробка может запуститься быстро, и конструктор может жить годами - если подрядчик хороший. Таблица задаёт направление проверки; истина - в смете и пилоте.

Шесть ошибок при выборе CRM

1. Покупать «на вырост». Клиника на два кресла берёт систему «для сети, которой пока нет». Платится за мощность, которая не используется, а загрузка команды - за обучение модулям, которые не нужны. Правильный размер - под планы на год-два, не дальше.
2. Выбирать по демо, а не по своим сценариям. Презентация всегда выглядит гладко - её показывали сотню раз. Свои сценарии («пациент написал в WhatsApp в 22:40», «нужно перенести запись на завтра») на демо не спрашивают, а зря: именно на них системы и различаются.
3. Не считать стоимость владения. Сравнивают цену лицензии и покупают самый дешёвый хвост доработок. Считайте год целиком, по формуле выше.
4. Забывать каналы пациентов. Система «красивая внутри», но заявки из мессенджеров и онлайн-запись подключаются за отдельные деньги - или не подключаются. О том, как пациенты мигрируют с телефона на онлайн-запись, - в материале «Онлайн-запись вместо телефона».
5. Не назначать внутреннего владельца. CRM внедряют «для клиники», а отвечает никто: администраторы работают по-старому, система превращается в дорогой ежедневник. Владелец - конкретный человек с фамилией, а не «коллектив».
6. Не проговаривать выход. Что происходит с базой пациентов при расторжении договора? В каком формате, в какие сроки, за какие деньги отдадут экспорт? Вопрос задают до подписания - или не задают никогда, а потом торгуются с закрытой дверью.

Чек-лист: десять вопросов вендору

Распечатайте и пройдите по списку на первой же встрече. Каждый вопрос, на который ответили невнятно, - это строка будущего хвоста расходов.

1. Сколько стоит год владения «всё включено»: лицензии, внедрение, поддержка, обновления?
2. Что входит во внедрение, а что считается доработкой - и по какой ставке считаются доработки?
3. Как работает поддержка ночью и в выходные - и через какое время обещаете реакцию на обращение?
4. Какие каналы заявок (телефон, WhatsApp, Telegram, сайт, онлайн-запись) подключаются из коробки, а какие за отдельные деньги?
5. Где физически хранятся персональные данные пациентов и как обеспечивается соответствие 152-ФЗ?
6. Что произойдёт с данными при расторжении договора: формат экспорта, сроки, цена?
7. Как обучается команда - кто, сколько часов, на каких материалах, входит ли в смету?
8. Можно ли начать с одного сценария, например записи и напоминаний, и расширяться позже?
9. Какие обновления входят в подписку, а какие покупаются отдельно?
10. Дайте контакты двух клиник нашего размера, которые работают в системе год и дольше.

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

Как выглядит здоровое внедрение

Порядок, который экономит деньги и нервы:

1. Неделя ноль - сценарии. Вы описали свои пять-семь ситуаций и получили от вендора встреченное описание: как каждый сценарий будет работать в системе. В письменном виде.
2. Пилот на одном процессе. Один канал, одна стойка, две-четыре недели. Пилот проходит на реальных заявках, но с правом откатиться без штрафов.
3. Обучение на своих примерах. Администраторы тренируются не на песочнице вендора, а на своих типовых диалогах и переносах.
4. Расширение по очереди. Следующий канал подключается, когда предыдущий стабилен: «пилот - стоп - проверили - дальше», а не «переходим всем отделом к понедельнику».

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

Критерии успеха пилота

У пилота должны быть числовые ворота, заданные до старта: например, «доля заявок с первым ответом в течение часа - не ниже нынешней, а перенос записи занимает не дольше, чем в тетради». Пилот без критериев превращается в бесконечное «ещё немного настроим» - с вендором, который настроит что угодно, пока платят. Дата окончания пилота назначается вместе с критериями; по итогам - письменное «работает» или «не работает» с причинами.

Перенос данных: скучная часть, на которой всё ломается

Отдельный разговор - база пациентов. Именно перенос чаще всего срывает сроки и разочаровывает в системе, поэтому проговаривайте его до договора:

• Формат на входе. Что у вас есть сейчас: таблица, тетради, экспорт из старой системы, обрывки в телефонах администраторов. Честная инвентаризация источников - половина работы.
• Дубли и мёртвые контакты. Пациент, записанный трижды как «Иван И.», «Иван Иванович» и «иван из телеграма», - это одна запись или три? Правило объединения дубликатов задаётся до переноса, а не после.
• Параллельный период. Две-четыре недели данные ведутся в обеих системах, расхождения разбираются ежедневно. Полный переход «одним днём» без параллельного периода - самая частая причина потерянных записей на ровном месте.
• Ответственный за сверку. Один человек сверяет перенесённое с исходником по выборке: несколько случайных пациентов в неделю. Ошибки переноса, найденные через месяц, стоят дороже всего.

Честные ограничения

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

Что делать сейчас

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

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

Читайте также: «Чек-лист запуска ИИ-сотрудника: 30 пунктов за неделю», «Автоворонка для услуг: от первой заявки до повторной продажи», «Переезд с n8n: пошаговый перенос сценариев на российскую платформу».