Інтеграція CRM-системи з мобільним застосунком
Мобільне застосунок для продажів або сервісу без CRM-інтеграції—ізольований інструмент, дані з якого менеджери переносять вручну. Дзвінки, задачі, угоди—все це живе в CRM, мобільне застосунок повинно отримувати та відправляти ці дані в реальному часі, а не батчами раз на день.
Пряма інтеграція vs Middleware
Прямий API з мобільного застосунку до CRM—погана практика. API-ключі у застосунку (легко витягти через jadx або class-dump), немає контролю бізнес-логіки, немає кеша.
Правильна схема: мобільне застосунок → власний API (BFF, Backend for Frontend) → CRM. BFF аутентифікується з CRM через OAuth 2.0 або API-ключ, зберігає секрети на сервері, трансформує дані під потреби мобільного клієнта.
BFF повертає тільки необхідні дані: список угод з назвою, сумою, статусом—не весь об'єкт угоди на 40 полів. Це зменшує трафік та час парсингу на мобільному.
Офлайн-режим та синхронізація
Торговий представник їде до клієнта—інтернет пропав у передмісті. Робить дзвінок, фіксує угоди у застосунку. Дані повинні дійти в CRM, коли з'явиться мережа.
На Android—WorkManager з NetworkType.CONNECTED. На iOS—BGProcessingTask. Локальне сховище (Room/Core Data) буферизує зміни. При відновленні з'єднання воркер читає непередані записи та відправляє у BFF пакетами.
Конфлікти: менеджер в офісі змінив угоду через веб-інтерфейс CRM, мобільний користувач—через застосунок без сети, конфлікт. Простих стратегія: server wins (дані з CRM перезаписують локальні). Складніше: версіонування через updated_at timestamp, користувач вибирає версію при конфлікті.
Сповіщення про зміни
CRM змінює статус угоди—мобільне застосунок дізнається. Варіанти:
Webhook → Push: CRM надсилає webhook на BFF при подіїї (угода змінена, новий лід). BFF надсилає FCM/APNs push на пристрій користувача. Низька затримка, потребує налаштування webhook'ів у CRM.
Polling: застосунок кожні N хвилин запитує зміни через GET /changes?since={timestamp}. Простіше, вища навантаження на сервер. Для CRM-даних (не real-time)—прийнятно.
WebSocket: при відкритому застосунку—підписка на события. При закритому—push. Найкращий UX, складна реалізація.
Типові сутності та маппінг
Кожна CRM має свої імена для стандартних об'єктів. При розробці слоя маппінгу в BFF:
| Стандартна | amoCRM | Bitrix24 | Salesforce |
|---|---|---|---|
| Угода | Lead/Opportunity | deal | Opportunity |
| Контакт | Contact | contact | Contact |
| Компанія | Company | company | Account |
| Задача | Task | task | Task |
Единна модель у мобільному (Deal, Contact, Company) з адаптерами під кожну CRM у BFF—дозволяє підтримувати кілька CRM або змінити CRM без переписування клієнта.
Графік
Інтеграція з однією CRM через BFF, базові CRUD-операції, offline-буфер: 2-4 тижні. Додавання push-сповіщень, розв'язання конфліктів, підтримка кількох CRM: плюс 1-2 тижні. Вартість розраховується індивідуально.