Демо: схемы интеграций сайта с CRM, 1С, оплатой и Telegram

Заявка с сайта → amoCRM / Битрикс24 → Telegram менеджеру

Каждая заявка становится сделкой с источником и UTM, менеджер узнаёт о ней за секунды.

Форма на сайте отдаёт заявку не напрямую в CRM, а небольшому серверу интеграции: сайт отвечает посетителю мгновенно, даже если CRM в этот момент тормозит. Сервер приводит телефон к одному виду, ищет клиента в базе, создаёт сделку в воронке «Сайт» с метками рекламы и ставит задачу перезвонить. В чат отдела продаж приходит сообщение с кнопкой «Взял в работу»; нажатие двигает сделку и фиксирует время реакции.

3–5 сот отправки формы до сообщения в Telegram

7 полей UTMsource, medium, campaign, term, content, yclid, client_id

0 потерьпри недоступной CRM: очередь и повторы

15 миннорма реакции, потом напоминание руководителю

Что может пойти не так и как мы это закрыли

Двойной клик и повторная отправка формыКлюч идемпотентности: телефон + форма за 10 минут. Одна сделка вместо трёх.

Клиент уже есть в CRMПоиск по нормализованному телефону и e-mail; новая сделка привязывается к существующему контакту, дубль контакта не создаётся.

CRM не отвечает или таймаутЗаявка сохраняется в очереди, повторы через 1, 5 и 30 минут; после третьей неудачи письмо на резервный ящик и сигнал в Telegram. Заявка не теряется.

Истёк токен доступа amoCRMАвтоматическое обновление по refresh-токену; если не вышло, предупреждение в служебный чат до того, как начнут копиться заявки.

UTM-метки теряются при переходах по сайтуМетки первого входа сохраняются в cookie на 30 дней и отправляются с любой формой, даже если заявка оставлена через неделю.

Спам-заявкиСкрытое поле-ловушка и Yandex SmartCaptcha; подозрительные заявки попадают в отдельный этап, а не к менеджерам.

Интернет-магазин ↔ 1С:УТ: товары, цены, остатки, заказы, статусы

Каталог ведётся в 1С, сайт только показывает и продаёт. Заказы сами появляются в 1С.

Ночью 1С выгружает полный каталог: товары, характеристики, картинки. Днём каждые 15 минут уходят только изменившиеся цены и остатки, поэтому обмен идёт секунды и не нагружает сайт. Заказ с сайта превращается в документ «Заказ клиента» в 1С с резервом на складе. Когда кладовщик проводит сборку и отгрузку, статус и трек-номер возвращаются на сайт и покупателю.

03:00полная выгрузка каталога (около 6 800 позиций)

каждые 15 минцены и остатки, только изменения

GUID 1Сединый ключ товара на обеих сторонах

до 5 минот заказа на сайте до документа в 1С

Что может пойти не так и как мы это закрыли

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

Товар продан в рознице между обменамиПеред оформлением сайт перепроверяет остаток по API 1С; если не хватает, предлагает «под заказ» вместо ошибки после оплаты.

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

Дубли контрагентов в 1СПоиск по телефону, для юрлиц по ИНН; розничные покупатели без ИНН идут на одного контрагента «Розница сайт» с данными в комментарии, если так ведёт учёт бухгалтерия.

Обмен упал, и никто не заметилЖурнал каждого обмена с числом строк; если обмена не было 40 минут или он с ошибкой, сообщение в Telegram ответственному.

Обмен затирает тексты сайтаНазвания, описания и SEO-поля после первой загрузки ведутся на сайте; из 1С приходят только цены, остатки, артикулы и характеристики.

Оплата: корзина → ЮKassa / СБП → вебхук → чек 54-ФЗ → CRM → письмо

Заказ считается оплаченным только после подтверждения от ЮKassa, а не по возврату покупателя на сайт.

Сайт создаёт платёж в ЮKassa вместе с данными чека: позиции, ставка НДС, e-mail покупателя. Покупатель платит картой или по QR через СБП в приложении своего банка. ЮKassa присылает уведомление (вебхук), сайт перепроверяет платёж запросом к API и только потом меняет статус заказа. Чек уходит в ОФД и покупателю автоматически, сделка в CRM переходит в «Оплачено», клиент получает письмо с составом заказа.

1–5 свебхук после оплаты

1 ключIdempotence-Key = номер заказа

каждые 5 минсверка зависших платежей

54-ФЗчек прихода и чек возврата автоматически

Что может пойти не так и как мы это закрыли

Вебхук пришёл дваждыОбработка по id платежа ровно один раз: второй вызов видит, что заказ уже оплачен, и просто отвечает 200.

Вебхук не пришёл совсемФоновая задача раз в 5 минут спрашивает ЮKassa о платежах в статусе «ожидает» и доводит их до конца.

Поддельный вебхукПринимаем только с адресов ЮKassa и не верим содержимому: статус и сумму берём повторным запросом к API.

Таймаут при создании платежаПовтор с тем же Idempotence-Key: ЮKassa вернёт уже созданный платёж, покупатель не заплатит дважды.

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

Возврат денегВозврат из CRM или админки вызывает API ЮKassa, чек возврата формируется сам, статус заказа и сделки меняется синхронно.

Что входит в работу

ОбследованиеКакие системы и версии, кто где ведёт данные, какие поля нужны. Доступы к тестовым копиям.

Схема и карта полейКак на этой странице: кто, что и когда передаёт; таблица соответствия полей. Согласуем до разработки.

Разработка обменаМодуль для CMS или отдельный сервер интеграции: REST API, вебхуки, CommerceML, очереди и повторы.

Защита от сбоевИдемпотентность, поиск дублей, сверки по расписанию, журнал обмена и сигналы в Telegram.

ТестированиеНа копии базы 1С, тестовом магазине ЮKassa и тестовой воронке CRM; прогон «плохих» сценариев.

ПередачаКороткая инструкция: где смотреть журнал, что делать при сигнале, как поменять поле.

← Все примеры