Банківські платежі, які самі знаходять своє замовлення
Виписка з банку приходила окремим потоком, і менеджери щодня вручну звіряли її із замовленнями. Тепер платіж сам знаходить своє замовлення, а людині лишається тільки те, де система не впевнена.
- 99,77% точності на історичному наборі з 1 308 ручних привʼязок
- Нуль хибних привʼязок три доби поспіль у тіньовому режимі перед запуском
- Близько 800 ручних операцій на місяць більше не робить людина
- Повнота близько 89%; решта - платежі без номера замовлення в призначенні
Клієнт оплатив. Гроші вже на рахунку. А замовлення в системі ще годинами вважається неоплаченим - бо ніхто не встиг звірити виписку руками.
Поки цього не зробили, замовлення висить у підвішеному стані. Менеджер не бачить оплати. Автоматичні нагадування продовжують просити клієнта заплатити ще раз. Склад не починає збірку. І так щодня: близько 38 ручних звірок і від 30 до 55 хвилин чиєїсь уваги.
Проблема: банк не знає про ваші замовлення
Виписка приходить окремим потоком. У ній є сума, є прізвище платника і є рядок призначення - те, що клієнт набрав у своєму банку. Іноді там номер замовлення. Іноді «Сплата за товар». Іноді номер, який до вас не має стосунку.
Здається, що звести це між собою - робота на пʼять хвилин для будь-якої програми. На практиці саме тут ховаються три пастки.
🔢 Номер не унікальний
- Група працює під кількома вивісками, і в кожної своя нумерація
- Серед тризначних номерів збіги у 50,3% випадків, серед коротших - у 100%
- «№386» у виписці може означати кілька різних замовлень одночасно
👥 Платить не покупець
- У 19,8% випадків платить чоловік, дружина або колега
- Прізвище у виписці не збігається з прізвищем у замовленні
- Це не помилка - просто ще одна ознака, яка нічого не підтверджує
⚠️ Помилка дорожча за пропуск
- Хибна привʼязка - це чуже замовлення, позначене оплаченим, і відвантажений товар
- Пропущений платіж - це просто робота для людини
- Ціна цих двох подій незіставна
Через третій пункт задача перестає бути задачею на розпізнавання. Вона стає задачею на обережність: система має право не знати відповіді, але не має права вгадувати.
Як автоматизація це вирішує
Кожні пʼять хвилин сервіс забирає нерознесені банківські транзакції, визначає, до якого замовлення належить кожна, проводить оплату і переводить замовлення в статус «є оплата». Те, де впевненості немає, окремим повідомленням іде менеджеру.
Третього не дано: або автомат, або жива людина. Журнал платежів менеджери все одно не читають - перевірено.
Рішення, яке зробило все інше можливим
Найважливіше тут ухвалене не в самому сервісі звірки, а раніше за течією.
Сервіс, який генерує клієнту посилання на оплату, почав писати в призначення платежу два числа одразу: номер, який упізнає клієнт, і внутрішній ідентифікатор замовлення в дужках. Внутрішній ідентифікатор унікальний завжди. А два числа поруч ще й перевіряють одне одного.
Через тиждень після запуску вже 65,3% клієнтських платежів приходили в цьому форматі. Тобто дві третини роботи зникли не завдяки розумному алгоритму, а завдяки одному правильному рядку на попередньому кроці.
Що дістається людині
Невпевнені випадки йдуть менеджеру поштучно, ніколи списком. Причина побутова: менеджери позначають зроблене реакцією на повідомлення, а реакція на переліку не каже, які саме позиції з нього закриті.
Успішні рознесення не пишемо взагалі. Інакше канал перетворюється на стрічку, яку перестають читати - і разом з нею перестають читати важливе.
Що це дало бізнесу
Історичний набір: 1 308 ручних привʼязок, з них 867 підтверджених системою і 2 хибних - причому обидві виявились помилками менеджерів, а не сервісу.
Ті 11%, які система не бере, - це платежі, де номера замовлення немає взагалі ні в якому вигляді. Їх неможливо привʼязати надійно, і система свідомо не намагається. Це не дефект, а межа задачі.
Що змінилось у щоденній роботі:
- близько 800 ручних операцій на місяць більше не робить людина;
- оплата зʼявляється в замовленні протягом пʼяти хвилин, а не через години;
- клієнт, який уже заплатив, більше не отримує нагадування заплатити;
- склад починає збірку одразу, без очікування на звірку.
Як це влаштовано всередині
Наступний розділ пояснює, чому системі можна довіряти гроші. Якщо вас цікавить лише результат, його можна пропустити - нижче є розділ про те, кому це підходить.
Уся конструкція тримається на одному принципі: система має право сказати «я не знаю». Звідси три запобіжники.
Як приймалось рішення про запуск
Три доби сервіс працював у тіньовому режимі: рахував усе, не писав нічого, вів журнал власних рішень. Щоночі цей журнал звірявся з тим, що за той самий час зробили руками люди.
Результат по добах: 20 привʼязок і нуль помилок, 41 і нуль, 43 і нуль. Тільки після третьої доби запис у CRM увімкнули.
Ця нічна самозвірка лишилась у проді назавжди. Вона більше не потрібна для запуску - вона потрібна, щоб помітити, якщо щось зміниться на чужому боці.
Кому це підходить
Будь-якому бізнесу, де вхідний грошовий потік приходить окремо від системи, у якій живуть замовлення: інтернет-магазинам з оплатою на рахунок, оптовикам, сервісним компаніям з передоплатою.
Ознака, за якою легко перевірити, чи це про вас: якщо хтось у компанії щодня відкриває виписку і шукає в ній очима номери - так, це про вас.
Автоматизація фінансів починається не з пошуку збігів, а з питання «що система робить, коли не знає». Якщо відповідь «здогадується» - вмикати її не можна.
Потрібне схоже рішення?
Опишіть задачу - підберу архітектуру під ваш бюджет і дані.