Какие интеграции нужны современному интернет-магазину?

Основные задачи, которые решают интеграции:

• поддерживают актуальность товаров, цен и остатков

• принимают оплату и передают её статус в заказ

• рассчитывают доступные способы и стоимость доставки

• помогают покупателю правильно заполнить адрес, реквизиты и другие данные с помощью сервисов подсказок и проверки, например DaData

• передают заказы менеджерам, в 1С, CRM и другие внутренние системы

• отправляют покупателю SMS, электронные письма и сообщения в мессенджерах

• уведомляют клиента об оплате, сборке, передаче в доставку и других изменениях статуса заказа

• собирают данные для аналитики и маркетинга

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

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

Набор интеграций зависит от процесса обработки заказа

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

Отправной точкой служат не названия программ, а вопросы о работе компании:

• где создаются товары и их характеристики

• кто устанавливает цены

• в какой системе учитываются остатки

• куда должен поступить заказ

• где менеджер меняет его статус

• как покупатель узнаёт об оплате и доставке

• какие данные нужны руководителю для анализа продаж

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

Интеграция с учётной системой поддерживает каталог и заказы

Обмен с учётной системой нужен, если товары, цены, остатки или заказы обрабатываются не только на сайте. Для магазинов на 1С-Битрикс такой системой часто становится 1С, но конкретный состав обмена зависит от организации учёта

Односторонняя выгрузка каталога и полноценный двусторонний обмен решают разные задачи:

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

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

Оплата должна быть связана с состоянием заказа

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

Покупатель может закрыть страницу после оплаты, вернуться по старой ссылке или повторить попытку. Платёжный сервис тоже может передать результат с задержкой. Поэтому сайт не должен считать заказ оплаченным только потому, что пользователь увидел страницу подтверждения

При настройке оплаты команда проверяет:

• создание платежа с правильной суммой

• связь платежа с конкретным заказом

• успешный и неуспешный результат

• повторную попытку оплаты

• отмену и возврат

• изменение состояния заказа

• обработку повторного уведомления от сервиса

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

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

Интеграция с доставкой должна учитывать весь маршрут заказа

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

Состав интеграции зависит от модели доставки:

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

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

CRM нужна, когда продажа продолжается после оформления заказа

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

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

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

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

Уведомления должны отражать реальное состояние заказа

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

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

При проектировании уведомлений команда определяет:

• какое событие запускает сообщение

• из какой системы приходит подтверждение

• какой канал используется

• что происходит при ошибке отправки

• можно ли повторить сообщение без дублирования

• где сотрудник видит историю уведомлений

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

Аналитика должна связывать рекламу с завершённой продажей

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

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

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

Аналитика полезна только тогда, когда её данные можно связать с реальным состоянием заказа и использовать для решения о рекламе, ассортименте или интерфейсе магазина

Маркетплейсы и рекламные площадки подключают после каталога

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

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

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

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

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

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

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

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

Как определить приоритет интеграций

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

Ориентиры для разных проектов:

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

Компетентный разработчик понимает проект целиком

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

Вопросы, которые стоит задать разработчику:

• Какие сценарии вы изучите до проектирования обмена?

• Где должен находиться основной источник каждого типа данных?

• Что произойдёт при частичной или повторной передаче?

• Какие связанные функции вы проверите после запуска?

• Какие вводные нужны для оценки интеграции?

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

Признак компетенции — способность объяснить не только способ соединения систем, но и бизнес-сценарий, который интеграция должна поддерживать без потери и дублирования данных

Пример из практики Ameton

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

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

Практический вывод: до настройки интеграции нужно определить, кто и на каком этапе может изменять данные заказа

Как не превратить интеграции в источник сбоев

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

Какие ошибочные решения делают интеграции неуправляемыми:

• «Чем больше интеграций, тем лучше» — неверно: подключение оправдано только тогда, когда убирает ручную операцию или улучшает управляемость заказа

• «Готовый модуль не требует анализа» — неверно: модуль предоставляет способ обмена, но не определяет источники данных и правила бизнеса

• «Соединение работает — значит интеграция исправна» — неверно: нужно проверить полноту данных, отсутствие дублей и итоговый статус заказа

• «Ошибку можно исправить вручную» — ненадёжно: при регулярном обмене должен быть понятный способ обнаружить и безопасно повторить операцию

• «Все системы могут редактировать одни данные» — рискованно: без приоритета изменений информация будет перезаписываться

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

Как оценить проектирование интеграций

Хорошее техническое решение описывает не только системы и направления обмена, но также источники данных, ошибки, повторные операции и критерии проверки

Признаки обоснованного и рискованного подхода:

Если предложение содержит только строки «интеграция с 1С», «подключение доставки» и «настройка оплаты», заказчику стоит запросить описание процессов. Одинаковые названия могут означать как установку готового модуля, так и полноценную настройку обмена с обработкой исключений

Современному интернет-магазину нужны не все возможные интеграции, а связанный набор систем, который поддерживает продажу от публикации товара до завершения заказа. Главные критерии — единый источник каждого типа данных, понятные направления обмена и предусмотренное поведение при ошибке

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