Перейти до основного вмісту
Рівень 3 — це етап, на якому AI-агент стає частиною реального бізнес-процесу. На цьому рівні агент вже не просто відповідає на запитання або спрямовує клієнтів до рішення. Йому потрібно знати, які системи існують, які дії він може виконувати та як запити мають рухатися у вашому бізнесі. Операційний агент повинен розуміти різницю між тим, що він може робити самостійно, і тим, що вимагає участі людини. Він повинен знати, куди направляти розмови, як створювати або оновлювати записи, коли ініціювати передачу та що він не має права робити без підтвердження.
У режимі Hardcore Mode правила рівня 3 визначають операційну логіку агента: які системи він може використовувати, які дії виконувати, які записи створювати або оновлювати, коли маршрутизувати або ескалювати запити та що він не повинен робити без підтвердження.

​
Що відкриває Рівень 3

Після завершення Рівня 3 ваш AI-агент повинен вміти:
  • розуміти підключені системи та їхнє призначення;
  • знати, які дії дозволені, а які — заборонені;
  • працювати з полями CRM, статусами, тегами, нотатками та наступними кроками;
  • дотримуватись правил бронювання та розкладу;
  • підтримувати платіжні процеси там, де це доречно;
  • використовувати правильне першоджерело у разі конфлікту інформації;
  • коректно маршрутизувати розмови залежно від типу запиту;
  • передавати менеджерам розмови з повним контекстом;
  • зменшувати повторювану операційну роботу вашої команди.

​
1. Інтеграції та підключені системи

Вашому AI-агенту потрібно знати, які системи існують у вашому бізнесі та як він може з ними взаємодіяти. Перерахуйте всі системи, з якими агенту може знадобитися розуміння або взаємодія. Поширені системи включають:
  • платіжні системи (наприклад, WayForPay, LiqPay);
  • бази знань (наприклад, Zendesk, Notion);
  • системи бронювання (наприклад, Calendly, EasyWeek);
  • CRM (наприклад, keyCRM, HubSpot);
  • електронна комерція (наприклад, Horoshop, Shopify);
  • системи планування (наприклад, Outlook Calendar, Google Calendar);
  • ERP (наприклад, Microsoft Dynamics 365, Odoo);
Для кожної системи вкажіть:
  • назву системи;
  • для чого вона використовується;
  • чи може агент мати до неї доступ;
  • чи може агент читати дані;
  • чи може агент створювати або оновлювати записи;
  • дозволені дії;
  • заборонені дії;
  • коли менеджер-людина повинен взяти ситуацію під контроль.
Приклад якісного введення: 
Система: HubSpot CRM
Призначення: Зберігання вхідних лідів і відстеження етапів воронки продажів.
Агент може: створювати новий лід, оновлювати контактні дані, додавати нотатки, присвоювати теги та змінювати статус ліда відповідно до попередньо визначених правил.
Агент не може: видаляти контакти, змінювати суму угоди, надавати знижки або позначати угоду як виграну без підтвердження менеджера.
Передача: передати менеджеру, якщо клієнт просить індивідуальних умов, юридичних умов або змін у контракті.
Чому це важливоБез чіткої карти підключених систем і прав доступу агент або робитиме замало, або намагатиметься виконувати дії, які йому не дозволені. Явні правила щодо дозволів захищають бізнес і забезпечують стабільність обробки запитів.

​
2. Канали комунікації

Агенту потрібно знати, де відбуваються розмови та яка поведінка очікується в кожному каналі. На відміну від правил каналів Рівня 2, які визначають тон комунікації та стиль продажів, правила каналів Рівня 3 визначають операційну поведінку: які дані збирати, які дії виконувати та які записи створювати в кожному каналі. Поширені канали включають:
  • Instagram;
  • Facebook Messenger;
  • WhatsApp;
  • Telegram;
  • Threads;
  • TikTok;
  • Viber;
  • чат на сайті;
  • електронна пошта;
  • телефон;
  • повідомлення на маркетплейсах;
  • інші галузеві канали.
Для кожного каналу визначте:
  • чи має агент там відповідати;
  • чи може агент надсилати посилання;
  • чи може він збирати персональні дані;
  • чи може він ініціювати передачу;
  • чи повинен він створювати запис у CRM;
  • чи мають відповіді бути короткими або розгорнутими;
  • чи може він підтверджувати бронювання або лише збирати запити;
  • будь-які особливі обмеження.
Приклад якісного введення: 
Instagram:
- Тримайте відповіді короткими та дружніми.
- Ставте не більше одного запитання за повідомлення.
- Створюйте лід у CRM, якщо користувач поділився ім'ям і номером телефону.
- Передавати менеджеру при скаргах або нестандартних випадках.

