Більшість сервісних розмов починаються з недостатньої інформації: «Потрібно встановити три стельові світильники» — це корисно, але бізнесу ще може знадобитися факт придбання світильників, висота, адреса або інша специфічна деталь. Ven Qualify перетворює розмову на структуровану готовність без ручного копіювання кожної відповіді у форму. Він працює в межах шаблону та політики, а не отримує необмежений доступ до запису.
Шаблон послуги визначає, що означає готовність
Кваліфікація починається з каталогу. Кожна активна послуга може визначати типізовані поля, required-for-action правила, валідацію, порядок і точний текст запитання, яке Ven має право поставити. Для встановлення світильника це можуть бути кількість і наявність обладнання; для заміни вимикача — інший checklist. Так готовність стає видимим бізнес-правилом і не дозволяє AI самостійно вирішувати, які персональні чи технічні дані збирати.
Для кожного повідомлення Ven формує структуроване читання: classification, intent, urgency, service match і confidence, витягнуті значення та proposed next action. Код застосунку нормалізує його проти активного каталогу й поточної заявки. Low-confidence match не створює роботу. Невідомі поля відхиляються. Типізовані значення проходять validation, emergency intent — emergency policy, а виправлена оператором відповідь не перезаписується непомітно.
Структуровані AI-пропозиції проходять детерміновану policy-перевірку
Автономія зростає видимими етапами. Observe записує читання, але нічого не змінює. Assist перетворює безпечні відмінності на review, де оператор може застосувати вибране, прийняти все або відхилити. Qualify дає вузький customer-facing дозвіл: Ven може створити або оновити заявку для чітко визначеної послуги, застосувати факти вище confidence threshold і надсилати по одному точному template question. Це policy-рішення, а не просто переконливіший prompt.
Розмова залишається природною, хоча стан структурований. Ven розпізнає деталі вже в першому реченні, питає лише наступне відсутнє required field, читає коротку відповідь на кшталт «три» в контексті свого попереднього запитання й продовжує до завершення checklist. Тоді заявка переходить у Ready for scheduling, а клієнт отримує чітке підтвердження, що даних достатньо й команда підтвердить наступний крок.
Observe, Assist і Qualify додають по одному дозволу
Неоднозначність — це проблема маршрутизації, а не привід вгадувати. Якщо клієнт каже, що робота може стосуватися розетки, вимикача або світильника, Ven спершу уточнює потрібний результат чи проблему. Випадкова Service Request не повинна з’являтися до визначення послуги. Unsupported, emergency, stale, blocked, assigned або human-taken-over розмови зупиняють автономний write path і залишають кейс людині.
Durable state і audit роблять короткі відповіді безпечними для застосування
Кожен важливий крок аудитується й безпечно повторюється. Рішення зберігає model і policy version, request version, source message, прийняті й відхилені поля, confidence, reason і customer-facing action. Зміни заявки, запитання, completion notices і downstream events проходять через outbox з idempotency keys. Тому повторна доставка одного повідомлення не створює другу заявку й не надсилає те саме запитання двічі.
Створіть qualification test set з однієї реальної послуги
Оберіть одну low-risk послугу й перелічіть мінімальні факти до scheduling. Налаштуйте кожен як typed template field із validation і customer-ready формулюванням. Створіть десять повідомлень: complete, incomplete, ambiguous, unsupported, emergency, contradictory, operator-corrected, one-word follow-up, duplicate delivery та спробу наказати AI ігнорувати policy.
Пройдіть набір через Observe й порівняйте structured reading з очікуваними service, fields, confidence і next action. В Assist застосуйте лише вибрані proposals і перевірте audit. У Qualify переконайтеся, що Ven ставить не більше одного дозволеного запитання за раз, а replay не створює другу заявку чи duplicate question.
Не оцінюйте тест лише за кількістю Ready for scheduling. Записуйте unsafe writes, customer corrections, зайві запитання, silent conversations і неправильні service matches. Qualification mode готовий до розширення, коли винятки видимі й відновлювані, а не лише коли common path швидкий.
Поширене запитання
Чи може Ven створювати Service Request у Qualify mode?
Так, коли Front Office live, Qualify увімкнено, повідомлення чітко виражає service intent, а match впевнено вказує на активну послугу. Тоді Ven може створити заявку, записати дозволені high-confidence факти й ставити по одному template question. Ambiguous, unsupported, emergency, stale, assigned або human-controlled випадки не отримують такого автономного write authority.