Інтеграція CRM з мобільним застосунком: де розривається обмін
Обрив зв'язку в ліфті чи метро — клієнт оформлює заявку, натискає «Надіслати» й бачить підтвердження. В обліковій системі заявки немає: запит пішов у момент, коли з'єднання вже розпалося, а повтору не було.
Заявка загубилася під час обриву зв'язку, і дізнається про це клієнт від менеджера телефоном, а не із застосунку, який щойно обіцяв протилежне.
Друге місце розриву — ключ, за яким застосунок і облікова система зіставляють людину. Якщо пошук іде за телефоном, а в базі той самий клієнт лежить з іншим написанням номера, під час наступного входу створюється новий запис.
Так з'являються дублі карток клієнтів: історія замовлень роз'їжджається по двох записах, знижки й бонуси рахуються двічі, а злиття потім роблять вручну і з втратою частини історії.
Третє — статуси. Менеджер переводить замовлення в «Відвантажено», застосунок ще годину показує «Збирається», бо обмін іде за розкладом, а не за подією.
Розбіжність статусів замовлення дає зайві звернення до підтримки й підриває довіру до застосунку сильніше, ніж будь-яка помилка інтерфейсу.
Окрема історія — ручне перенесення даних як латка: вивантаження із застосунку, звірка в таблиці, правки руками. Воно з'їдає час співробітників і додає нові розбіжності рівно там, де їх намагалися прибрати.
Причина в усіх чотирьох збоях одна: між застосунком і обліковою системою немає шару, який відповідає за повторний запис без дублів, розв'язання конфліктів і доставку до конкретного пристрою. Розбираємо, як це закривається.
Усунені класи відмов і швидкість роботи менеджера
Дорожче за все коштували не відмови сервера, а тихі втрати: заявка, оформлена там, де зв'язку немає, жила в пам'яті телефона й зникала під час перезапуску.
Тепер вона одразу лягає в чергу відкладеної відправки й іде в CRM, щойно з'являється канал; повторна відправка позначена ключем запису, тому обрив мережі дає не дубль, а ту саму картку.
Другий клас — конфлікт версій запису, коли менеджер і оператор правлять одну картку одночасно. Ревізії порівнюються за полями, а не за принципом «хто останній, той і правий»: збіжні зміни зливаються, розбіжності позначаються й ідуть на підтвердження з підсвічуванням відмінностей. Заявка перестає затиратися застарілою формою.
Третій — повторне введення даних. Раніше цикл виглядав так: замітка в блокнот, увечері ручне перенесення, звірка з фотографіями. Тепер дані вводяться один раз на місці, вкладення й підписи довантажуються фоново, і менеджер закриває заявку одразу, а не через день.
У цифрах це виглядає так: частка звернень, загублених до потрапляння в CRM, падає з одиниць відсотків до нуля — кожен випадок або йде в систему, або залишається в журналі з причиною відмови.
Схему ми збирали і для Битрикс24, і переносимо на будь-яку CRM з відкритим програмним інтерфейсом. Час обробки заявки на виїзді скорочується в рази, бо шлях від запису до картки в системі стискається до однієї дії.
Варіанти зв'язки: прошарок на сервері, прямий доступ, шина
Перше рішення при зв'язці — де живе логіка відбору даних і хто володіє доступом до облікової системи. Якщо застосунок звертається до неї напряму, будь-яка правка структури ламає випуск, а права доводиться роздавати назовні.
Серверний прошарок тримає облікову систему закритою: застосунок отримує лише підготовлені відповіді під конкретний екран і не знає про її внутрішній устрій.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Серверний прошарок | Мобільний сценарій відрізняється від облікового: свої екрани, свої поля, черга офлайн-дій | Потрібен окремий контур, який хтось супроводжує і випускає разом із застосунком |
| Прямий доступ до облікової системи | Один вузький сценарій, небагато користувачів, готові інтерфейси системи покривають його повністю | Правки в обліковій системі одразу видно клієнтам, права й ліміти запитів ідуть назовні, відкат неможливий |
| Обмін за розкладом | Дані невибагливі до секунд: довідники, каталоги, зведення | Затримка між зміною й появою в застосунку, а конфлікти при правках з двох боків розв'язуються вручну |
| Шина даних | Кілька облікових систем і каналів, потрібен єдиний потік подій | Важче в супроводі: окремий контур маршрутизації виправданий від трьох джерел |
Вибір диктують обмеження синхронізації. Там, де правки йдуть з обох боків, потрібна явна стратегія розв'язання конфліктів і повторювані операції — інакше повторна відправка створює дублі записів.
Ми починаємо з розбору сценаріїв: найчастіше достатньо прошарку й обміну за розкладом, а шина з'являється, коли джерел стає кілька і розбіжності між ними перестають бути винятком.
Як іде впровадження: від розбору даних до передачі
Чим раніше зафіксована схема даних, тим дешевша кожна наступна правка. До першого рядка коду розбираємо, які сутності CRM справді потрібні на екрані, а які тягнути в мобільний контур не варто: зайве поле — це вага відповіді й новий привід для конфлікту під час синхронізації. Підсумок етапу — карта обміну, а не домовленість «треба інтегрувати».
- Аудит схеми даних. Зводимо угоди, контакти, завдання й історію активності до полів, які реально потрапляють в інтерфейс, і позначаємо ті, що змінюються з обох боків, — це карта майбутніх конфліктів.
- Проєктування обміну. Вирішуємо, що застосунок запитує напряму, а що отримує через проміжний шар: він збирає відповідь з кількох джерел і віддає екрану один компактний набір замість серії запитів.
- Налаштування черг відправки. Записи, зроблені без мережі, лягають у локальну чергу з порядком і повторними спробами. Сервер звіряє їх за ідентифікатором і лише потім пише в CRM — повторна відправка не створює дублів.
- Випробування на конфлікти. Ламаємо сценарії навмисно: правка з двох пристроїв, обрив мережі в момент відправки, вхід після зміни прав доступу. Дивимося, яка версія запису перемагає і чи бачить співробітник, що правка не збереглася.
- Передача й навчання команди. Віддаємо схему обміну, конфігурацію черг, довідник полів і розбір типових збоїв, навчаємо ваших розробників і підтримку — щоб правки в сценаріях не вимагали повертатися до нас.
- Супровід після запуску. Тримаємо метрики доставки, частку успішних синхронізацій і глибину черги: оповіщення про її зростання приходить раніше, ніж користувачі помічають втрату даних.
Що залишається у вас: схеми обміну, правила, регламенти
Інтеграція вважається завершеною не в момент, коли дані пішли, а коли супровід не потребує автора рішення. Тому в контурі замовника залишається комплект артефактів, за якими підтримка, служба безпеки й нові розробники працюють самостійно, без звернення до нас за поясненнями.
- Схема обміну даними — які сутності CRM потрапляють у застосунок, у якому вигляді, які поля обов'язкові й як розв'язується конфлікт одночасних правок одного запису.
- Правила доступу й ролі — матриця «роль → доступні сутності та операції», окремими блоками для зовнішніх користувачів і для відкликаних облікових записів.
- Регламент обробки помилок — які відмови вважаються тимчасовими, скільки спроб робиться автоматично і в який момент подія йде в ручне розбирання.
- Інструкція для підтримки — готові сценарії: дані не прийшли, повідомлення не дійшло, запис не зберігся — і що саме перевіряти в кожному випадку.
- Журналювання подій — які події пишуться, строк їх зберігання і як за ідентифікатором звернення пов'язати скаргу користувача з конкретним обміном.
- Схема розгортання — які сервіси живуть у контурі замовника, де зберігаються адреси й ключі доступу, як піднімається тестовий контур для перевірок.
- Порядок змін — як додати поле або сутність, не ламаючи застосунок на пристроях із попередніми версіями.
Кожен документ підкріплений робочими конфігураціями, а не описом «у загальному вигляді». Перед передачею проходимо по артефактах разом із вашою командою й відповідаємо на запитання — щоб після запуску не залишилося вузлів, які працюють лише в нас у голові.
Кейс: як заявки перестали губитися під час обриву зв'язку
Сервісна компанія з виїзними бригадами приймала заявки через мобільний застосунок, а диспетчер вів їх у Битрикс24. Під час обриву зв'язку картка створювалася на пристрої, але відповідь сервера не доходила — застосунок позначав відправку невдалою і повтору не робив.
За зміну губилося до 14% звернень, і про частину з них диспетчер дізнавався від клієнта телефоном, а не із системи.
Впровадили офлайн-чергу: заявка зберігається локально й повторно йде при відновленні мережі, а кожна отримує ключ, за яким сервер відкидає дублі. Між застосунком і CRM поставили шар-посередник з єдиним контрактом — застосунок не залежить від того, як перейменували поля в CRM. Статуси йдуть назад push-повідомленнями, тому оператор не дзвонить уточнювати, чи прийнято заявку.
Що змінилося за перший місяць роботи:
- частка загублених звернень — 14% → 0,4%;
- середній час обробки звернення — 26 → 9 хвилин;
- звернень на оператора за зміну — 40 → 65 без розширення штату;
- частка клієнтів, які телефонують уточнити статус, — 31% → 6%.
Цінність тут не в «стало зручніше», а в тому, що втрата заявки перестала бути сценарієм: мережа зникла, застосунок закрили, телефон розрядився — звернення все одно доходить до диспетчера й повертається клієнту зі статусом.
Що робити, якщо облікова система вже розгорнута і нею користуються?
Розгорнутий контур не зупиняють заради обміну: нову логіку нарощують поруч із працюючою, а не замість неї. Заявки, довідники й залишки продовжують іти поточними маршрутами, поки зміни перевіряються на копії трафіку, — так впровадження проходить без простою продажів. Перемикання йде не одним днем, а за групами користувачів і офісами, з планом етапів.
Зворотна сумісність тримається на версіонуванні методів: нові поля приходять опціональними, і старі збірки, які ще стоять на телефонах співробітників, отримують відповідь у попередньому форматі.
Обмін іде через BFF-шар, тому мобільний клієнт не знає, в якій обліковій системі (1С) лежать дані, і перезбирати його при кожній зміні схеми не потрібно.
Перенесення даних без втрат — окремий етап, а не побічний ефект запуску. Іде звірка контрольних сум на джерелі й приймачі, кожен запис позначається ключем повтору, розбіжності складаються в журнал і довантажуються після основного проходу. Масові операції ставимо в нічне вікно, коли навантаження на облікову систему мінімальне.
План відкату готують до старту, а не після збою: попередня збірка застосунку залишається доступною для встановлення, серверна частина тримає перемикач на старий маршрут обміну, тому повернення займає хвилини.
Рішення ухвалюється за контрольними метриками — частка успішних синхронізацій, глибина черги на відправку, час відклику. Що перемикати першим — обмін, офлайн-чергу чи push-повідомлення — залежить від того, де в поточному контурі більше ручної роботи.
Часті технічні сумніви перед стартом
Перед стартом замовник хоче зрозуміти, хто в системі головний за даними і що станеться при збої синхронізації. Нижче — питання, які виникають майже на кожній оцінці, і наші відповіді по суті.
Хто джерело правди — CRM чи мобільний застосунок?
Джерело правди — CRM. Застосунок і проміжний серверний шар лише читають дані й надсилають правки, а сам запис проходить перевірку на сервері. Тому застаріла копія на пристрої не перезапише актуальний стан.
Що якщо один запис правлять з двох боків одночасно?
Розв'язання конфліктів будується на версії та часі зміни: сервер порівнює їх і або приймає правку, або позначає запис на ручне розбирання. Поля, які веде лише CRM, змінами із застосунку не зачіпаються.
Як захищені дані клієнтів?
Дані на пристрої зберігаються в зашифрованому вигляді, авторизація — за короткоживучими токенами, права перевіряються на сервері при кожному запиті, а не всередині застосунку. Сесію можна відкликати віддалено, в журналах не залишається персональних даних.
Чи можна змінювати правила обліку без перевстановлення застосунку?
Так. Логіка розрахунків, статуси й довідники винесені на сервер, у застосунку залишається відображення. Оновлення правил приходить на пристрій без випуску нової збірки й без дій з боку користувача.
Що відбувається при слабкому зв'язку?
Правки складаються в локальну чергу й ідуть на сервер, щойно зв'язок з'являється. Повторна відправка не створює дублів — кожна операція позначена своїм ідентифікатором.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб обговорити задачу інтеграції предметно й повернутися з оцінкою та планом за етапами, а не із загальними словами, потрібен мінімальний набір ввідних. Нижче — що надіслати для розбору; якщо чогось немає, зафіксуємо це першим етапом робіт.
- Сценарії роботи в застосунку: що користувач дивиться і змінює з телефона, які операції мають працювати без мережі й як дані довантажуються при поверненні зв'язку.
- Доступи й стенди: тестовий контур CRM, облікові записи з різними ролями, правила мережевого доступу з боку вашої інфраструктури.
- Модель даних: сутності, які йдуть на пристрій, зв'язки між ними, приблизний обсяг записів і частота змін.
- Контракти: опис наявного програмного інтерфейсу або вивантаження поточних запитів, формати відповідей, коди помилок.
- Права й повідомлення: хто що бачить і може змінювати, які події мають приходити на пристрій, шаблони текстів.
- Обмеження: розрахункове навантаження, очікувані строки, що вже пробували і чому рішення не підійшло.
Порядок взаємодії простий: розбираємо сценарії та обмеження, ми збираємо план робіт за етапами зі складом ввідних на кожному, потім повертаємося з оцінкою строків і розбором ризиків. Уточнення ведемо письмово, щоб оцінка залишалася перевірюваною. Опишіть задачу — повернемося з планом і строками.
