Мобільний застосунок і CRM як одна система: двостороння інтеграція без дублів

У продавців зʼявився мобільний застосунок. У компанії вже була CRM, у якій живуть замовлення, оплати й уся історія клієнта.

Готова інтеграція між ними вміла рівно одне: перекидати замовлення в один бік. Статуси, оплати, товари й категорії лишались на людях - а те, що лишається на людях між двома системами, розходиться приблизно за тиждень.

Далі починається знайоме. У застосунку замовлення ще збирається, у CRM воно вже відправлене, клієнт питає, а правильної відповіді немає в жодній із двох програм.

напрями обміну замість одного

20 хв

цикл звірки, що ловить пропущене

категорій зведено один в один

Проблема: дві односторонні дороги не складаються в обмін

Здається логічним: якщо дані вміють ходити в один бік, треба просто зробити ще один такий самий канал у зворотний. На практиці друга дорога не додає можливостей, вона додає ризиків.

Коли обидві системи мають право змінювати ту саму сутність, зʼявляється питання, на яке жодна з них не відповідає сама: чия версія правильна. Поки на нього немає письмової відповіді, будь-який обмін рано чи пізно псує дані.

Три ризики, яких немає в односторонній інтеграції

👯 Дубль

Та сама подія приходить двічі - через повтор або через збій мережі
Наївний обробник створює друге замовлення на те саме
Помилку помічають на складі, коли товар уже зібрано двічі

🔁 Цикл

Ми записали статус у другу систему, вона повідомила про зміну
Ми прийняли це повідомлення і записали статус назад
Дві системи штовхають одне одного нескінченно, доки хтось не вимкне сервіс

⚠️ Немає джерела правди

Обидві сторони вважають себе головними щодо статусу
Виграє та, що записала останньою, а не та, що має рацію
Дані не втрачаються - вони тихо стають неправильними

Як автоматизація це вирішує

Обмін зроблено в обидва боки власним сервісом. Замовлення із застосунку заходять у CRM, зміни статусів повертаються назад до продавця, товари й категорії їдуть з основного каталогу.

Але головне тут не другий напрям, а третій контур: незалежна звірка. Кожні двадцять хвилин система сама питає застосунок, які замовлення там зʼявились за останні два тижні, і дозаливає те, чого в CRM немає.

Два напрями і страховка

Застосунок продавця → подія замовлення → дедуплікація і мапінг → CRM

CRM → зміна статусу → захист від відлуння → Застосунок

Звірка кожні 20 хв → чого немає в CRM → дозаливка

Одне джерело правди на статус

Домовленість, без якої нічого не працює: майстром статусів є CRM. Застосунок може змінити статус у себе, але остаточне слово лишається за CRM.

Це не технічне, а управлінське рішення, і ухвалює його власник, а не програміст. Зате далі все просто: перед записом система читає поточне значення і пише тільки тоді, коли воно справді інше.

Що це дало бізнесу

Дві програми перестали бути двома джерелами новин. Продавець у застосунку і менеджер у CRM бачать той самий статус того самого замовлення, і питання «а в кого правильно» більше не виникає.

Каталог теж перестав жити окремим життям: дерево категорій застосунку зведене один в один з основним - 47 категорій, жодного сироти й жодного товару поза деревом.

Що змінилось у щоденній роботі

ЗамовленняЗаходять у CRM самі, без ручного перенесення. Повторна поява тієї самої події не створює другого замовлення

СтатусиПовертаються до продавця автоматично. Продавець бачить в застосунку те саме, що менеджер бачить у CRM

ПропущенеЗамовлення, яке не приїхало вебхуком, дозаливається протягом двадцяти хвилин. Втратити його безслідно система не може

Тепер чесно про межу, яку кодом не обійти. Фотографії товарів через API застосунку не заливаються: запит приймається, завдання завершується успішно, а поле лишається порожнім.

Тож автоматично створені картки поки що йдуть без фото, і це закривається руками. Ми пробували кілька шляхів і не приховуємо результат: не кожне обмеження чужої системи можна перемогти з нашого боку.

Як це влаштовано всередині

Далі - інженерна частина

Наступний розділ пояснює, як система влаштована. Якщо вас цікавить лише результат, його можна пропустити - нижче є розділ про те, кому це підходить.

Три запобіжники

Без цих трьох речей двосторонній обмін вмикати не можна

Дедуплікація подійКожна подія має ключ. Повторна обробка тієї самої події - беззвучний пропуск, без запису й без помилки, бо повтор тут нормальне явище, а не збій

Захист від відлунняЗміна, яку ми самі щойно записали, на короткий час позначається як своя. Зворотний вебхук про неї приходить і відкидається, тому дві системи не починають штовхати одне одного

Обмеження темпуОбидва API мають ліміти запитів на хвилину, і наш сервіс не єдиний, хто ними користується. Темп тримається нижче стелі свідомо, з запасом на чужі процеси

Урок: назва події змінилась мовчки

Одного дня замовлення із застосунку перестали заходити в CRM. Нічого не падало, жоден монітор не спрацював, у журналах було порожньо. Причина виявилась простою: постачальник перейменував подію, на яку ми підписані.

Ніхто не попереджав, помилки не було - просто тиша. Це найгірший вид відмови, бо система в цей момент виглядає абсолютно здоровою.

Звідси два правила, які тепер діють постійно. Перше: код тримає всі відомі назви події одночасно, а не лише актуальну. Друге: вебхук ніколи не буває єдиним каналом - саме тому зʼявилась звірка кожні двадцять хвилин.

Окремо варто згадати сусідній клас відмов: автоматичне заведення товарів у застосунку двічі ламалось через втрачене поле у вивантаженні, і той самий клас помилок розгорнуто описаний в іншому кейсі, про синхронізацію цін і залишків.

Кому це підходить

Усім, хто ставить мобільний застосунок або друге робоче місце поверх наявної CRM: роздрібу з польовими продавцями, магазинам з окремим застосунком для торгової точки, компаніям, у яких склад працює в одній програмі, а продажі - в іншій.

Побутова ознака, за якою легко перевірити, чи це про вас: якщо співробітники вголос питають «а де дивитись правильний статус», значить, джерела правди у вас поки що немає. Другий сигнал ще простіший - хтось відкриває дві програми поруч і звіряє їх очима.

Вебхук - це обіцянка чужої системи. Звірка - це ваша власна гарантія.