CRM ведёт отношения и историю взаимодействия с клиентом, а SFA управляет исполнением полевой продажи: маршрутом, визитом, заказом и фактом работы в торговой точке. Эти классы могут дополнять друг друга, если у каждого определены собственные данные и ответственные процессы.
Liqui Moly в Узбекистане: цены и заказы в поле вместо запроса в офис
Два класса систем
Один клиент. Разные управленческие вопросы.
Переключите перспективу: CRM сохраняет контекст отношений, SFA управляет повторяемым исполнением в торговой точке, а связанная архитектура передаёт между ними только нужные следующему процессу события.
Контекст отношений
Кто клиент и о чём мы договорились?
CRM собирает историю контактов, обращений, возможностей и договорённостей вокруг клиента или аккаунта.
01Контакты и коммуникации
02Лиды, возможности и обращения
03Следующее действие по отношениям
Факт исполнения
Что должно быть выполнено в торговой точке?
SFA превращает территорию, маршрут и сценарий визита в проверяемые полевые действия и первичные факты исполнения.
01Маршрут, визит и задачи
02Заказ, оплата и причины отказа
03Фото, GPS и результат визита
Управляемая граница
Как связать отношения с фактическим исполнением?
Системы обмениваются идентификатором клиента, назначением, статусом визита, заказом и итогом - без копирования каждого внутреннего поля.
01Согласованный внешний ID клиента
02События вместо полного зеркала данных
03Владелец и разбор каждого исключения
CRM обычно отвечает на вопрос, что происходит в отношениях с клиентом: кто контактировал, какое обращение открыто и на каком этапе находится возможность. Для дистрибуции этого недостаточно, потому что результат создаётся внутри повторяемого визита в торговую точку.
От интереса до исполнения
Передавайте решение дальше - не заставляйте системы дублировать друг друга.
Схема показывает типовую границу. Конкретный владелец клиента, заказа и финансового документа фиксируется в интеграционной карте проекта.
01CRM
Контекст клиента
Контакт, обращение и коммерческая договорённость получают ответственного.
Понятно, зачем действовать
02Граница
Назначение
Клиент и согласованная задача передаются полевой команде по внешнему ID.
Нет повторного ввода
03SFA
Маршрут
Точка попадает в план посещений с частотой, приоритетом и сценарием визита.
Действие запланировано
04SFA
Визит
Сотрудник фиксирует заказ, задачи, фото, GPS и структурированный результат.
Факт подтверждён
05SFA → ERP/DMS
Заказ
Документ передаётся в систему исполнения отгрузки и финансового учёта.
Следующий процесс запущен
06CRM / BI
Обратный статус
CRM получает значимый итог, а аналитика - сопоставимые факты процесса.
История замкнута
Контекст клиента → назначение → маршрут → визит → заказ → подтверждённый итог
SFA описывает сам визит: куда должен приехать сотрудник, какую задачу выполнить, какой заказ оформить и какие факты оставить после работы. Поэтому сравнивать системы только по списку экранов неверно - важно определить, где рождается первичный факт исполнения.
Source of truth
Не выбирайте владельца по названию системы. Выбирайте по месту рождения факта.
Нажмите на группу данных. Для неё показаны типичный первичный источник, минимальный обмен и ошибка, которую стоит исключить до разработки интеграции.
Первичный факт
Единый идентификатор связывает аккаунт, юрлицо и торговую точку
Источник
Определяется проектом: ERP/MDM, CRM или Smartup
Событие
Создание, изменение реквизитов, статус активности и назначение территории
Минимальный обмен
Внешний ID, изменённые атрибуты, версия и время обновления
Не делать
Создавать независимые карточки одного клиента без правила сопоставления
Первичный факт
Коммуникация и коммерческий контекст обычно остаются в CRM
Источник
CRM
Событие
Новое обращение, договорённость, возможность или задача аккаунт-команды
Минимальный обмен
Только то решение, которое должно изменить полевое назначение
Не делать
Переносить в SFA полную историю писем и внутренних CRM-активностей
Первичный факт
Первичный факт полевого исполнения формируется в SFA
Источник
SFA
Событие
План визита, check-in/check-out, задача, фото, заказ и причина отказа
Минимальный обмен
Итог визита и значимые статусы, необходимые CRM, ERP/DMS и BI
Не делать
Считать ручную отметку «контакт состоялся» доказательством визита
Первичный факт
SFA создаёт полевой заказ, ERP/DMS продолжает его исполнение
Источник
Граница SFA ↔ ERP/DMS фиксируется проектом
Событие
Создание заказа, проверка, подтверждение, отгрузка, отказ и возврат
Минимальный обмен
Идентификатор документа, строки, суммы, версии и бизнес-статусы
Не делать
Редактировать один заказ независимо в двух системах
Первичный факт
BI сопоставляет отношения, действия и коммерческий результат
Источник
DWH/BI получает факты из согласованных источников
Событие
Завершённый визит, созданный заказ, отгрузка и изменение клиента
Минимальный обмен
События с едиными ключами клиента, точки, сотрудника и документа
Не делать
Сравнивать показатели, рассчитанные из разных версий справочников
В совместной архитектуре CRM может оставаться системой коммуникаций и клиентской истории, а SFA - источником полевых действий и заказов. Обмен нужен на границах процессов, а не для копирования всех данных между системами.
Архитектурный выбор
Выбирайте не продукт-победитель, а минимальную архитектуру для вашего процесса.
Три варианта отвечают разной зрелости продаж. Переключите вариант и проверьте, какой сигнал делает его оправданным, что нужно подготовить и где находится риск.
CRM-first
CRM как основной рабочий инструмент
Сохраняйте простую архитектуру, пока поле не стало отдельным операционным процессом.
Когда подходит
Продажа строится вокруг редких контактов, длинной возможности и аккаунт-команды; повторяемый полевой визит не является ядром процесса.
Что подготовить
Единая карточка клиента, этапы возможности, коммуникации и ответственные действия.
Риск
При появлении регулярных маршрутов и стандартов точки CRM-процесс быстро обрастает ручными полевыми формами.
SFA-first
SFA как центр повторяемых полевых продаж
Сконцентрируйте сотрудника на исполнении в точке и не переносите в приложение лишнюю CRM-сложность.
Когда подходит
Основной результат создают территория, маршрут, визит, заказ и контроль стандарта торговой точки.
Что подготовить
Качественные точки, маршруты, ассортимент, цены, правила визита и интеграция документов с ERP/DMS.
Риск
Если маркетинг и аккаунт-команды ведут сложную историю отношений, им может понадобиться отдельный CRM-контур.
CRM + SFA
Связанные системы с явными владельцами данных
Передавайте между системами решения и статусы, необходимые следующему процессу.
Когда подходит
Компания одновременно управляет сложными отношениями с клиентами и масштабной полевой командой.
Что подготовить
Карта источников, external ID, события, идемпотентность, мониторинг обмена и владельцы исключений.
Риск
Без архитектурной границы интеграция превращается в дорогое двустороннее зеркало всех данных.
Надёжная интеграция
Четыре контроля удерживают CRM и SFA в одной операционной модели.
01
Единая идентичность
Клиент, торговая точка, сотрудник и документ имеют устойчивые внешние идентификаторы.
02
Контракт события
Определены состав, версия, источник, получатель и бизнес-смысл каждого обмена.
03
Безопасная доставка
Повторная отправка не создаёт дубликат, а ошибка остаётся видимой до закрытия.
04
Сверка и владелец
Команда видит расхождение, его причину, ответственного и подтверждённый итог исправления.
Готовность решения
Пять вопросов до выбора CRM, SFA или их связки
Ответы превращают обсуждение функций в проверяемую карту процесса и сокращают риск дублирования данных.
01
Где создаётся результат?
В коммуникации с аккаунтом, в повторяемом визите или в обоих процессах.
02
Какой факт считается первичным?
Для клиента, точки, маршрута, визита, заказа и итогового статуса.
03
Что действительно нужно передавать?
Только данные и события, которые запускают следующее управленческое решение.
04
Что происходит при ошибке?
Назначены повторная попытка, сверка, ответственный и критерий закрытия.
05
Как доказать эффект пилота?
Сравнить полноту визитов, повторный ввод, задержку статуса и время разбора исключений.
01
Опишите путь от назначения клиента сотруднику до подтверждённого визита и заказа.
02
Для каждого шага определите систему, в которой возникает первичный факт, и владельца его качества.
03
Разделите справочные данные, полевые события, коммерческие договорённости и итоговые документы.
04
Настройте обмен только для событий, которые нужны следующему процессу, и предусмотрите разбор ошибок синхронизации.
Практический чек-лист
Маршрут, визит и заказ имеют одного владельца данных.
Сотруднику не приходится повторно вводить один факт в разные системы.
Руководитель видит не только контакт, но и подтверждённое действие в точке.
Интеграционная граница описана до начала внедрения.
Граница применения
SFA не заменяет все функции CRM, а CRM не подтверждает полевое исполнение сама по себе. Итоговая архитектура зависит от процессов, ролей и систем, которые уже используются в компании.
