Корпоративное мобильное приложение для управления заявками

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

До внедрения приложения основная информация о заявках передавалась через несколько каналов: сотрудники получали задания в корпоративной системе, уточняли детали по телефону или в мессенджерах, а статусы выполнения передавали диспетчеру вручную.

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

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

Требовалось реализовать:

авторизацию сотрудников;

список назначенных заявок;

фильтрацию по статусам;

карточку заявки;

адрес и контактные данные клиента;

маршрут до объекта;

статусы выполнения;

чек-листы;

комментарии;

фотографии и документы;

push-уведомления;

частичную работу без интернета;

последующую синхронизацию данных;

интеграцию с корпоративной backend-системой.

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

Этап 1. Анализ рабочего процесса

Перед началом разработки подробно разобрали существующий процесс обработки заявки.

Проследили полный жизненный цикл:

создание заявки → назначение сотрудника → выезд → выполнение → фиксация результата → закрытие заявки.

Определили, какие данные сотруднику действительно необходимы на каждом этапе, а какие можно оставить только в административной системе.

Это позволило избежать перегруженного корпоративного интерфейса.

Этап 2. Проектирование приложения

Главным разделом приложения сделали список заявок.

Заявки разделили по статусам:

• новые;

• принятые;

• в работе;

• отложенные;

• завершенные.

В карточке заявки собрали всю необходимую для сотрудника информацию:

• адрес;

• контакты;

• описание проблемы;

• приоритет;

• время выполнения;

• инструкции;

• вложения;

• историю изменений.

Этап 3. UX/UI для полевых условий

Интерфейс проектировали с учетом использования приложения непосредственно на объекте.

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

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

Также предусмотрели состояния плохого интернет-соединения.

Этап 4. Мобильная разработка

Клиентское приложение реализовали на Flutter.

Для бизнес-логики использовали BLoC, сетевое взаимодействие организовали через Dio.

Структуру проекта разделили по функциональным модулям:

• авторизация;

• заявки;

• профиль;

• документы;

• уведомления;

• синхронизация.

Это позволило независимо развивать отдельные части корпоративного продукта.

Этап 5. Интеграция с корпоративной системой

Приложение связали с backend API заказчика.

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

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

Этап 6. Офлайн-режим

Так как часть объектов могла находиться в местах с нестабильным интернетом, реализовали локальное хранение основных данных заявки.

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

Действия сохранялись локально, а после восстановления соединения приложение отправляло накопленные изменения на сервер.

Этап 7. Маршруты и работа с объектами

В карточку заявки добавили адрес объекта и возможность открыть маршрут.

Для сотрудников это исключило необходимость вручную переносить адрес в стороннее приложение.

Также предусмотрели быстрый доступ к контактам клиента непосредственно из карточки заявки.

Этап 8. Уведомления и изменение статусов

Push-уведомления использовали для информирования сотрудников о:

• новых заявках;

• изменении приоритета;

• переносе времени;

• отмене заявки;

• комментариях диспетчера.

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

Этап 9. Тестирование

Особое внимание уделили сценариям, связанным с нестабильным интернет-соединением и синхронизацией данных.

Проверили:

• работу без сети;

• повторную отправку изменений;

• восстановление сессии;

• одновременное изменение заявки;

• push-уведомления;

• корректность отображения больших объемов данных.

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

В результате был создан единый мобильный инструмент для работы выездных сотрудников с заявками непосредственно на объектах.

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

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

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

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

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