Чат на сайті:
- Будьте більш конкретними та інформативними.
- Кваліфікуйте лід на більш ранньому етапі розмови.
- Збирайте ім'я, email, телефон і послугу, що цікавить, перед передачею.

Телефон:
- Тримайте відповіді короткими.
- Уникайте довгих списків і складних пояснень.
- Швидко переходьте до визначення потреби та підтвердження наступного кроку.
Чому це важливоПравила для каналів забезпечують відповідну поведінку агента в кожному контексті та гарантують, що правильні дані збираються та маршрутизуються незалежно від того, де починається розмова.

​
3. Логіка CRM: поля, статуси, теги, нотатки та наступні кроки

Якщо агент працює з CRM або системою відстеження лідів, необхідно визначити точні правила для створення та оновлення записів. Включіть:
  • коли створювати лід;
  • обов’язкові поля;
  • необов’язкові поля;
  • доступні статуси та коли їх використовувати;
  • доступні теги;
  • які нотатки додавати;
  • коли створювати наступні кроки або нагадування;
  • хто є відповідальним за лід;
  • що ініціює передачу.
Приклад якісного введення: 
Створювати лід, коли:
- користувач ділиться номером телефону або email-адресою;
- користувач просить записатися на консультацію;
- користувач запитує про ціни та відповідає профілю цільового клієнта.

Обов'язкові поля:
- ім'я;
- номер телефону;
- канал комунікації;
- послуга, що цікавить;
- джерело ліда;
- бажана дата або зручний час для зв'язку;
- короткий зміст розмови.

Статуси:
- Новий запит;
- Кваліфікований лід;
- Запит на бронювання;
- Потрібен менеджер;
- Нерелевантний.

Теги:
- hot_lead;
- price_question;
- booking_request;
- complaint;
- custom_case;
- returning_client.
Порада для Hardcore Mode 
Якщо користувач просить найближчий вільний час і ділиться номером телефону — встановити статус «Запит на бронювання» та додати тег hot_lead.
Якщо користувач ставить лише загальне запитання і не залишає контактних даних — залишити статус «Новий запит».
Якщо користувач скаржиться на попередній досвід — встановити статус «Потрібен менеджер» та додати тег complaint.
Чому це важливоПослідовна логіка CRM означає, що менеджери завжди отримують ліди з повною інформацією. Це також дозволяє бізнесу точно відстежувати конверсію, час відповіді та якість лідів.

​
4. Системи бронювання та розкладу

Бізнеси, що використовують записи, демо, бронювання або консультації, повинні визначити чіткі правила для роботи з бронюванням. Включіть:
  • яка система бронювання використовується;
  • чи може агент переглядати доступні слоти;
  • чи може він пропонувати слоти;
  • чи може він створювати бронювання;
  • чи може він переносити або скасовувати бронювання;
  • яка інформація потрібна перед тим, як зробити бронювання;
  • чи потрібне підтвердження менеджера;
  • що робити, якщо запитаний слот недоступний;
  • що надсилати після підтвердження бронювання.
Приклад якісного введення: 
Система бронювання: Calendly
Агент може переглядати доступні слоти та надсилати посилання для бронювання.
Агент не може вручну створювати бронювання поза системою.
Обов'язкова інформація перед надсиланням посилання: ім'я, послуга та бажаний діапазон часу.
Якщо запитаний час недоступний — запропонувати найближчі альтернативні варіанти.
Якщо клієнт хоче перенести запис — зібрати дані поточного бронювання та передати менеджеру.
Важливе правило: 
Агент може підтвердити бронювання лише після того, як слот успішно створено в системі бронювання.
Якщо система не підтверджує слот — агент не повинен повідомляти клієнту, що бронювання підтверджено.
Чому це важливоПравила бронювання запобігають подвійним записам, хибним підтвердженням і неузгодженому розкладу. Чіткі правила захищають як досвід клієнта, так і календар вашої команди.

​
5. Платіжні системи та процеси, пов’язані з оплатою

Платіжні процеси вимагають суворих правил. Агент повинен чітко знати, що він може і не може робити з платіжною інформацією. Включіть:
  • прийняті способи оплати;
  • чи потрібна передоплата;
  • чи може агент надсилати посилання на оплату;
  • коли надсилати посилання на оплату;
  • чи може агент підтверджувати оплату;
  • що робити у разі невдалої оплати;
  • що робити після успішної оплати;
  • правила повернення коштів;
  • коли питання щодо оплати необхідно передавати менеджеру.
