Как связать интернет-магазин с CRM и не получить дубли клиентов и заказов
Разбираю схему интеграции магазина с CRM: какие сущности передавать, как назначить владельцев данных, защититься от дублей и проверить результат до запуска.
В этой статье
После подключения CRM один заказ нередко превращается в три сущности: заявка из формы, сделка после оплаты и ещё одна сделка после звонка менеджера. Покупатель тоже дублируется — по телефону, почте и гостевой сессии. Это не ошибка конкретной CRM. Так выглядит интеграция, в которой начали с передачи полей, но не договорились о жизненном цикле данных.
Надёжная связь магазина с CRM начинается с ответа на три вопроса: что считается заказом, какая система владеет каждым полем и по какому ключу повторное событие узнаёт уже существующую запись. Только после этого имеет смысл выбирать API, готовый модуль или промежуточный сервис.
Разделите события, сущности и этапы продажи
Форма «Перезвоните мне», корзина без оплаты и оплаченный заказ — разные события. Если каждое безусловно создаёт сделку, воронка быстро перестаёт отражать реальность. Сначала составьте карту: какое действие покупателя создаёт лид, контакт, сделку, заказ или задачу менеджеру.
Событие на сайте | Что обычно нужно CRM | Главный риск |
|---|---|---|
Запрос обратного звонка | Лид или обращение | Повторная форма создаёт дубль |
Начало оформления | Не всегда требует сделки | Воронка заполняется брошенными корзинами |
Создание заказа | Сделка с составом заказа | Повтор webhook создаёт вторую сделку |
Успешная оплата | Обновление существующей сделки | Оплата ошибочно создаёт новый заказ |
Отмена или возврат | Статус и финансовое событие | История затирается одним финальным статусом |
Карта не обязана совпадать с внутренними названиями CRM. Важно, чтобы одно бизнес-событие имело одно ожидаемое последствие и чтобы это последствие можно было проверить.
Назначьте владельца каждому полю
У одного заказа есть цена, скидка, доставка, статус оплаты, статус сборки, комментарий покупателя и заметки менеджера. Разрешить редактировать всё в обеих системах — значит создать постоянные конфликты.
Сайт обычно отвечает за исходный состав корзины, выбранные покупателем доставку и способ оплаты.
Платёжный сервис подтверждает факт и сумму платежа; отметка менеджера не должна заменять это событие.
CRM может владеть этапом работы менеджера, задачами, причиной потери и внутренними комментариями.
Учётная система определяет фактические остатки, резервирование и отгрузочные документы, если она подключена к схеме.
Изменение заказа после оформления требует отдельного правила: кто может менять состав и как фиксируется история.
Для каждого поля полезно записать направление передачи и поведение при конфликте. Формулировка «двусторонняя синхронизация» ничего не объясняет, пока не определено, какое изменение считается более новым и какие изменения вообще разрешены.
Используйте устойчивые ключи, а не совпадение текста
Телефон и почта помогают искать человека, но не всегда годятся как единственный идентификатор. Номер может быть общим корпоративным, адрес — введён с опечаткой, а один покупатель вправе использовать несколько контактов. Заказу нужен неизменяемый внешний ключ сайта, контакту — правила нормализации и объединения.
Перед сравнением телефон приводят к единому формату, почту — к согласованному регистру, а пустые значения не считают совпадением. Автоматическое объединение по одному слабому признаку опасно: две разные организации могут указать общий номер секретаря.
Повторная доставка одного и того же события должна обновлять прежнюю запись. Для этого интеграция хранит идентификатор события или сочетание источника и внешнего ID заказа. Такой подход называют идемпотентностью: повтор не умножает сущности.
Не передавайте персональные данные «на всякий случай»
Интеграции часто копируют в CRM весь профиль покупателя, хотя менеджеру нужны только имя, контакты, заказ и согласованные признаки. Чем больше систем хранит данные, тем больше мест нужно защищать, обновлять и очищать по правилам компании.
Состав полей определяют до разработки. Секреты API хранят на сервере, доступ ограничивают по ролям, запросы подписывают или авторизуют, а журналы не должны содержать пароли, токены, полные платёжные реквизиты и лишние персональные данные. В журнале достаточно идентификаторов, времени, направления, результата и безопасного описания ошибки.
Продумайте очередь и повторные попытки
Сайт не должен задерживать ответ покупателю, пока CRM обрабатывает запрос. Практичная схема сохраняет заказ локально, ставит событие в очередь и передаёт его отдельно. Если CRM временно недоступна, заказ остаётся на сайте, а задача повторяется по ограниченному расписанию.
Повтор должен отличать временную ошибку от постоянной. Тайм-аут и ответ о перегрузке допускают повтор. Ошибка формата телефона или неизвестный тип доставки требует исправления данных или сопоставления. Бесконечные повторы одной неправильной записи создают нагрузку и скрывают новые события.
Как принять интеграцию
Оформите заказ гостем, затем повторите с тем же телефоном и другой почтой. Проверьте согласованное правило контактов.
Отправьте одно событие дважды. В CRM должна остаться одна сделка с одним внешним ID.
Оплатите заказ после его создания. Должна обновиться существующая сделка, а сумма оплаты — совпасть с событием платёжной системы.
Измените разрешённое поле в CRM и запустите обмен. Убедитесь, что сайт не перезаписывает его старым значением.
Сделайте CRM недоступной в тестовом контуре, затем восстановите. Заказ не должен потеряться, а очередь — создать дубли.
Отмените заказ и оформите частичный возврат. Проверьте историю событий, а не только последний статус.
Сверьте журнал: время, внешний ID, результат, число попыток и причина отказа должны быть понятны без чтения исходного кода.
Интеграцию можно считать готовой, когда команда умеет доказать не только успешную передачу, но и безопасный повтор, восстановление после сбоя и однозначное владение данными. Если эти правила не помещаются в короткую схему, разработку рано оценивать только по количеству полей API.
After connecting a CRM, one order often turns into three entities: a lead from a form, a deal after payment, and another deal after a manager's call. The buyer is also duplicated—by phone, email, and guest session. This is not an error of a specific CRM. This is what an integration looks like that started by transferring fields but failed to agree on the data lifecycle.
A reliable connection between a store and a CRM begins with answers to three questions: what counts as an order, which system owns each field, and by what key a repeated event recognizes an existing record. Only after that is it meaningful to choose an API, a ready-made module, or an intermediate service.
Separate events, entities, and sales stages
A "Call Me Back" form, a cart without payment, and a paid order are different events. If each unconditionally creates a deal, the funnel quickly stops reflecting reality. First, create a map: which buyer action creates a lead, contact, deal, order, or task for a manager.
Event on the Website | What a CRM Typically Needs | The Main Risk |
|---|---|---|
Request for a Callback | Lead or Inquiry | Submitting the form again creates a duplicate |
Checkout start | Does not always require a deal | The funnel fills with abandoned carts |
Order creation | Deal with order composition | A repeated webhook creates a second deal |
Successful payment | Updating an existing deal | Payment erroneously creates a new order |
Cancellation or refund | Status and financial event | History is overwritten by a single final status |
The card does not have to match the internal CRM names. It is important that one business event has one expected outcome and that this outcome can be verified.
Assign an owner to each field
An order has a price, discount, shipping, payment status, fulfillment status, buyer comment, and manager notes. Allowing edits in both systems creates constant conflicts.
The site is typically responsible for the original cart composition, the delivery method selected by the buyer, and the payment method.
The payment service confirms the fact and amount of the payment; a manager's note must not replace this event.
The CRM may own the manager's work stage, tasks, reason for loss, and internal comments.
The accounting system determines actual stock levels, reservations, and shipping documents if it is connected to the scheme.
Changing an order after placement requires a separate rule: who can modify the composition and how the history is recorded.
For each field, record the transfer direction and behavior during conflicts. The phrase 'bidirectional synchronization' explains nothing until it is defined which change is considered newer and which changes are allowed at all.
Use stable keys, not text matching
Phone and email help find a person but are not always suitable as the sole identifier. A number may be a shared corporate line, an address may be entered with a typo, and one buyer may use multiple contacts. An order needs an immutable external site key; a contact needs rules for normalization and merging.
Before comparison, phone numbers are converted to a unified format, emails to a consistent case, and empty values are not treated as a match. Automatic merging based on a single weak attribute is dangerous: two different organizations may list the same secretary's number.
A repeated delivery of the same event must update the original record. To achieve this, the integration stores the event ID or a combination of the source and the external order ID. This approach is called idempotency: a repeat does not multiply entities.
Do not send personal data "just in case"
Integrations often copy the entire buyer profile into the CRM, although the manager only needs the name, contact details, order, and agreed-upon attributes. The more systems that store data, the more places must be protected, updated, and cleaned according to company rules.
Define the field set before development. API secrets must be stored on the server, access must be restricted by role, requests must be signed or authorized, and logs must not contain passwords, tokens, full payment details, or unnecessary personal data. The log should include only identifiers, timestamps, direction, result, and a safe error description.
Plan for queues and retries
The site must not delay the response to the buyer while the CRM processes the request. A practical scheme saves the order locally, queues the event, and transmits it separately. If the CRM is temporarily unavailable, the order remains on the site, and the task is retried on a limited schedule.
A retry must distinguish between a transient error and a permanent one. Timeouts and overload responses allow retries. A phone number format error or an unknown delivery type requires data correction or mapping. Infinite retries of the same incorrect record create load and obscure new events.
How to Accept an Integration
Place an order as a guest, then repeat with the same phone number but a different email address. Verify the agreed contact rule.
Send one event twice. The CRM must retain a single deal with a single external ID.
Pay for the order after it is created. The existing deal must be updated, and the payment amount must match the payment system event.
Modify an allowed field in the CRM and trigger the synchronization. Ensure the site does not overwrite it with the old value.
Make the CRM unavailable in the test environment, then restore it. The order must not be lost, and the queue must not create duplicates.
Cancel the order and process a partial refund. Verify the event history, not just the last status.
Check the log: time, external ID, result, number of attempts, and rejection reason must be clear without reading the source code.
An integration can be considered complete when the team can demonstrate not only successful data transfer but also safe retries, recovery from failures, and clear data ownership. If these rules do not fit into a concise diagram, it is too early to evaluate the development based solely on the number of API fields.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.