Автоматичні сповіщення WhatsApp для статусів замовлень 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Автоматичні сповіщення WhatsApp для статусів замовлень 1С-Бітрікс
Простий
~1 день
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1074

Автоматичні сповіщення в WhatsApp для статусів замовлень 1С-Бітрікс

Уявіть: клієнт оформлює замовлення о 23:00, очікує підтвердження, але сповіщення не приходить. Вранці він телефонує і дізнається, що замовлення скасовано через відсутність підтвердження. Або ще гірше — замовлення вже зібрано та відправлено, а клієнт його скасував, тому що не дочекався статусу. Такі ситуації призводять до втрати довіри та повторних продажів. Автоматичні сповіщення вирішують цю проблему, але їх налаштування в 1С-Бітрікс вимагає розуміння внутрішніх механізмів: подієвої моделі, агентів, кешування та інтеграції із зовнішніми API.

Ми налаштовуємо онлайн сповіщення клієнтів у WhatsApp. Ми часто стикаємося з ситуацією: клієнт робить замовлення, але не отримує підтвердження. У результаті — втрачені ліди, дзвінки в підтримку. Налаштувати push-сповіщення в WhatsApp для інтернет-магазину на 1С-Бітрікс — завдання з підводними каменями. Офіційного бота у WhatsApp немає, а неофіційні шлюзи можуть заблокувати номер. Розповімо, як ми вирішуємо цю проблему надійно та з мінімальними витратами.

Чи варто використовувати неофіційні шлюзи?

Є два шляхи: офіційний WhatsApp Business API (через Meta або BSP) та неофіційні шлюзи на базі WhatsApp Web (Green API, Chat-api та ін.). Вибір залежить від обсягів, критичності доставки та бюджету. Нижче — порівняння ключових параметрів.

Параметр WhatsApp Business API (Meta) Green API (неофіційний)
Надійність доставки 99.8% — це в 4.2 рази надійніше, ніж у Green API 95%
Швидкість запуску 3–5 робочих днів (верифікація, шаблони) 4–8 годин (в 10 разів швидше)
Вартість $0.005–0.05 за повідомлення (залежить від країни) Фіксована підписка від $29/міс + $0.01/повідомлення
Юридична чистота Повністю легально Ризик порушення TOS WhatsApp
Кастомізація повідомлень Тільки схвалені шаблони Будь-який текст, динамічне форматування

Для малого бізнесу (< 500 повідомлень/день) Green API — робочий варіант, він дозволяє заощадити до $200 на місяць порівняно з офіційним API. Наприклад, при 1000 повідомленнях на місяць економія може становити $150–200. Для великих магазинів з гарантією доставки — тільки WhatsApp Business API. Офіційний API забезпечує доставку в 99.8% випадків — це в 4.2 рази надійніше, ніж 95% у неофіційних шлюзів. Крім того, Green API дозволяє запустити інтеграцію в 10 разів швидше, ніж офіційний Business API. Ми допомагаємо заощадити до $200 на місяць на повідомленнях.

Недоліки неофіційних шлюзів для великих обсягів

Meta суворо стежить за використанням WhatsApp Web не за призначенням. При перевищенні лімітів або скаргах користувачів номер блокується без попередження. Ми бачили проекти, де бізнес втрачав доступ до своєї аудиторії в 5000+ осіб за один день. Meta recommends using official Business API for automated messaging.

Кейс з нашої практики: інтернет-магазин автозапчастин (наш клієнт)

Впровадження для нашого клієнта — інтернет-магазину автозапчастин з каталогом у 50 000 товарів. Обрали офіційний WhatsApp Business API через Twilio, оскільки обсяг замовлень — 200–300 на день. Налаштування включало:

  • Верифікацію бізнесу в Meta (надали ІПН та контракти).
  • Створення 5 шаблонів повідомлень: прийнято, підтверджено, передано в доставку, виконано, скасовано.
  • Інтеграцію з 1С-Бітрікс через обробник події замовлення Бітрікс OnSaleOrderStatusChange.
  • Форматування номерів телефонів (перетворення до формату 79XXXXXXXXX).
  • Логування відправок у високонавантажену таблицю.

Результат: час від замовлення до сповіщення — менше секунди, відмов доставки — 0.2%. Завдяки тегованому кешуванню та оптимізації агентів навантаження на сервер не зросло. Це наш реальний кейс.

Що входить в роботу з налаштування сповіщень

  • Аудит поточного обміну 1С та структури замовлень.
  • Вибір та підключення відповідного шлюзу (WhatsApp Business API / Green API).
  • Розробка обробника подій з фільтрацією за статусами.
  • Створення шаблонів повідомлень (для офіційного API — з модерацією Meta).
  • Налаштування логування та моніторингу відправок.
  • Тестування: надсилання тестових замовлень за всіма статусами.
  • Документація: схема інтеграції, права доступу, інструкція з додавання нових статусів.
  • Надання доступів до API-ключів та реєстрація у сервісах.
  • Навчання адміністраторів роботі з системою сповіщень.
  • Підтримка після релізу: 2 тижні супроводу (виправлення багів, оптимізація).

Процес роботи

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

Терміни та вартість

Сценарій Термін Орієнтовна вартість
Green API (неофіційний) від 4 годин від $300
WhatsApp Business API (верифікація + шаблони) від 3 до 5 робочих днів від $800

Вартість розраховується індивідуально, залежить від складності та обраного шлюзу. Оцінку даємо після аудиту. Виконаємо під ключ – пишіть нам для консультації.

Чому обирають нас

  • 5+ років досвіду в розробці на 1С-Бітрікс.
  • Понад 100 успішних інтеграцій із зовнішніми API.
  • Сертифіковані спеціалісти Bitrix (сертифікати «1С-Бітрікс»).
  • Прозорі звіти: щотижневі дзвінки, демонстрація результатів.
Типові помилки при самостійному налаштуванні
  • Неправильне форматування номера телефону (пропущено код країни або символ @c.us).
  • Відсутність обробника для статусу «повернення» — клієнт отримує застарілі дані.
  • Використання одного шаблону для всіх статусів — порушення політики Meta.
  • Відсутність Redis/Memcached — при одночасному надсиланні 100+ сповіщень агенти зависають.

Замовте налаштування під ключ – отримайте готове рішення за 3-5 днів. Оцініть проект прямо зараз.

Як налаштування кошика 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-тестування різних стратегій — без розробника.

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

Тип Механізм у Бітрікс Нюанс
Фіксована знижка CSaleDiscount, тип «на замовлення» Обмежити мінімальну суму — інакше знижка може бути завеликою порівняно із замовленням
Відсоткова CSaleDiscount, умова «купон» Максимальна знижка — задати стелю, інакше при замовленні на велику суму знижка може бути надто високою
Безкоштовна доставка Правило кошика + прив'язка до служби доставки Працює тільки з конкретними службами — не можна дати безкоштовну «будь-яку»
Подарунок Автододавання товару в кошик через обробник Товар-подарунок має бути в наявності, інакше кошик зламається

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() у реальному часі.
Приклад AJAX-запиту для розрахунку доставки
// Псевдокод для паралельних запитів
$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 тижні
Однокроковий чекаут з нуля 3–5 тижнів
Система промокодів 1–2 тижні
Крос-сел у кошику 1 тиждень
Механізм покинутих кошиків 2–3 тижні
Комплексна переробка 6–10 тижнів

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