Админка для мобильного приложения — это веб-панель, через которую ваши сотрудники меняют всё, что видит пользователь, без выпуска новой версии в сторах: баннеры, каталог, акции, тексты, push-рассылки, статусы заказов. Хорошая панель управления приложением повторяет реальные рабочие процессы компании, а не схему базы данных. Ниже разбираем, какие разделы в ней действительно нужны, кто ими пользуется и какие данные лучше вообще не дублировать в админке, а брать из CRM и 1С.
- Админка — часть бэкенда приложения. Если её не спроектировать заранее, любое изменение контента превращается в задачу для программиста и релиз.
- Базовый набор: контент, каталог, заказы или заявки, пользователи, push, роли и журнал действий.
- Товары, цены и остатки живут в 1С, клиенты и сделки — в CRM. Админка их показывает, но не становится вторым источником правды.
- Состав разделов определяется тем, кто и что меняет каждый день, а не списком «как у всех».
Зачем приложению отдельная панель управления
Мобильное приложение нельзя «поправить на лету», как страницу сайта: каждая новая сборка проходит ревью App Store и Google Play, а пользователи обновляются не сразу. Поэтому всё, что меняется чаще раза в квартал, должно приходить с сервера и управляться из админки. Баннер к распродаже, текст условий доставки, порядок категорий на главном экране, список городов с самовывозом — это данные, а не код.
Вторая причина — разделение ответственности. Маркетолог запускает акцию, оператор меняет статус заказа, руководитель смотрит отчёт. Без панели все трое пишут разработчику, и приложение зависит от одного человека. С продуманной админкой разработчик нужен только для новых функций.
Админка — это часть серверной стороны вместе с API и обменом с вашими системами. Её проектирование, как и связку с сайтом, CRM и 1С, мы берём в рамках интеграции и разработки бэкенда для приложения: сначала выясняем, кто и какие данные меняет, затем решаем, что живёт в админке, а что приходит из учётных систем.
Обязательные разделы админки для мобильного приложения
Набор зависит от типа продукта, но у большинства приложений для бизнеса — магазина, сервиса записи, клиентского кабинета — ядро одинаковое.
| Раздел | Что в нём делают | Кто пользуется |
|---|---|---|
| Контент | Баннеры, сторис, тексты экранов, FAQ, политика конфиденциальности, порядок блоков на главной | Маркетолог, контент-менеджер |
| Каталог | Категории, карточки, фото, характеристики, видимость в приложении | Контент-менеджер, товаровед |
| Заказы и заявки | Список, статусы, комментарии, возвраты, отмены | Оператор, менеджер |
| Пользователи | Профили, блокировка, история действий, бонусный счёт | Поддержка, руководитель |
| Push и сообщения | Рассылки по сегментам, расписание, шаблоны триггерных уведомлений | Маркетолог |
| Акции и промокоды | Условия, сроки, лимиты, правила начисления бонусов | Маркетолог |
| Настройки и справочники | Города, точки самовывоза, зоны доставки, минимальная сумма заказа, версии приложения | Администратор |
| Сотрудники и роли | Учётные записи, права по разделам, журнал действий | Администратор |
Управление контентом приложения
Самый недооценённый раздел. Если главный экран собран из блоков, порядок и наполнение которых задаются в админке, маркетинг может менять витрину под сезон без разработки. Если экран «зашит» в код, любая перестановка — это релиз и неделя ожидания. Мы советуем выносить в управляемый контент всё, что связано с продажами: баннеры, подборки, тексты акций, онбординг.
Версии приложения и принудительное обновление
Неочевидная, но важная настройка: минимальная поддерживаемая версия. Когда API меняется, старые сборки должны получить экран «обновите приложение», а не падать. Этот переключатель должен быть в админке, а не в коде сервера.
Роли и права: кто что видит в админ панели для приложения
Ошибка, которую мы чаще всего видим в чужих проектах, — один общий логин на всех. Через полгода невозможно понять, кто отменил заказ или отправил push всей базе в три часа ночи. Минимальная схема ролей выглядит так:
- Администратор — управляет сотрудниками, ролями и настройками, видит журнал.
- Маркетолог — контент, акции, push, но без доступа к персональным данным в полном объёме.
- Оператор — заказы и заявки своего филиала или города, без права массовых рассылок.
- Поддержка — профили пользователей и история обращений, без изменения цен и акций.
- Руководитель — отчёты и просмотр, без редактирования.
Каждое действие в админке пишется в журнал: кто, когда, что изменил и какое было значение до этого. Это защищает и от ошибок, и от злоупотреблений, а при разборе инцидента экономит часы.
Делать массовую push-рассылку одной кнопкой без подтверждения и предпросмотра аудитории. Одна ошибка в сегменте — и уведомление о чужом заказе получают тысячи людей. В админке должно быть видно, сколько человек получат сообщение, а отправка на всю базу — требовать отдельного права.
Когда админку заменяют CRM и 1С
Не всё, что нужно приложению, должно редактироваться в его собственной панели. Если в компании уже есть учётные системы, дублировать в них данные — прямой путь к расхождениям: цена в приложении одна, на кассе другая.
Правило, которое мы фиксируем на этапе архитектуры: у каждого поля есть один источник правды. Типичное распределение такое:
- 1С — номенклатура, цены, типы цен, остатки по складам, статусы отгрузки. В админке приложения эти поля только для чтения.
- CRM (amoCRM или Битрикс24) — клиенты, сделки, статусы заявок, задачи менеджеров. Из CRM в приложение уходят статусы и push клиенту.
- Админка приложения — то, чего нет нигде больше: баннеры, экраны, акции приложения, push-кампании, настройки.
Остатки, цены и статусы синхронизируются по расписанию от 15 минут, заказы и заявки уходят в учётные системы сразу. Если 1С недоступна, заказы встают в очередь и отправляются, когда связь восстановится, — пользователь сбоя не видит. Подробнее о том, из чего складывается серверная часть и сколько она стоит, мы писали в статье о стоимости бэкенда для мобильного приложения.
Бывает и обратная ситуация: у компании нет CRM, а заявки из приложения нужно где-то обрабатывать. Тогда в админке появляется полноценный раздел заявок со статусами и ответственными. Но если менеджеров больше двух-трёх, обычно дешевле подключить приложение к CRM, чем строить мини-CRM внутри админки.
Сколько разделов делать в первой версии
Админка растёт вместе с приложением. Пытаться сразу сделать «всё» — значит потратить бюджет на разделы, которыми никто не пользуется. Мы предлагаем считать по сценариям: какие действия сотрудники выполняют каждый день, какие раз в неделю, какие раз в год.
Отдельный вопрос — внешний доступ. Если с данными приложения должны работать партнёры, дилеры или ваши подрядчики, им нужна не админка, а документированный API с ключами и правами. Такие задачи — связать приложение со старой ERP, банком или службой доставки, открыть API партнёрам — решаются через разработку API и нестандартных интеграций.
Как админка влияет на стоимость и сроки
Панель управления — не бесплатное приложение к коду. Каждый раздел — это экраны, права, проверки и журнал. Но экономия на админке почти всегда оборачивается расходами на поддержку: если контент меняет разработчик, вы платите ему часами каждый месяц.
У нас серверная часть и интеграции оцениваются по функциям. Формат «CRM + аналитика» — события приложения в amoCRM или Битрикс24, push из CRM, сквозная аналитика — стоит от 1 500 000 ₸ и занимает около 4 недель. «Полный контур» с единым профилем на сайте и в приложении, обменом с 1С, платежами и документацией API — от 3 000 000 ₸, 6–8 недель. Ориентиры по всем направлениям собраны на странице цен на мобильные приложения.
Покажем на аудите, какие данные вашему приложению брать из 1С и CRM, а какие вести в собственной админке, — и посчитаем смету по разделам.
Обсудить бэкенд и админкуЧто проверить в админке перед запуском приложения
Перед релизом мы проходим по панели вместе с людьми, которые будут в ней работать. Это занимает пару часов и экономит недели переписки после запуска.
- Дать каждой роли реальную задачуОператор меняет статус заказа, маркетолог публикует баннер, поддержка находит пользователя по телефону. Если на задачу уходит больше минуты — интерфейс нужно упростить.
- Проверить праваЗайти под каждой ролью и убедиться, что лишнего не видно: маркетолог не меняет цены, оператор не делает рассылок.
- Проверить журналИзменить пару полей и найти эти изменения в журнале с автором и временем.
- Проверить синхронизациюПоменять цену в 1С и статус в CRM — и увидеть их в приложении в заданный интервал.
- Описать регламентКто отвечает за контент, кто за push, кто выдаёт и отзывает доступы при увольнении сотрудника.
После запуска админку, как и само приложение, нужно развивать: появляются новые акции, разделы, роли. Это удобно делать в рамках поддержки и доработки приложения — пакетом часов спринтами по две недели, с демо и релизом.
Что делать дальше
Начните со списка: кто в компании будет менять что-то в приложении и как часто. Рядом выпишите системы, где уже живут товары, цены, клиенты и заказы. Эти два списка и определяют состав админки: всё, что уже есть в 1С и CRM, приложение забирает оттуда, всё остальное получает свой раздел в панели. С таким документом разговор с подрядчиком становится предметным, а смета — проверяемой.
Можно ли использовать готовую админку вместо разработки своей?
Для простого контента — да, существуют готовые headless-CMS. Но заказы, роли, push по событиям и обмен с 1С всё равно потребуют разработки. Обычно выгоднее единый бэкенд, где контент и бизнес-логика управляются из одной панели.
Нужна ли админке мобильная версия?
Для операторов и курьеров, которые меняют статусы на ходу, — да, хотя бы адаптивная. Маркетинговые разделы удобнее на компьютере, их можно оставить десктопными.
Кто будет владельцем админки и данных?
Вы. Код, сервер и доступы оформляются на вашу компанию, бэкенд размещается на ваших серверах или в облаке в Казахстане, доступ сотрудников — по ролям.
Можно ли управлять push-уведомлениями из CRM, а не из админки?
Да. Триггерные push по смене статуса сделки или заказа удобнее отправлять из amoCRM или Битрикс24, а маркетинговые рассылки по сегментам — из админки приложения.
