Сервіс-деск із ШІ-першою лінією
Багатоканальний сервіс-деск для організацій із масовим потоком звернень: месенджери, пошта і мобільний застосунок зводяться в одну картку, типові питання закриває мовна модель, а людина бачить лише те, що автоматика не подужала.
Побудовано на промисловій ITSM-платформі для Odoo і доповнено чотирма власними шарами: чатбот-платформою для месенджерів, власним фреймворком API, інтеграцією з ШІ-сервісом відповідей і серверним контрактом для мобільного застосунку.
Кожен канал живе окремо, а типові питання все одно чекають на оператора
Звернення приходять у месенджери, на пошту й у мобільний застосунок; кожен канал живе окремо, а історія розсипана. Переважна частина звернень — типові питання, відповідь на які вже є в базі знань, але оператор усе одно витрачає на них робочий час, замість того щоб братися за випадки, де людина справді потрібна.
Автоматика, яка не вміє здатися, гірша за її відсутність — користувач застрягає в циклі відповідей, які не допомагають. А оператор, що веде переписку одразу в кількох месенджерах, змушений тримати в голові, у якому каналі клієнт і чи прочитав він відповідь.
Як це працює
Одна картка незалежно від каналу
Джерело фіксується міткою — бот, пошта чи програмний інтерфейс. Контакт визначається або дедуплікується; якщо в автора вже є відкрите звернення з того самого каналу, репліка доклеюється туди, а не плодить дублікат.
Перша лінія без оператора
Нова картка одразу потрапляє на окрему стадію «працює ШІ». Відповідь генерується і публікується і клієнту в канал, і в стрічку картки — так само обробляється кожен наступний хід діалогу.
Ескалація за одним із п'ятнадцяти тригерів
Явний запит на людину, низька впевненість моделі, порожня чи помилкова відповідь, вкладення від клієнта, вичерпаний ліміт ходів — будь-який з незалежних тригерів переводить картку в операторську чергу.
Закриття і цикл оцінки
Оператор, сам клієнт або фоновий процес за мовчанням закривають звернення зі структурованою причиною. Після закриття клієнту йде форма оцінки, а результат повертається в ШІ-сервіс як сигнал якості.
Чатбот, ШІ й сервіс-деск працюють як один цикл
Це не три окремі продукти поруч, а один потік: чатбот приймає і передає, ШІ відповідає і сигналізує, сервіс-деск маршрутизує, ескалує і замикає цикл.
Чатбот — приймає і передає
Через крок сценарію «дія платформи» бот пише в будь-яку модель Odoo: створює звернення, лід чи замовлення з прикріпленим транскриптом, надсилає клієнту документ або рахунок, заводить і зіставляє контакти. Коли потрібна людина, бот обирає оператора за стратегією — випадково, усім або найменш завантаженому, з урахуванням ролей і ознаки доступності; якщо вільних немає, сценарій має окрему гілку.
ШІ — відповідає і сигналізує
ШІ підключений у трьох точках: обробник кожної вхідної репліки, перехоплення нового повідомлення на картці, що вже стоїть на ШІ-стадії, і перший вхід у цю стадію. У відповідь картка отримує мітку наміру і посилання на розділи джерел, а впевненість нижче порога сама запускає примусову ескалацію.
Сервіс-деск — замикає цикл
Стадії й іменовані маршрути переходів, а рішення додає окремий тип стадії під автоматичну обробку. Ескалація — три незалежні механізми: бюджет ходів ШІ, стадійна ескалація маршрутом і перехоплення оператором. Власних полів SLA рішення не додає — рівень сервісу лишається за платформою.
Де межі відповідальності
У чатбота межа — сценарій: кнопка, ключове слово чи явний запит передають розмову оператору, бот сам не намагається «вгадати» далі. У ШІ межа — впевненість і формат: порожня чи помилкова відповідь, виняток або збій транспорту, вкладення від клієнта — усе це одразу передає картку далі.
Спільне правило на стику всіх трьох: якщо жоден маршрут переходу не підійшов, платформа логує це й лишає одноразову службову нотатку — переходу немає, але й винятку, що зламав би процес, теж немає.
Що з цього — готовий продукт, а не одноразовий проєкт
27 із 32 власних модулів — тиражований чатбот-продукт і власний фреймворк API. Обидва не прив'язані до конкретного впровадження і переносяться на нового клієнта майже без змін.
Чатбот-платформа
20 модулів: 13 типів кроків сценарію, 9 живих транспортів, візуальний конструктор діалогів, передача оператору з поверненням у сценарій, багатомовність, черга з гарантією порядку реплік. Самостійний продукт для будь-яких месенджерів Odoo, не частина одного впровадження.
Фреймворк API
Конструктор кінцевих точок через інтерфейс, жива генерація специфікації OpenAPI з інтерактивною документацією, токени й ключі доступу, обмеження частоти запитів, журнал викликів із маскуванням і строком зберігання.
Оснащення безпеки вебінтерфейсу
Примусова двофакторна автентифікація для всіх, крім кореневого облікового запису, і чотиришаровий захист реєстрації: пастка-поле, капча, підтвердження пошти токеном з обмеженням частоти, список одноразових поштових доменів.
ШІ-перша лінія над сервіс-деском
Окремий тип стадії під автоматичну обробку, бюджет ходів моделі, повний набір тригерів ескалації, замкнений цикл оцінки якості. Прив'язки до одного постачальника ШІ в архітектурі немає — змінюється конектор, не логіка.
Інженерія надійності інтеграції з мовною моделлю
Поділ ходу на фази з власною транзакцією на кожну, ідемпотентність за ідентифікатором репліки, збереження відповіді моделі до її застосування, гарантована доставка сигналів завершення сесії.
Оптимізації під конкурентне навантаження
Виявлення й усунення гарячих рядків, що давали помилки серіалізації під паралельними обробниками: частина збережених агрегатів переведена в обчислювані на льоту, поштучні підрахунки замінені груповими запитами.
Чатбот, що не тільки відповідає, а й діє
Сценарій — явна станова машина над орієнтованим графом: сценарій → крок → перехід, із розгалуженням через кнопки, а не деревом.
13 типів кроків у ядрі: інформаційне повідомлення, розгалуження кнопками, умовний перехід, збереження змінної, запуск дії платформи зі зворотним записом ідентифікатора запису, вибір запису довільної моделі як кнопок, шаблон по запису, передача оператору, оцінка діалогу — та інші.
Дев'ять живих транспортів: два глобальні месенджери (один через бізнес-API), регіональний месенджер, два канали приватних повідомлень соцмереж через спільний хаб авторизації, регіональний агрегатор, сторонній SaaS підтримки, конектор мобільного застосунку і вбудований вебчат сайту. Новий канал — це новий конектор, а не правка ядра.
Тексти кроків, кнопок, відмов і шаблонів перекладні — один сценарій несе всі мови. Вхідні повідомлення йдуть через чергу задач із ключем розмови: репліки одного діалогу обробляються строго послідовно, різні діалоги — паралельно.
Відповідь без власного індексу знань
Генерація відповіді делегована зовнішньому ШІ-сервісу відповідей по базі знань, що працює поза контуром впровадження — Odoo не тримає власного пошукового індексу.
Система надсилає репліку користувача, ідентифікатор розмови, підрізану історію діалогу й дескриптор потрібної бази знань — а отримує назад текст відповіді, мітку наміру, коефіцієнт впевненості, посилання на розділи джерел і маркер «потрібна людина».
Приблизно дві третини обсягу інтеграційного модуля — захисна механіка: хід ділиться на фази з окремою транзакцією на кожну; ключ ідемпотентності прив'язаний до ідентифікатора захопленої репліки; відповідь моделі зберігається до застосування, щоб повторна спроба не оплачувала виклик двічі.
Після закриття звернення клієнту надходить форма оцінки — шкала від 1 до 5 плюс каталог тегів і вільний коментар. Оцінка нормалізується у трибальний вигляд і повертається в ШІ-сервіс як сигнал якості, з окремим ретрай-механізмом і журналом доставки.
Мобільний застосунок будує окрема команда — Odoo віддає готовий контракт
У репозиторії немає жодного рядка клієнтського коду мобільного застосунку — те, що є, це серверний контракт, на якому такий застосунок можна зібрати.
Базовий клас REST-ресурсу з переліком, читанням, створенням, оновленням і посторінковою навігацією, три контролери поверх нього. Контракт покриває вхід із токеном доступу й токеном оновлення, подання звернення, перегляд статусу й стрічки відповідей, надсилання репліки, вкладення двома шляхами, довідники каналів і базу часто-питаних, прив'язану до категорій.
Сповіщення йдуть без вендорської push-служби: сервер відправляє подію вихідним вебхуком на бекенд застосунку, а той відповідає за фактичну доставку; паралельно в Odoo створюються записи сповіщень, які клієнт забирає наступним запитом.
Технології та архітектура
Платформа
Odoo 18, промисловий ITSM-стек для управління зверненнями як фундамент; власні модулі — надбудова над ним.
Фреймворк API
Диспетчер маршрутів, серіалізація в JSON або XML з одного джерела, посторінковий конверт відповіді, перемикання локалі заголовком, власний валідатор схеми запиту, вихідний конектор із журналюванням.
Автентифікація
Непрозорі bearer-токени (зберігаються лише як геш) і ключі доступу з необов'язковими списками дозволених адрес і точок; обмеження частоти на ключ і на джерельну адресу.
Спостережуваність
Кожен вхідний виклик пишеться в окрему модель — адреса, метод, заголовки, тіло, код, час обробки — у власній транзакції, тож відкочений запит усе одно лишає слід.
Фонові процеси
Черга задач із унікальними ключами й політикою повторного використання запущеної задачі — для чатбота і для ходів ШІ. Таймери нагадування й автозакриття, повтори доставки оцінок, сторожовий процес.
Стійкість під навантаженням
Групові запити замінили поштучні підрахунки, фіксовані розміри пакетів у фонових процесах, ізоляція кожного запису у власній точці збереження при масових операціях.
Часті запитання
Так. Прив'язки до конкретного постачальника в архітектурі немає: точка інтеграції — конектор, зміна вендора — це заміна даних підключення, а не переписування логіки сценаріїв чи ескалації.
Один із приблизно п'ятнадцяти незалежних тригерів — явний запит на людину, низька впевненість, порожня відповідь, вкладення від клієнта, ліміт ходів — переводить картку в операторську чергу. Автоматика, яка не здається, на цій платформі неможлива за задумом.
Так — чатбот-платформа працює як самостійний продукт, а не лише частина цього рішення; є сателіти під CRM, замовлення, рахунки й персонал.
Ні, готового застосунку «з коробки» немає. Ми будуємо серверний REST-контракт в Odoo, під який окрема команда збирає клієнтську частину — вхід, подання звернень, стрічка відповідей, вкладення вже описані на боці Odoo.
Власних полів дедлайну чи часу реакції рішення не додає — рівень сервісу (SLA) лишається за вибраною ITSM-платформою і вашими домовленостями з підтримки. Власний внесок — облік робочого часу й позаробочих годин при передачі оператору.
Розкажіть, як улаштована ваша підтримка
Опишіть, скільки каналів обробляєте зараз і що забирає найбільше часу в операторів — покажемо, що закривається готовою платформою, а що потребує окремої конфігурації.
Читайте також
- Чат-боти для Odoo — Telegram, Viber, WhatsApp →Тиражована чатбот-платформа з цієї ж системи: 20 модулів, 13 типів кроків і 9 транспортів працюють і окремим продуктом
- ШІ-агенти для Odoo →Той самий принцип «ШІ виконує дію, а не лише відповідає»
- AI-асистент Odoo з будь-якого екрана →Інший канал ШІ в Odoo: асистент відповідає користувачам системи в контексті екрана
- Пакети підтримки →Супровід для систем такого класу після запуску
- Усі модулі KitWorks для Odoo →
- Обговорити свій проєкт →