Приложение для торговых представителей: визиты, заказы и офлайн

Что нужно приложению торгового представителя: точки, визиты, клиентские цены, заказ без сети, конфликты и подтверждение ERP.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

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

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

Начать с рабочего дня, а не каталога функций

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

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

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

Клиент, торговая точка и адрес

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

Карточка точки содержит рабочий контекст: адрес, часы приёма, контакт, ассортиментные ограничения и последние договорённости в пределах прав. Не перегружайте первый экран всей историей CRM. Представителю нужно быстро понять, к кому он пришёл, что обещано и какие действия доступны сейчас.

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

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

План визитов и фактический результат

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

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

Не превращайте карту в единственное доказательство визита. Геопозиция бывает неточной или недоступной и не подтверждает содержание разговора. Если она нужна для функции продукта, определите конкретный момент запроса и запасной путь. Android различает типы доступа и точность: документация о разрешениях геолокации.

На экране завершения достаточно структурированного результата и следующего действия: заказ оформлен, предложение требуется, клиент не готов, контакт не состоялся. Свободный комментарий дополняет результат, а не заменяет его. Руководитель затем может отличить реальную причину переноса от пустой отметки «выполнено».

Цены клиента и ассортимент

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

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

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

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

Оформление заказа в точке

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

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

Состояния заказа должны различать черновик, очередь отправки, принят сервером и передан в ERP. Если ERP дополнительно подтверждает исполнение, это ещё один результат. Пользователю нужен понятный номер и следующий шаг. Зелёная плашка после локального сохранения не должна выглядеть как окончательное подтверждение поставки.

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

Офлайн как самостоятельный режим

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

Официальное руководство Android рекомендует проектировать офлайн-поведение через локальный источник данных и синхронизацию, учитывая операции записи и конфликты. Источник: offline-first data layer. Для бизнес-приложения важно дополнительно определить, какие действия являются предварительными и когда сервер их принимает.

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

Синхронизация не должна блокировать весь рабочий день из-за одного проблемного заказа. Разделите независимые операции, покажите очередь и причины отказа. Пользователь может открыть конфликт, исправить его и повторить отправку, сохранив исходную историю. Кнопка «синхронизировать всё» без результатов по документам оставляет сотрудника в неведении.

Конфликты после восстановления связи

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

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

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

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

Интеграция с 1С, CRM или другой ERP

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

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

Передача заказа включает идентификатор операции, автора, клиента, строки, единицы, условия и версию расчёта. Ответ сообщает принятый номер и результат проверки. HTTP-успех транспорта не равен проведению документа в ERP. В интерфейсе разделяйте доставку сообщения и бизнес-подтверждение.

Сверка сравнивает отправленные и принятые документы. Для зависших сообщений видны последняя попытка, причина и ответственный за разбор. Повторная отправка не создаёт второй заказ. Если ERP недоступна, очередь сохраняется, а представитель видит честное ожидание вместо ложного результата.

Фотографии, заметки и задачи

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

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

Договорённость должна превращаться в задачу с владельцем и сроком, если требуется действие офиса. Комментарий «отправить предложение» в длинной заметке легко потерять. Представитель видит состояние задачи, а офис — связь с клиентом и визитом. Завершение задачи не меняет задним числом факт визита.

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

Экран руководителя и показатели

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

Разделяйте запланированные, начатые и завершённые визиты; созданные, отправленные и принятые заказы. Иначе после внедрения показатели искусственно вырастут из-за другого момента фиксации. Для сравнения периодов сохраняйте определения и исключайте тестовые операции по согласованному признаку.

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

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

Как проверить приложение в поле

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

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

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

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

Что оставить за пределами первого запуска

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

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

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

Частые вопросы

Нужен ли офлайн в первой версии?

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

Можно ли показывать остаток на телефоне как гарантированный?

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

Достаточно ли встроить каталог в мобильную CRM?

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

Как подтвердить, что представитель был в точке?

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

С чего начать собственный продукт?

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

Связанные материалы

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

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