CRM и аналитика клиники: как связать обращение, запись и состоявшийся визит

Какой результат должна давать связка систем

Практическая задача аналитики — объяснить, что произошло после обращения. Человек отправил форму, сотрудник уточнил условия, появилась запись, затем состоялся визит. Руководитель должен видеть эту цепочку и понимать, на каких данных основан каждый переход. Отчёт с отдельными числами звонков, заявок и приёмов такой связи ещё не доказывает.

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

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

Что делают CRM, МИС и веб-аналитика

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

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

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

Человек, обращение, запись и визит — разные единицы

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

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

Составьте паспорт данных

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

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

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

Минимальная модель связей

Ниже — условная схема для обсуждения с интегратором, а не обязательная структура конкретной CRM или готовая база данных. Поля показывают связи между объектами. Состав, место хранения и доступность каждого поля нужно отдельно согласовать. Имена технических полей используются только для однозначного обсуждения.

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

Какие события и идентификаторы сохранять

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

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

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

Договоритесь о статусах и правилах перехода

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

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

Дубли, родственники и несколько контактов

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

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

При спорном совпадении создавайте очередь ручной проверки. Сохраняйте исходные номера и возможность разъединить объекты после ошибочного объединения. Для отчёта полезно показывать число устранённых технических повторов отдельно от числа объединённых обращений. Иначе снижение потока после настройки очистки легко принять за проблему рекламы.

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

Переносы и движение между филиалами

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

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

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

Как сохранять источники обращения

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

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

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

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

Как обращаться с атрибуцией

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

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

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

CRM и офлайн-конверсии в Метрике

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

Для сопоставления CRM-заказов с онлайн-историей Яндекс рекомендует сохранять ClientId в CRM. Но наличие идентификатора ещё не гарантирует успешную привязку. Проверять надо всю цепочку: получение значения, сохранение, передачу, обработку и результат. Если идентификатор отсутствует, нельзя подставлять номер пациента или вымышленное значение ради заполнения поля.

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

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

Какие данные ограничить и кто получает доступ

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

Условия Метрики запрещают передавать идентификационную информацию вне функций, которые прямо предусматривают такую передачу. Не включайте персональные и медицинские сведения в UTM-метки, URL, названия целей и произвольные события. Хеширование или замена имени кодом сами по себе не являются универсальным разрешением на передачу.

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

Тестируйте на синтетических записях. Не копируйте реальные базы в публичные таблицы, открытые формы, незащищённые сервисы и инструменты ИИ для удобства разбора. Договорённости о получателях, сроках хранения и основаниях обработки проверяют уполномоченные специалисты клиники применительно к её ситуации.

Надёжная доставка: повторы, ошибки и порядок событий

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

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

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

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

Как принимать интеграцию

Приёмка начинается с заранее составленных сценариев и ожидаемых результатов. Интегратор показывает маршрут тестового обращения через системы и журнал доставки. Клиника проверяет смысл статусов и работу сотрудников. Наличие соединения с API и зелёной отметки «подключено» не подтверждает правильность управленческого отчёта.

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

Как контролировать полноту данных

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

Условный пример, не результат клиента: источник сформировал 100 тестовых событий, очередь получила 100, получатель принял 96, а сопоставилось 81. Ошибка доставки касается 4 событий, вопросы сопоставления — ещё 15. Если смотреть только на 81 результат, команда смешает две разные задачи и начнёт исправлять идентификаторы там, где событие вообще не дошло.

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

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

Каким должен быть отчёт руководителя

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

Разделите два представления. Календарное показывает работу за период: сколько обращений обработали и сколько приёмов состоялось. Когортное следует за группой обращений, созданных в выбранное время, до их последующих результатов. Июльский приём по июньской заявке принадлежит июлю в календаре посещений и июньской группе в анализе обращений. Это согласованные разные ответы.

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

План внедрения на 30 дней

Дни 1–5: описать действующий процесс

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

Дни 6–10: согласовать данные и правила

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

Дни 11–17: настроить ограниченный обмен

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

Дни 18–24: пройти приёмку и сверку

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

Дни 25–30: запустить управляемый пилот

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

Частые вопросы

Можно ли обойтись без отдельной CRM?

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

Нужно ли добиваться совпадения всех чисел с веб-аналитикой?

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

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

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

Что делать при смене МИС или CRM?

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

Можно ли сразу передавать визиты в оптимизацию рекламы?

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

Чек-лист перед запуском

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

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

Источники и актуальность

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