Один пациент — одна карточка: звучит очевидно, но на практике база быстро обрастает дублями. Клиент звонил с рабочего номера, потом с личного, администратор записал имя с опечаткой — и вот в CRM уже три записи на одного человека. История приёмов раскидана, аналитика врёт, робот при звонке не понимает, знакомый это клиент или новый. Дедупликация решает это: бот сопоставляет входящий звонок с существующей карточкой и заводит новую только тогда, когда совпадения действительно нет.
Дедупликация карточек — это автоматическое сопоставление входящего звонка с уже существующей карточкой пациента, чтобы система не создавала вторую запись на того же человека. Бот сначала ищет совпадение по номеру телефона, имени и дате рождения, и только при отсутствии надёжного совпадения заводит новую карточку. Так база пациентов остаётся чистой и без дублей.
Проблема не в том, что дубль появляется однажды. Он размножается: при каждом новом контакте система снова не узнаёт человека и плодит ещё одну запись.
Разберём, как бот сопоставляет звонок с карточкой, где проходит порог уверенности и что происходит в спорных случаях.
Дубль карточки — это не косметический беспорядок, а потеря данных: история приёмов, аллергии, прошлые обращения раскидываются по нескольким записям, и в каждой видна только часть. По разным оценкам, доля дублей в запущенной клиентской базе достигает 10–15%, а разбор такого хаоса вручную занимает недели работы администраторов.
Врач, открывший неполную карточку, не увидит, что пациент уже был на приёме. Администратор перезвонит по старому номеру. Аналитик посчитает одного человека как трёх новых.
Чем дольше база живёт без дедупликации, тем дороже потом наводить порядок — количество дублей растёт нелинейно.
Когда поступает звонок, бот не создаёт карточку сразу — он сначала ищет пациента в базе. Поиск идёт по нескольким признакам: номеру телефона, имени, дате рождения. Если находится совпадение с высокой уверенностью, бот работает с существующей карточкой; если нет — предлагает завести новую. Порядок «сначала найти, потом создать» и есть суть дедупликации.
Этот поиск происходит за доли секунды в момент звонка, ещё до приветствия. Пациент не замечает проверки — он просто слышит, что его узнали.
Как робот подтягивает историю и узнаёт вернувшегося клиента, подробно разобрано в материале про как бот помнит клиента.
Номер телефона — самый надёжный признак сопоставления: он уникален и почти всегда приходит вместе со звонком через определитель номера. Поэтому бот в первую очередь ищет карточку именно по телефону в базе, ещё до начала разговора. Совпадение номера даёт наибольшую уверенность, что звонит именно этот пациент, а не случайный однофамилец из соседнего района.
Но телефон не идеален как единственный ключ. Один номер бывает у всей семьи, пациенты меняют симки, а корпоративный номер регистратуры родственника ломает картину.
Поэтому телефон — первый, но не единственный признак: при неоднозначности бот подключает имя и дату рождения, чтобы не слить разных людей в одну карточку.
Когда телефона недостаточно или он совпал у нескольких людей, в ход идёт связка «фамилия, имя, отчество плюс дата рождения». Эта пара сильна тем, что дата рождения надёжно отсекает однофамильцев: двух Ивановых Иванов легко различить по разным датам. Комбинация ФИО и даты рождения — классический ключ идентификации пациента в медицинских системах.
Дату рождения бот уточняет голосом, если её нет в базе: короткий вопрос снимает неоднозначность между похожими карточками.
Само по себе ФИО без даты рождения — слабый ключ: тёзки встречаются чаще, чем кажется, особенно в крупной городской клинике.
Имена редко пишут одинаково: «Наталья» и «Наталия», «Алёна» и «Алена», опечатка в фамилии, пропущенная или лишняя буква. Точное посимвольное сравнение строк такие карточки не свяжет, поэтому бот применяет нечёткое совпадение — оценку похожести, которая прощает мелкие расхождения. «Иванов» и «Ивонов» система при этом распознаёт как вероятно одного и того же человека.
Нечёткий матчинг учитывает частые вариации: сокращения имён, латиница вместо кириллицы, перестановка имени и отчества, лишние пробелы.
Без такой гибкости дедупликация ловила бы только идеальные совпадения и пропускала бы большую часть реальных дублей, где виновата обычная опечатка.
Каждому потенциальному совпадению бот присваивает числовую оценку уверенности, и итоговое решение зависит от заданного порога. Высокая уверенность — работаем с найденной карточкой. Низкая — заводим новую. Средняя, «серая зона» — спорный случай, который отдаётся живому человеку. Порог настраивают так, чтобы не сливать разных людей и не плодить лишние дубли.
Порог — это баланс двух ошибок. Слишком мягкий склеит двух разных пациентов; слишком жёсткий не узнает своего и создаст дубль.
Для медицинской базы безопаснее смещать порог в сторону осторожности: лучше уточнить у человека, чем ошибочно объединить две карточки с чужими диагнозами.
По итогу поиска у бота три исхода: связать звонок с существующей карточкой, создать новую или передать спорный случай оператору. Уверенное совпадение ведёт к работе с найденной записью, явное отсутствие — к созданию новой. Автоматического слияния двух уже существующих карточек бот обычно не делает — это ответственная операция.
Разница важна: «создать новую» — обратимая мелочь, а «слить две карточки» — потенциально необратимое действие с чужими данными внутри.
Поэтому робот скорее эскалирует сомнение, чем рискнёт объединить записи без подтверждения человека.
Главная потеря от дубля — разорванная история пациента. Человек лечился полгода, но половина визитов ушла в одну карточку, а половина — в другую, и ни в одной нет полной картины. Врач видит лишь фрагмент, а пропущенные назначения и аллергии остаются невидимыми. Это уже не про удобство, а про качество помощи.
Теряется и контекст общения: робот, открывший пустой дубль, встречает постоянного пациента как незнакомца и заново спрашивает то, что уже известно.
Единая карточка, наоборот, даёт полный контекст — и врачу, и роботу, и администратору, который ведёт запись.
Когда один человек размножен в трёх карточках, аналитика послушно считает его тремя разными пациентами. Раздувается число «новых» клиентов, искажается доля повторных обращений, ломается весь расчёт удержания постоянных пациентов. По грубой оценке, база с 15% дублей даёт отчёты с двузначной погрешностью — и решения принимаются на заведомо кривых цифрах.
Особенно страдает маркетинг: возврат клиента засчитывается как новый лид, стоимость привлечения выглядит хуже реальной, каналы оцениваются неверно.
Как звонки и записи собираются в корректные метрики, показано в материале про сквозную аналитику.
Когда уверенность попадает в серую зону, бот не угадывает, а передаёт случай администратору с пометкой «возможен дубль» и данными обеих карточек. Человек смотрит и решает: тот же это пациент или разные. Такая эскалация превращает сомнение бота в контролируемое решение, а не в тихую ошибку в базе.
Это тот же принцип, что и с медицинскими вопросами: там, где цена ошибки высока, робот привлекает человека, а не действует наугад.
Как правильно построить передачу от бота к сотрудникам, разобрано в материале про эскалацию с бота на регистратуру.
Перед сравнением данные приводят к единому виду — это нормализация. Телефон очищается от скобок, пробелов и разных префиксов: «8», «+7», «7» превращаются в один формат. Имена приводятся к нижнему регистру, убираются лишние пробелы, ё и е выравниваются. Без этого шага одинаковые по сути данные выглядели бы разными.
Нормализация — незаметный, но решающий этап: половина «неуловимых» дублей возникает именно из-за разного формата записи одного и того же номера.
Единый формат хранения телефонов заодно упрощает и обратный обзвон, и отправку уведомлений пациенту.
Если дубли уже накопились, их сливают — но делают это аккуратно, сохраняя данные из обеих записей. При слиянии история приёмов, контакты и заметки объединяются, а не затираются: цель — собрать полную карточку, ничего не потеряв по дороге. Операцию обязательно логируют, чтобы при ошибке можно было понять, что и с чем объединили.
Слияние — редкая и ответственная операция, поэтому его обычно доверяют человеку или подтверждают вручную, а не автоматизируют полностью.
Чтобы объединённые данные корректно доехали до CRM, важна надёжная двусторонняя синхронизация записей между роботом и системой.
В сети филиалов задача заметно усложняется: пациент был в одном центре, а потом позвонил в другой. Если базы разрознены и не связаны, он станет новым пациентом в каждой точке сети. Единая база с общей дедупликацией узнаёт человека независимо от филиала, куда он обратился, и хранит одну карточку на всю сеть.
При этом дедупликация уживается с разграничением доступа: карточка одна, но филиал видит только свою часть данных, а не всё подряд.
Такой подход экономит и время: пациенту не приходится заново диктовать данные при обращении в соседний центр сети.
Проверка проста: сделайте два звонка от имени одного «пациента» — с одинаковыми данными и с лёгкой опечаткой в имени. Бот должен во втором случае узнать существующую карточку, а не создать вторую. Затем позвоните с новыми данными: тут, наоборот, должна появиться новая запись. Так тестируется и матчинг, и порог.
Стоит проверить и серую зону — данные, похожие, но не идентичные: убедитесь, что сомнительный случай уходит на человека, а не решается втихую.
Такой мини-тест занимает 10 минут и сразу показывает, настроена ли дедупликация под вашу базу.
Начните с оценки масштаба проблемы: выгрузите базу и прикиньте долю дублей по совпадающим телефонам, именам и датам рождения. Затем задайте чёткие правила сопоставления — какие признаки и с каким порогом считать совпадением. Настройте эскалацию спорных случаев на дежурного администратора и только после этого запускайте автоматическое создание карточек роботом.
Уже накопленные дубли разбирайте отдельным разовым проходом со слиянием, а робота настройте так, чтобы новые не появлялись.
Проверить, как робот сопоставляет звонки и не плодит дубли на вашей базе, можно бесплатно 7 дней без карты — подключение занимает около 15 минут.
7 дней бесплатно, без карты. Подключение к вашему номеру за 15 минут.