Задание не обрывается на календаре.
Наш вывод: в своём приложении нужно определить, что происходит после визита. Иначе расписание будет удобным, а отчёты продолжат собирать вручную.
BORNLI / о разработке по делу
Приложение для выездных специалистов.
От назначения мастера до принятого отчёта. Показываем концепцию для сервисной компании, разбираем решения Jobber и определяем, что нужно вашей первой версии.
Концепция BORNLI · модельный сценарий
Заявка → выезд → отчёт
Рабочий день.
Без потерянных заданий.Три экрана для обсуждения первой версии
Без потерянных заданий.Три экрана для обсуждения первой версии
План на день
Сначала — ближайший визит.
09:00–10:30Проверка вентиляции
11:00–12:30 · следующийОфис · оборудование V-12
Отчёт принятОбслуживание кондиционера
Магазин · оборудование K-04
Назначено вамОткрыть задание ↗
Всё по заданию
Инструкции, оборудование и контакт.
- Вход со двора · второй этаж
- Чек-лист обслуживания
- Фото результата
Работы и материалы
сохранены в черновик
сохранены в черновик
Передать отчёт ↗
Можно проверить
Результат привязан к заявке.
Задание № 024
Работы, материалы, фотографии
Ожидает проверки- Чек-лист заполнен
- Вложения получены
- Счёт — после проверки
Проверить результат ↗
Задача бизнеса
Одна заявка связывает офис и мастера.
Представим сервисную компанию: диспетчер принимает обращения, назначает специалистов и проверяет выполненные работы. Мастера ездят на объекты, заполняют отчёты и передают фотографии. Если сообщения, расписание и документы хранятся порознь, сотрудникам приходится вручную сопоставлять их.
В нашей концепции у задания есть единый номер, исполнитель и история. Мастер открывает ближайший визит, видит доступ и инструкции, фиксирует результат. Диспетчер принимает отчёт или возвращает его с конкретным замечанием. После приёмки можно передать согласованные данные в CRM или учётную систему.
Для начала выбираем один тип выезда: например, плановое обслуживание. Разовые ремонты, повторные визиты и работа нескольких бригад могут потребовать других правил. Их стоит описать до добавления новых экранов.
Разбор существующего продукта
Jobber: полезен связный путь от заявки до оплаты.
Jobber — самостоятельный продукт для сервисных компаний. По его официальному описанию можно изучить расписание, назначение сотрудников, инструкции и чек-листы, клиентский портал, выставление счетов и статусы работ. Источник и экраны Jobber ↗
Здесь мы разбираем публичные материалы Jobber. Не заявляем участие BORNLI в разработке этого продукта.
Инструкция рядом с работой.
В концепции прикрепляем чек-лист к заданию. Требования зависят от услуги: для осмотра нужны одни поля, для ремонта — другие.
Каждый видит следующий шаг.
Мастеру — ближайшее задание, диспетчеру — исключения и отчёты на проверку. Общий список всех функций уступает место рабочей задаче.
Сначала сравните с готовым сервисом.
Если существующий продукт подходит по процессу, доступности и интеграциям, отдельная разработка может не понадобиться. Свой продукт имеет смысл оценивать под конкретные отличия бизнеса.
Границы первой версии
Сначала замкнём один рабочий цикл.
Что проверяем в MVP
- Вход мастера и доступ только к назначенным заданиям.
- Список визитов, карточка объекта и контакт клиента.
- Статусы: назначено, в работе, на проверке, принято.
- Чек-лист, комментарий и фотографии результата.
- Кабинет диспетчера: назначение, перенос, возврат отчёта.
Что оцениваем отдельно
- Обмен с вашей версией 1С, CRM или ERP.
- Работу без сети и разрешение конфликтов данных.
- Учёт остатков, резервирование и списание запчастей.
- Платежи, документы и подписи.
- Оптимизацию маршрутов и непрерывную геолокацию.
Это предложенный состав для обсуждения, а не пакет с фиксированной ценой. В материале о MVP разбираем, как выбрать первую работающую версию и не перегрузить её функциями.
Приёмка на реальных ситуациях
Проверяем не только удачный выезд.
Ниже — наш лист проверки для этой концепции. Эти сценарии стоит включить в требования и испытать на пилоте.
Черновик остался у мастера.
Заполнить отчёт, отключить сеть и закрыть приложение. После открытия данные должны сохраниться, а статус — явно показывать, что отправка ещё не подтверждена. Офлайн-работу включаем в объём отдельно.
Один отчёт не стал двумя.
Отправить результат повторно после тайм-аута. В кабинете должен появиться один отчёт по заданию; повтор не должен создавать второй счёт или списание материалов.
Старое время не осталось единственным.
Диспетчер меняет время, пока мастер смотрит карточку. При обновлении приложение показывает актуальный визит и изменение. Для работы без сети нужно заранее решить, когда предупреждать о возможной неактуальности данных.
Понятно, что исправить.
Передать результат без обязательного фото. Приложение должно показать незаполненное поле и сохранить остальное. Возврат диспетчером сопровождается комментарием и понятным статусом.
Как оценить пилот: до запуска и после него сравнить время оформления отчёта, число возвратов и долю заданий с полными данными. Это предлагаемые показатели, а не заявленные результаты клиентов BORNLI.
Смета и интеграции
Оцениваем процесс за экранами.
Типовой проект BORNLI для iOS и Android — 300 000 ₽ в согласованном объёме. Сложные проекты — от 450 000 ₽, экосистемы — от 600 000 ₽. Приложение для выездного сервиса нельзя автоматически отнести к первому тарифу: кабинет диспетчера, интеграции и работа без связи влияют на объём.
Для оценки нужны пример задания и отчёта без персональных данных, роли сотрудников, используемая учётная система и список обязательных действий. Если нужен обмен с CRM, сначала выясняем, где создаётся заявка, кто меняет её статус и как система подтверждает получение результата.
Срок 30 дней относится к типовому согласованному проекту после утверждения задачи и материалов. Для более сложного процесса срок и этапы определяются отдельно. Подробности — на странице стоимости разработки мобильного приложения.
Перед оценкой
Три частых вопроса.
Нужно ли отдельное приложение клиенту?
Не всегда. В этой концепции сначала делаем рабочее место мастера и кабинет диспетчера. Для клиента может хватить страницы со статусом или уведомления. Отдельное приложение имеет смысл обсуждать, когда у клиента появляются регулярные действия: заявки, согласования, оплата, история обслуживания.
Можно ли подключить существующую CRM или 1С?
Возможность и стоимость определяем после проверки конкретной системы, доступных интерфейсов обмена и прав доступа. Название CRM само по себе не гарантирует готовую интеграцию. Для обсуждения полезны документация и тестовая среда.
Что можно проверить ещё до разработки?
На кликабельном прототипе — порядок действий, понятность статусов и состав карточки задания. Сохранность данных без сети, синхронизацию и обмен с учётной системой проверяют уже на рабочей реализации. Посмотрите разбор проверок на примере прототипа AVIOKI.
От идеи к конкретике
Покажем, как может работать ваш продукт.
Обсудим задачу и материалы, затем подготовим бесплатный кликабельный прототип за 24 часа. До договора.
Обсудить прототип ↗