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

На примере развития Krasotula CRM разбираем мобильные сценарии, API, инфраструктуру, безопасность и модульную архитектуру продукта.

Мобильная CRM — это не уменьшенная копия веб-интерфейса. С телефона сотруднику нужны другие действия: быстро найти клиента, увидеть следующую задачу, подтвердить запись, добавить комментарий или изменить статус сделки. Если просто перенести на маленький экран все разделы большой системы, приложение получится сложным и медленным.

На примере развития «Красотули» разберём, из каких частей складывается мобильная CRM для малого бизнеса, почему приложение нельзя проектировать отдельно от серверной инфраструктуры и когда полезнее подключать отдельные модули, а не расширять единый продукт бесконечно.

Зачем малому бизнесу мобильная CRM

Собственник, администратор или менеджер не всегда находится за компьютером. Работа продолжается в дороге, на объекте, между встречами и рядом с клиентом.

На телефоне чаще всего нужны короткие сценарии:

посмотреть карточку клиента;
увидеть ближайшие записи;
принять новый лид;
позвонить или написать;
создать задачу;
изменить статус сделки;
добавить итог разговора;
получить уведомление о просрочке или новом обращении.

Если для каждого действия нужно открыть ноутбук, сотрудники начинают вести часть работы в личных заметках и чатах. CRM перестаёт быть единой системой.

Не переносите весь веб-интерфейс на телефон

Веб-версия подходит для настройки, анализа и массовых операций. Мобильный интерфейс — для быстрых действий в контексте.

Перед разработкой полезно ответить:

Какие роли работают с телефона?
Какие действия они выполняют несколько раз в день?
Какие данные нужны перед звонком или встречей?
Что должно работать при слабом соединении?
Какие действия опасно выполнять одним нажатием?
Какие уведомления действительно требуют реакции?

Так формируется первая версия. В неё не нужно включать каждый отчёт, справочник и настройку веб-системы.

Какие сценарии вошли в направление «Красотули»

В исходном обновлении продукта мы обозначили четыре ключевые области мобильной работы:

таск-трекер;
CRM;
онлайн-запись;
уведомления и рабочие действия на ходу.

Это направление разработки, а не обещание, что все функции уже выпущены в одинаковом объёме. Продуктовые обновления нужно описывать именно так: отделять доступные возможности от находящихся в разработке.

Подробный обзор действующих рабочих сценариев собран в статье о Krasotula CRM для малого бизнеса.

Почему мобильное приложение зависит от инфраструктуры

Приложение не хранит всю бизнес-логику само. Оно обращается к API, получает данные, отправляет изменения, загружает файлы и регистрирует уведомления. Поэтому пользовательское качество зависит от серверной части.

Нужно обеспечить:

стабильный API;
контроль доступа;
предсказуемое время ответа;
обработку повторных запросов;
синхронизацию изменений;
журнал ошибок;
резервное копирование;
мониторинг;
безопасный выпуск новых версий.

Если API медленный или нестабильный, красивый мобильный интерфейс не решит проблему. Если данные могут изменяться с телефона и компьютера одновременно, система должна корректно обрабатывать конфликт.

Переезд «Красотули» на Selectel

В июне 2026 года мы перенесли сервис с Таймвеба на Selectel. Для пользователя это не отдельная кнопка, а изменение фундамента продукта.

Переезд инфраструктуры обычно включает:

подготовку нового окружения;
перенос приложений и данных;
настройку сети и доступов;
проверку резервных копий;
переключение DNS или трафика;
наблюдение после запуска;
план отката.

Мы не публикуем неподтверждённые проценты ускорения или доступности. Корректный результат такого этапа — проверяемая работа критичных сценариев и возможность развивать продукт дальше.

Зачем менять внутреннюю архитектуру

По мере роста CRM новые функции начинают влиять друг на друга. Клиенты связаны со сделками, сделки — с задачами, задачи — с уведомлениями, онлайн-запись — с расписанием и коммуникациями.

Архитектурные изменения нужны, чтобы:

отделить части системы друг от друга;
сделать правила единообразными;
уменьшить количество случайных связей;
безопаснее выпускать новые функции;
упростить тестирование;
снизить технический долг;
подготовить API для мобильного приложения и модулей.

Но «перепишем архитектуру» не должно превращаться в бесконечный внутренний проект. Каждый этап связывается с пользовательским результатом: стабильнее синхронизация, быстрее конкретный сценарий, меньше ошибок при выпуске.

Офлайн-режим: нужен не всем

Полноценная работа без интернета значительно усложняет мобильную CRM. Нужно хранить данные на устройстве, защищать их и разрешать конфликты после восстановления связи.

Поэтому сначала определяют реальные требования:

достаточно ли показать ранее загруженные данные;
нужно ли создавать задачу без связи;
можно ли отложить отправку комментария;
какие сведения нельзя хранить локально;
что делать, если одна карточка изменилась на двух устройствах.

