В 11:42 пациент заполняет форму на сайте клиники. Страница благодарит его и обещает звонок. В аналитике появляется конверсия. Маркетолог видит зелёный отчёт.
Но в регистратуре никто ничего не видит. Письмо попало в спам, webhook получил ошибку, CRM создала дубль без ответственного, а уведомление ушло сотруднику, который сегодня не работает. Вечером руководитель скажет: «Заявок мало». Пациент решит, что клинике неинтересен.
Сайт при этом действительно работал. Он открывался, форма нажималась, реклама списывала деньги. Не работал маршрут после кнопки.
Потеря заявки редко происходит в одном месте. Это цепочка из десяти маленьких переходов: браузер, форма, сервер, интеграция, очередь, сотрудник, звонок, расписание, подтверждение и состоявшийся визит. Если клиника измеряет только первый и последний, всё между ними превращается в догадки.
«Форма отправлена» — ещё не заявка в работе
Для пациента заявка существует, когда он получил ожидаемую помощь: клиника увидела обращение, связалась по согласованному каналу и предложила следующий шаг. Для системы полезно разделить состояния:
- форма принята сайтом;
- создан уникальный идентификатор;
- данные прошли техническую проверку;
- событие доставлено в целевую систему;
- заявка появилась в рабочей очереди;
- назначен ответственный;
- сотрудник начал обработку;
- контакт состоялся или попытка зафиксирована;
- результат классифицирован;
- запись создана и подтверждена;
- визит состоялся либо маршрут закрыт иной причиной.
Каждый переход имеет время и результат. Тогда фраза «потерялась заявка» превращается в точное наблюдение: «сайт принял обращение, но CRM не подтвердила доставку» или «задача создана, но осталась без владельца 37 минут».
Один идентификатор связывает весь маршрут
Без общего ID маркетолог видит событие формы, CRM — карточку, телефония — звонок, а МИС — запись. Никто не может доказать, что это один человек и один маршрут, не склеивая данные вручную.
При создании обращения генерируется технический идентификатор, который безопасно проходит через интеграцию, рабочую очередь и итоговый статус. Он не должен содержать телефон, фамилию, диагноз или другой персональный смысл.
Примером может быть случайная строка или UUID. В журналах достаточно ID, времени, типа события, версии формы, результата доставки и кода ошибки. Содержание полей хранится только там, где оно необходимо и защищено.
Этот принцип даёт важную возможность: проверить маршрут на синтетической заявке, не используя реальные данные пациента.
Где именно пропадают обращения
Составьте карту каналов. Помимо формы на сайте это могут быть:
- нажатие на номер телефона;
- входящий звонок;
- пропущенный звонок;
- чат или мессенджер;
- виджет обратного звонка;
- онлайн-запись;
- письмо;
- агрегатор;
- рекламная форма внутри площадки;
- обращение из карточки организации;
- рекомендация врача;
- повторный контакт старого пациента.
У каждого канала свой транспорт и владелец. Ошибка формы не похожа на переполненную очередь звонков, а неработающий callback — на заявку из агрегатора без филиала.
Начните с одного канала и пройдите его целиком. Массовая карта полезна позже, когда понятен способ проверки.
Форма может красиво врать
Сообщение «Спасибо, заявка отправлена» иногда появляется до подтверждения сервера. JavaScript очистил поля, аналитика записала событие, но запрос не дошёл. Пользователь уверен, что всё сделано.
Правильная форма различает:
- локальную проверку полей;
- приём сервером;
- создание обращения;
- техническую доставку дальше;
- понятную ошибку и возможность повторить.
Не нужно рассказывать пациенту внутреннюю архитектуру. Но нельзя обещать звонок, если сервер не подтвердил приём. При ошибке страница сохраняет введённое в допустимых пределах, предлагает безопасный альтернативный канал и не создаёт бесконечные дубли от повторных нажатий.
Проверяйте форму в обычном и мобильном браузере, с медленным соединением, блокировщиком, истёкшей сессией и повторной отправкой. Тест только на ноутбуке разработчика почти ничего не доказывает.
Письмо на общую почту — не очередь
Небольшая клиника часто начинает с отправки формы на адрес администратора. Пока писем мало, схема кажется достаточной. Затем появляется спам-фильтр, отпуск, правило сортировки, переполненный ящик и спор «я думал, ответит коллега».
Почта может быть дополнительным уведомлением, но у рабочей очереди должны быть:
- уникальная карточка;
- статус;
- время поступления;
- владелец;
- крайний срок реакции;
- история попыток;
- причина закрытия;
- защита от двойной обработки;
- эскалация при ожидании.
Если CRM слишком велика для текущего масштаба, минимальную очередь можно реализовать проще. Но таблица без блокировки строк, ролей и журнала быстро станет новой почтой.
Webhook должен уметь ошибаться
Интеграции редко работают идеально всегда. Целевая система может быть недоступна, отвечать медленно, вернуть временную ошибку или принять запрос, но не отдать подтверждение.
Надёжная доставка предусматривает:
- ограниченный тайм-аут;
- повтор с увеличивающимся интервалом;
- максимальное число попыток;
- очередь недоставленных событий;
- идемпотентный ключ;
- журнал без лишних персональных данных;
- сигнал ответственному;
- возможность безопасно повторить после исправления.
Идемпотентность означает, что повтор одного события не создаёт две заявки. Это особенно важно, когда пациент повторно нажал кнопку, браузер повторил запрос или интеграция не получила ответ.
Нельзя считать HTTP 200 полным успехом, если целевая система просто приняла пакет в промежуточную очередь. Определите, какое подтверждение действительно доказывает появление задачи у регистратора.
Ошибка должна иметь владельца, а не только лог
Лог delivery_failed полезен инженеру, но не перезвонит пациенту. Для каждого типа ошибки нужен маршрут:
- кто получает уведомление;
- через сколько минут;
- что проверяет;
- как создаёт ручную задачу;
- как не дублирует уже обработанное;
- кто информирует руководителя;
- когда инцидент закрывается.
Если webhook недоступен, сайт может сохранить событие в локальной очереди и повторить доставку. Если очередь переполнилась, включается резервный канал. Если данные невозможно восстановить, клиника честно фиксирует границы инцидента и не выдумывает число потерянных обращений.
Алерт без дежурного получателя — всего лишь ещё одно письмо.
Рабочее время сайта и рабочее время команды — не одно и то же
Форма доступна круглосуточно. Регистратура может работать по расписанию. Пациент должен понимать, когда ждать ответ, а система — учитывать календарь.
Для каждого канала определите:
- часы обработки;
- праздники и исключения;
- допустимое время первого ответа;
- что показывается вне рабочего времени;
- куда попадает заявка ночью;
- кто открывает очередь утром;
- когда начинается отсчёт SLA;
- как эскалируется просрочка.
Не обещайте «перезвоним за минуту», если вечером никто не дежурит. Честное «свяжемся завтра с 9:00» полезнее автоматического обещания.
SLA без владельца не работает
Можно установить цель «ответить за пять минут», но она ничего не изменит, если задача не назначается. В каждый момент у заявки должен быть один текущий владелец и понятная следующая операция.
Полезные состояния:
- новая;
- назначена;
- в работе;
- попытка связи;
- ожидается ответ пациента;
- ожидается медицинское уточнение;
- предложено время;
- запись подтверждена;
- отказ;
- неверный контакт;
- дубль;
- закрыта с причиной.
Статус «обработано» слишком широк. Он может означать успешную запись, один безответный звонок или простое открытие карточки.
Очередь должна показывать следующий шаг
Администратор открывает карточку и должен сразу понимать:
- откуда пришло обращение;
- когда;
- что человек просил;
- каким каналом допустимо связаться;
- какой филиал или направление выбрано;
- была ли попытка;
- что делать сейчас;
- когда задача станет просроченной;
- куда передать медицинский вопрос.
Не нужно показывать весь рекламный профиль и лишние медицинские сведения. Контекст минимален и достаточен для организационного действия.
Хороший интерфейс не заставляет держать очередь в голове. После звонка сотрудник выбирает результат и время следующего шага, а не оставляет свободный комментарий «не дозвонился» без продолжения.
Пропущенный звонок тоже заявка
Пациент может не заполнять форму, а просто позвонить. Если все линии заняты или звонок завершился до ответа, событие должно попасть в управляемую очередь.
Для каждого пропущенного звонка полезно знать:
- время;
- номер линии или кампании;
- филиал;
- длительность ожидания;
- был ли повторный звонок;
- связался ли пациент позже сам;
- создана ли единая карточка;
- кто и когда перезвонил;
- чем завершился маршрут.
Не звоните несколько раз от разных сотрудников. Дедупликация связывает события по допустимым признакам и временным окнам, сохраняя возможность ручной проверки.
Почему дешёвая телефония часто теряет не стоимость минуты, а возможность управлять очередью, подробно разобрано в статье о дорогой «дешёвой» телефонии.
Коллтрекинг не должен ломать обратный звонок
Подменные номера помогают связывать рекламный источник и звонок, но добавляют зависимость. Номер может быть недоступен, закрепиться за неправильной сессией, истечь или передать в CRM некорректный источник.
Проверьте:
- стабильность пула;
- маршрут при исчерпании номеров;
- отображаемый номер при исходящем звонке;
- запись согласованного источника;
- поведение при прямом повторном звонке;
- работу с несколькими филиалами;
- экспорт истории при смене подрядчика;
- отсутствие чувствительных данных в рекламной системе.
Атрибуция полезна, но не важнее связи. Если ради идеального источника пациент не может дозвониться, система решает не ту задачу.
Дубли: удалять нельзя, объединять автоматически опасно
Один человек может заполнить форму, позвонить и написать в чат. Три заявки не означают трёх пациентов. Но автоматическое объединение по телефону тоже может ошибиться: номер бывает семейным, корпоративным или уже принадлежит другому человеку.
Безопасная дедупликация:
- связывает технические события в одну предполагаемую цепочку;
- не сливает медицинские карты без установленной процедуры;
- сохраняет источники и время;
- показывает сотруднику возможное совпадение;
- позволяет отклонить связь;
- не скрывает повторное обращение, если у него новый смысл.
Задача CRM — уменьшить параллельные звонки, а не незаметно переписать идентичность пациента.
Минимальная форма обычно сильнее длинной анкеты
Чем больше полей, тем больше данных клиника должна обосновать, защитить, передать и поддерживать. Для первого контакта часто достаточно имени или предпочитаемого обращения, канала связи, общего направления и удобного времени.
Не просите в публичной форме подробно описывать диагноз, прикладывать исследования или вводить паспортные данные, если это не требуется для конкретного законного процесса. Публичная форма не заменяет защищённый медицинский канал.
Для каждого поля ответьте:
- зачем оно нужно именно сейчас;
- кто увидит;
- куда передаётся;
- как долго хранится;
- что произойдёт без него;
- можно ли заменить менее чувствительным вариантом.
Текст согласия, политика и фактический маршрут данных должны совпадать. Проверку выполняют ответственный за данные и юрист.
Защита от спама не должна блокировать пациентов молча
CAPTCHA, rate limit и антибот-фильтр необходимы, но могут отбрасывать людей с особенностями браузера, VPN, медленным соединением или нетипичным поведением.
Контролируйте:
- долю отклонённых запросов;
- причины;
- доступность формы с клавиатуры и мобильного устройства;
- понятность ошибки;
- резервный телефон;
- возможность повторить без потери полей;
- ложные срабатывания после обновления правил.
Если антиспам блокирует событие до создания ID, маркетинговая аналитика может ничего не показать. Нужна агрегированная техническая метрика без сохранения запрещённого содержимого.
Синтетическая заявка — главный ежедневный тест
Проверка доступности страницы не доказывает, что маршрут работает. Создайте отдельный безопасный сценарий с явно синтетическими данными и меткой, исключённой из коммерческой аналитики.
Тест проходит:
- открытие страницы;
- отправку формы;
- серверное подтверждение;
- интеграцию;
- появление в очереди;
- назначение тестовому владельцу;
- перевод статуса;
- закрытие без реального звонка.
Он не должен использовать реальные телефоны пациентов, создавать запись в медицинской карте или запускать рекламную коммуникацию. Частота зависит от риска и архитектуры; ежедневный end‑to‑end тест часто полезнее сотни проверок одного URL.
Мониторинг должен видеть задержку, а не только отказ
Интеграция может не упасть, а замедлиться. Заявка придёт через сорок минут, когда пациент уже записался в другом месте. Поэтому измеряйте распределение времени по этапам:
- браузер → сервер;
- сервер → CRM;
- CRM → очередь;
- очередь → назначение;
- назначение → первая попытка;
- попытка → состоявшийся контакт;
- контакт → запись.
Среднее скрывает редкие длинные хвосты. Смотрите медиану, высокие перцентили и количество заявок старше порога. Порог задаётся реальным обещанием клиники и рабочим календарём, а не универсальным числом из маркетинговой статьи.
Не каждый быстрый звонок полезен
Сотрудник может позвонить через минуту и не знать, о чём просил человек. Или звонить во время, которое пациент отметил как неудобное. Формально SLA выполнен, фактически доверие потеряно.
Качество первого контакта включает:
- корректное представление клиники;
- проверку, удобно ли говорить;
- понимание исходного запроса;
- отсутствие медицинской импровизации;
- предложение выполнимого следующего шага;
- фиксацию результата;
- уважение к отказу;
- безопасную передачу врачу при необходимости.
Поэтому скорость — одна метрика, не вся цель.
Сайт, CRM и МИС не должны иметь три правды
Сайт может показывать услугу и филиал, CRM — маркетинговую заявку, а МИС — расписание. Нужно определить систему-источник для каждого факта:
- услуга и публичное описание;
- актуальная цена;
- филиал;
- график;
- статус заявки;
- медицинская запись;
- согласие на коммуникацию;
- состоявшийся визит.
Интеграция передаёт данные, но не делает все системы одинаковыми. CRM не должна становиться медицинской картой, а аналитика — источником расписания.
Если цены на сайте и в рабочей системе расходятся, администратор начинает разговор с оправдания. Отдельный разбор есть в статье о несовпадающих ценах клиники.
Онлайн-запись — отдельный маршрут
Форма «перезвоните мне» создаёт задачу человеку. Онлайн-запись должна проверить реальный слот, ресурсы, длительность и правила подтверждения. Нельзя оценивать их одинаково.
Для онлайн-записи дополнительно проверяют:
- блокировку слота на время операции;
- конкурентное бронирование;
- часовой пояс;
- подтверждение;
- отмену и перенос;
- возврат слота;
- связь с листом ожидания;
- ограничения специальности и ресурса;
- сбой после оплаты, если она предусмотрена.
Почему сам виджет не создаёт загрузку, подробно показано в статье об онлайн-записи и свободных окнах.
Заявка после рекламы и заявка от старого пациента требуют разного контекста
Новый человек может впервые знакомиться с клиникой. Старый — продолжать начатый маршрут. Скрипт и допустимые данные различаются.
Не смешивайте в одну очередь:
- первичный рекламный интерес;
- сервисный вопрос;
- отмену без переноса;
- медицинский вопрос;
- жалобу;
- запрос документов;
- повторное обращение после рекомендации врача.
У каждой категории владелец и SLA. Правила бережного повторного контакта разобраны в статье о возврате старых пациентов без спама.
Что делать, если сотрудник занят пациентом у стойки
Регистратор не может одновременно спокойно обслуживать человека перед собой, отвечать на звонок, чат и новую форму. Требование «берите всё сразу» создаёт поверхностное обслуживание в каждом канале.
Очередь должна учитывать реальную пропускную способность:
- звонок маршрутизируется на свободного сотрудника;
- форма создаёт задачу с понятным сроком;
- чат имеет ограничение числа диалогов;
- просрочка эскалируется второму сотруднику;
- руководитель видит перегрузку;
- вне пика разбираются причины, а не только результат.
Иногда клинике нужен второй администратор, иногда — другое расписание смен, иногда — автоматическое подтверждение приёма заявки без ложного обещания мгновенного звонка.
Ручной резервный маршрут
Если CRM недоступна, заявки не должны исчезать в личных блокнотах. Подготовьте контролируемый резерв:
- временный журнал с уникальными ID;
- ограниченные поля;
- один владелец;
- время начала и окончания аварийного режима;
- защищённое место хранения;
- порядок обратного переноса;
- проверка дублей;
- уничтожение временной копии после подтверждения миграции.
Резервный журнал не превращается в постоянную параллельную базу. После восстановления две системы сверяют по ID и времени, а координатор подтверждает, что ни одна задача не осталась только на бумаге.
Составной сценарий: реклама работала лучше, чем казалось
Следующий пример — иллюстративный составной сценарий, не описание конкретной клиники и не обещание типичной конверсии.
Руководитель видел дорогие заявки и слабую запись. Маркетолог предложил сменить рекламу. Перед решением команда отправила серию синтетических форм в разные часы.
Днём заявки попадали в CRM почти сразу. Но после перерыва они создавались без филиала, потому что справочник формы и CRM расходился. Автораспределение не находило группу, карточки оставались в общей очереди. Сотрудники видели их только вечером.
Команда исправила сопоставление справочника, добавила quarantine-очередь для неизвестного филиала и алерт при отсутствии владельца. Рекламу не меняли до повторного измерения.
Главная находка была не в маркетинге. Клиника платила за интерес, который сама оставляла без ответа.
Как расследовать потерю одной заявки
Не ищите фамилию по всем системам. Используйте технический ID и временную линию:
- событие браузера;
- серверный запрос;
- создание записи;
- попытки доставки;
- подтверждение CRM;
- назначение;
- действия сотрудника;
- звонки и сообщения;
- создание записи в расписании;
- итоговый статус.
Для каждого шага есть timestamp, система и результат. Если участок не журналируется, это отдельный gap. Журналы предоставляют только уполномоченным сотрудникам и не копируют без необходимости.
После расследования исправляют не только конкретную карточку, но и условие: справочник, тайм-аут, отсутствие владельца, обучение или интерфейс.
Метрики без красивой лжи
Разделите показатели на три слоя.
Техническая доставка
- доля серверно принятых форм;
- успешная доставка в очередь;
- задержка интеграции;
- повторы и dead-letter;
- дубли;
- ошибки по версии формы.
Работа команды
- время до назначения;
- время до первой осмысленной попытки;
- количество попыток;
- просрочки;
- задачи без владельца;
- доля корректно классифицированных результатов.
Результат пациента
- состоявшийся контакт;
- предложенный выполнимый следующий шаг;
- созданная и подтверждённая запись;
- состоявшийся визит;
- отказ и его корректная причина;
- жалобы и просьбы прекратить связь.
«Конверсия формы» относится только к интерфейсу. Она не доказывает работу клиники.
Дашборд должен показывать исключения
Общая цифра заявок успокаивает. Рабочий экран показывает то, что требует действия:
- заявки без владельца;
- превышение срока;
- сбой канала;
- рост дублей;
- неизвестный филиал;
- повторная ошибка контакта;
- очередь после нерабочего времени;
- незакрытые медицинские вопросы;
- отсутствие доступных слотов.
Каждый вид исключения имеет владельца и runbook. Если дашборд только краснеет, но никто не знает, что делать, это декоративный мониторинг.
Пятнадцать проверок перед запуском рекламы
Перед увеличением бюджета подтвердите:
- форма создаёт серверный ID;
- сообщение об успехе появляется после подтверждения;
- повторная отправка не создаёт неконтролируемый дубль;
- webhook повторяет временные ошибки;
- недоставленные события видны;
- CRM подтверждает появление в рабочей очереди;
- у новой заявки появляется владелец;
- календарь рабочих часов настроен;
- просрочка эскалируется;
- телефония связывает обратный звонок с карточкой;
- сотрудник видит минимальный достаточный контекст;
- медицинский вопрос передаётся врачу;
- отказ прекращает недопустимую коммуникацию;
- синтетический end-to-end тест проходит;
- итоговая запись подтверждается в правильной системе.
Если тест ломается, сначала почините маршрут. Дополнительный трафик лишь увеличит очередь ошибок.
FAQ
Почему аналитика показывает заявку, а CRM её не видит?
Событие аналитики часто фиксирует нажатие или локальный успех формы, а не серверную доставку. Нужен единый ID и подтверждение каждого этапа до рабочей очереди.
Достаточно ли отправлять заявки на электронную почту?
Для небольшого временного процесса почта может быть уведомлением, но она плохо управляет владельцем, сроком, дублями и результатом. Рабочая очередь должна иметь статусы и эскалацию.
За сколько минут клиника должна перезвонить?
Универсального числа нет. Обещание зависит от часов работы, канала и мощности команды. Важно публиковать реалистичный срок, измерять длинные задержки и обеспечивать качественный ответ.
Как тестировать форму без реальных данных?
Создать явно синтетический профиль, отдельную метку и сценарий, который проходит до тестовой очереди, но не создаёт медицинскую карту и не запускает реальный звонок или рекламу.
Что делать с несколькими обращениями одного человека?
Связать технические события в предполагаемый маршрут и передать сотруднику на проверку. Нельзя автоматически объединять медицинские карты только по номеру телефона.
Нужно ли менять CRM, если заявки теряются?
Не обязательно. Сначала локализуйте этап: форма, доставка, справочник, назначение, интерфейс или работа смены. Новая CRM воспроизведёт неясный процесс, если не изменить правила.
Что сделать завтра
Отправьте пять синтетических заявок: утром, в пик, в перерыв, перед закрытием и после рабочего времени. Каждая получает уникальный технический ID и безопасный тестовый контакт, который не принадлежит пациенту.
Засеките время каждого перехода до тестовой рабочей очереди. Попросите администратора объяснить, что он видит, какой следующий шаг и когда задача станет просроченной. Затем отключите один промежуточный сервис на стенде или в контролируемом тесте и убедитесь, что событие не исчезает молча.
Первый найденный разрыв не маскируйте новым уведомлением. Назначьте владельца, исправьте переход и повторите те же пять сценариев. Так клиника перестаёт верить зелёной кнопке и начинает управлять реальным пациентским маршрутом.
Материал носит информационный характер и не заменяет юридическое заключение, проект защиты персональных данных или техническое обследование конкретной инфраструктуры. Формы, согласия, записи разговоров, сроки хранения, каналы связи и интеграции необходимо проверять по действующим требованиям и документам клиники. Используйте синтетические данные; не переносите реальные обращения в публичные логи, личные таблицы и незащищённые сервисы.
