Помічник може добре пояснювати інформацію, але для роботи з актуальними заявками, контактами чи документами йому потрібен зв’язок із системами компанії. Інтеграція визначає, звідки надходять факти, які операції доступні та як перевіряється їх виконання. Саме цей шар перетворює окрему модель на частину робочого процесу.

Розглянемо умовний сценарій: працівник просить знайти звернення в CRM, підсумувати історію та підготувати наступну задачу. Команді потрібно спроєктувати весь шлях від запиту до підтвердженого запису, включно з помилками й повторними спробами.

Спочатку опишіть конкретну операцію

Фраза «підключити ШІ до CRM» не визначає обсяг розробки. Пошук звернення, читання історії, створення задачі та зміна відповідального — окремі операції з різними правами й наслідками. Для кожної варто описати вхідні дані, результат і умови виконання.

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

Як працює зв’язок через API

API — програмний інтерфейс, через який одна система звертається до іншої. Інтеграційний сервіс отримує запит, перевіряє його, викликає потрібну операцію CRM і перетворює відповідь у формат, з яким може працювати помічник. Модель не повинна самостійно визначати довільну адресу чи необмежену команду для виконання.

Розробники уточнюють підтримувані методи, формат полів, обмеження кількості запитів і способи авторизації. Також перевіряють, чи існує тестове середовище. Наявність API ще не означає, що через нього доступні всі операції, видимі людині в інтерфейсі.

Як може виглядати сценарій із CRM

  1. Працівник указує номер звернення або інші дані для пошуку.
  2. Сервер перевіряє користувача та виконує дозволений пошук. Якщо збігів кілька, система просить уточнення.
  3. Інтеграція отримує лише потрібні для задачі поля та доступну історію.
  4. Помічник готує підсумок, відокремлюючи факти із запису від запропонованого наступного кроку.
  5. Працівник перевіряє чернетку задачі: зміст, відповідального та пов’язане звернення.
  6. Після підтвердження сервер створює задачу й отримує її ідентифікатор. Лише тоді система повідомляє про завершення.

Ця схема дозволяє зрозуміти, де потрібна гнучка робота з текстом, а де — звичайна перевірка полів і чітка програмна операція. Це також основа для тестування кожного переходу.

Права доступу не варто залишати моделі

Якщо користувач може читати звернення лише своєї команди, інтеграція повинна враховувати це обмеження. Загальний технічний доступ без перевірки користувача може відкрити більше даних, ніж передбачено процесом. Тому повноваження сервісу та людини узгоджують окремо.

OWASP описує надмірні функції, дозволи й самостійність як причини небажаних дій агентних систем. Практичний висновок для проєкту — надавати інструменту лише потрібні операції та перевіряти дозвіл на сервері. Інструкція в чаті не замінює цієї перевірки.

Що робити зі збоями й повторними запитами

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

Поведінку визначають відповідно до можливостей API. Для операцій запису можна використовувати підтримуваний ключ ідемпотентності або інший механізм перевірки повтору. Якщо результат невідомий, інтерфейс має показати це чесно й запропонувати перевірку, а не заявляти про успіх чи запускати безмежні спроби.

Для читання та зміни даних можуть діяти різні правила повторення. Кількість спроб, час очікування й дії після остаточної помилки погоджують заздалегідь. Це звичайні інтеграційні вимоги, які залишаються важливими й у рішеннях із ШІ.

Які дані передавати для задачі

Для підсумку звернення не завжди потрібна вся картка контакту та повна історія компанії. Узгодьте мінімальний набір полів, потрібний для результату. Це полегшує перевірку, зменшує обсяг зайвого контексту й допомагає уникнути змішування інформації з різних процесів.

Зміст отриманих записів також варто відокремлювати від правил роботи програми. Наприклад, текст у коментарі CRM є даними для аналізу; він не повинен сам надавати помічнику дозвіл на нову операцію. Доступні інструменти визначаються налаштуваннями системи.

Що перевірити перед запуском

  • Правильний запис, кілька збігів і відсутність результату пошуку.
  • Доступ користувачів із різних команд і зміна їхніх прав.
  • Неповні поля, інший формат дати й застарілий запис.
  • Недоступність API, обмеження частоти та невідомий результат операції.
  • Повторне натискання кнопки та повторна доставка тієї самої події.
  • Збіг повідомлення про успіх із фактично створеною задачею.

Який опис потрібен для початку

Підготуйте перелік систем, документацію їхніх інтерфейсів, приклади записів без зайвих даних і одну пріоритетну задачу. Визначте, які дії можна виконувати самостійно, а які потребують погодження. Цього достатньо, щоб почати предметну технічну оцінку.

Корисна інтеграція дає перевірюваний результат у чинному процесі компанії. Підготовку прикладів описано в матеріалі про початок розробки, а перевірку поведінки — у статті про тестування.

Джерело та подальше читання