Клієнт надіслав листа про поточний проєкт. Менеджер знаходить його запис у CRM, перечитує історію, додає нотатку й готує відповідь. З наступним зверненням послідовність повторюється.
AI-прототип може показати, як підготувати частину цієї роботи. Для щоденного використання потрібно визначити, які дані система читає, які зміни готує та що їй дозволено виконувати. Бізнесова мета — зменшити сумарні зусилля на обробку звернення й залишити зрозумілу відповідальність за результат.
Перший запуск варто обмежити невеликим процесом, який команда зможе спостерігати й оцінити. Розгляньмо умовний приклад. Він ілюструє підхід до проєктування; клієнтських результатів або виміряної економії в ньому немає.
Визначте одну одиницю роботи
Запишіть речення, у якому є вхідна інформація, очікуваний результат і відповідальний:
Коли надходить клієнтський лист, підготувати нотатку до CRM і чернетку відповіді для відповідального менеджера.
Для першої версії визначте скриньку або категорію звернень і тип клієнтських записів. Домовтеся, що має містити корисна нотатка й кому передавати звернення поза обраною категорією. Наприклад, внутрішня чернетка може містити короткий зміст, посилання на початковий лист і запропонований наступний крок.
Спочатку розберіть поточну роботу. Для розподілу частини листів може вистачити звичайного правила. Для опрацювання тексту потрібен інший підхід. Обирайте поєднання, яке відповідає визначеному процесу та яке команда зможе перевірити.
Якщо ви ще порівнюєте кілька напрямів автоматизації, скористайтеся оцінкою першого процесу для AI.
Розділіть читання, підготовку та виконання
Для кожної з цих можливостей потрібно визначити власні межі:
| Можливість | Межі в нашому прикладі |
|---|---|
| Читати | Отримувати початковий лист і дані клієнта, потрібні для цього завдання. |
| Готувати | Створювати запропоновану нотатку й чернетку відповіді для перегляду менеджером. |
| Виконувати | Додавати погоджену нотатку до визначеного запису CRM. Надсилання відповіді потребує окремого рішення. |
У першій версії менеджер надсилає відповідь зі своєї поштової програми. Право інтеграції на запис обмежене додаванням переглянутої нотатки. Зміна суми угоди, видалення записів або надсилання листів розширювали б обсяг впровадження.
Перевіряти права має програма, яка виконує дію. Вона повинна враховувати користувача, конкретний запис та операцію. Інструкції для моделі самі по собі цього контролю не забезпечують. Цей принцип описано в рекомендаціях OWASP щодо керування доступом.
У матеріалі про підключення AI до CRM розглянуто основу — дані та права доступу. Тут наступне питання: за яких умов підготовлена інформація може стати зміною в робочій системі.
Покажіть людині конкретну зміну
Менеджер має розуміти, що саме погоджує: запис клієнта, майбутню нотатку та лист, на основі якого її підготовлено. Кнопка «Погодити» без цього контексту залишає надто багато невідомого.
У нашому прикладі екран перевірки може показувати назву запису, посилання на джерело та точний текст для додавання. Якщо після перегляду текст змінили, нова версія потребує нового рішення. Погодження має стосуватися саме тієї дії, яку людина бачила. Такий підхід відповідає рекомендаціям OWASP щодо погодження операцій.
Потрібна й зручна можливість відредагувати або відхилити чернетку. Якщо виправлення займає забагато часу, процес може додати навантаження. Перевірте цей крок із тими, хто працюватиме з ним щодня.
Визначте поведінку, коли процес зупиняється
Демонстрація зазвичай показує підготовлену послідовність. Для робочого запуску потрібні відповіді й на випадки, які її переривають. У прикладі з клієнтським листом варто заздалегідь визначити таку поведінку:
| Ситуація | Яку поведінку потрібно визначити |
|---|---|
| Знайдено два схожі записи клієнта | Передати вибір відповідальній людині до підготовки зміни для будь-якого із записів. |
| Лист суперечить нотатці в CRM | Показати обидва джерела для перегляду без прихованого вибору «актуальної» версії. |
| CRM недоступна | Показати стан очікування або помилки та визначити відповідального за звернення. |
| Запит на додавання нотатки завершився без відповіді | Перевірити, чи додано нотатку, перед рішенням повторити операцію. |
| Чернетку змінили після погодження | Повернути змінену версію на перегляд до виконання. |
Відсутність відповіді на запит залишає результат невизначеним. У розробці потрібно передбачити перевірку вже виконаної дії та керування повторними спробами. Конкретний механізм залежить від CRM і способу інтеграції.
Визначте, що команда має бачити після виконання: джерело, запропоновану зміну, хто її погодив, яку дію система спробувала виконати та який результат підтверджено. Для цього запису потрібні власні права доступу й строки зберігання. Не варто без потреби дублювати в ньому клієнтські дані.
Оцініть усю ручну роботу
До пілота подивіться, як команда обробляє зіставні звернення зараз. Під час перевірки враховуйте час підготовки, перегляду, виправлень та обробки винятків.
Корисні запитання для оцінки:
- Скільки ручного часу потребує зіставне звернення від початку до завершення?
- Як часто менеджер суттєво переписує нотатку або відповідь?
- Чи потрапили погоджені зміни до правильних записів?
- Скільки роботи повернулося людині через неможливість продовжити процес?
- Чи користується команда цим способом, коли має вибір?
Критерії продовження варто записати до пілота. Сама кількість підготовлених чернеток ще не показує користі. Потрібні свідчення, що процес допомагає з реальним навантаженням за прийнятної якості й обсягу контролю.
Результат може підказати залишити поточні межі, покращити перегляд, розширити одну дозволену дію або зупинити експеримент. Це спосіб оцінки, а не обіцянка економії чи універсальний поріг готовності.
Перетворіть ці рішення на обсяг розробки
Тепер у прикладі є конкретні складові для оцінки: підключені системи, доступні записи, зміст чернеток, дозволені зміни, погодження, обробка зупинок, журнал результатів і відповідальний після запуску.
Ці рішення показують і роботу за межами прототипу. Потрібні доступи до реальних систем, характерні приклади для перевірки та зрозумілий порядок дій при проблемах. Визначте, хто відповідатиме за користь процесу після змін у даних і роботі команди. У матеріалі про AI-підтримку розібрано цю постійну відповідальність.
Процес Madency починається з короткої розмови для оцінки доречності впровадження. Якщо наступним кроком є Discovery, його вартість — $500, які зараховуються у вартість розробки. Обсяг розробки визначається після цього. Discovery не обіцяє готової інтеграції за цю суму. У матеріалі про вартість AI-агента пояснено, що впливає на обсяг робіт та інвестицію.
Опишіть одну повторювану ручну дію й місце, де людина має погодити результат. Обговорімо цей процес із Madency, щоб визначити, чи буде Discovery доречним наступним кроком.