Як під’єднати ваш застосунок на ШІ до інструментів, якими ви вже користуєтеся

Звичний момент у житті застосунку на ШІ: він працює, ви користуєтеся ним тиждень, а потім помічаєте, що копіюєте дані з нього кудись.

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

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

Чесна правда про інтеграції

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

Перш ніж просити свій конструктор на ШІ «під’єднатися до Slack», дайте відповідь на три запитання:

Які зміни в моєму застосунку мають щось запускати деінде? (Нова реєстрація, оновлення статусу, завантажений файл.)
Що має статися деінде, коли ці зміни відбуваються? (Опублікувати повідомлення, додати рядок, надіслати лист.)
Чи має щось повертатися назад у мій застосунок? (Іноді відповідь — ні, і це набагато простіше.)

Що чіткіші ви в цих трьох речах, то простіша інтеграція. Причина, через яку інтеграції стають заплутаними, — зазвичай не технологія, а те, що ніхто заздалегідь не вирішив, яка система «володіє» певним фрагментом інформації. Якщо і ваш застосунок, і ваш Google Sheet вважають себе джерелом істини щодо e-mail клієнтів, ви будете звіряти їх між собою вічно.

Три способи з’єднати речі

Є по суті три шаблони підключення вашого застосунку до інших інструментів. Оберіть той, що підходить, і не перемудровуйте з рештою.

1. Вихідні сповіщення (одностороннє назовні)

Це найпростіший шаблон, і він покриває більше випадків, ніж люди очікують. Ваш застосунок щось робить. Він надсилає повідомлення кудись. Готово.

Приклади:

Нова надіслана форма публікується в канал Slack.
Новий клієнт запускає вітальний лист через ваш поштовий інструмент.
Завантажений файл отримує копію у спільну папку Google Drive.

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

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

2. Заплановані синхронізації (одностороннє всередину чи назовні, за годинником)

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

Приклади:

Раз на день підтягувати нові рядки з Google Sheet у застосунок як чернеткові елементи на перегляд.
Раз на годину оновлювати список майбутніх бронювань із вашого календаря.

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

Більшість конструкторів на ШІ можуть налаштувати заплановане завдання однією інструкцією: «Щоранку о 8:00 підтягуй нові відповіді з цієї Google-форми й створюй запис для кожної в таблиці “Заявки”.»

3. Вебхуки (шаблон реального часу)

Третій шаблон — і той, з яким треба бути обережними, — вебхуки. Вебхук — це маленьке повідомлення, яке інший інструмент надсилає вашому застосунку щоразу, коли щось стається. Це жива версія запланованої синхронізації.

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

Використовуйте вебхуки, коли:

Вам потрібна відповідь за секунди, а не хвилини.
Інструмент-джерело їх пропонує (більшість сучасних інструментів пропонують).
Ви готові протестувати сценарії збою — що станеться, якщо вебхук прийде двічі? А якщо не прийде взагалі?

Розумна інструкція для вебхука: «Додай ендпойнт вебхука за адресою /webhooks/stripe, що приймає події платежів. Коли надходить успішний платіж, знайди відповідного клієнта за e-mail і онови його статус на “Сплачено”.» Потім протестуйте. Надішліть фейковий платіж. Надішліть справжній. Надішліть два поспіль.

Питання Zapier

Багато людей, коли хочуть щось з’єднати, спершу тягнуться до Zapier чи Make. На це є гарна причина — ці інструменти є інтеграціями як продуктом. Вони дають вам візуальний конструктор, де ви з’єднуєте «коли X стається в інструменті A, зроби Y в інструменті B».

Ви цілком можете використовувати Zapier зі своїм застосунком на ШІ. Найчистіший шаблон такий:

Ваш застосунок надсилає вебхук у Zapier, коли стається щось цікаве.
Zapier розгалужує далі — повідомлення в Slack, поштові сповіщення, рядки таблиці, оновлення CRM.

Навіщо маршрутизувати через Zapier замість того, щоб просити конструктор на ШІ під’єднатися до кожного інструмента напряму? Дві причини. По-перше, коли ви завтра вирішите, що хочете ще й створювати картку в Trello, ви додаєте це в Zapier за дві хвилини замість того, щоб просити конструктор на ШІ передеплоїтися. По-друге, якщо інструмент нижче по ланцюжку змінить свій API (а вони змінюють), Zapier це обробить без потреби торкатися вашого застосунку.

Компроміс — вартість. Zapier швидко дорожчає, якщо у вас великий обсяг. Якщо ви надсилаєте менше ніж кілька сотень подій на місяць, Zapier, імовірно, правильний вибір. Якщо ви надсилаєте десятки тисяч, попросіть конструктор на ШІ інтегруватися напряму.

Що протестувати, перш ніж довіряти

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

Три тести для будь-якої інтеграції, яку ви додаєте:

Чи справді вона працює від кінця до кінця? Не просто перевірте, що ваш застосунок надіслав повідомлення. Зайдіть в інструмент-приймач і переконайтеся, що повідомлення прийшло й виглядає правильно.
Що станеться, коли приймач лежить чи помиляється? Поставте на паузу свій zap у Zapier. Надішліть дані. Чи обробляє ваш застосунок це гладко, чи помиляється й відмовляється зберігати дані локально? (Ви хочете гладко.)
Чи є спосіб повторити чи надіслати знову? Якщо щось пішло не так, чи можете ви перезапустити інтеграцію для конкретного запису? Якщо ні, ви збудували односторонній люк без вороття.

Якщо ваш конструктор на ШІ сам не дає відповідей на це, запитайте. «Як я дізнаюся, що повідомлення в Slack не надіслалося?» — розумне запитання, і відповідь має бути на кшталт «помилки логуються тут, і ви можете повторити з цієї сторінки».

Розумна відправна точка

Якщо ви тільки починаєте додавати інтеграції, ось прагматичний порядок:

Одне вихідне сповіщення — оберіть єдине найкорисніше. «Коли надходить новий лід, опублікуй у Slack» чи «Коли проєкт позначено Завершено, надішли лист клієнту».
Одна запланована синхронізація — зазвичай витягування даних із вашого застосунку в місце, де ваша команда вже працює (спільна таблиця, CRM).
Потім, лише якщо вам це справді потрібно, вебхук для одного конкретного випадку реального часу.

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

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