Интеграция готового модуля Retail CRM. Проблемы и решения

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

К нам в руки попал проект, где модуль RetailCRM был внедрён предыдущим подрядчиком. Команда “Импульс Маркетинг” проверила, как он работает в реальных условиях и где может принести максимум пользы. В процессе выяснилось: с похожими проблемами может столкнуться любой владелец интернет-магазина.

Мы провели полную экспертизу, нашли решения и теперь делимся ими – чтобы вы могли заранее понять риски и выбрать лучший путь для своего бизнеса.

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

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

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

Рис 1 - Запись “кастомных” цен для каждой позиции корзины на основе рассчитанных данных

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

Рис 2 - Удаление данных платежей при обмене из внешней системы в заказ

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

Отсутствие единой структуры привело к тому, что код стал сложным и дублировал одни и те же операции в разных местах.

Из-за отсутствия общего стандарта логирования система вела себя непредсказуемо: одновременно работали два разных сервиса логов, но не было ясно, какой использовать в конкретном случае. Где-то логгер подключался как свойство класса, где-то – по-другому, а часть событий писалась напрямую в логи Битрикса.

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

Рис 3 - Отсутствие общего стандарта логирования

Рис 3.2 - Ошибка не обрабатывается при применении баллов

Ниже приведены примеры дублирования кода. Одинаковые вызовы, причем даже в 1-ом классе.

Команда “Импульс Маркетинг” несколько недель тщательно разбирала проект: искали причины сбоев, тестировали разные сценарии оформления заказа, проверяли логику начисления скидок и списания баллов, настраивали модули и отлаживали взаимосвязи между системами.
Мы посмотрели на процесс глазами и клиента, и разработчика, чтобы понять, где именно теряется предсказуемость и как сделать путь от корзины до оплаты стабильным.

После серии тестов и исправлений мы сформировали чёткое понимание, какие решения подходят под разные типы проектов.

Что же выбрать для проекта?

Если задача базовая, скидки и каталог простые, а доставка и оплата единые, мы рекомендуем использование готового модуля. Он позволяет настроить соответствия статусов, оплат и доставок с минимальными правками.

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

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

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

Что делаем мы при таком обращении?
Сначала проводим короткий аудит текущей конфигурации и фиксируем риски в зонах расчета скидок, доставки и платежей. Затем вместе с владельцем продукта смотрим риски и считаем экономику сценариев, и выбираем оптимальный метод интеграции.

Вам нужно интегрировать Retail CRM с сайтом на Битрикс? Обращайтесь!