Короткий ответ: когда нужно приложение для выездов
Если сотрудник получает задания по телефону, хранит фото в чате, а акт заполняет после возвращения в офис, начните с маршрута одного выезда. В нём должны быть назначение, сведения об объекте, действия на месте, использованные материалы, подтверждение результата и его получение офисом. Мобильное приложение полезно, когда этот путь повторяется и потери между шагами мешают работе.
Заказывать отдельный продукт сразу необязательно. Готовые полевые системы уже умеют показывать задания и фиксировать работу. Сначала проверьте их на вашей заявке, включая участок без сети. Если нужный акт, правила материалов или обмен с вашей системой приходится постоянно обходить вручную, обсуждайте собственный мобильный модуль. Он может работать рядом с существующей CRM — системой учёта клиентов и заявок — без полной замены офиса.
Что сотрудник должен получить до выезда
Для мастера полезна не вся база компании, а сведения, с которыми он сможет выполнить конкретное задание: адрес и контакт, окно визита, описание проблемы, историю оборудования, необходимые материалы и действия, которые нужно подтвердить. Если диспетчер поменял время или исполнителя, телефон получит новую версию при связи. Без сети свежая правка не гарантирована: покажите время последней загрузки и предупредите, что задание могло измениться.
На объекте человек должен быстро отметить прибытие, открыть чек-лист и зафиксировать результат, даже когда связь слабая. Длинная офисная форма на маленьком экране вынуждает пропускать поля. Покажите будущий прототип одному сотруднику в перчатках или с занятыми руками: сможет ли он снять фото и вернуться к заданию без поиска по меню? Это проверка удобства, не замена тесту данных.
Что мы уже связали в реальном проекте
В проекте «Бакаев» мы сделали мобильный магазин и панель управления доставкой. Администратор видит активные заказы, назначенных курьеров и их движение на карте; покупатель видит статус своего заказа. Это пример связанного пути между человеком в дороге и офисной системой. Для сервисного инженера к такой логике потребуется добавить историю оборудования, выполненные работы, материалы и акт. Работу без сети нужно проектировать и проверять отдельно.
Реальный проект 13FOX
«Бакаев»: заказ и курьер видны команде
Мы связали мобильный магазин, админ-панель и доставку. В панели видны активные заказы, назначенные курьеры и карта; покупатель видит статус и движение заказа.
Карта в таком сервисе имеет смысл, потому что доставка и статус курьера входят в пользовательский путь. Для ремонтной бригады постоянная геолокация может не помогать выполнению работы. Сначала определите, кому и зачем нужна точка на карте; на iOS доступ к местоположению требует разрешения пользователя, что отдельно описывает Apple Developer.
Скопируйте карту одного выезда
Возьмите вчерашнюю заявку без личных данных и заполните строки под свой процесс. Эта таблица пригодится как первая часть технического задания. Она заставляет назвать не только экран сотрудника, но и момент, когда офис получает подтверждённый результат.
| Момент | На телефоне сотрудника | В общей системе | При потере и возврате связи |
|---|---|---|---|
| До выезда | Адрес, контакт, проблема, история объекта, план работ | Диспетчер назначил исполнителя и версию задания | Видны последняя загруженная версия и время загрузки; новая версия без сети не гарантирована |
| На объекте | Статус прибытия, чек-лист, замеры и фото | Офис видит только принятую сервером запись | Изменения сохранены на телефоне и помечены как неотправленные |
| Материалы | Что планировали и что фактически использовали | Расход сверяют с учётом по согласованному правилу | Запись ждёт передачи; остаток склада не объявляют окончательным |
| Завершение | Результат, фото после работ, комментарий и акт | Ответственный принимает или возвращает результат | Акт остаётся черновиком до приёма сервером и проверки |
| После связи | Видно, что отправлено, принято или требует исправления | У заявки одна понятная история с версиями | Повторная отправка не создаёт второй выезд или второй расход |
Названия полей могут отличаться. Для доставки нужен получатель и статус передачи. Для обслуживания оборудования важнее серийный номер и история ремонтов. Рядом с этапами укажите ответственных: диспетчер назначает выезд, сотрудник фиксирует работу, руководитель сервиса принимает акт или возвращает его с причиной. Не копируйте весь офисный справочник на каждый телефон: определите, что сотруднику действительно нужно на его заданиях и что удалять после завершения работы.
Фото, материалы и акт должны отвечать на разные вопросы
Фото показывает состояние объекта до и после работы, но без номера заявки и подписи к кадру его трудно найти. Записывайте, к какому выезду и этапу оно относится, кто его добавил и когда. Если сотрудник переснял неудачный кадр, важно не оставить в истории неясные версии. Сотруднику нужны простые подсказки: что именно сфотографировать и где посмотреть уже сохранённое.
Материалы влияют на учёт. Разделяйте «взял с собой», «установил на объекте» и «вернул». Если приложение без сети просто списывает деталь со склада, офис может увидеть неверный остаток до синхронизации. Согласуйте с бухгалтерией и складом, какой шаг подтверждает фактический расход и какая система остаётся источником остатка.
Акт или сервисный отчёт фиксирует выполненные работы и решение клиента. Готовый Dynamics 365 Field Service, например, умеет собрать отчёт с работами и деталями, получить подпись на экране и выдать PDF при соответствующей настройке. Это показывает, что форма отчёта доступна без заказной разработки. Если документ должен иметь особый юридический статус, его требования нужно согласовать отдельно до выбора способа подписи.
Работа без интернета: сохранено на телефоне не значит принято офисом
Для офлайн-режима заранее загрузите нужные сотруднику задания и справочники, а новое действие сначала надёжно сохраните на устройстве. Приложение показывает понятные состояния: «сохранено на телефоне», «отправляется», «принято» или «требует внимания». «Сохранено на телефоне» означает, что запись ещё не дошла до офиса. Если телефон потеряется или сломается до передачи, данные могут пропасть. Мастер может закончить работу на объекте без сети, но офис не закрывает заявку до состояния «принято» и проверки акта. Когда связь вернулась, очередь передаёт записи и не повторяет одну и ту же операцию как новую. Android Developers описывает локальную запись и последующее согласование данных как отдельные задачи офлайн-архитектуры.
Кто следит за зависшими записями: назначьте в офисе ответственного за очередь после смены. Он видит, какие выезды всё ещё «на телефоне» или «требуют внимания», связывается с исполнителем и не принимает акт молча. Сотрудник тоже должен видеть, что результат не получен офисом, и сообщать о долгом сбое по согласованному каналу. Конкретный срок и канал задайте в своём регламенте.
Представьте, что диспетчер отменил визит, пока инженер без сети отметил работу завершённой. Простое правило «последняя запись победила» может скрыть одно из решений. Для такого конфликта задайте бизнес-правило: показать обе версии ответственному, не списывать материал автоматически и сообщить инженеру, что итог требует разбора. Документация Microsoft тоже приводит конфликт изменений задания сотрудником и диспетчером как реальный случай синхронизации.
Проверка без сети: загрузите задание, включите авиарежим, добавьте фото и расход детали, закройте приложение и откройте снова. Записи должны остаться на телефоне с ясным статусом. После восстановления связи проверьте офисную карточку, затем повторите отправку: дубль расхода или акта появляться не должен.
Когда хватит готовой системы, а когда нужен свой модуль
У готовых продуктов уже есть значительная часть полевого процесса. Например, официальный обзор Microsoft Field Service перечисляет назначенные работы, маршрут, сервисные записи и настройку офлайн-данных. В текущей документации отдельно указано, что обновлённый мобильный интерфейс не поддерживает офлайн; нужный режим и конфигурацию надо проверять до закупки. Другие продукты и тарифы имеют свои условия.
| Вариант | Когда начинать | Что испытать на своей заявке |
|---|---|---|
| Готовая полевая система | Типовые задания, фото, чек-листы, отчёты и роли | Ваш акт, материалы, права и офлайн-режим выбранной версии |
| Мобильный модуль к CRM (системе учёта клиентов и заявок) | Офисная система подходит, но на объекте работать неудобно | Передачу статусов, фото и материалов в действующую карточку |
| Свой сервис выездов | Маршрут, документы и интеграции не собираются из готовых частей | Границы первой версии, владение данными и стоимость поддержки |
Тестируйте не презентацию продукта, а одну обезличенную заявку. Дайте сотруднику телефон, диспетчеру офисный экран и пройдите путь с отключённой связью. Если готовая система справляется без постоянной ручной переписки, заказной код можно отложить. Если разрыв остаётся только в одном действии, отдельный модуль часто понятнее полной замены CRM. Для маршрута обращения до выезда пригодится статья о системе учёта заявок.
Из чего складывается смета разработки
Сравнивайте предложения по одинаковым блокам работ. Сначала разбор ролей и маршрута выезда, затем интерфейс сотрудника и диспетчера, сервер и данные, интеграции с CRM или 1С, офлайн-хранение и передача, тесты на реальных устройствах, запуск и поддержка. Без решения о том, какие данные доступны без сети и как разбирать конфликт, точная цена будет лишь предположением.
Особенно спросите, что входит в проверку: прерывание загрузки фото, повтор отправки, изменение задания в офисе, нехватка памяти телефона, смена устройства и потеря доступа сотрудником. Если нужны разные версии для iOS и Android, складской учёт или сложные карты, это должно быть видно отдельными строками. Общий цикл мобильного проекта разобран в статье о приложении под ключ; для выездной работы к нему добавляются офлайн-очередь и испытания на устройствах.
Контрольный выезд перед запуском
Выберите одну заявку с фото и материалом. Пусть диспетчер назначит исполнителя, а сотрудник откроет задание на телефоне. Далее выполните проверку как рабочую смену, а не как показ нескольких экранов:
- До выезда. Нужные сведения загрузились; сотрудник видит версию задания и адрес.
- Без сети. Сотрудник меняет статус, добавляет фото и расход материала, закрывает и снова открывает приложение. Данные остаются на телефоне.
- Возврат сети. Записи переходят из «не отправлено» в «принято»; офис видит фото, расход и время. Повтор отправки не создаёт дубль.
- Конфликт. Пока телефон офлайн, диспетчер меняет задание. После синхронизации обе стороны видят, что требуется решение, а не молчаливую потерю одной версии.
- Приёмка. Ответственный в офисе проверяет акт, принимает его или возвращает с причиной; сотрудник понимает следующий шаг.
Запишите ожидаемый результат для каждого шага и имя того, кто его принимает. Так же можно проверить готовый продукт до покупки и свой модуль перед выпуском. Итогом должен быть один понятный выезд в общей истории, а не набор не связанных между собой фото, сообщений и таблиц.
Частые вопросы
Можно ли взять готовое приложение для выездных сотрудников?
Да. Готовые полевые системы уже поддерживают задания, фото, материалы и отчёты. Проверьте на одной вашей заявке роли, нужный акт, интеграцию и конкретную конфигурацию офлайн-режима. Свой модуль имеет смысл, если важный переход нельзя настроить без постоянного ручного обхода.
Что должно работать без интернета?
Минимум определите сами по рабочему процессу: обычно это просмотр заранее загруженного задания, запись выполненных действий, фото и расхода материалов. Приложение должно явно показать, что сохранено на телефоне и что принято офисом после синхронизации. Новые адреса и данные из внешних систем без сети могут быть недоступны.
Нужна ли геолокация каждому сотруднику?
Нет. Если для выезда хватает адреса в задании и отметки результата, постоянное отслеживание может быть лишним. Если карта действительно нужна диспетчеру или клиенту, объясните цель, время использования и права доступа; система должна учитывать разрешение владельца устройства.
Что нужно для оценки разработки?
Дайте одну обезличенную заявку, список действий сотрудника на объекте, образец акта, данные о материалах, названия CRM или учётной системы и пример зоны без связи. По этому набору можно оценить готовую настройку, отдельный мобильный модуль и проверки после запуска.
Источники и дата проверки
- Android Developers: локальная запись и синхронизация офлайн-приложения.
- Microsoft: возможности мобильного Field Service.
- Microsoft: задания, материалы и вложения на выезде.
- Microsoft: синхронизация и конфликты.
- Microsoft: сервисный отчёт.
- Apple Developer: разрешение на местоположение.
Документация и состав готового продукта проверены 23 сентября 2026 года. Перед выбором сервиса проверьте действующую версию и нужный режим на своём процессе.
Разберём один выезд до оценки
Оставьте номер для короткого разговора. На нём опишите один выезд и место, где пропадает связь; обезличенную заявку и образец акта можно передать позже. Мы разложим действия сотрудника и офиса, проверку готового продукта и границы собственного модуля.
Для первого разговора не нужны пароли и доступы к рабочим системам.