Scenario · 01
“«Заявки с сайта теряются или приходят с дублями»”
Менеджеры видят несколько карточек одного клиента, источник трафика (UTM) теряется, заявки попадают не тому менеджеру, или часть заявок остаётся только в почте и никто о них не знает. Готовый модуль из маркетплейса Битрикс24 «вроде работает», но дубли копятся, а UTM пропадают. Что мы делаем: настраиваем передачу заявок с правильной дедупликацией (по почте, телефону и организации), сохраняем UTM-метки и источник, распределяем заявки по правилам (география, услуга, тип клиента), отправляем уведомления менеджерам, ведём журнал событий.
Scenario · 02
“«Остатки и цены не сходятся между сайтом и 1С»”
На сайте — одни остатки, в 1С — другие. Клиенты заказывают то, чего нет на складе, менеджеры сверяют вручную, появляются возвраты. Готовые модули «1С ↔ Битрикс» при росте каталога (от 500–1 000 SKU) начинают тормозить или молча терять обновления. Что мы делаем: фиксируем источник истины (как правило 1С для остатков и цен), настраиваем синхронизацию по событиям или по расписанию (раз в 5–15 минут), правила разрешения конфликтов, журнал ошибок синхронизации, админ для ручной проверки спорных позиций.
Scenario · 03
“«Оплата прошла, а доступ или заказ не обновился»”
Клиент оплатил через ЮKassa, видит «успешно», но в личном кабинете доступ не появился. Или возврат сделан в провайдере, а в системе он не отражён. Вебхук от провайдера приходит дважды и создаёт дубликаты. Что мы делаем: проектируем модель платёжных статусов, обработку вебхуков с идемпотентностью (защита от дублей), связку платёж → заказ → доступ, обработку повторов и ошибок, админ-панель, где видно все спорные операции с возможностью ручной правки.
Scenario · 04
“«Zapier / Albato / Make сломались при росте»”
Сначала конструкторы автоматизаций помогли быстро запуститься: связали форму на сайте с AmoCRM и счетами в 1С. Через 6–12 месяцев — подписка $50–200/мес, каждая правка формы рушит цепочку, никто не знает, где пропали заявки, ошибки приходят на почту без контекста. Что мы делаем: разбираем текущие связки, оставляем конструкторы автоматизаций там, где он уместен (напоминания, простые уведомления), переносим критичные потоки в бэкенд с правильной обработкой ошибок и журналом, документируем правила обмена.
Scenario · 05
“«Команда тратит полдня на ручную сверку между системами»”
Заказы в CRM, оплаты в 1С-Бухгалтерии, остатки в «Мой Склад», заявки на доставку в кабинете СДЭК. Команда копирует данные между интерфейсами, ошибается, теряет время. На проектах с хаотичными интеграциями мы часто видим, что значительная часть операционного времени уходит не на работу с клиентом, а на сверку заказов, оплат, остатков и статусов. Что мы делаем: интеграционный слой — связываем 3–5 систем через бэкенд (а не через подписку-посредника), правильные правила обмена с журналом, админ для разбора спорных случаев, дашборд статусов синхронизации.