Иногда пользователю достаточно понятного состояния «нет сети» и автоматической повторной отправки. Полный офлайн нужен только там, где это подтверждено условиями работы.

Уведомления должны вести к действию

Если приложение сообщает обо всём, пользователь отключает уведомления целиком. У каждой категории должен быть смысл:

новый лид — открыть карточку и взять в работу;
запись перенесена — проверить расписание;
задача просрочена — изменить план или срок;
клиент ответил — продолжить диалог;
интеграция не сработала — передать инцидент ответственному.

Уведомление не заменяет задачу. Оно помогает вовремя открыть нужный контекст.

Маркетплейс решений вместо бесконечного меню

Малому бизнесу не всегда нужен большой универсальный комбайн. Одному проекту важна аренда инструмента, другому — работа с обращениями на Авито, третьему — сбор коммерческих предложений.

Идея маркетплейса «Красотули» — подключать отдельные решения под конкретные процессы. В исходном обновлении мы рассказывали о направлениях, которые находятся в работе и обкатке:

аренда инструмента;
автоответы на Авито;
сбор коммерческих предложений;
сценарии для сервисных и операционных процессов.

Модульный подход полезен, если у решений есть общая платформа: пользователи, права, клиенты, задачи, уведомления и журнал действий. Иначе маркетплейс превращается в набор несвязанных мини-сервисов.

Как решить, что делать модулем

Отдельный модуль оправдан, когда:

сценарий нужен не всем пользователям;
у него собственные сущности и правила;
его можно включить без изменения базовой CRM;
он использует общих клиентов, задачи или уведомления;
его можно обновлять и отключать независимо;
понятна бизнес-модель и ответственность за поддержку.

Базовые функции — авторизация, права, контакты, сделки и задачи — не стоит дублировать в каждом модуле.

Безопасность мобильной CRM

Телефон можно потерять, передать другому человеку или подключить к небезопасной сети. Минимальный контур включает:

короткую сессию для критичных действий;
отзыв доступа для конкретного устройства;
роли и ограничения данных;
отсутствие секретов в уведомлениях;
защищённое хранение локальных данных;
журнал входов и важных операций;
подтверждение опасных действий;
план обновления уязвимых версий приложения.

Права мобильного пользователя должны совпадать с серверными правилами. Нельзя полагаться только на то, что кнопка скрыта в интерфейсе.

Как запускать мобильное приложение поэтапно

Этап 1. Сценарии

Наблюдаем, что сотрудники реально делают с телефона, и выбираем 3–5 частых действий.

Этап 2. API и права

Проверяем, что серверная часть отдаёт нужные данные, ограничивает доступ и корректно обрабатывает повторные запросы.

Этап 3. Прототип

Тестируем навигацию на реальных ролях до полной разработки.

Этап 4. Ограниченный запуск

Подключаем небольшую группу пользователей, собираем ошибки и измеряем завершение ключевых действий.

Этап 5. Уведомления и надёжность

Добавляем только те уведомления, для которых определено действие. Проверяем слабую сеть и повторную отправку.

Этап 6. Расширение

Новые разделы появляются после подтверждения пользы первой версии.

Что измерять

Количество установок не показывает, помогает ли приложение работе. Полезнее смотреть:

долю принятых с телефона лидов;
время до первого действия по обращению;
завершение ключевых сценариев;
ошибки синхронизации;
повторные отправки;
отключение уведомлений;
частоту использования разделов;
обращения в поддержку по мобильной версии.

Когда мобильная CRM не нужна

Отдельное приложение может быть преждевременным, если:

сотрудники почти всегда работают за компьютером;
мобильная веб-версия закрывает основные сценарии;
процессы ещё не определены;
API нестабилен;
нет ресурсов поддерживать две клиентские платформы;
приложение создаётся только ради присутствия в магазине приложений.

В этом случае лучше сначала улучшить адаптивный интерфейс и серверную основу.

Главное

Мобильная CRM для малого бизнеса начинается не с выбора технологии приложения, а с коротких рабочих сценариев. Затем нужны устойчивый API, понятные права, синхронизация, инфраструктура и управляемые уведомления.

«Красотуля» развивается в этом направлении одновременно с серверной архитектурой и модульными решениями. Если бизнесу нужна собственная CRM или мобильный контур, KorDevTeam начинает с процессов и первой проверяемой версии, а не с копирования всего веб-интерфейса. Подробнее — на странице разработки CRM-систем и в инструкции по внедрению CRM.

Источник первоначального материала: Telegram-канал «Красотуля»

Теги: Мобильная CRM, Малый бизнес, Krasotula CRM, Инфраструктура, Архитектура, Модули Дата публикации: 18 июня 2026

Мобильная CRM для малого бизнеса: как связать приложение, инфраструктуру и модули