Lavenity переходить від універсального AI help desk до AI Front Office для виїзного сервісного бізнесу. Мета — не просто відповідати на більше повідомлень. Потрібно перетворити вхідну розмову на структуровану й відповідальну роботу: визначити послугу, зібрати необхідні факти, знайти валідний час, підтвердити візит і передати команді work order із тим, про що домовилися з клієнтом. Цей roadmap пояснює, що вже є в продукті, які межі безпеки залишаються свідомими та що додають наступні етапи.
Зміна категорії: від відповідей на повідомлення до створення роботи
Продукт зберігає сильні частини help desk: омніканальний прийом звернень, ідентифікацію клієнта, shared inbox, перевірені знання, вкладення, призначення оператора й звіти. Front Office додає поруч окремий операційний шар. Service Request описує замовлену роботу; відповіді кваліфікації показують її готовність; Appointment фіксує погоджений час; Job — роботу, яку бізнес має виконати. Розділення цих понять не дозволяє статусу розмови вдавати повноцінний операційний процес.
M1 створив основу Service Request. Оператор може перетворити розмову на заявку, обрати послугу з каталогу, пов’язати адресу або обладнання, побачити відсутню інформацію й керувати явним життєвим циклом. Шаблони послуг визначають потрібні поля кваліфікації замість однієї універсальної форми. Панель заявки тримає структурований стан поруч із розмовою, тому значення можна виправити, не втрачаючи повідомлення-джерело.
M1 і M2: структуровані заявки з контрольованою AI-кваліфікацією
M2 додав кваліфікацію Ven і надійну оркестрацію. Ven повертає структуроване рішення, а не довільно змінює записи. Детермінований policy layer перевіряє послугу, впевненість, версію заявки, права, emergency policy і дозволені поля. Observe показує розуміння Ven, Assist дає оператору схвалити зміни, а Qualify дозволяє записувати факти з високою впевненістю та ставити по одному дозволеному запитанню. Action audit і transactional outbox роблять повтори видимими та ідемпотентними.
M3 додав безпечне native scheduling. Resources мають доступність, винятки, навички, зони виїзду та буфери. Пошук слотів детермінований, тимчасові holds спливають, а confirm повторно перевіряє стан заявки й доступність. Захист конфліктів у базі не дає двом клієнтам зайняти один ресурс і час, а повторний confirm повертає ту саму зустріч. Підтвердження клієнту доставляються надійно, тому тимчасовий збій каналу не скасовує валідне бронювання.
M3 і M4: безпечне планування та відповідальні work orders
M4 закриває перший операційний цикл через Jobs і Work Orders. Підтверджена зустріч створює рівно один Job у тій самій транзакції. Job отримує знімок послуги, клієнта, адреси, нотаток доступу, обладнання, терміновості, опису й відповідей кваліфікації на момент підтвердження. Далі dispatch може провести роботу через created, dispatched, in progress, completed або cancelled, не переписуючи вихідну заявку клієнта.
M5–M8: quotes, вертикальні процеси, hardening та інтеграції
Наступні етапи розширюють можливості, не стираючи межу між AI-пропозицією та зобов’язувальною дією. M5 додає quote drafts і явне погодження. M6 — вертикальний onboarding, редактори політик, операційні звіти, packaging і позиціювання. M7 охоплює multi-node hardening, retention, failure tests і security runbooks. M8 додає зовнішні календарі та ERP/FSM-конектори. Autonomous Book залишається вимкненим, доки Ven не отримає allowlisted-інструменти availability, hold і booking: основа планування готова, але агент не повинен обіцяти час, який не може безпечно зарезервувати.
Використовуйте roadmap як deployment gate, а не календар релізів
Почніть з однієї активної послуги, правила кваліфікації якої команда може пояснити. Запускайте Observe, доки service match, required fields, emergency classification і handoff-рішення не стануть надійними. Переходьте до Assist лише тоді, коли оператор швидко перевіряє зміни й може простежити кожне значення до повідомлення клієнта.
Увімкніть Qualify, коли template questions готові для клієнтів, а exception queue має відповідального. Вимірюйте частку Ready for scheduling, виправлення фактів клієнтом і безпечну реакцію на неоднозначні чи unsupported випадки. Вищий рівень автономії має прибирати ручну роботу, не збільшуючи recovery work.
Сприймайте Book, надсилання quote і записи у зовнішні конектори як окремі gates. Кожен потребує allowlist, idempotency, conflict handling, delivery evidence і rollback path. Roadmap працює, коли workspace отримує наступний дозвіл за виміряною поведінкою, а не коли всі режими вмикаються в наперед визначену дату.
Поширене запитання
Які частини roadmap Lavenity AI Front Office доступні зараз?
Основу M1–M4 реалізовано: Service Requests і шаблони, оркестрацію Observe/Assist/Qualify, native scheduling із holds та захистом конфліктів і Jobs із підтверджених зустрічей. Autonomous Book вимкнено до появи policy-controlled scheduling tools у Ven. Quotes, глибший vertical onboarding і reporting, hardening та зовнішні календарі або ERP-конектори йдуть у M5–M8.