Мобильное приложение для автоматизации работы мастеров сервисной компании

Компания «Ленремонт» — один из крупнейших игроков на рынке бытового ремонта в Санкт-Петербурге и Ленобласти. В штате — более 2000 мастеров, главных участников бизнес-процессов, ежедневно обслуживающих десятки тысяч клиентов.

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

Компания обратилась в Aiston с запросом на разработку нового мобильного приложения — решения, которое будет соответствовать текущим бизнес-процессам и помогать мастерам в работе.

В проект заложили задачи:

— автоматизировать работу мастеров: ускорить приём заказов, фиксацию статусов и передачу данных;

— дать руководству инструмент контроля: собрать в одном месте загрузку, статусы и метрики;

— повысить скорость и качество сервиса: сократить задержки и улучшить коммуникацию с клиентом;

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

Чтобы решить задачу, мы совместно с командой Ленремонта описали все этапы работы мастера — от получения заявки до сдачи отчёта. На основе этого построили цифровую модель процессов, спроектировали логику работы приложения и разработали интерфейс, который учитывает реальные условия и задачи сотрудников на выезде.

В фокусе были:

— полная фиксация данных по каждому заказу;

— линейная, прозрачная структура выполнения работ;

— простота использования и встроенная система мотивации через геймификацию.

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

В этап предпроектного исследования вошли три фокуса — анализ, описание, конкуренты. 

1. Анализ процессов.

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

Совместно с командой Заказчика выявили ключевые проблемы:

— фиксация начала работ часто происходила с задержкой или не проводилась вовсе;

— часть задач выполнялась вне приложения, что нарушало целостность отчётности; 

— отсутствие подтверждения визита приводило к холостым выездам и потере времени.

2. Описание сценариев.

На основе собранных наблюдений и интервью сформировали сквозной маршрут работы мастера — от назначения заказа до его завершения и сдачи отчёта. 

Этот процесс стал основой для дальнейшего проектирования.

3. Конкуренты.

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

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

Такой подход хорошо совпал с задачей «Ленремонта» — сократить время реакции мастера, ускорить выполнение работ и поддерживать уровень сервиса, соответствующий девизу компании: «Починим всё».

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

— Получение и назначение.

Заявки попадают в приложение через автоподбор или вручную от диспетчера. Раньше процесс принятия заявки был фрагментированным и неудобным: нужная информация разбросана по экранам, мастер тратил время на навигацию и уточнения. 

Теперь мастер видит push-уведомление или может открыть заказ из списка. Если заказ уже занят другим мастером, система уведомит об этом. При пропуске заказа требуется указать причину — это формирует управляемую статистику отказов. 

Всё сосредоточено в одном экране для ускорения реакции — адрес, описание, контакты и карта доступны сразу. Логика экрана настроена на быстрое принятие решения без лишних переходов.

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

— Подтверждение визита. 

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

Можно добавить план звонка в календарь, а при договорённости — зафиксировать дату и интервал визита. Для нештатных ситуаций (отмена, невозможность дозвониться, перенос) предусмотрен специальный сценарий с комментарием. Мы исключили риски потерь и «зависших» без статуса заказов.

— Выполнение работ.

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

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

— Закрытие и отчёт.

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

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

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

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

Каждый раздел приложения — это не просто группа функций, а часть рабочего сценария.

— Монитор.

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

Здесь же — быстрый доступ к достижениям и соревнованиям, встроенным в геймификацию.

— Доступные заказы.

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

Сделали так, чтобы мастер понимал суть заказа уже на первом экране: тип задачи, клиент, адрес и условия — всё считывается за секунды.

— Текущие заказы.

В этом разделе отображаются активные заявки, с которыми мастер уже работает. 

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

— Карточка заказа.

Центр управления заявкой. Всё, что касается работы по конкретному заказу, сосредоточено здесь: история звонков, визиты, этапы выполнения, подтверждение оплаты, сообщения с диспетчером. 

Всё организовано по вкладкам, привязанным к этапам бизнес-процесса — от подготовки до завершения.

— Профиль.

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

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

— Инструменты и поддержка.

Отдельный блок с доступом к чату, справочным материалам и финансовым расчётам. 

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

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

По итогу проекта: 

— Сформировали полную цифровую модель процессов от заявки до отчёта.

— Спроектировали интерфейс, который отражает реальные сценарии работы мастеров.

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

— Подготовили прототип, готовый к разработке: с логикой, экранами и пользовательскими сценариями.

— Обеспечили основу для масштабируемого и управляемого цифрового инструмента.