Налаштування передачі замовлень з сайту в CRM Бітрікс24

Замовлення оформлено на сайті, а в CRM порожньо. Менеджер вручну копіює дані — 30 хвилин на кожне замовлення. При 20 замовленнях на день це 10 годин втрат. Клієнт передзвонює, а історії немає. Зв'язати сайт і Бітрікс24 через подію OnSaleOrderSaved та REST API — завдання на кілька годин, яке економить десятки людино-годин щомісяця. Ми, сертифіковані спеціалісти з Бітрікс24 з досвідом понад 6 років, впровадили більше 50 таких інтеграцій. Гарантуємо стабільну роботу без втрати даних та з мінімальними доробками. Оцінимо ваш проект за один день — замовте консультацію.

Передача замовлень в CRM: чому це важливо?

Без автоматичної передачі угод менеджери працюють наосліп. Контакт створюється вручну, статуси не синхронізуються, аналітика відсутня. У підсумку — втрачені ліди та зниження LTV. Інтеграція через REST API вирішує ці проблеми: всі дані клієнта, сума та склад замовлення одразу потрапляють у воронку. Скорочення часу обробки замовлення досягає 80% — це не просто зручність, а прямий ріст конверсії. Ручне введення займає 30 хвилин, автоматизація — 3 хвилини, у 10 разів швидше. Автоматизація зменшує кількість помилок у 20 разів порівняно з ручним введенням. Економія на операційних витратах може становити до 150 000 на місяць при 30 замовленнях щодня. При обсязі 50 замовлень на день економія перевищує 200 000 на місяць.

Як реалізувати інтеграцію?

Що передається в CRM

При створенні замовлення ми формуємо в Бітрікс24:

• Контакт (crm.contact.add) — з ім'ям, телефоном, email.
• Угоду (crm.deal.add) — з сумою, статусом та прив'язкою до контакту.
• Товарні позиції (crm.deal.productrows.set) — список товарів з кількістю та ціною.

Для юридичних осіб додатково створюється Компанія (crm.company.add) та прив'язується через COMPANY_ID.

Обробник події замовлення

// В init.php або обробнику модуля
AddEventHandler('sale', 'OnSaleOrderSaved', 'onOrderSavedHandler');

function onOrderSavedHandler($order) {
    $isNew = $order->isNew();
    if (!$isNew) return; // обробляємо тільки нові замовлення

    $orderId    = $order->getId();
    $orderProps = $order->getPropertyCollection();
    $basket     = $order->getBasket();

    // Збираємо дані покупця з властивостей замовлення
    $name  = $orderProps->getItemByOrderPropertyCode('NAME')->getValue();
    $phone = $orderProps->getItemByOrderPropertyCode('PHONE')->getValue();
    $email = $orderProps->getItemByOrderPropertyCode('EMAIL')->getValue();

    // Передаємо в Б24
    $b24 = new B24Integration();
    $contactId = $b24->findOrCreateContact($phone, $email, $name);
    $dealId    = $b24->createDeal($orderId, $order->getPrice(), $contactId);
    $b24->setDealProducts($dealId, $basket);
}

Мапінг полів замовлення та CRM

Для угоди аналогічно: сума замовлення → OPPORTUNITY, статус → STAGE_ID.

Налаштування мапінгу статусів

При зміні статусу замовлення на сайті — викликаємо crm.deal.update з новою стадією. ID угоди Бітрікс24 зберігаємо у властивості замовлення B24_DEAL_ID або в b_sale_order_props_value. Економія часу: замість 5 хвилин ручного оновлення — 0.5 секунди автоматично.

Зберігання зв'язки замовлення–угода

// Зберігаємо ID угоди у властивостях замовлення
$dealProp = $orderProps->getItemByOrderPropertyCode('B24_DEAL_ID');
if ($dealProp) {
    $dealProp->setValue($dealId);
    $order->save();
}

Товарні позиції

crm.deal.productrows.set замінює весь список позицій угоди. Кожна позиція:

$products[] = [
    'PRODUCT_NAME' => $basketItem->getField('NAME'),
    'PRICE'        => $basketItem->getPrice(),
    'QUANTITY'     => $basketItem->getQuantity(),
    'CURRENCY_ID'  => 'RUB',
    'PRODUCT_ID'   => 0, // якщо немає каталогу в Б24 — 0
];

Якщо в Бітрікс24 є каталог товарів і він синхронізований з сайтом через CommerceML, передаємо реальний PRODUCT_ID для коректної аналітики по товарах.

Як уникнути дублів контактів?

При повторному замовленні того ж клієнта перевіряємо наявність контакту через crm.duplicate.findByComm за телефоном. Якщо контакт існує — використовуємо його ID, не створюємо дубль. Нова угода прив'язується до існуючого контакту. Згідно з документацією Бітрікс24 REST API, метод crm.duplicate.findByComm дозволяє уникнути дублікатів. Ручна перевірка займає 5 хвилин на замовлення, автоматична — 0.5 секунди.

Типові помилки та їх вирішення

