Практический гид
CRM ведёт отношения и историю взаимодействия с клиентом, а SFA управляет исполнением полевой продажи: маршрутом, визитом, заказом и фактом работы в торговой точке. Эти классы могут дополнять друг друга, если у каждого определены собственные данные и ответственные процессы.
Сравните отношения с клиентом, работу в точке и обмен между ними. Функции конкретных продуктов могут пересекаться: сначала проверьте, какие задачи уже решает ваша система.
CRM собирает историю контактов, обращений, возможностей и договорённостей вокруг клиента или аккаунта.
В полевых продажах SFA помогает вести маршрут, задания и результаты визита. Что считать выполненной работой, определяют правила вашего процесса.
Если отдельные системы действительно нужны, согласуйте передачу назначений и результатов. Состав данных и направления обмена определяются задачами проекта.
Нужна ли отдельная SFA, если CRM уже есть? Сначала проверьте ваш рабочий сценарий в действующей системе. Названия классов не задают жёсткую границу: SFA-функции могут входить в CRM. Здесь речь о полевых продажах FMCG/CPG: маршруте, визите, работе с полкой и заказе. Связка двух систем оправданна, когда она закрывает подтверждённый пробел, а не потому, что считается более зрелой архитектурой.
Сравнивайте действия сотрудника, а не число экранов. Может ли он получить актуальное задание, выполнить сценарий визита и передать результат без повторного ввода? Если нужна работа без связи, проверьте её отдельно, включая отправку после восстановления сети. GPS и фото помогают проверить обстоятельства визита, но сами по себе не доказывают выполнение всех задач. Запись об оплате также требует сверки с ответственным источником финансовых данных.
Схема показывает типовую границу. Конкретный владелец клиента, заказа и финансового документа фиксируется в интеграционной карте проекта.
Контакт, обращение и коммерческая договорённость получают ответственного.
Понятно, зачем действоватьКлиент и согласованная задача передаются полевой команде по внешнему ID.
Получатель принял задание?Точка попадает в план посещений с частотой, приоритетом и сценарием визита.
Действие запланированоСотрудник записывает результат и материалы визита. Их проверяют по согласованным правилам.
Результат требует проверкиПолучение заказа, его принятие и отгрузка - разные этапы. Отказ и частичное исполнение учитываются отдельно.
Какой этап подтверждён?Следующему участнику нужен понятный статус с источником и временем, а при расхождении - ответственный.
Итог сверён с источником?Разделите этапы заказа: сохранён у сотрудника, получен другой системой, прошёл её проверки, подтверждён к исполнению, отгружен. Отправка сообщения не подтверждает отгрузку. Если ответ потерян, результат может быть неизвестен: перед повтором выясните, принят ли исходный заказ, и проверьте защиту от повторного создания. Частичное принятие, отказ и частичная отгрузка должны иметь понятные статусы и ответственного.
Для каждой группы согласуйте основной источник и право изменения. Ниже - пример распределения ответственности, который нужно проверить на вашем процессе.
Клиентский аккаунт, юридическое лицо и торговая точка - разные сущности. Например, одна сеть может включать несколько юрлиц и магазинов. Согласуйте отдельные идентификаторы, связи между ними и правила исправления дублей. Для реквизитов, договорённостей, заданий и документов укажите, какой источник считается основным и кто вправе менять каждое поле. Место первого ввода не всегда определяет владельца всех последующих изменений.
В карте обмена нужны исходные справочники, последующие изменения и сверка результата. Для каждого потока зафиксируйте получателя, нужные поля, права доступа, версию, допустимую задержку и порядок разбора ошибок. При изменении адреса точки или условий заказа заранее определите, какое значение применять. Не отправляйте всю историю коммуникаций, если следующему процессу достаточно задания и ссылки на клиента.
Это разные рабочие сценарии, а не уровни зрелости. Сравните возможности действующей системы, нужные доработки и стоимость сопровождения каждого варианта.
Сопоставьте аккаунт, юрлицо, точку и документ. Проверьте несколько магазинов одного клиента и исправление дубля.
Укажите источник каждого поля, права доступа, версию и допустимую задержку. Проверьте конфликт изменений.
Если ответ потерян, сначала выясните результат исходной операции. Проверьте, что разрешённый повтор не создаёт второй заказ.
Назначьте ответственного за отказ или расхождение. После исправления повторно сопоставьте документы, строки и статусы.
Начните с этих вопросов, затем подготовьте примеры для проверки. Не передавайте реальные клиентские данные для первичного обсуждения.
В коммуникации с аккаунтом, в повторяемом визите или в обоих процессах.
Для клиента, точки, маршрута, визита, заказа и итогового статуса.
Исходные справочники и изменения, необходимые получателю; отдельно - права доступа и порядок сверки.
Различаются отказ и неизвестный результат; согласованы проверка исходной операции, безопасный повтор и ответственный.
Сопоставить исходный процесс и пилот на согласованном участке: повторный ввод, полноту данных, задержки, ошибки и стоимость сопровождения.
До выбора решения подготовьте обезличенные примеры обычного визита, заказа с ошибкой и спорного изменения карточки. На одном согласованном участке сравните исходный процесс и пилот по повторному вводу, полноте обязательных данных, задержке статусов и времени разбора исключений. Сохраните одинаковые определения показателей и учитывайте состав команды, нагрузку и связь. В оценку стоимости включите настройку, обучение и сопровождение обмена. Это критерии проверки, а не обещание роста продаж.
Зафиксируйте конкретную потерю в текущем процессе: повторный ввод, недоступное задание или непонятный статус. Укажите, кому и когда это мешает.
Покажите тот же сценарий в действующей системе. Отделите недостающую функцию от ошибки настройки, данных или обучения.
Подготовьте обезличенные карточки аккаунта, юрлица и торговой точки. Назначьте основные источники и правила изменения полей.
Для выбранного потока проверьте обычную отправку, повтор, потерянный ответ и частичный результат. Заранее согласуйте порядок сверки.
Определите критерии приёмки пилота, исходные показатели и владельца каждого исключения. Отдельно оцените затраты на сопровождение.
Для обсуждения Smartup принесите карту процесса, перечень систем и примеры спорных статусов. По ним можно определить, что нужно проверить на демонстрации и какой обмен требуется проекту.
Это схема выбора и проверки архитектуры, а не подтверждение готовой интеграции с вашей CRM. Функции систем могут пересекаться; состав обмена и ответственность за документы нужно проверить для конкретного проекта.
