Інтеграція сайту з CRM/ERP: як не губити замовлення

Надійна інтеграція сайту з CRM або ERP має зберігати узгоджені дані навіть при повторній події, тимчасовому збої чи затримці відповіді. Її мета — не просто передати форму в іншу систему, а зробити шлях замовлення зрозумілим для клієнта й команди. Для цього потрібно визначити джерела даних, правила статусів і спосіб відновлення після помилок.

Початковий сценарій часто здається простим: покупець оформлює замовлення, менеджер бачить його у CRM. Складність з’являється далі. Клієнт двічі натиснув кнопку, оплата прийшла пізніше, залишок змінився, менеджер виправив адресу, а зовнішній сервіс деякий час не відповідав. Саме ці ситуації визначають якість інтеграції у щоденній роботі.

Що є головним джерелом для кожного поля

Одна система не обов’язково є головною для всього. Сайт може створювати замовлення, ERP — вести залишки, CRM — зберігати комунікацію, а платіжний сервіс — підтверджувати транзакцію. Для кожного типу даних потрібно зафіксувати власника та правила обміну. Інакше двостороння синхронізація може перезаписувати правильне значення старим.

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

• Який ідентифікатор пов’язує один запис у різних системах?

• Хто може змінювати поле й у якому напрямку передається зміна?

• Як відрізнити нову версію від застарілої події?

• Що робити з порожніми значеннями, скасуванням або видаленням?

• Як перевірити, що обидві сторони зрештою узгоджені?

Webhook — повідомлення, а не гарантія одноразової доставки

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

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

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

Черги та повторні спроби

Коротка недоступність CRM не повинна змушувати покупця повторно оформлювати замовлення. Сайт може зберегти його локально, поставити передачу в чергу й показати чесний статус. Менеджер має бачити, які записи очікують синхронізації, а технічна команда — причину затримки. При цьому локальне приймання й остаточне підтвердження потрібно розрізняти.

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

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

Не плутайте красивий кабінет із завершеною інтеграцією

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

У кейсі «Бідняжка» поряд із туристичним порталом є власна CRM/ERP для внутрішніх процесів. Він ілюструє різницю між публічним вибором подорожі та операційною роботою команди. Конкретні правила фінансів і доступів завжди описують для самого бізнесу; їх не варто переносити з чужого кейсу за аналогією.

Перевірки, які часто забувають

1. Надіслати ту саму подію повторно й перевірити відсутність дубля.

2. Доставити старіший статус після новішого.

3. Змоделювати недоступність зовнішнього API та відновлення зв’язку.

4. Передати частково некоректні дані й перевірити пояснення для менеджера.

5. Перевірити скасування, повернення та часткове виконання, якщо вони є у процесі.

6. Зіставити записи двох систем після завершення серії операцій.

Останній пункт — звірка — важливий навіть за наявності webhooks. Частину подій можна пропустити через неправильну конфігурацію, зміну API або збій під час релізу. Періодична перевірка узгодженості допомагає знайти розбіжності, які не видно з одного повідомлення про помилку.

Як запускати інтеграцію поступово

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

Якщо створюється новий продукт, мінімальний реліз теж потребує завершеного шляху даних. Можна відкласти другорядний звіт, але не варто залишати без відповіді питання, де зберігається прийняте замовлення. Про такі межі першого релізу — у матеріалі про MVP вебпродукту.

Поширені запитання

Чи потрібна двостороння синхронізація всіх полів?

Ні. Для багатьох даних достатньо одного напрямку. Двосторонній обмін варто додавати там, де визначені власник, конфлікти та правила їх розв’язання.

Чи можна використати готовий конектор?

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

Що потрібно для початкової оцінки?

Список систем, приклад запису, схему статусів і доступну документацію API. Із цим набором можна предметно обговорити впровадження та інтеграцію CRM/ERP, визначивши найважливіший потік даних для першого етапу.