Заявка приходит и выглядит как новая. На деле этот человек уже работает с вами год. Менеджер этого не видит и начинает продавать как первому встречному: рассказывает то, что клиент давно знает, ведёт по сценарию холодной заявки. Клиент чувствует, что его не узнали.
Мы сделали робота, который сверяет каждый новый лид с базой контактов по телефону и почте. Если это действующий клиент, робот ставит метку "существующий клиент" - и дальше лид идёт в допродажи, а не в первую продажу. Робот ставится на отдел продаж в Битрикс24 или другой CRM.
Что было до
Без метки отдел продаж путает своих и чужих. Действующему клиенту продают как новому: тратят раунд на то, что он и так знает, иногда повторяют то, за что он уже заплатил.
Страдает и отчётность. Заявки от своих смешиваются с новым притоком - руководитель смотрит на цифру лидов и не понимает, сколько среди них настоящих новых клиентов, а сколько повторных обращений базы.
И маршрутизация. Лид от действующего клиента должен уходить на допродажи к тому, кто его ведёт, а не в общую воронку первой продажи. Без метки он попадает не туда.
Как это работает
Робот берёт у нового лида телефон и почту и ищет совпадение в базе контактов. Нашёл действующего клиента - ставит на лиде метку "существующий клиент".
Метка ставится осторожно. Робот выставляет только значение "да" и только по чистому номеру. Заглушки и мусорные номера он отсекает - чтобы по битому телефону не приклеить чужую метку и не отправить нового человека в допродажи как старого знакомого. Если уверенности нет, метки нет.
Дальше метку читают два механизма. Маршрутизация уводит помеченный лид на допродажи. Отчёт по новым заявкам исключает помеченных, чтобы показывать реальный новый приток. Вся сверка идёт внутри вашего Битрикса - данные не уезжают за ваш контур.
Техническая сторона
Дальше - как это устроено внутри. Именно эти детали и есть доказательство, что робот работает, а не рисуется на слайде.
- →Стек. Python на стандартной библиотеке, без внешних зависимостей. Робот - таймер systemd на сервере: забирает свежие лиды через REST Битрикс24, проверяет совпадение и пишет метку обратно.
- →Поиск совпадения. Телефон и почта лида ищутся в базе контактов штатным поиском дублей Битрикса по средствам связи. Нашлось совпадение с контактом - лид считается обращением действующего клиента.
- →Чистый номер против заглушки. Метка ставится только по нормальному номеру. Заглушки и мусорные номера отсекаются на входе - такой предохранитель нужен, потому что по битому телефону легко поймать ложное совпадение и пометить нового человека как своего. Робот ставит только "да": если совпадения нет, поле он не трогает.
- →Метка работает дальше. Значение "существующий клиент" - вход для двух механизмов: маршрутизации на допродажи и отчёта по новым заявкам, который своих в новый приток не считает.
- →Данные остаются у вас. Сверка телефона и почты идёт внутри вашего Битрикса, на вашем сервере. Данные клиента дальше этого контура не уезжают. По закону о персональных данных это снимает вопрос ещё на входе.
- →Тихая запись. Метка пишется без события в живой ленте, чтобы не дёргать команду лишним уведомлением на каждый узнанный лид.
Что это даёт
Действующий клиент сразу попадает в нужный сценарий: его ведут на допродажу, а не продают с нуля то, что он уже купил. Менеджер видит, с кем говорит, до первого слова.
Отчёт по новым заявкам очищается от своих и показывает реальный новый приток - руководитель смотрит на честную цифру. Маршрутизация уводит повторное обращение туда, где его ждут.
