Дубли и “двойные списания/двойные заявки”: как это предотвращать
Дубли — это когда одна и та же операция создаётся дважды: клиент оплатил один раз, а списаний два; клиент оставил заявку, а в CRM их две; заказ ушёл в доставку дважды. В итоге страдает и прибыль, и репутация, и команда: приходится вручную разбирать “что было первым”, делать возвраты, объясняться с клиентами и чинить отчёты.
Важно понять главное: дубли появляются даже в хорошо работающих системах, если вы не заложили защиту. Повторы — нормальная часть реальности: интернет “мигает”, сервисы временно недоступны, люди нажимают кнопку второй раз, менеджер открывает страницу и повторяет отправку, потому что “ничего не произошло”.
Почему дубли возникают (простыми словами)
- Повторное действие пользователя. Двойной клик, обновление страницы, повторная отправка формы.
- Повторная попытка со стороны сервиса. Когда внешний сервис не получил подтверждения, он может отправить операцию ещё раз (это стандартно и правильно с их стороны).
- Сбой на середине. Деньги списались, но подтверждение “успех” не сохранилось в вашей системе — и при повторе создаётся второй платеж/заказ.
- Ручные обходные пути. Сотрудник “дублирует” операцию, потому что не видит понятного статуса и думает, что ничего не произошло.
Какие решения должен требовать заказчик
Ниже — формулировки, которые можно прямо включать в ТЗ и приемку.
1) Правило “повтор не создаёт новую операцию”
Если система получает повтор той же оплаты/заявки, она должна:
- либо показать уже созданный результат (тот же заказ/платёж);
- либо корректно сказать “операция уже выполнена”, без новых списаний и новых записей.
2) Понятные статусы: “в процессе / успешно / ошибка”
Дубли часто рождаются из-за неизвестности. Поэтому пользователь и менеджер должны видеть:
- операция выполняется (и сколько обычно длится),
- успешно завершилась,
- не завершилась и что делать дальше (повторить или обратиться в поддержку).
3) Защита в интерфейсе от “двойного клика”
Минимум:
- кнопка “Оплатить/Отправить” блокируется после нажатия;
- появляется сообщение “обрабатываем”;
- при обновлении страницы человек видит статус, а не пустоту.
Это простая мера, но она снимает значительную долю дублей.
4) Защита на уровне бизнес-правил (а не только интерфейса)
Интерфейс помогает, но не спасает от повторов “снаружи”. Поэтому система должна иметь правило: если пришла повторная операция по тому же заказу/клиенту/сумме/времени — не создаём новую, а привязываваем к существующей. Как именно это определить — задача подрядчика, но требование со стороны бизнеса должно быть чётким: “повтор не должен приводить к новым деньгам/новой заявке”.
5) Отчет и журнал: как быстро находить и разбирать случаи
Для владельца бизнеса важно не “как устроено внутри”, а чтобы:
- можно было найти операцию по номеру заказа, телефону или email;
- было видно, когда и что происходило (попытки, статусы);
- был простой отчет “подозрения на дубль” (например, 2 заявки от одного контакта за 2 минуты).
6) Сценарии приемки “на дубли”
На приемке попросите подрядчика показать 5–7 сценариев:
- двойной клик/повторное нажатие;
- обновление страницы во время оплаты;
- повтор операции через минуту;
- временная недоступность сервиса и повторная попытка.
Результат везде один: не должно появляться второй оплаты/второй заявки.
Что это даст бизнесу
- меньше возвратов и конфликтов с клиентами;
- меньше “ручной уборки” и потерь времени команды;
- стабильные отчеты и меньше сюрпризов “в конце месяца”.
Если коротко: ваша цель — не “чтобы никогда не повторялось”, а чтобы повторы были безопасны и не стоили вам денег.