Запись в расписание при нестабильном интернете

Чем опасен обрыв связи при записи

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

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

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

Разделение звонка и синхронизации с CRM

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

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

Такое разделение — базовая защита от того, чтобы сетевая икота превратилась в потерянного пациента.

Очередь синхронизации и оффлайн-буфер

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

Буфер держит записи минутами и часами при нужде, поэтому даже долгий обрыв не приводит к потере ни одной брони.

Защита от задвоения при повторной отправке

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

Без идемпотентности любой ретрай при плохой связи плодил бы двойные записи — здесь этого не происходит по построению.

Пациент в итоге записан ровно один раз, независимо от того, сколько раз сеть подводила во время разговора.

Что видит пациент и администратор

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

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

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

Порядок и целостность отложенных записей

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

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

Целостность важнее скорости: лучше применить накопленное на секунду позже, но в верной последовательности, чем быстро и вразнобой.

Мониторинг канала и сигнал администратору

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

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

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

Что будет при полном пропадании сети

Короткий обрыв робот переживает буфером незаметно. Но что если сеть пропала надолго — на минуты? Тогда робот продолжает вести разговоры и накапливать подтверждённые записи в очереди, а досылает их все разом, как только канал вернётся. Ни один разговор не отменяется из-за того, что CRM временно недоступна.

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

Даже в худшем случае — без обоих каналов — записи не теряются, а ждут в очереди и приземляются в расписание после восстановления, сохранив порядок и не создав повторов.

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

Надёжность как условие доверия к роботу

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

Клиникам с плохим интернетом эта архитектура важнее любых голосовых красот: без неё робот терял бы пациентов на каждом обрыве. О типичных промахах внедрения — в материале про ошибки при внедрении бота.

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

Надёжность при плохом канале — это конкретные числа: при обрывах по несколько раз в час потери записей стремятся к нулю, отложенные брони приземляются в расписание за 2-3 секунды после возврата связи, а буфер держит их часами при затяжном сбое. Подключение занимает около 15 минут, а 7 дней бесплатного периода позволяют проверить устойчивость именно на своём нестабильном интернете, прежде чем клиника доверит роботу запись без ручной подстраховки на случай пропадания сети.