• Відсутність перевірки дублів контактів — призводить до засмічення CRM. Рішення: завжди викликати crm.duplicate.findByComm.
• Неправильний мапінг статусів: наприклад, якщо у воронці кілька стадій і код статусу не відповідає. Рішення: узгодити мапінг до запуску.
• Перевищення лімітів запитів до REST API. Рішення: використовувати чергу агентів і не більше 2 запитів на секунду.
• Ігнорування користувацьких полів: якщо в замовленні є кастомні властивості, їх треба явно мапити в UF_CRM_*.

Наш підхід та процес

Ми використовуємо стек: PHP 8.1+, інфоблоки v2.0, ORM Бітрікс, REST API (cloud або on-premise). Обробники обгорнуті в try-catch, помилки пишуться в HL-блок. На вебхуці виставляються права: crm.contact.add, crm.deal.add, crm.deal.update, crm.duplicate.findByComm, crm.deal.productrows.set. Дотримуємося лімітів — не більше 2 запитів на секунду. За 6+ років на ринку ми реалізували понад 50 інтеграцій, обслуговуємо понад 20 постійних клієнтів. Маємо сертифікацію Бітрікс24.

Етапи роботи

1. Аналітика — вивчаємо структуру замовлень, воронку продажів, виявляємо нестандартні поля.
2. Проектування — складаємо схему мапінгу полів і статусів, узгоджуємо з вами.
3. Реалізація — пишемо обробник, налаштовуємо вебхук, тестуємо на тестовому замовленні.
4. Тестування — перевіряємо створення/оновлення угод, дублі, обробку помилок.
5. Деплой — викочуємо на бой, моніторимо логи перший день, даємо гарантію на роботу.

Терміни орієнтовно

Базове налаштування передачі нових замовлень — 6–8 годин. Повна двостороння синхронізація статусів — 2–3 робочих дні. Вартість базової інтеграції від 15 000 грн. Вартість розраховується індивідуально після аудиту вашого сайту. Оцінимо проект безкоштовно — замовте консультацію.

Що входить у роботу?

• Документація з інтеграції (схема мапінгу, опис обробників)
• Налаштування вебхука та прав доступу
• Розробка та тестування обробника подій
• Навчання менеджерів роботі з інтеграцією
• Підтримка протягом 30 днів після запуску

Ми надаємо письмову гарантію на безперебійну роботу.

Типові проблеми виникають через відсутність перевірки дублів або невірного мапінгу статусів. Наш досвід показує: 80% помилок вирішуються додаванням перевірок та асинхронною обробкою. Ми гарантуємо стабільну інтеграцію та підтримку після запуску. Зв'яжіться з нами для детального аудиту вашої системи.

Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії

Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.

sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.

Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.

Чому однокроковий чекаут збільшує конверсію?

Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:

• Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
• Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
• Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
• Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
• Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.

Під капотом:

• Повний AJAX — жодного перезавантаження. Компонент працює через Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
• Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска inputmask + серверна перевірка.
• Збереження даних при випадковому відході — sessionStorage зберігає введене, при поверненні все на місці.
• Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
• Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.

Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.

Як відновити покинуті кошики?

Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.

Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.

Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.

Гостьове замовлення: убити обов'язкову реєстрацію

«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.

• Покупка без акаунта — оформлюємо через CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
• Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
• Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
• Авторизація прямо в чекауті: SMS-код замість пароля — через Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.

Крос-сел: допродажі, які не дратують

У кошику

Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.

Управління через адмінку

Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.

Промокоди: правильна реалізація

UX промокоду:

• Поле видно, але не кричить — не відволікає тих, у кого коду немає.
• Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «Error 422».
• Знижка видна в підсумковому розрахунку окремим рядком.
• Можна прибрати промокод і застосувати інший.

UX-оптимізація: дрібниці, які вирішують

Десктоп:

• Прогрес-бар — користувач бачить, де він.
• Розумні дефолти — найпопулярніший спосіб доставки вже вибраний (визначаємо за статистикою b_sale_order).
• Мінімум обов'язкових полів — тільки те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково.
• Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах.

Мобільні:

• Великі кнопки — палець не промахується. min-height: 48px за гайдами Google.
• Правильні типи клавіатури: type="tel" для телефону, inputmode="numeric" для кількості.
• Кнопка «Оформити» зафіксована внизу — position: sticky.
• Згорнуті секції — екранний простір на 375px дорогий.

Обробка помилок:

• «Перевірте номер картки» замість «Payment processing error».
• Автопрокрутка до першої помилки — scrollIntoView({ behavior: 'smooth' }).
• «Товар закінчився» — обробляємо без втрати заповнених даних. Пропонуємо аналог або прибираємо з перерахунком.

Інтеграції

• DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
• Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
• НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
• LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
• CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
• Склад — перевірка залишків через CCatalogStoreProduct::GetList() у реальному часі.

// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

Що входить у роботу

• Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
• Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
• Розробка компонента чекауту на основі Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
• Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
• Налаштування промокодів, крос-селу, покинутих кошиків.
• Тестування на реальних сценаріях: десктоп, мобільні, планшети.
• Передача документації (опис API, інструкції для менеджерів, доступи).
• Навчання співробітників роботі з новим кошиком.
• Пост-релізна підтримка — 2 тижні моніторингу та правок.

Строки

Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.