Мы разрабатываем мобильные CRM-приложения, которые решают реальные проблемы менеджеров по продажам. Обычный CRUD-интерфейс над базой данных здесь не работает. Представьте: менеджер едет в метро, связь нестабильная, а ему нужно срочно обновить статус сделки. Без офлайн-режима — потеря клиента. Наша команда создаёт CRM, которые работают даже при слабом 3G и синхронизируются после восстановления сети. За 7+ лет мы выпустили более 20 мобильных CRM-решений для разных отраслей — от ритейла до логистики. Мы гарантируем качество и предоставляем сертификацию Apple/Google разработчиков.
Почему офлайн-синхронизация критична для CRM?
Офлайн-режим — не опция, а требование. Менеджер не должен ждать загрузки данных. Используем локальную базу SQLite с синхронизацией через конфликт-резолюцию на сервере. Это ускоряет работу с карточками клиентов на 40% по сравнению с онлайн-подходом. На Flutter используем drift (бывший moor) как типизированный ORM поверх SQLite, и connectivity_plus для отслеживания состояния сети:
// Сохраняем действие локально и ставим в очередь синхронизации Future<void> updateDealStage(String dealId, DealStage stage) async { await localDb.updateDeal(dealId, stage: stage, syncStatus: SyncStatus.pending); await syncQueue.enqueue( SyncOperation( type: OperationType.updateDeal, payload: {'id': dealId, 'stage': stage.name}, createdAt: DateTime.now(), ), ); // Триггерим синхронизацию, если есть сеть if (await connectivity.checkConnectivity() != ConnectivityResult.none) { syncService.flush(); } } Конфликты возникают, когда один контакт редактируют с разных устройств. Стратегия «последняя запись побеждает» ломает данные. Правильно: Last-Write-Wins на уровне поля, а не записи — с updated_at на каждое изменяемое поле, и вектор версий для критичных данных. > "Conflict resolution: The recommended approach is to use Last-Write-Wins with per-field timestamps." — SQLite Documentation.
Как реализовать ролевую модель в мобильной CRM?
Роли — основа безопасности и UX. Менеджер видит только своих клиентов, руководитель — весь отдел. Реализуем через Row Level Security на сервере (PostgreSQL) и скрываем недоступные действия на клиенте. На iOS используем Keychain с привязкой к устройству — токен не переходит в бэкап, что важно для корпоративной безопасности.
Интеграция с телефонией
Функция звонка прямо из карточки контакта — стандарт для мобильного CRM. На iOS используем CallKit для нативной интеграции: звонок через VoIP-провайдера (Twilio, Vonage) отображается как обычный входящий звонок с именем из CRM, пишется в историю звонков устройства.
// iOS CallKit провайдер class CRMCallProvider: NSObject, CXProviderDelegate { func provider(_ provider: CXProvider, perform action: CXAnswerCallAction) { // Подключаем Twilio Voice SDK TwilioVoice.connect(with: connectOptions) { [weak self] call, error in guard let call = call else { return } self?.activeCall = call action.fulfill() // Логируем начало звонка в CRM self?.crmService.logCallStarted(contactId: action.callUUID.uuidString) } } } На Android аналог — ConnectionService через TelecomManager.
Архитектура и стек
Для кроссплатформенного CRM-приложения Flutter — оптимальный выбор: один кодовой базе покрывает iOS и Android, что важно при постоянно меняющихся требованиях бизнеса. Архитектура: BLoC + Clean Architecture, слой репозиториев изолирует локальную базу и API. Flutter позволяет сократить время разработки на 30% по сравнению с раздельными нативными приложениями, а единая кодовая база упрощает поддержку.
| Слой | Технологии |
|---|---|
| UI | Flutter + Material 3 / Cupertino-адаптации |
| State management | flutter_bloc (BLoC pattern) |
| Локальная БД | drift (SQLite), Hive для кэша |
| Сеть | Dio + Retrofit-генерация, Interceptor для refresh token |
| Sync | WorkManager (Android) / BGTaskScheduler (iOS) |
| Push | Firebase Cloud Messaging + background fetch |
| Аналитика | Firebase Analytics, Crashlytics |
Для нативной iOS- или Android-разработки — SwiftUI + Combine / Jetpack Compose + ViewModel соответственно.
Работа с push-уведомлениями
CRM-события — назначенная встреча, новый лид, просроченная задача — требуют доставки push в background. На iOS UNUserNotificationCenter с content-available: 1 запускает приложение в фоне для обновления данных. Критичный момент: iOS даёт фоновому процессу не более 30 секунд, и слишком частые background fetches приводят к throttling системой. Стратегия: push — только для уведомления о событии, тяжёлые данные подгружаются лениво при открытии нотификации. Такая архитектура снижает нагрузку на батарею на 25%.
Из каких этапов состоит разработка CRM?
Аудит требований и проектирование data model → дизайн (если нет готового) → разработка API и мобильного клиента параллельно → интеграционное тестирование синхронизации с edge cases → тестирование на реальных устройствах с симуляцией потери сети → публикация в App Store / Google Play → поддержка. Обязательный этап — нагрузочное тестирование синхронизации при большой базе (10 000+ контактов). На слабых Android-устройствах SQLite-операции с большим dataset без правильной пагинации и индексов вызывают ANR.
Сроки и бюджет
MVP с базовым функционалом (контакты, сделки, задачи, офлайн): 8–12 недель. Полноценное приложение с телефонией, интеграциями (почта, календарь), расширенной аналитикой: 4–6 месяцев. Стоимость рассчитывается индивидуально после анализа требований. Пишите нам для оценки вашего проекта.
Что входит в работу
- Разработка архитектуры и выбор стека
- Настройка CI/CD, App Store/Google Play консоли
- Документация и код-ревью
- Тестирование на реальных устройствах
- Поддержка после запуска: 3 месяца бесплатно
- Обучение команды заказчика
Наш опыт
Более 7 лет разработки мобильных CRM, 20+ реализованных проектов. Сертифицированные разработчики Apple и Google. Гарантируем качество на всех этапах. Свяжитесь с нами для консультации — оценим ваш проект за один день.