Кастомні роботи Бітрікс24: коли штатних сценаріїв не вистачає
Штатні роботи та тригери в Бітрікс24 закривають лінійні сценарії: змінити стадію, поставити завдання, надіслати лист за шаблоном.
Щойно логіка угоди обростає умовами — погодження знижки від суми та сегмента клієнта, перерахунок графіка платежів, збирання комплекту документів з кількох сутностей — конструктор упирається в стелю.
Кастомні роботи Бітрікс24 з'являються саме там, де штатних не вистачає, і закривають розрив між «майже автоматизовано» та реальним процесом.
Ціна цього розриву видна в ручних операціях у CRM. Менеджер дублює дані між угодою, рахунком і карткою клієнта, вручну перераховує умови при кожній правці, копіює реквізити й нагадує колегам про наступний крок.
На потоці в десятки угод на день це години рутини, забуті завдання та зірвані терміни — при тому що сама логіка вже описана й повторюється від угоди до угоди.
Робот на бізнес-процесі знімає цю роботу цілком: сам читає поля угоди, перевіряє умови, звертається до зовнішніх систем і пише результат назад у картку.
Автоматизація угод перестає залежати від того, чи пам'ятає менеджер про регламент — правило виконується однаково на кожній угоді, а відхилення спливають як завдання, а не як забутий пункт.
Розбираємо, як це закривається: які сценарії має сенс виносити в робота, чим він відрізняється від штатного тригера і що потрібно від процесу, щоб автоматизація не зламалася на першій нестандартній угоді.
Що дають кастомні роботи Бітрікс24: ефект і порівняння підходів
Кастомні роботи Бітрікс24 закривають те, що не беруть штатні сценарії: логіку із зовнішніми системами, умовні розгалуження за даними угоди, повторні спроби при збоях інтеграції.
Ефект від автоматизації CRM вважається не «стало зручніше», а в конкретних величинах — частка операцій без ручної участі, час реакції на лід, кількість втрачених звернень.
Де з'являється вимірюваний результат
Робот на стадії угоди підтягує дані з 1С і зовнішніх сервісів, перевіряє умови й переводить угоду далі без оператора — частка ручних операцій падає на 60-80% на типових сценаріях.
Обробка вхідного ліда з маршрутизацією за регіоном і завантаженням менеджера скорочує час першої відповіді з годин до хвилин.
Повторні спроби й журналювання на кожному кроці прибирають клас відмов «інтеграція впала, заявка зависла» — замість тиші в логах з'являється запис із причиною та автоматичний повтор.
Чим відрізняється від штатних інструментів
Штатні роботи й тригери працюють у межах передбачених дій: зміна стадії, лист, завдання. Бізнес-процеси тягнуть складні погодження, але погано переносять зовнішні виклики та масові операції — на обсязі починають гальмувати.
Кастомний робот — це код усередині бізнес-логіки порталу: він звертається до API, до бази 1С, до зовнішніх сервісів, ухвалює рішення за даними й пише результат назад у картку.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Штатні роботи й тригери | Типові дії всередині порталу | Немає зовнішніх викликів і складної логіки |
| Бізнес-процеси | Погодження, довгі ланцюжки за участю людей | Важко масштабуються, слабка обробка помилок |
| Кастомні роботи | Інтеграції, розрахунки, розгалуження, масові операції | Потребують підтримки коду й тестового контуру |
Бітрікс24 дає точки розширення для такої логіки, але проєктування сценарію, обробка відмов і підтримка залишаються на боці команди — саме там і живе стійкий результат.
Як ми впроваджуємо кастомних роботів: етапи інженерної роботи
Впровадження роботів Битрикс24 починається не з налаштування, а з аудиту бізнес-процесів: дивимося, які сценарії вже живуть у CRM, де співробітники вручну дублюють дії, на яких стадіях угоди губляться.
На виході — карта процесів із точками, де робот знімає ручну роботу, і списком винятків, які не можна автоматизувати без ризику для логіки продажів.
Далі — проєктування та налаштування. Кожного робота прив'язуємо до конкретної стадії або події, описуємо умови спрацювання, поля-тригери та порядок дій, щоб автоматика не конфліктувала з наявними правилами та бізнес-процесами. Нижче — етапи, за якими йде впровадження роботів Битрикс24 від старту до передачі.
- Аудит поточних сценаріїв. Розбираємо воронки, стадії, права доступу та ручні операції. Фіксуємо, які дії повторюються найчастіше і де виникають затримки.
- Узгодження логіки. Описуємо кожен сценарій словами: подія-тригер, умова, дія, відповідальний. Замовник підтверджує логіку до початку налаштування — правки на цьому етапі дешевші, ніж після запуску.
- Проєктування роботів. Визначаємо тип робота під задачу, поля та стадії, на яких він спрацьовує, і точки, де потрібен контроль людини.
- Налаштування та збірка. Збираємо роботів у Битрикс24, зв'язуємо з бізнес-процесами та повідомленнями, налаштовуємо обробку винятків — що робити, якщо дані неповні або угода повернулася на попередню стадію.
- Тестування на реальних даних. Прогоняємо сценарії на копії воронки: перевіряємо спрацювання, відсутність дублів і коректність повідомлень. Помилки ловимо до виведення в робочу CRM.
- Запуск і спостереження. Включаємо роботів поетапно, стежимо за метриками: частка автоматичних дій, час проходження стадії, кількість ручних операцій.
- Передача документації. Віддаємо опис кожного робота, схеми сценаріїв та інструкції для співробітників — команда може підтримувати й доопрацьовувати автоматизацію без нас.
Такий порядок дає передбачуваний результат: автоматика закриває рутину, а не створює нову. Опишіть задачу — повернемося з оцінкою та планом за етапами.
Чим кастомний робот відрізняється від бізнес-процесу та тригера?
Це три різних механізми з різною зоною відповідальності, і плутанина між ними — часта причина, чому автоматизація «не працює».
Бізнес-процес — це послідовність кроків зі станом: він живе в картці сутності, веде її по етапах, зберігає історію і вимагає, щоб хтось (або щось) рухав його вперед. Тригер — це реакція на подію: змінилося поле, надійшов лист, настав час — спрацювало правило.
Кастомні роботи Бітрікс24 займають третю нішу: вони виконують конкретну дію в момент, коли бізнес-процес дійшов до потрібної точки або тригер підняв подію.
Різниця проявляється на практиці. Бізнес-процес зручний там, де є регламент і контроль виконання: погодження, поетапна угода, заявка з кількома відповідальними. Тригер вирішує прості сценарії «якщо — то»: перевести угоду в іншу стадію, поставити завдання, надіслати повідомлення.
Але щойно логіка виходить за межі стандартних умов — потрібен розрахунок за даними із зовнішньої системи, перевірка контрагента, генерація документа за шаблоном із підстановкою десятків полів — штатних блоків не вистачає.
Тут і з'являється кастомна логіка в CRM. Робот не замінює бізнес-процес і не дублює тригер: він викликається з них як виконавець і робить те, що стандартними засобами не виражається.
Вибір механізму автоматизації — це не «що сучасніше», а «що відповідає завданню»: регламент — бізнес-процес, реакція на подію — тригер, нестандартна дія — робот.
Змішувати їх без розбору дорого: логіка розповзається по десятках правил, конфліктує між собою, і при збої незрозуміло, де шукати причину. Коли робот або бізнес-процес спроєктовані під свою роль, картка залишається передбачуваною, а зміни в одному сценарії не ламають сусідні.
Кейс: як кастомні роботи прибрали ручний етап у відділі продажів
Відділ продажів працював на Битрикс24, але між кваліфікацією ліда та постановкою задачі менеджеру залишався ручний етап: узгодження знижки, перевірка дебіторки, збірка комерційної пропозиції з даних у 1С.
Кожен крок жив у голові конкретного співробітника, і варто було йому піти у відпустку — угоди зупинялися.
Що було до впровадження
Заявка з сайту потрапляла в CRM, але далі її рухали руками: менеджер звіряв контрагента з базою 1С, копіював реквізити, вручну виставляв стадію та нагадування. На узгодження знижки йшло в середньому 4-6 годин — робот не міг стартувати, поки не зберуть дані з двох систем.
Заміри за два тижні показали: 22% угод втрачали термін першого дотику, а 8% йшли в роботу з невірною сумою через розсинхрон з 1С.
Що змінили
Написали кастомних роботів, які спрацьовують на зміну стадії та самі звертаються до 1С через обмін. Робот перевіряє контрагента, тягне актуальну дебіторку, підставляє реквізити в шаблон КП і, якщо сума в межах регламенту, переводить угоду далі без участі менеджера.
Якщо поріг перевищено — ставить задачу керівнику з уже зібраним контекстом, а не з порожньою карткою.
Окремий робот стежить за завислими угодами: якщо лід не торкнулися за відведений час, він перерозподіляє його та фіксує причину в історії. Логіка живе в самій CRM, тому не залежить від того, хто сьогодні на зміні.
Що стало
| Метрика | До | Після |
|---|---|---|
| Час першого дотику | 4-6 годин | 15-20 хвилин |
| Угоди з порушенням терміну | 22% | 3% |
| Помилки в сумі через 1С | 8% | 0 |
| Ручних дій на угоду | 6-7 | 2 |
Клас помилок з невірною сумою зник повністю — дані більше не переносять руками. Звільнений час менеджери витрачають на дзвінки, а не на звірку. Рішення побудовано на штатному механізмі бізнес-процесів Битрикс24, тому оновлення платформи не ламають логіку.
Сумніви перед впровадженням: сумісність, міграція, відкат і доступи
Кастомні роботи Битрикс24 працюють поверх штатного движка бізнес-процесів і REST-шару, тому сумісність з існуючою CRM визначається не «магією» робота, а тим, які сутності та поля він зачіпає.
Якщо робот пише у стандартні поля угоди, ліда або смарт-процесу і не підміняє ядро, він уживається з уже налаштованими воронками, правами та тригерами.
Ризик виникає в одному місці — коли кілька роботів пишуть в одне поле за подією: тоді порядок спрацьовування фіксується в налаштуваннях і перевіряється на тестовому контурі до викочування.
Що якщо робот конфліктує з поточною автоматизацією? Конфлікт ловиться на етапі проєктування: ми знімаємо карту подій і полів, дивимося, хто ще на них підписаний, і розводимо роботів за умовами спрацьовування.
Якщо перетин неминучий — робот отримує пріоритет через окреме поле-маркер, а не через правку існуючих правил.
Як проходить міграція та відкат? Логіка робота версіонується: конфігурація вивантажується у файл, зміни йдуть через окрему гілку, а перемикання між версіями — однією операцією.
Відкат повертає попередню конфігурацію без втрати накопичених даних, бо робот не зберігає стан у собі, а читає його з CRM.
Що з доступами та безпекою? Робот працює під окремим сервісним користувачем з мінімально необхідними правами — тільки ті сутності та методи, які реально потрібні. Токени зберігаються в захищеному сховищі, а не в коді, і ротуються за регламентом.
Чи можна доопрацювати робота після здачі без нас?
Так. Передаємо конфігурації, схеми подій і полів, опис точок розширення. Штатний інженер з досвідом Битрикс24 вносить правки в логіку, не переписуючи інтеграцію цілком.
Після здачі замовник отримує на руки:
- конфігурації роботів з описом кожної умови спрацьовування;
- карту подій і полів: хто на що підписаний і в якому порядку спрацьовує;
- схему прав сервісного користувача і регламент ротації токенів;
- інструкцію з викочування, перемикання версій і відкату;
- чеклист перевірки після змін у воронках і смарт-процесах;
- журнал тестових прогонів із зафіксованими результатами.
Опишіть вашу конфігурацію — які воронки, смарт-процеси та зовнішні системи зачіпає автоматизація. Повернемося з оцінкою та планом робіт.
Терміни впровадження кастомних роботів: етапи та орієнтири
Терміни впровадження кастомних роботів Битрикс24 залежать не від обсягу коду, а від того, наскільки швидко вдається зафіксувати бізнес-логіку та отримати доступи до порталу.
Практика показує: сам робот пишеться за лічені дні, а ось узгодження правил спрацьовування, тестування на реальних угодах і перенесення в робочий контур займають основну частину проєкту.
Тому план впровадження ми будуємо так, щоб кожен етап давав перевірюваний результат, а не «рухалися до фінішу».
Етапи та орієнтовні терміни
Що впливає на тривалість проєкту
Розкид термінів дає інтеграція: якщо робот лише змінює стадію угоди та ставить задачу — це один обсяг робіт, а якщо він тягне дані з 1С, звіряє залишки та ініціює документи — зовсім інший.
Окремо закладаємо час на узгодження, коли в процесі беруть участь кілька підрозділів: кожна сторона бачить свою частину логіки, і її потрібно звести в єдиний сценарій без конфліктів.
Ми не розтягуємо етапи штучно і не стартуємо розробку до того, як зафіксовано правила. Такий порядок дозволяє показати працюючий прототип уже на першому тижні та уточнювати деталі на живих даних, а не на припущеннях. Опишіть задачу — повернемося з оцінкою та планом під ваш портал.
