Пришёл случай, который повторяется у меня раз в квартал: клиент подключил CRM, потом эквайринг, потом доставку, потом чат-бота, и каждый сервис живёт своей жизнью. Менеджер сверяет заказы руками между amoCRM и личным кабинетом СДЭК, деньги приходят в WooCommerce, а статус оплаты в CRM обновляется на следующий день, если не забыли. Интеграция CRM с сервисами - это не про «подключить всё, что можно», а про то, чтобы система осталась управляемой, когда сервисов уже семь-восемь. Ниже - как я строю такие связки на практике, что реально стоит автоматизировать, а что лучше оставить руками, и почему зоопарк интеграций возникает не от количества сервисов, а от отсутствия одной точки, которая знает правду о клиенте.
По теме статьи
Готовое решение
AI-чатбот для сайта на Claude - отвечает как ваш менеджер, работает 24/7
Подключу к вашему сайту чат-бота на Claude API. Бот отвечает на вопросы клиентов голосом вашего бренда, знает каталог и условия доставки, забирает лиды в CRM или Telegram.
от25 000 ₽
AI / Claude API
Искусственный интеллект для бизнеса
AI-чатбот на сайт с базой знаний, автообработка заявок, генерация контента, умный парсинг. Claude API, OpenAI, RAG.
от50 000 ₽
Какие сервисы обычно подключают к CRM
На практике набор почти всегда один и тот же, меняется только порядок подключения. Сначала идёт приём заявок: сайт на Tilda или WordPress, форма, квиз, иногда сразу Telegram-бот как основной канал продаж. Дальше приём оплаты: эквайринг вроде T‑Bank, платёжные шлюзы маркетплейсов, иногда рассрочка. Следом доставка: СДЭК, Boxberry, свои курьеры с трек-номерами. Потом коммуникации: рассылки, SMS-уведомления о статусе заказа, чат-бот с ответами на частые вопросы. И почти всегда где-то сбоку висит 1С или другая бухгалтерская система, с которой CRM должна синхронизировать хотя бы номенклатуру и оплаты.
Проблема в том, что каждый из этих сервисов подключают по мере необходимости, отдельным подрядчиком или штатным разработчиком, без общей схемы. Через год у CRM оказывается двенадцать точек входа данных, три из них дублируют друг друга, а два вебхука никто уже не может объяснить. Я разбирал такой проект для интернет-магазина стройматериалов: в Bitrix24 заказ создавался и через форму на сайте, и через API маркетплейса, и вручную менеджером из письма на почту. В результате один заказ мог существовать в CRM в трёх экземплярах с разными статусами.
Три способа подключить сервис к CRM
Прежде чем писать код, я всегда прикидываю, каким способом тянуть данные, и не потому что один способ лучше другого, а потому что для разных задач подходят разные инструменты.
| Способ | Когда оправдан | Что нужно для запуска |
|---|---|---|
| Готовый модуль/плагин | Популярная связка вроде WooCommerce и Bitrix24, стандартный сценарий без кастомной логики | Настройка модуля, проверка полей, тест на паре заказов |
| Вебхуки и кастомный скрипт | Нестандартная логика: свои статусы, условная маршрутизация, объединение нескольких источников | Скрипт-обработчик, хранение токенов, логирование событий |
| iPaaS (n8n и аналоги) | Несколько сервисов сразу, часто меняющиеся сценарии, нужна визуальная схема для не-разработчика | Развёрнутый n8n, узлы под каждый сервис, тестовые прогоны |
Модуль хорош, пока сценарий укладывается в его логику: пришёл заказ, ушёл в CRM, всё. Как только нужно, например, отправлять в CRM не все заказы, а только оплаченные, да ещё с разными воронками для розницы и опта, готовый модуль начинает мешать больше, чем помогает. Тут я перехожу на вебхуки и пишу обработчик под конкретную логику клиента.
n8n я беру, когда сервисов больше трёх и клиент сам хочет видеть и время от времени менять схему: добавить условие, переставить шаг, включить уведомление в Telegram при определённой сумме заказа. Визуальный редактор в этом случае экономит куда больше времени, чем написание отдельного скрипта под каждую мелкую доработку. Комплексная интеграция CRM, эквайринга и доставки под Tilda у меня стоит от 40 000 ₽, автоматизация сценариев в n8n отдельно - от 25 000 ₽, в зависимости от числа узлов и сервисов.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
CRM и приём платежей: T‑Bank, WooCommerce и синхронизация статусов
Самая частая ошибка здесь - тянуть в CRM факт создания заказа, но не тянуть факт оплаты. Заказ появляется, менеджер видит его в воронке, начинает звонить клиенту, который уже оплатил через T‑Bank десять минут назад, но CRM об этом не знает, потому что вебхук настроен только на создание заказа в WooCommerce.
Правильная последовательность у меня выглядит так: заказ в WooCommerce создаёт лид в CRM со статусом «ожидает оплату», T‑Bank присылает вебхук об успешном платеже на отдельный обработчик, обработчик находит заказ по идентификатору и переводит лид в CRM в статус «оплачен», параллельно запуская сценарий передачи в доставку. Три события, три отдельных вебхука, и каждый логируется отдельно, чтобы при разборе ошибки было видно, на каком шаге сломалось. На одном проекте с розницей стройматериалов такая связка сократила время от оплаты до передачи заказа в отгрузку с полутора часов, пока это делали руками, до пары минут.
Отдельно стоит комиссия эквайринга - она зависит от тарифа банка и оборота, а не от того, интернет-магазин это или лендинг с разовыми продажами, поэтому в сравнительных таблицах я её никогда не привязываю к типу сайта.
CRM и доставка: СДЭК без ручного переноса трек-номеров
СДЭК подключают почти всегда одинаково: при переводе заказа в статус «готов к отправке» CRM дёргает API СДЭК, создаёт заявку на доставку, получает номер заказа и трек-номер, записывает их обратно в карточку сделки. Дальше по вебхуку от СДЭК статус доставки подтягивается автоматически - «принят на склад», «в пути», «доставлен». Клиенту при этом можно сразу слать SMS или сообщение в Telegram-бота со ссылкой на трек, без участия менеджера.
Тонкое место - расчёт стоимости доставки. Если он считается на сайте одним способом, а в CRM для выставления счёта другим, суммы расходятся, и тогда именно менеджер оказывается крайним перед клиентом. Я всегда завожу расчёт стоимости в одном месте, и дальше и сайт, и CRM обращаются к нему через один и тот же метод API, а не дублируют формулу в двух местах на разных языках.
CRM и мессенджеры: Telegram-боты и Tilda-скрипты
Здесь два типовых сценария. Первый - бот на aiogram как самостоятельный канал продаж: клиент оставляет заявку прямо в Telegram, бот создаёт сделку в CRM через API, дальше вся переписка логируется в карточке клиента. Такой бот с интеграцией в CRM у меня стоит от 30 000 ₽, а если нужна ещё и обработка вопросов через ИИ с базой знаний по товарам, услуга уже про AI-интеграции, от 50 000 ₽.
Второй сценарий - кастомный скрипт на Tilda-странице, который отправляет данные формы не в почту, а сразу в CRM через вебхук, минуя стандартный модуль интеграции Tilda. Это нужно, когда стандартной интеграции не хватает полей или нужна логика вроде выбора воронки в зависимости от того, какой товар выбрал клиент в квизе. Такие доработки я делаю на заказ, и в блоке разработки кастомных интеграций обычно и рождаются подобные скрипты под конкретный проект.
Как не собрать зоопарк: точка правды и мониторинг интеграций
Правило, которое я применяю на каждом проекте с числом сервисов больше трёх: у данных клиента должна быть одна точка правды, и обычно это CRM. Сайт, бот, платёжка и доставка не хранят собственную копию контактов клиента - они читают и пишут в CRM через API, а не создают параллельные базы. Как только появляется вторая база с телефонами и почтой, начинается рассинхрон, и его невозможно вылечить без ручной сверки.
Второе правило - логирование каждого вебхука. Если платёжная система прислала уведомление, а обработчик упал с ошибкой, об этом нужно узнать сразу, а не через неделю от клиента, который оплатил, но заказ так и не сдвинулся из статуса «ожидает оплату». Я обычно веду отдельную таблицу событий интеграций с полем «статус обработки» и настраиваю уведомление в Telegram себе или ответственному менеджеру при ошибке.
Третье - контакты клиентов и переписку с ними нужно хранить на серверах в России, а не в иностранных облачных таблицах вроде Google Sheets или Airtable, если речь о персональных данных: это требование локализации по 152-ФЗ, и я закладываю его в архитектуру заранее, а не когда клиент уже собрал базу за границей.
И последнее - каждую интеграцию стоит документировать хотя бы в одном файле: какой сервис, какой токен, куда смотреть при сбое, кто отвечает. Без этого через год никто не помнит, зачем стоит один из вебхуков, и его либо боятся трогать, либо случайно отключают вместе с рабочей связкой.
Частые вопросы
Сколько стоит интеграция CRM с внешним сервисом
Зависит от сложности логики и количества сервисов. Кастомная интеграция CRM с эквайрингом и доставкой в связке с Tilda у меня стоит от 40 000 ₽, автоматизация нескольких сервисов через n8n - от 25 000 ₽, простая доработка скрипта под один сценарий - от 3 000 ₽.
Что делать, если сервис не поддерживает вебхуки
Тогда остаётся опрос API по расписанию: скрипт раз в несколько минут запрашивает изменения и передаёт их в CRM. Работает надёжно, но с задержкой в пределах интервала опроса, и такой вариант я закладываю сразу, если вебхуков у сервиса нет в принципе.
Обязательно ли писать код, если есть готовый модуль интеграции
Нет, если сценарий укладывается в логику модуля. Модуль экономит время и деньги на старте. Код нужен, когда логика нестандартная: свои статусы, условная маршрутизация заявок, объединение данных из нескольких источников в одну сделку.
Как понять, что интеграций уже слишком много
Если для ответа на вопрос «где сейчас правда о заказе» нужно открыть больше одной системы, а изменения в одном сервисе перестают доходить до других без ручной проверки - это уже зоопарк, и его стоит пересобирать вокруг одной точки правды, а не добавлять ещё один сервис поверх.