Интеграции
Один заказ, два звонка: почему появляются дубли
Покупатель звонит Лене, руководителю оптового отдела, не ради срока доставки, а чтобы понять, сколько заказов у него получилось. Первый менеджер уже подтвердил заявку. Второй только что спросил всё заново. «Я отправлял один», — говорит покупатель. Лена открывает CRM и видит две карточки.
Возьмём эту ситуацию как иллюстрацию. В обеих карточках похожий состав заказа и один и тот же номер телефона. Менеджеры не сговорились звонить по очереди: каждому досталась своя рабочая задача. Лене предстоит понять, откуда взялась вторая.
О чём эта история
Две карточки из одной отправки
Лена сначала спрашивает менеджеров, кто создал карточки. Оба отвечают: заказ пришёл с сайта. На сайте покупатель заполнил форму и нажал отправку один раз. В каждой карточке уже есть запись о разговоре. CRM здесь — рабочая программа, где отдел ведёт заявки и звонки. Отдел продаж честно исполнил две задачи, хотя покупатель просил об одной.
В этой истории передача с сайта задержалась. Сайт не получил вовремя понятного ответа и отправил тот же запрос ещё раз. CRM приняла обе попытки как новые. Это один из возможных путей появления дубля, не диагноз для любой пары похожих карточек. Повтор мог начаться и раньше — например, если покупатель не увидел подтверждения и нажал кнопку снова. Сначала приходится восстановить путь конкретного заказа, а не назначать виноватым менеджера, который позвонил последним.
Лена просит показать время отправки, состав заказа и сохранённую отметку исходной заявки. Ей важно узнать, были ли это две попытки передать одну просьбу или два самостоятельных заказа. «Вторую можно удалить?» — спрашивает менеджер. Пока нет: одинаковый телефон здесь лишь повод проверить. Постоянный покупатель вправе заказать похожий товар утром и снова после обеда. Лена хочет избавить его от лишнего звонка, а не от следующего заказа.
Сначала прекращают второй звонок
Отметка исходной заявки подтверждает: сайт передал одну отправку дважды. Лена сохраняет историю обоих разговоров и помечает лишнюю карточку как повтор. Отделу сообщает, по какой карточке продолжают работу и кто отвечает покупателю. Второй менеджер больше не должен звонить по ней.
Эта отметка не убрала все похожие записи в архиве. Лена разобрала один заказ. Теперь ей нужен порядок, при котором такая передача не создаст лишнюю задачу в следующем цикле.
С разработчиком она договаривается проверить задержку ответа и повтор доставки. Связь с CRM настраивают отдельно; затем проверяют, что уже принятую заявку узнают и не создают по ней вторую рабочую карточку. Номер заявки помогает связать попытки, но сам по себе не обеспечивает этот результат.
После настройки повтор приходит к той же карточке
В следующем рабочем цикле покупатель отправляет заказ с сайта. Карточка уже сохранена, а ответ сайту задерживается. Передача повторяется. Отдел видит одну рабочую карточку, а не ещё одну задачу для свободного менеджера. Лена открывает историю: попыток две, заказ один. Покупателю не приходится отвечать на второй звонок.
Это предусмотренный и проверенный маршрут нашего примера, не обещание, что любая CRM сама так поступает. Если подтверждения нет, запись могла уже сохраниться. Ответственный видит, что передача ждёт проверки; никто не создаёт ещё одну карточку вручную «на всякий случай».
Как различают повтор и новый заказ
Исходной отправке сохраняют собственную отметку — например, номер запроса. При повторной доставке отметка остаётся той же; настоящий новый заказ получает другую. При настройке проверяют весь путь, в том числе две попытки почти одновременно. Один номер без такой проверки не гарантирует одну карточку.
Похожее не значит одинаковое
После обеда тот же покупатель заказывает ещё одну партию. Телефон и товар совпадают. Лена видит отдельную новую заявку и оставляет её в работе: это следующая покупка, не доставка прежнего запроса.
Другой случай менее ясен. Покупатель сначала позвонил, потом прислал похожее через форму. Общей отметки нет. Менеджер уточняет: «Это дополнение к утреннему заказу или ещё один?» Пока ответ не получен, похожие обращения отмечены для проверки. Они не исчезают автоматически только потому, что совпал телефон.
У отдела теперь три разных действия: повтор доставки связывают с принятой карточкой, новый заказ ведут отдельно, сомнительное совпадение проверяют с покупателем. Лена больше не объясняет каждый из этих случаев словом «дубль».
Вопрос для первого разбора
Для первого разговора напишите, откуда приходят заявки и в какой программе появляются дубли. Не нужно заранее восстанавливать передачу или готовить обезличенный заказ. На разборе уже можно посмотреть один конкретный путь и проверить, что случается с повтором и новым заказом того же покупателя.
В истории про один заказ в нескольких программах сведения расходились после изменения доставки. Здесь проблема раньше: одна отправка дважды превратилась в рабочую задачу. А в истории о заявке из переписки следующий шаг вообще не был назначен. Эти сбои выглядят похоже только снаружи — когда покупателю снова приходится объяснять свой заказ.
Два телефона на упаковочном столе не беда сами по себе. Беда начинается, когда каждому из них достаётся отдельная карточка на одну и ту же просьбу. Проверять стоит не добросовестность звонящих, а путь запроса от первого нажатия до одной рабочей карточки.