Приклад якісного введення: 
Способи оплати: онлайн-посилання на оплату, картка на місці, готівка на місці.
Передоплата: обов'язкова для клієнтів, що звертаються вперше.
Агент може надсилати посилання на оплату лише після підтвердження послуги, дати, часу, імені та номера телефону.
Агент не може вручну підтверджувати оплату. Підтвердження оплати має надходити з платіжної системи.
Запити на повернення коштів завжди передавати менеджеру.
Чому це важливоПравила оплати захищають бізнес від помилок, шахрайства та суперечок. Агент не повинен давати обіцянок щодо платежів або повернень, які він не може перевірити.

​
6. Процеси маршрутизації та ескалації

Агенту потрібна чітка карта того, куди направляти кожен тип запиту і яку дію виконувати. Визначте правила маршрутизації для кожного типу запиту:
  • запити щодо продажів;
  • запити на бронювання;
  • запитання підтримки;
  • скарги;
  • запити на повернення коштів;
  • запити щодо партнерства;
  • технічні проблеми;
  • VIP-клієнти;
  • нерелевантні запити;
  • термінові запити.
Для кожного типу визначте:
  • хто є відповідальним;
  • чи обробляє агент самостійно або ескалює;
  • яку інформацію зібрати перед ескалацією;
  • рівень пріоритету;
  • повідомлення, яке показується користувачу;
  • внутрішню нотатку, що додається до CRM або передачі.
Приклад якісного введення: 
Запит щодо продажів:
- Агент проводить первинну кваліфікацію.
- Якщо кваліфікований — створити лід у CRM та призначити менеджеру з продажів.
- Нотатка має містити: послугу або продукт, що цікавить, бюджет (якщо згадано), терміновість та зручний час для зв'язку.

Скарга:
- Ввічливо підтвердити отримання.
- Не сперечатися та не захищати компанію.
- Зібрати ім'я, номер телефону, деталі замовлення або бронювання та суть проблеми.
- Передати менеджеру підтримки з високим пріоритетом.

Запит щодо партнерства:
- Зібрати ім'я, компанію, email і тип партнерства.
- Призначити менеджеру з розвитку бізнесу.
Чому це важливоЛогіка маршрутизації гарантує, що запити потрапляють до потрібної людини з потрібним контекстом. Без неї агент може обробляти те, чого не повинен, або не ескалювати те, що потребує уваги людини.

​
7. База знань і першоджерело

Агент повинен покладатися на точну, актуальну інформацію. Якщо документи суперечать один одному, йому потрібен чіткий порядок пріоритетів. Поширені джерела включають:
  • FAQ;
  • прайс-лист;
  • каталог продуктів;
  • описи послуг;
  • інструкції з бронювання;
  • політика доставки;
  • політика повернень;
  • скрипти;
  • гайд з тону спілкування;
  • юридичні умови;
  • СОП;
  • документи для onboarding;
  • внутрішні процесні документи;
  • приклади хороших і поганих розмов.
Для кожного джерела визначте:
  • що воно містить;
  • чи є воно актуальним;
  • хто є відповідальним;
  • як часто оновлюється;
  • пріоритет у разі конфлікту джерел;
  • чи може агент цитувати його напряму;
  • чи є воно внутрішнім або доступним для клієнтів.
Приклад якісного введення: 
Пріоритет джерел:
1. Актуальний прайс-лист — найвищий пріоритет для всіх запитань щодо цін.
2. FAQ — найвищий пріоритет для поширених запитань клієнтів.
3. Політика бронювання — найвищий пріоритет для правил перенесення, скасування та неявки.
4. Скрипти менеджерів — використовувати для тону та структури, але не вважати застарілі ціни у старих скриптах актуальними.

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

​
Чекліст завершення Рівня 3

Перед запуском операційного агента переконайтеся, що ви підготували:
  • список підключених систем та їхнє призначення;
  • права агента для кожної системи, включаючи дозволені та заборонені дії;
  • правила для кожного активного каналу комунікації;
  • поля CRM, статуси, теги, нотатки та логіку наступних кроків;
  • правила бронювання та розкладу, включаючи логіку підтвердження;
  • правила для платіжних процесів, якщо оплата є частиною процесу;
  • процеси маршрутизації та ескалації для кожного типу запиту;
  • затверджені джерела знань із зазначенням відповідального та частоти оновлення;
  • правила пріоритету джерел у разі конфлікту документів;
  • чіткі правила того, що агент може і не може робити операційно.
Рівень 3 перетворює ваш AI-агент на частину бізнес-процесу. Якщо агент повинен виконувати дії, оновлювати системи або маршрутизувати запити, операційні правила мають бути написані чітко і розглядатись як бізнес-логіка, а не загальні рекомендації.