Магазин на WooCommerce без связи с CRM рано или поздно превращается в узкое место отдела продаж: менеджеры вручную переносят заказы в таблицы или в карточки клиентов, теряют часть заявок и не видят историю покупок при повторном обращении. Интеграция с CRM закрывает это одним движением данных, но то, насколько она надёжна, целиком зависит от технической реализации.
Готовый плагин-коннектор подходит, если CRM популярна и у неё есть официальная или проверенная интеграция с WooCommerce — быстрее всего, но с ограничениями на то, что именно и как передаётся. Вебхуки WooCommerce — средний по сложности вариант, который даёт полный контроль над моментом и форматом передачи данных. Прямая работа с REST API CRM в обе стороны — самый гибкий, но и самый трудозатратный путь, оправданный, когда нужна нестандартная логика синхронизации.
Базовая точка входа — хуки WooCommerce, которые срабатывают на создание заказа и на смену его статуса:
add_action('woocommerce_thankyou', 'it_gig_send_order_to_crm'); function it_gig_send_order_to_crm($order_id) { $order = wc_get_order($order_id); $payload = ['name' => $order->get_billing_first_name(), 'phone' => $order->get_billing_phone(), 'email' => $order->get_billing_email(), 'total' => $order->get_total()]; wp_remote_post(CRM_WEBHOOK_URL, ['body' => json_encode($payload), 'headers' => ['Content-Type' => 'application/json']]); }
Хук woocommerce_thankyou срабатывает один раз при подтверждении заказа и не дублируется при повторных просмотрах страницы, что важно для избежания задвоенных лидов в CRM.
Синхронный вызов CRM прямо в хуке заказа означает, что временная недоступность стороннего сервиса не должна блокировать оформление заказа для покупателя. Правильный паттерн — не дожидаться ответа CRM на критичном пути, а поставить отправку в фоновую задачу через wp_schedule_single_event, и при неудачном HTTP-ответе повторить попытку с увеличивающейся задержкой вместо однократной попытки без возможности восстановления.
Соблазн передать в CRM весь объект заказа целиком упрощает код, но раздувает полезную нагрузку и может случайно передать персональные данные, для которых в CRM не предусмотрено соответствующих полей и политики хранения. Практичнее явно сформировать ограниченный набор полей под конкретную задачу отдела продаж — имя, контакты, состав заказа, сумма — вместо сериализации всего объекта WooCommerce.
Односторонняя передача из WooCommerce в CRM закрывает только половину задачи — менеджер видит заказ в CRM, но покупатель не видит изменения статуса («подтверждён», «передан в доставку»), если они происходят внутри CRM, а не на сайте. Для обратной связи CRM должна уметь отправлять вебхук на сторону WordPress при смене статуса, а сайт — принимать его через публичный, но защищённый токеном эндпоинт, обновляющий статус заказа через wc_update_order_status().
Для проектов на WooCommerce выбор CRM чаще сводится к двум вариантам. AmoCRM проще в интеграции по REST API и лучше подходит для небольших отделов продаж с линейной воронкой. Bitrix24 — более тяжёлое решение с собственной экосистемой (телефония, задачи, документооборот), оправданное, когда CRM нужна не только для фиксации заказов, но и как центральная система управления всем бизнес-процессом компании, а не только сайтом.
Отправка данных в CRM на каждое сохранение заказа, включая промежуточные автосохранения корзины, а не только на финальное подтверждение, — приводит к десяткам дублей одного и того же заказа в CRM. Вторая ошибка — хранение webhook-адреса и токена CRM прямо в коде темы вместо констант wp-config.php, из-за чего при смене интеграции приходится редактировать код, а не конфигурацию. Третья — отсутствие логирования неудачных попыток отправки: без лога единственный способ узнать, что интеграция не работает, — жалоба клиента, которого забыли в воронке продаж. Четвёртая — отсутствие разграничения прав доступа у токена API, которым сайт обращается к CRM: токен с полными правами администратора CRM, зашитый в код сайта, в случае утечки даёт атакующему доступ не только к созданию заказов, но и ко всей базе клиентов.
