Колись відкривали вхідні повідомлення служби підтримки клієнтів і відчували, ніби дивитесь у кошик із брудною білизною, яким користується весь район? Я також. Саме тому існують робочі процеси з підтримкою ШІ: щоб відсортувати хаос, відповісти на прості запити і передати складні ситуації людині. Сьогодні ми покроково побудуємо робочий процес підтримки на базі ШІ за допомогою Agent Builder — простими словами, із порадами, обмеженнями та кількома веселими моментами.
Примітка: Agent Builder — це інструменти без коду або з мінімальним кодуванням, які дозволяють створити чатбота або автоматизовану систему підтримки: ви визначаєте наміри клієнтів, підключаєте базу знань, налаштовуєте передачу справ людині і тестуєте. Якщо ви вмієте малювати схему системи поливу в саду, ви зможете намалювати агента.
Що ми створюємо (коротко)
- Робочий процес підтримки на базі ШІ, який вітає клієнтів, визначає наміри, шукає відповіді у вашій базі знань і плавно передає справу людині, коли потрібно.
- Перевірки безпеки, щоб ШІ не вигадував історії, як ваш дядько на рибалці.
- Метрики для вимірювання, чи допомагає система, або просто пересуває "брудну білизну" по кошику.
Чому Agent Builder?
Бо він економить час і зменшує хаос. Багато сучасних Agent Builder підтримують візуальні потоки, RAG (Retrieval‑Augmented Generation) для точних відповідей, аналітику та легку інтеграцію з платформами підтримки, які ви вже використовуєте. Вони обіцяють від ідеї до запуску за години замість тижнів — із розумними обмеженнями, щоб ви випадково не створили чатбот, який робить повернення коштів за Teslas.
Перед тим як почати, швидка карта шляху:
- Визначте цілі та обмеження
- Зберіть і очистіть джерела знань
- Спроєктуйте наміри та шляхи розмов
- Підключіть RAG, щоб відповіді базувалися на ваших документах
- Додайте дії: тікети, пошуки, перевірки статусу
- Створіть правила ескалації та передачі
- Тестуйте, налаштовуйте і додавайте запобіжники
- Вимірюйте, удосконалюйте і покращуйте
Частина 1: Починайте з кінця (і тримайте адвоката на швидкому наборі)
Що означає успіх
- Швидші відповіді на поширені питання (доставка, повернення, паролі, як‑то‑… ).
- Вищий показник самозарадності: більше питань вирішує бот без участі людини.
- Стабільний або зростаючий CSAT (задоволення клієнтів).
- Плавна ескалація, коли бот досягає своїх меж.
Визначте, що бот робити не буде
- Жодних повернень понад певну суму.
- Ніяких юридичних порад (ніколи). Ніяких медичних порад (абсолютно ніколи).
- Не змінювати конфіденційну інформацію без перевірки особи.
Напишіть коротку політику для бота: «Дозволено», «Заборонено» і «Передати людині». Зробіть її нудною, але чіткою. Ваше майбутнє «я» вам подякує.
Частина 2: Зберіть свої знання (бо бот не читає думки)
Зберіть джерела
- Статті центру допомоги і FAQ
- Внутрішні SOP, особливо документи «як обробляти X»
- Каталоги продуктів або прайс‑листи
- Політики доставки, гарантії, повернень
- Відомі проблеми і обхідні шляхи
Очистіть і впорядкуйте
- Видаліть дублікати і ставте дати на документи
- Розділіть великі PDF на логічні частини; де потрібно — робіть резюме
- Позначайте кожен документ категорією (повернення, оплата, технічне налаштування) і мовою
Порада: Напишіть одну «головну політику» — сторінку з топ‑10 правилами (терміни повернення, гарантійні ліміти, години роботи служби). Регулярно оновлюйте. Ваша ШІ буде покладатися на неї як дитина на холодильник.
Частина 3: Спроєктуйте наміри (тут магія стає практичною)
Ви будуєте аеропорт: прибуття (питання клієнтів), маршрути (намір), призначення (відповіді/дії) і відправлення (вирішення або ескалація). Почніть з основних намірів:
- Статус замовлення («Де моє замовлення?»)
- Повернення/обміни («Чи можу я повернути це?»)
- Доступ до акаунту («Забув пароль» )
- Проблеми з оплатою («Чому мені нарахували?»)
- Інформація про продукт («Чи працює з X?»)
- Технічна підтримка («Не підключається» )
- Поговорити з людиною («Агент зараз!»)
Для кожного наміру запишіть:
- Типові фрази користувачів («Відстежити посилку», «Повернення» )
- Необхідна інформація («Номер замовлення», «Email на акаунті»)
- Дозволені дії (наприклад, «перевірити статус замовлення», «створити RMA», «розпочати верифікацію»)
Частина 4: Підключіть RAG (щоб бот відповідав на основі ваших документів, а не фантазій)
Retrieval‑Augmented Generation означає, що бот шукає відповідні уривки у базі знань і використовує їх для формування відповіді. Перевага: актуальні та політично коректні відповіді. Налаштування:
- Індексуйте документи з метаданими (категорія, дата, мова).
- Перевірте пошук: ставте запитання боту і дивіться, які уривки він бере.
- Додайте правило «Немає джерела = немає відповіді». Якщо нічого релевантного не знайшлося, бот повинен: (а) поставити уточнююче питання, (б) запропонувати ескалацію, або (в) дати посилання на загальну сторінку допомоги.
Порада: Включайте офіційні відповіді для «складних» тем — ліміти повернень, гарантійні виключення. Ваш бот має цитувати політику, не імпровізувати.
Частина 5: Додайте дії та інтеграції (де бот «тримає руки в справі»)
Поширені дії, які Agent Builder може викликати:
- Перевірка статусу замовлення за номером
- Оновлення адреси доставки (в межах обмежень)
- Створення і призначення тікета підтримки
- Запуск процесу скидання пароля
- Початок повернення та генерація RMA
- Запис на зворотній дзвінок або зустріч
Дотримуйтесь mindset безпеки:
- Потрібне підтвердження («Я збираюсь почати повернення для замовлення №1234. Продовжити?»)
- Блокуйте небезпечні дії перевіркою особи (email + одноразовий код)
- Логування кожної дії з часовою позначкою і контекстом запиту
Частина 6: Спроєктуйте плавну передачу (бо іноді люди — це покращення)
Передача має зберігати контекст, щоб агенти не задавали 20 повторних питань. Підходящі тригери для ескалації:
- Низька впевненість у намірі
- Чутливі теми (спори з оплатою, юридичні, безпека)
- Повторні непорозуміння (дві невдалі спроби уточнити)
При передачі:
- Додавайте транскрипт розмови
- Резюмуйте, що відбулося: «Бот перевірив особу. Клієнт хоче обміняти річ на розмір L. Запропоновано RMA, клієнт сумнівається.»
- Надавайте рекомендації для агента («Пропонуйте безкоштовну пересилку обміну; політика допускає 30 днів»).
Частина 7: Візьмімося за реальний сценарій (короткий скрипт)
Створимо стандартний шлях «Статус замовлення».
- Привітання
Бот: «Привіт! Я допомагаю з відстеженням замовлень, поверненнями і швидкими вирішеннями. Що у вас сьогодні?»
- Визначення наміру
Якщо користувач згадує «замовлення», «відстежити», «де» — переходьте до статусу замовлення.
- Збір даних
Бот: «Я можу перевірити. Який у вас номер замовлення або email на акаунті?»
- Якщо користувач дає тільки email: Бот просить підтвердити ім’я або останні 4 цифри телефону.
- Бот викликає API для пошуку замовлення.
- Якщо знайдено: повертає статус, орієнтовну доставку і останні оновлення перевізника.
- Уточнення та пропозиція наступного кроку
Бот: «Добрі новини: сьогодні доставлять. Хочете, щоб я надіслав смс, коли прийде?»
- Якщо замовлення не знайдено: «Гм — співпадінь поки немає. Спробуєте інший email чи передати агенту?»
- Якщо затримка: «Здається, затримка через погоду. Можу зв’язатися з перевізником або передати агенту — як вам зручніше.»
- Бот підсумовує, записує взаємодію, пропонує коротке опитування CSAT.
Повторюйте структуру для Повернень, Доступу до акаунту, Оплати і Техпідтримки. Зберігайте консистентність для легкого обслуговування.
Частина 8: Запобіжники і тон (неприємні, але важливі речі)
- Відмова та резервний план: Якщо бот не має джерела, має повідомити це і попросити уточнити або ескалювати. Уникайте впевнених, але неправильних відповідей.
- Тон: Допоміжний, лаконічний та доброзичливий. Без юридичного жаргону. Якщо користувач засмучений, бот визнає емоції і пропонує варіанти („Вибачаюся, що так сталося. Можу одразу передати людині або спробувати допомогти сам.“)
- Конфіденційність: не показуйте повні адреси або платіжні дані. Вилучайте чутливу інформацію з логів.
- Обмеження частоти: запобігати спаму з боку бота у зовнішні системи.
Частина 9: Тестування: візьміть роль вашого найдратівливішого клієнта
Створіть план тестування з такими категоріями:
- Позитивні сценарії (прості питання)
- Заплутані фрази («де мої речі???»)
- Крайні випадки (кілька замовлень, часткові повернення)
- Політичні пастки («Прийшло пошкоджене через 45 днів — можна повернути?»)
- Безпека (позови про викрадення email, невідповідні імена)
Для кожного тесту фіксуйте:
- Чи зробив бот правильну ескалацію
Виправляйте потік, коли:
- Бот відповідає без джерел
- Він занадто часто ескалує (налаштуйте пороги)
- Застрягає у циклах (додайте правило відступу після двох уточнень)
Частина 10: Запуск (повільно – значить плавно, плавно – значить швидко)
Стратегія м’якого старту:
- Почніть з одного каналу (чат на сайті) і робочих годин в будні
- Обмежтеся топ‑3 намірами на перший тиждень
- Додайте тег «Бета» і кнопку зворотного зв’язку
- Режим тіні: перший день спостерігайте людину поруч, щоб відразу підключитися при потребі
При розширенні додайте email і повідомлення в соцмережах, коли бот вже навчився.
Частина 11: Вимірюйте важливе (і ігноруйте показники для краси)
Ключові метрики:
- Рівень самозарадності: % вирішених без людини. Якщо занизький — потрібна робота з базою знань. Якщо завищений, а CSAT падає – блокуєте потрібні ескалації.
- Перший контакт для вирішення (FCR): Чи вирішилась проблема зразу? Чудова ціль.
- CSAT та настрій: Якщо користувачі зітхають менше – ви перемагаєте.
- Середній час обробки (AHT): Має знижуватись для простих питань; слідкуйте, щоб ескалації не збільшились.
- Заощадження на відхиленнях: Оцінка економії на кожній самозарадній взаємодії — не женіться за економією ціною щастя клієнтів.
Встановіть тижневий ритуал: переглядайте 20 транскриптів, де була ескалація або низький CSAT. Виправляйте корені проблем, оновлюйте документи. Повторюйте.
Частина 12: План підтримки (улюблений чеклист майбутнього вас)
- Щомісяця: переіндексація документів, вилучення застарілої політики, оновлення деталей продуктів
- Щокварталу: додавання нових намірів (сезонні акції, новинки), налаштування порогів
- Завжди: лог змін і план відкату
Покрокова інструкція: Створюємо в Agent Builder
Це основа для більшості сучасних Agent Builder — хоч кнопки і виглядають інакше, суть однакова.
Крок 1: Створіть нового агента
- Назва: «Customer Support Bot»
- Мета: «Відповідати на часті питання підтримки і передавати складні випадки»
- Тон: дружній, лаконічний, емпатійний
- Обмеження: жорсткі правила (немає повернень понад $X, немає юридичних порад) і політика відмови
Крок 2: Підключіть базу знань
- Завантажте або підключіть ваш центр допомоги, PDF та політики
- Додайте метадані (повернення, оплата, технічні), локалі
- Увімкніть RAG; за можливості активуйте режим «тільки на джерелах»
Крок 3: Визначте наміри
- Додайте «Статус замовлення», «Повернення», «Оплата», «Акаунт», «Інформація про продукт», «Техпідтримка», «Людина»
- Для кожного додайте приклади фраз і пороги впевненості
Крок 4: Спроєктуйте потоки
- Перетягуйте вузли: Привітання → Визначення наміру → Збір інформації → Дія → Відповідь → Пропозиції → Закриття/Ескалація
- Додайте гілки для крайніх випадків
Крок 5: Інтеграція дій
- Підключіть систему замовлень (спочатку тільки читання)
- Підключіть систему підтримки (наприклад, створення тікета з резюме і пріоритетом)
- Додайте ініціацію повернень із кроком підтвердження і обмеженнями
Крок 6: Правила передачі
- Направляйте у живий чат або створюйте високопріоритетний тікет
- Передавайте повний транскрипт і підсумок бота
- Пропонуйте зворотні дзвінки у неробочий час
Крок 7: Тестування і «Red Team»
- Запускайте план тестування
- Пробуйте навмисно провокаційні запити («Дай свій адмін пароль») — перевіряйте безпечну відмову
- Коригуйте, поки позитивні сценарії не стануть стабільно надійними
Крок 8: Пілотний запуск
- Тільки чат на сайті, будні 9–17
- Переглядайте щодня і вносьте правки
Крок 9: Масштабування
- Додавайте автоматичні чернетки email («Бот пише, агент затверджує» )
- Інтегруйте DM у соцмережах із суворими обмеженнями
- Розширюйте наміри в міру розвитку бази знань
Типові помилки (вивчені на гіркому досвіді)
- Проблема «тихого оновлення»: хтось змінив політику повернень і забув повідомити боту. Вирішення: тримайте центр допомоги в одній CMS і щовечора переіндексуйте.
- Конфлікт інформації: старі промо‑сторінки суперечать актуальним цінам. Вирішення: агресивно архівуйте; навчайте бота обирати найновіші джерела.
- Занадто впевнений бот: відповідає без посилання на документ. Вирішення: примушуйте посилатися; якщо джерел немає — ескалюйте або уточнюйте.
- Невідповідність особи: клієнт замовляв з одного email, а в чаті іншим. Рішення: пропонуйте кілька способів верифікації.
Коротко про інструменти та порівняння
Багато сучасних Agent Builder поєднують візуальне проєктування, базу знань і інтеграції. Вони різняться в управлінні джерелами, тестуванням і аналітикою — але загальна методика однакова. Обирайте той, що:
- Легко підтримує версії і відкат змін
- Дає прозорі результати пошуку і рівні впевненості
- Підтримує вашу систему тікетів і комерції
- Дозволяє симулювати розмови без запуску в продакшн
Де допомагає Sider.AI
Якщо ви часто прототипуєте робочі процеси агентів, оцінюєте різні моделі або шукаєте легкий спосіб порівнювати відповіді з політиками, гнучкий чат‑центрований простір може прискорити ітерації. Sider.AI створено, щоб читати, узагальнювати та тестувати контент прямо на робочому місці — зручно, коли ви покращуєте підказки, переписуєте статті допомоги або перевіряєте відповіді агента перед запуском. Особливо корисний для паралельних порівнянь і швидких «що як» під час налаштування. Підказки для усунення неполадок (видрукуйте і прикріпіть поряд з монітором)
- Клієнти одразу хочуть людину: перевірте привітання і пороги впевненості; пропонуйте легкі вирішення, наприклад, відстеження замовлення за один крок.
- Бот зациклюється на «Я не зрозумів»: після двох спроб переходьте на кнопки: «Відстежити замовлення», «Повернення», «Агент»
- Високий рівень самозарадності, але низький CSAT: бот може занадто часто відмовлятися або давати скупі, невиразні відповіді. Додайте приклади, розширте базу знань і додайте емпатійні фрази.
- Низький рівень самозарадності і багато ескалацій: ваші наміри загальні або документи слабкі. Покращуйте приклади і перепишіть топ‑10 статей для ясності.
- Випадкові помилки у політиках: проблема індексації. Перерозбивайте документи, додавайте метадані, віддавайте перевагу найновішим джерелам.
Шаблон політики бота (коротка версія)
«Ви помощник служби підтримки для [Brand]. Відповідайте лише з дозволених джерел. Якщо релевантних джерел немає, задайте уточнення або ескалюйте. Ніколи не давайте юридичні, медичні або фінансові поради. Не виконуйте чутливі дії без верифікації і явного підтвердження. Будьте лаконічні, дружні та емпатійні.»
Формат резюме ескалації
«Намір клієнта: [Намір]. Виконані кроки: [Перевірка/Пошуки]. Знаходки: [Підсумок]. Настрій клієнта: [Спокійний/Роздратований]. Запропоновані наступні кроки: [Варіант A/B]. Додані джерела: [Посилання].»
Опитування CSAT після вирішення
«Як ми сьогодні впоралися? (Чудово / Добре / Погано). За бажанням: розкажіть, що покращити.»
Ваш чеклист на одній сторінці
- Цілі визначені, обмеження прописані
- Документи очищені, індексовані, датовані
- Наміри змодельовані з прикладами
- RAG увімкнений, цитування обов’язкове
- Дії інтегровані з підтвердженнями
- Тригери передачі і резюме транскриптів
- План тестування виконано, проблеми виправлено
- Щотижневий перегляд та безперервне покращення
Підсумок: Справжня обіцянка робочого процесу підтримки за допомогою ШІ
Робочий процес підтримки ШІ не замінює людей — він замінює час, який люди витрачають на копіювання номерів для відстеження в маленькі поля. Коли зробити це правильно, клієнти отримують швидші відповіді, агенти мають чистіші передачі, а у компанії менше обурених листів, що починаються словами «Я чекаю на лінії вже 47 хвилин.»
Починайте з малого. Зробіть прості сценарії приємними. Ескалюйте з повагою. Вимірюйте важливе. І тримайте документи свіжими, як нова банка арахісового масла. Ваш майбутній вхідний ящик виглядатиме не як кошик для брудної білизни, а як акуратна шухляда, яку можна легко закрити.
Часті питання
Q1: Що таке робочий процес підтримки ШІ простими словами?
Це спроєктована система розмов, яка дозволяє ШІ вітати клієнтів, визначати наміри, відповідати на основі вашої бази знань і передавати людині, якщо виникає проблема. Можна порівняти з розумною рецепцією, яка знає, коли викликати менеджера.
Q2: Як зупинити ШІ від вигадок?
Використовуйте Retrieval‑Augmented Generation (RAG), щоб відповіді бралися з ваших документів із цитуваннями. Якщо бот не знайде відповідного джерела, він повинен поставити уточнень або ескалювати — ніякої творчої імпровізації.
Питання 3: Які показники доводять, що мій робочий процес підтримки на основі ШІ дійсно працює?
Слідкуйте за коефіцієнтом утримання, вирішенням проблеми з першого звернення (FCR), CSAT і якістю ескалації (чи отримав агент корисний підсумок?). Якщо утримання зростає, але CSAT падає, ви блокуєте необхідну допомогу людини — скоригуйте свої порогові значення.
Питання 4: Коли ШІ має перенаправляти до людини?
Перенаправляйте у випадках низької впевненості, делікатних тем (суперечки щодо виставлення рахунків, юридичні питання, безпека), повторних непорозумінь або коли клієнт просить людину. Завжди передавайте розшифровку та короткий підсумок, щоб агент міг одразу приступити до справи.
Питання 5: Який найшвидший спосіб розгортання без поломок?
Зробіть м'який запуск: один канал, обмежені наміри, лише в робочий час. Тестуйте щодня, виправляйте очевидні прогалини та розширюйте, коли щасливі шляхи стануть нудно надійними.
