- Спочатку перевіряємо штатні функції та готові інтеграції, потім конектор і окрему доробку через API.
- Потрібну операцію та доступ у вашому акаунті перевіряємо до оцінки; назви програм не є переліком наших кейсів.
- Перевіряємо повтори та збої, залишаємо акаунти під контролем клієнта; вартість погоджуємо після безкоштовного розбору.
Якщо KeyCRM, Checkbox або Poster не закриває одну частину вашої роботи, міняти всю програму зазвичай зарано. Спершу перевірте її налаштування та готові інтеграції, потім сервіс-конектор, далі окрему доробку через офіційний API. Власна система має сенс, коли обмеження зачіпають основу бізнесу, а підтримка обходів забирає більше, ніж дає збереження програми.
API - це дозволений програмою спосіб, яким інша програма може отримувати дані або виконувати визначені дії. Наприклад, сайт передає замовлення в CRM, а окремий модуль забирає дані для вашого звіту. Це не доступ до всіх внутрішніх функцій сервісу. Спочатку треба перевірити саме потрібну дію та її доступність у вашому акаунті.
Налаштувати, підключити чи доробити: порядок вибору
Спочатку можливості самої програми
Попросіть адміністратора показати налаштування полів, статусів, звітів і список готових підключень. Нерідко ручний крок прибирається вже наявною функцією. Це перший і зазвичай найдешевший шлях: немає окремого модуля, який доведеться підтримувати. Ознака достатнього рішення: працівник проходить потрібний сценарій до кінця без додаткової таблиці чи копіювання.
Конектор для короткого обміну
Сервіси на кшталт n8n або Make з'єднують дії різних програм у послідовність. Такий варіант перевіряємо, коли треба передати заявку, оновити поле чи повідомити відповідального. Умова вибору: доступні всі потрібні дії, помилки видно, є відповідальний за повторне виконання. Окремо ми розібрали коли вистачить n8n або Make, а коли потрібна розробка.
Окремий модуль через API
Доробка доречна, якщо готове підключення не відтворює ваше правило: особливий розрахунок, погодження, звіт чи доступ підрядника. Можемо зробити модуль, бота, сторінку або обмін поруч із чинною програмою. Перед оцінкою перевіряємо, чи API дозволяє читати потрібні дані й повертати результат. Доступ до даних не означає можливості змінити будь-який екран усередині сервісу.
Заміна, коли доробки вже не допомагають
Розглядайте власну систему, коли основний процес постійно доводиться вести поза програмою, потрібної операції немає в API або кілька обходів суперечать один одному. Порівнюйте підтримку доробок із користю від збереження звичного інструмента. У рішення про заміну включайте перенесення історії, навчання людей і перевірку чинних підключень. Самого бажання мати інший вигляд картки замало.
Яке обмеження справді треба прибрати
Сформулюйте проблему як дію працівника: «після погодження замовлення вручну переносимо позиції в іншу програму». Такий опис одразу показує початок і результат обміну. Формулювання «потрібна автоматизація» не пояснює, що перевіряти на прийманні. Типові причини звернення:
- Власний розрахунок вартості, знижки чи комплектації не вкладається в доступні правила.
- Потрібні свої етапи та статуси, але чинний маршрут не дає контролювати перехід.
- Керівник збирає відсутній звіт із кількох вивантажень.
- Ті самі товари, замовлення або реквізити набирають у двох програмах.
- Працівник має бачити свою частину роботи без доступу до всієї бази.
- Клієнту потрібне повідомлення в Telegram або Viber, а менеджеру доводиться писати вручну.
- Документ готують за власним шаблоном, копіюючи поля з картки.
Для повідомлень окремо перевіряємо доступний спосіб надсилання в обраному каналі та умови його використання. Для документів потрібні зразок шаблону й правило вибору даних. Для звіту визначте, що саме означає кожен показник: створене замовлення, завершений продаж і отримана оплата дають різні відповіді.
KeyCRM і SalesDrive: сайт, замовлення та власні правила
Офіційний OpenAPI KeyCRM передбачає роботу із замовленнями, покупцями, товарами та картками воронок. API SalesDrive дозволяє додавати й оновлювати заявки, працювати з товарами та отримувати статуси; є повідомлення про додавання заявки й зміну статусу. Це можливі точки підключення, а не доказ готовності будь-якого сценарію.
Можемо підключити форму сайту до потрібного процесу, передати додаткові поля, підготувати окремий звіт або розрахунок перед створенням замовлення. Спершу перевіряємо штатні поля й автоматизації CRM. Якщо потрібен власний розрахунок, погоджуємо, де він виконується, хто може змінити результат і що відбувається після ручного виправлення менеджером.
Покажіть звичайну заявку й виняток: клієнт змінив склад після погодження. Якщо сайт повторно передає заявку, CRM має отримати оновлення того самого запису. На прийманні перевіряємо відповідність товарів, потрібний статус і збереження ручних правок, які обмін не повинен перезаписувати. Додавання нового клієнта та нового замовлення також перевіряємо окремо.
Checkbox: фіскальний чек із вашого процесу
Офіційний API Checkbox описує відкриття й закриття зміни, створення чеків продажу та повернення, отримання статусу й вигляду чека. Можемо зв'язати ці дії з сайтом або CRM, якщо готова інтеграція не підтримує потрібний маршрут. Підтверджена оплата і завершене створення фіскального чека мають залишатися окремими станами.
Перед роботою разом із відповідальним за облік визначаємо, у який момент ваш процес має створювати чек, які позиції та способи оплати передавати, як оформлювати повернення. Наявність API сама по собі не визначає правила фіскалізації саме вашої операції. Перевіряємо налаштування каси й доступні сценарії сервісу.
Випробування проводимо на тестовій касі, як вимагає документація Checkbox. Якщо відповідь затрималась, модуль спершу з'ясовує результат попередньої спроби. Менеджер має бачити, що чек ще обробляється або потребує уваги. Повторне натискання не повинно створювати інший чек на ту саму операцію.
Poster і Syrve: меню та замовлення з сайту
Poster документує отримання товарів і техкарт меню та створення онлайн-замовлень через API. У Syrve Cloud API є розділи меню й створення та отримання замовлень доставки. Потрібну операцію, доступ для вашого закладу та версію підключення перевіряємо перед оцінкою. Наявність функції в документації не підтверджує її доступність у кожній конфігурації.
Можемо підключити сайт замовлень, сторінку меню або окремий звіт. Почніть із одного закладу та погодженого набору позицій. Покажіть не лише назву страви, а й доступні варіанти, додатки, кількість і спосіб отримання. Якщо правила сайту відрізняються від каси, треба вирішити цю різницю до запуску.
На перевірці замовлення має з'явитися там, де його справді приймає працівник. Отримана сайтом відповідь ще не замінює цього результату. Окремо перевіряємо недоступну позицію, зміну складу та повтор після затримки. Не обіцяємо через API довільно переписати внутрішню роботу касової програми.
Binotel і Ringostat: дзвінок має наступну дію
Binotel у своїх офіційних матеріалах описує отримання інформації про дзвінки, статистику та виклик із CRM. Повну технічну документацію сервіс надає через підтримку. Ringostat документує вивантаження журналу дзвінків і повідомлення про події. Можемо використати доступні дані для картки звернення або звіту.
Корисна задача звучить так: після пропущеного дзвінка відповідальний бачить звернення, бере його в роботу й фіксує результат. Спершу перевіряємо готовий зв'язок телефонії з вашою CRM. Для окремої доробки погоджуємо, як знайти вже наявного клієнта та що робити, якщо за номером знайдено кілька записів.
Повторне повідомлення про один дзвінок має доповнити історію, а не створити новий запит на передзвін. Доступ до записів розмов визначає власник процесу. Не передаємо їх у загальний чат лише тому, що інтеграція може отримати посилання.
monobank: еквайринг для бізнесу
Для приймання оплат на сайті перевіряємо API еквайрингу monobank: він документує створення рахунку, перевірку статусу та скасування оплати. Тут ідеться про підключення бізнесу до еквайрингу. Доступ до особистого рахунку власника не є передумовою такого сценарію.
Можемо підключити оплату до замовлення та передати підтверджений результат у CRM. Статус «оплачено» встановлюємо після перевірки повідомлення банку або запиту статусу, а не після повернення покупця на сторінку магазину. Власник визначає, яка дія дозволена після підтвердження: повідомлення менеджеру, підготовка чека чи передача замовлення далі.
Під час перевірки потрібні успішна й невдала оплата, затримка підтвердження та повторне повідомлення банку. Якщо результат невідомий, спершу перевіряємо чинний рахунок. Покупець і менеджер мають бачити очікування перевірки, щоб невизначеність не перетворилася на повторне замовлення або зайвий запит на оплату.
Нова Пошта: оформлення та контроль відправлення
Офіційні матеріали Нової Пошти передбачають створення експрес-накладних, довідники й керування відправленнями через API. Можемо підключити вибір місця доставки на сайті, створення накладної з погодженого замовлення та повернення доступного статусу в робочий інтерфейс. Конкретні методи перевіряємо для потрібного напрямку доставки.
Визначте, хто підтверджує дані одержувача, вагу, спосіб оплати й платника доставки. Якщо накладна вже існує, повтор обміну має знайти її. Зміна замовлення після оформлення відправлення потребує окремого правила: мовчки створювати ще одну накладну не можна.
Вибір відділення, оформлена накладна та фактичне відправлення є різними результатами. На прийманні звіряємо їх окремо. Не прирівнюємо статус замовлення в CRM до події перевізника без погодженої відповідності.
Prom і Rozetka: робота з кабінетами продавця
Публічний API Prom описує отримання замовлень, зміну їхніх статусів та роботу з товарами. API продавця Rozetka містить операції із замовленнями, цінами й наявністю. Можемо підключити ці операції до чинного обліку, якщо потрібних дій немає в готовому обміні.
Спочатку визначаємо, де менеджер змінює дані й який результат має повернутися на майданчик. Для Rozetka окремі зміни залежать від статусу замовлення, тому правило треба перевірити на потрібній операції. Для обох сервісів перед оцінкою перевіряємо доступ у вашому кабінеті та актуальні обмеження.
Якщо головна проблема в залишках між каналами, скористайтеся окремим розбором синхронізації магазину, складу й маркетплейсів. Саме передавання числа не вирішує питання резервів і скасувань. Для першого етапу оберіть один канал і конкретну операцію, яку зараз дублюють вручну.
BAS і 1С: зберегти облік, додати зв'язок
Якщо бухгалтерія та склад уже працюють у BAS або 1С, спершу визначаємо дані й напрямки обміну з урахуванням конфігурації та доробок. Питання документів, довідників і відповідальності систем докладно розібрані в матеріалі про інтеграцію 1С/BAS з CRM. Окремий звіт або обмін не потребує автоматичної заміни обліку.
Задача → що робимо
| Задача | Що робимо |
|---|---|
| Заявку набирають повторно | Передаємо поля та зберігаємо зв'язок між записами |
| Потрібен власний розрахунок | Виносимо погоджене правило в окремий модуль |
| Немає потрібного звіту | Збираємо доступні дані й погоджуємо показники |
| Документ копіюють вручну | Готуємо файл за перевіреним шаблоном |
| Клієнту пише менеджер | Перевіряємо канал, подію та умови надсилання |
| Підряднику потрібні обмежені дані | Перевіряємо штатні права або робимо окрему сторінку |
Що може піти не так і як перевіряємо запуск
Ліміти й зміни API. Перед роботою перевіряємо документацію сервісу та обсяг обміну. Передачі, які не пройшли одразу, зберігаємо для контрольованого повтору; показуємо час останнього успіху й помилки. Після зміни API потрібна перевірка відповідного сценарію. Обіцянка «підключити назавжди» приховує майбутню роботу.
Повтори та невідомий результат. Для операції зберігаємо її номер і зв'язок із записом у другій програмі. Якщо відповідь не надійшла, перевіряємо результат перед повтором. На прийманні навмисно повторюємо передачу: вона не повинна створити ще одне замовлення, чек або повідомлення клієнту.
Права та ключі. Акаунти програм і ключі залишаються під контролем клієнта. Погоджуємо необхідні дозволи, спосіб передачі доступу та його відкликання. Ключі не вставляємо у відкритий код сторінки, паролі в першому повідомленні не потрібні. Окрема сторінка для працівника перевіряє права на сервері, навіть якщо її адреса відома сторонній людині.
Підтримка та повернення до ручної роботи. До запуску фіксуємо, хто стежить за помилками, хто оновлює доробку й куди звертатися при збої. Передаємо інструкцію та погоджуємо тимчасовий ручний порядок. Вимкнення модуля не скасовує вже створені записи: перед повторним запуском їх треба звірити.
Спершу перевіряємо обмежений сценарій на тестових даних: звичайне виконання, неправильне поле, відмова в доступі, недоступний сервіс і відновлення. Потім відповідальний працівник проходить весь маршрут у своєму інтерфейсі. Розширюємо обмін після приймання цього результату.
Що надіслати для безкоштовного розбору
Підготуйте назву програми та тариф, опишіть ручний крок і бажаний результат. Додайте приклад структури даних без імен, телефонів та інших персональних даних. Вкажіть, хто має права адміністратора й хто підтвердить правильність процесу. Паролі та ключі для першого звернення не надсилайте.
На сторінці інтеграцій Artbrain наведені наші чинні підключення: TurboSMS у CRM клініки, 1С, Нова Пошта, Telegram і Google. Підключення до KeyCRM, Checkbox, Poster та інших перелічених програм можемо розглянути як окрему задачу після перевірки документації. Для вашого процесу перевіряємо потрібну дію, а не лише наявність назви програми в каталозі.
Якщо штатних функцій недостатньо, можемо зробити окрему доробку під ваш процес. Після безкоштовного розбору погоджуємо обсяг, вартість і відповідальність за підтримку до початку роботи. Результат розбору має дати зрозумілий вибір: використати наявну функцію, підключити готовий обмін або розробити конкретну відсутню частину.
Часті питання
Чи можна інтегрувати KeyCRM або SalesDrive з наявним сайтом?
Можемо перевірити й підключити потрібний обмін через готову інтеграцію або офіційний API. Для оцінки потрібні назва CRM і тариф, поля заявки та очікуваний результат. Окремо перевіряємо повторну передачу, щоб вона не створювала дубль замовлення.
Чи можна автоматично створювати чеки Checkbox із CRM?
API Checkbox передбачає створення чеків і перевірку їхнього статусу. Можемо підключити цей маршрут після погодження моменту створення чека, складу даних і повернень. Перевірку проводимо на тестовій касі, а затримку відповіді обробляємо без повторного чека на ту саму операцію.
Чи можна передавати замовлення з сайту в Poster або Syrve?
У документації Poster та Syrve Cloud API є операції для онлайн-замовлень або доставки. Перед оцінкою перевіряємо потрібну дію, конфігурацію та доступ вашого закладу. На прийманні замовлення має з’явитися в робочому інтерфейсі працівника.
Чи треба міняти програму, якщо в ній немає потрібної функції?
Спочатку перевірте налаштування й готові інтеграції, потім конектор або окремий модуль через API. Заміну розглядають, якщо обмеження зачіпають основний процес, потрібної операції немає або підтримка обходів забирає більше, ніж дає збереження програми.
Що потрібно для безкоштовного розбору інтеграції?
Надішліть назву програми й тариф, опис ручного кроку, бажаний результат і знеособлений зразок даних. Вкажіть, хто має права адміністратора. Паролі та ключі в першому повідомленні не потрібні. Обсяг, вартість і підтримку погоджуємо до початку роботи.
