• khung giờ đã thực sự được giữ hay mới chỉ là yêu cầu;
• đúng mẫu xe mình muốn thử có sẵn hay không;
• showroom có thực sự sẵn sàng phục vụ vào thời điểm đã chọn hay không;
• ai sẽ phụ trách khi mình tới;
• sau khi gửi yêu cầu thì còn phải làm gì tiếp theo.

Một phát hiện quan trọng từ nghiên cứu là người dùng có thể bỏ hẹn không phải vì ngay từ đầu họ không muốn đi, mà vì ý định bị giảm dần sau nhiều bước trải nghiệm thiếu chắc chắn.

Điều này khiến “no-show” không chỉ là vấn đề nhắc lịch. Nó có thể là hậu quả của việc người dùng không còn tin rằng cuộc hẹn của mình được vận hành nghiêm túc.

2.3. Người dùng không muốn phải liên hệ với sales chỉ để quản lý lịch

Một vấn đề khác là việc đổi hoặc hủy lịch thường buộc người dùng phải liên hệ trực tiếp với một nhân viên. Điều này tạo ra ma sát tâm lý: hủy lịch đồng nghĩa với việc phải nhắn, gọi hoặc giải thích với một người thật.

Trong trường hợp đó, im lặng dễ hơn hủy.

Với showroom, điều này tạo ra hậu quả ngược lại: xe demo, nhân sự và khung giờ vẫn bị giữ cho một khách không còn ý định tới, trong khi hệ thống không nhận được tín hiệu sớm để giải phóng nguồn lực.

Do đó, một yêu cầu quan trọng của hệ thống là cho phép khách tự tra cứu, đổi hoặc hủy lịch trong cùng một luồng, có xác thực và không cần giải thích với sales.

2.4. Trường hợp “người đặt” và “người lái” là hai người khác nhau

Phỏng vấn người dùng cho thấy trường hợp một người đặt lịch hộ cho vợ/chồng hoặc người thân là tình huống thực tế. Nếu hệ thống chỉ có một hồ sơ “khách hàng”, nhiều lỗi có thể xảy ra:

• thông báo bị gửi hết cho người đặt thay vì người lái;
• showroom tìm theo tên người lái nhưng không thấy booking;
• agent hỏi sở thích lái xe của người đặt dù người thực sự trải nghiệm xe là người khác;
• người đặt bị yêu cầu trả lời thay các thông tin mang tính cá nhân của người lái.

Vì vậy, hệ thống phải phân biệt rõ hai vai trò:

• Booker — người thực hiện booking và quản lý lịch;
• Driver — người trực tiếp tới showroom và lái thử.

Hai vai trò có hồ sơ, nội dung thông báo và phạm vi thông tin khác nhau.

2.5. Khoảng trống lớn nhất xuất hiện sau khi bấm “Xác nhận”

Sau khi hoàn thiện và kiểm thử bản Hi-Fi, nhóm chủ động nhìn rộng hơn toàn bộ hành trình từ lúc khách đặt lịch cho tới khi thực sự đến showroom, thay vì chỉ dừng ở việc tạo được một booking.

Kết quả test cho thấy phần đặt lịch có thể được xử lý tốt bằng giao diện có cấu trúc, trong khi sau khi lịch được xác nhận vẫn còn một khoảng trống lớn:

• không chắc lịch đã hoàn tất hay vẫn chờ duyệt;
• không biết cần mang gì;
• không biết quy trình tại showroom;
• không rõ buổi lái thử kéo dài bao lâu và ai sẽ hỗ trợ;
• có câu hỏi về xe, chi phí, thủ tục hoặc bảo hành nhưng thông tin khó tìm;
• agent có thể chủ động gợi ý thay vì chờ khách tự nghĩ ra câu hỏi.

Từ đó, nhóm mở rộng vai trò của ViVi sang giai đoạn sau khi booking được xác nhận: phần booking tiếp tục dùng workflow có cấu trúc để đảm bảo nhanh và chính xác, còn ViVi hỗ trợ chuẩn bị, giải đáp và duy trì context cho khách trước khi tới showroom.

2.6. Năm nhu cầu chính mà sản phẩm cần giải quyết

Từ slide và nghiên cứu người dùng, bài toán được cô đọng thành năm việc chính:

1. Bắt đầu đúng chỗ: người đang xem một mẫu xe có thể đi thẳng tới luồng lái thử mà không phải tìm lại từ đầu.
2. Đặt một lịch có thật: xe, showroom và khung giờ phải gắn với khả năng phục vụ thực tế.
3. Đặt hộ đúng người: tách người đặt và người lái, để thông tin đi đúng người.
4. Chuẩn bị sau khi xác nhận: khách biết rõ cần làm gì trước khi tới showroom.
5. Tự quản lý lịch: đổi hoặc hủy lịch an toàn mà không cần gọi điện cho sales.

3. Giải pháp kỹ thuật

3.1. Nguyên tắc thiết kế: structured workflow cho giao dịch, AI cho phần hội thoại

Quyết định kỹ thuật quan trọng nhất của dự án là tách phần giao dịch xác định được bằng trạng thái khỏi phần hội thoại cần suy luận.

Phần đặt lịch

Các hành động như:

• tìm xe/showroom/khung giờ;
• giữ slot;
• cập nhật booking draft;
• xác minh quyền truy cập;
• xác nhận booking;
• đổi lịch;
• hủy lịch;

được xử lý bằng backend service và các action có cấu trúc. Các nút bấm trong UI có thể đi thẳng tới nghiệp vụ booking thay vì bắt buộc đi qua LLM.

Thiết kế này giúp đảm bảo rằng ngay cả khi model gặp lỗi, hết quota hoặc dịch vụ AI tạm thời không khả dụng, người dùng vẫn có thể hoàn thành các thao tác booking cốt lõi.

Phần ViVi

ViVi được dùng khi nhiệm vụ cần hiểu ngữ cảnh hoặc tương tác tự nhiên, đặc biệt là:

• giải đáp câu hỏi sau booking;
• hướng dẫn khách chuẩn bị trước buổi lái thử;
• tra cứu kho tri thức đã được kiểm soát;
• thu thập những sở thích hoặc nhu cầu người dùng tự nguyện chia sẻ;
• duy trì ngữ cảnh hội thoại;
• hỗ trợ tạo bản tóm tắt có nguồn để sales biết thông tin nào đã chắc chắn và thông tin nào còn cần hỏi lại.

Cách chia này giúp hệ thống tận dụng AI mà không để LLM trở thành nguồn sự thật của booking.

3.2. Luồng booking end-to-end

Luồng chính của hệ thống được thiết kế theo các bước:

1. Khách mở trang đặt lịch ngay trên website.
2. Xác định đặt cho chính mình hay đặt hộ.
3. Chọn đúng xe và phiên bản muốn thử.
4. Chọn showroom phù hợp.
5. Hệ thống kiểm tra khung giờ còn khả dụng dựa trên dữ liệu xe demo và nguồn lực vận hành.
6. Khi khách chọn slot, hệ thống tạo hold để tránh tranh chấp và đặt trùng.
7. Người đặt được xác minh thông qua cơ chế OTP.
8. Chỉ sau khi đủ điều kiện, booking mới được xác nhận và sinh mã lịch.
9. Thông tin được gửi đúng vai trò: người đặt nhận thông tin quản lý lịch, người lái có nội dung và đường dẫn riêng khi cần.
10. ViVi bắt đầu chăm sóc sau khi booking đã chuyển sang trạng thái xác nhận.
11. Showroom check-in đúng người lái và kiểm tra giấy phép bản gốc tại quầy.
12. Booking được đóng thành hoàn tất hoặc no-show để có thể đo vận hành.

Nếu khung giờ khách chọn không còn khả dụng, hệ thống ưu tiên gợi ý các lựa chọn thay thế gắn với inventory thật thay vì chỉ trả về một thông báo chung chung.

3.3. Chống double-booking và quản lý trạng thái

Booking được xây dựng như một nghiệp vụ giao dịch chứ không phải chỉ là một đoạn hội thoại.

Các cơ chế chính gồm:

• transaction ở tầng database;
• hold slot có thời hạn;
• idempotency để hạn chế thao tác lặp ngoài ý muốn;
• version check/optimistic concurrency cho các bước cập nhật;
• audit event để truy vết thay đổi;
• job nền tự giải phóng hold hết hạn.

PostgreSQL đóng vai trò source of truth cho booking, showroom, xe demo, slot, hồ sơ người dùng và trạng thái liên quan.

3.4. Tách người đặt và người lái

Đây là một phần quan trọng của thiết kế sản phẩm lẫn backend.

Sau khi xác định booking là đặt hộ:

• booker và driver được lưu thành hai context khác nhau;
• người đặt không bị buộc trả lời thay sở thích của người lái;
• người lái có thể nhận một driver invitation link có thời hạn để tự trao đổi với ViVi;
• thông tin từ hai người được gắn provenance rõ ràng trước khi tổng hợp cho sales.

Trong post-booking agent, câu hỏi được tách thành ba nhóm:

1. Dặn dò chung: ViVi có thể cung cấp trực tiếp.
2. Thông tin hậu cần của lịch hẹn: hỏi người đặt.
3. Sở thích, nhu cầu và bối cảnh sử dụng xe: ưu tiên hỏi chính người lái.

Nếu người lái không cung cấp thông tin, hệ thống không cố suy đoán. Bản tóm tắt có thể ghi rõ dữ liệu đó chưa có và cần xác minh tại showroom.

3.5. Agent architecture với LangGraph

Backend sử dụng FastAPI làm API layer và LangGraph để điều phối ViVi.

Một message hội thoại đi qua các bước chính:

1. Input guard — kiểm tra kích thước, chuẩn hóa input và chặn các trường hợp injection/abuse theo policy.
2. Intent classification — dùng fast-path cho trường hợp đơn giản, LLM cho trường hợp khó hơn, và có fallback.
3. Skill routing — đưa yêu cầu tới đúng skill, chủ yếu là booking hoặc post-booking.
4. Guarded tool execution — mỗi skill chỉ được phép gọi tập tool đã đăng ký cho skill đó.
5. Output guard — lọc dữ liệu nhạy cảm, giới hạn output và ngăn lộ thông tin nội bộ.

Việc giới hạn tool theo skill giúp giảm khả năng agent gọi nhầm nghiệp vụ. Các hành động có tính thay đổi trạng thái, đặc biệt là xác nhận booking, còn được ràng buộc với action/confirmation cụ thể thay vì để free-form model tự quyết định.

3.6. Post-booking agent và hồ sơ người dùng

Sau khi booking được xác nhận, ViVi chuyển trọng tâm sang hỗ trợ chuẩn bị cho buổi lái thử.

Agent có thể:

• tra cứu knowledge phù hợp;
• ghi nhận các preference hoặc context mà người dùng chia sẻ;
• tiếp tục hội thoại ở các lần truy cập sau;
• phân biệt thông tin đến từ booker và driver;
• tổng hợp context phục vụ sales.

Hồ sơ có thể bắt đầu ở trạng thái gắn với conversation/session và được liên kết với identity tin cậy khi người dùng đã xác thực hoặc booking thành công. Điều này cho phép hệ thống giữ được tính liên tục của trải nghiệm mà không buộc người dùng phải khai báo quá nhiều ngay từ đầu.

3.7. Bản tóm tắt cho sales có provenance

Một mục tiêu của ViVi không phải là thay sales, mà là giảm việc sales phải hỏi lại từ đầu.

Thông tin được tổng hợp theo nguồn, ví dụ:

• người đặt cung cấp;
• người lái tự cung cấp;
• hệ thống đã biết từ booking;
• chưa có thông tin và cần hỏi lại tại showroom.

Cách làm này giúp nhân viên phân biệt rõ đâu là dữ liệu chắc chắn và đâu là dữ liệu chưa được xác nhận, thay vì nhận một đoạn “AI summary” không có nguồn gốc.

Slide cũng đặt ra hai nguyên tắc vận hành cần kiểm soát:

• không để một booking bị nhiều người liên hệ trùng;
• một booking chỉ có một người chịu trách nhiệm liên hệ tại một thời điểm.

3.8. Notification và quản lý lịch sau booking

Hệ thống có notification worker để xử lý xác nhận, reminder và các tác vụ nền liên quan booking. Trong phạm vi sản phẩm được trình bày trên slide, email là kênh giao tiếp chính cho xác nhận và nhắc lịch.

README vẫn giữ một số integration tùy chọn trong codebase, nhưng slide thể hiện quyết định sản phẩm hiện tại là thu hẹp phạm vi để tránh phụ thuộc vào nhiều kênh cùng lúc.

Người dùng cũng có thể quay lại một entry point quản lý booking để:

• xác thực quyền truy cập;
• xem booking;
• cập nhật thông tin phù hợp;
• đổi lịch;
• hủy lịch.

3.9. Internal Portal

Internal Portal dùng chung backend với customer app nhưng có authentication và RBAC riêng.

Portal hỗ trợ các vai trò vận hành quản lý:

• booking;
• catalogue;
• showroom;
• nhân sự;
• ca làm;
• xe demo;
• điều phối xe;
• trạng thái booking;
• audit events.

Nhờ dùng chung source of truth, trạng thái mà khách nhìn thấy, trạng thái ViVi sử dụng và trạng thái nhân viên vận hành xử lý có thể được đồng bộ từ cùng một hệ thống dữ liệu.

3.10. Hạ tầng và triển khai

Stack chính hiện tại gồm:

Mạch hội thoại được checkpoint trong PostgreSQL ở production, vì vậy có thể tiếp tục sau khi backend restart thay vì phụ thuộc hoàn toàn vào memory trong process.

4. Hướng phát triển

Hướng phát triển tiếp theo tập trung vào ba việc: hoàn thiện điều kiện trước pilot, làm sâu post-booking agent và mở rộng agent tư vấn khi use case đã đủ rõ.

4.1. Giai đoạn 1 — Hoàn thành các điều kiện trước pilot

1. Test lại với người dùng có nhu cầu thật

Thực hiện usability test với ít nhất 7 người đang thực sự có ý định đi lái thử để kiểm tra lại toàn bộ hành trình trên phiên bản hiện tại.

Các điểm cần quan sát chính gồm:

• người dùng có hiểu rõ booking đã được xác nhận hay chưa;
• có tự đổi hoặc hủy lịch mà không cần hỗ trợ thủ công;
• trường hợp đặt hộ có phân biệt rõ booker và driver;
• phần chăm sóc sau booking có thực sự giúp khách hiểu bước tiếp theo và chuẩn bị tốt hơn trước khi tới showroom.

2. Đưa toàn bộ kiểm thử về trạng thái đạt yêu cầu

Trước khi mở pilot, cần đảm bảo các test liên quan tới booking, access control, guardrail và regression đều đạt, đồng thời xử lý các lỗ hổng quyền truy cập còn tồn tại. Đây là điều kiện cần để thử nghiệm với người dùng thật mà không làm thay đổi tính đúng đắn của luồng booking hiện tại.

4.2. Giai đoạn 2 — Làm sâu post-booking agent

Sau khi phần booking đã ổn định, ViVi tiếp tục được phát triển sâu hơn ở giai đoạn từ lúc lịch được xác nhận tới trước khi khách đến showroom.

Trọng tâm gồm:

• chủ động cung cấp checklist và hướng dẫn chuẩn bị cho buổi lái thử;
• giải đáp các câu hỏi về quy trình tại showroom và những thông tin khó tìm trong phạm vi knowledge đã được kiểm soát;
• cá nhân hóa gợi ý dựa trên nhu cầu, bối cảnh sử dụng và mối quan tâm mà người lái tự chia sẻ;
• tiếp tục phân biệt rõ thông tin từ booker và driver;
• cải thiện bản tóm tắt bàn giao cho sales, trong đó mỗi thông tin vẫn giữ được nguồn và mức độ xác nhận rõ ràng.

Mục tiêu của bước này không phải thu thập càng nhiều profile càng tốt, mà là giúp ViVi hiểu đủ ngữ cảnh để đưa ra hỗ trợ hữu ích hơn cho chính nhu cầu đang diễn ra.

4.3. Giai đoạn 3 — Mở rộng agent tư vấn

Một hướng phát triển tiếp theo là đưa agent tư vấn hiện đã có nền tảng trong codebase vào luồng sản phẩm khi use case và phạm vi tri thức đã đủ rõ.

Agent này có thể đảm nhiệm phần hỗ trợ người dùng trong giai đoạn tìm hiểu và cân nhắc xe: hiểu nhu cầu sử dụng, giải đáp câu hỏi dựa trên nguồn tri thức được kiểm soát và giúp người dùng thu hẹp những yếu tố cần quan tâm trước khi quyết định đăng ký lái thử.

Việc mở agent tư vấn cần tiếp tục tuân theo nguyên tắc hiện tại của hệ thống:

• chỉ tư vấn trong phạm vi dữ liệu có nguồn và đã được kiểm soát;
• không tự suy diễn thông tin sản phẩm, chính sách hoặc trạng thái booking;
• không thay thế các workflow giao dịch có cấu trúc;
• chỉ được đưa vào luồng chính khi chứng minh được rằng nó giải quyết một nhu cầu thực của người dùng.

Theo hướng này, ViVi có thể phát triển từ một hệ thống booking + post-booking thành một trợ lý hỗ trợ xuyên suốt hơn trong hành trình lái thử, nhưng vẫn giữ ranh giới rõ giữa tư vấn bằng AI và nghiệp vụ giao dịch cần tính chính xác tuyệt đối.

5. Kết luận

ViVi giải quyết bài toán rộng hơn một form đăng ký lái thử.

Giá trị cốt lõi của hệ thống nằm ở ba điểm:

1. Biến yêu cầu đặt lịch thành một booking có trạng thái và nguồn lực thật, thay vì chỉ ghi nhận lead rồi chờ xử lý thủ công.
2. Giảm sự không chắc chắn sau khi đặt, cho phép khách biết rõ lịch của mình đang ở trạng thái nào, tự quản lý booking và chuẩn bị trước buổi lái thử.
3. Dùng AI đúng vị trí, tập trung vào post-booking guidance và context thay vì để LLM điều khiển toàn bộ giao dịch.

Về kỹ thuật, hệ thống đã có các thành phần của một MVP end-to-end: frontend, backend nghiệp vụ, agent orchestration, database, OTP, notification, Internal Portal, guardrail, benchmark và CI/CD. Trước pilot, hai việc cần được ưu tiên là mở rộng user testing với người có nhu cầu thật và đóng các vấn đề access/security còn lại; sau đó nhóm mới tiếp tục làm sâu post-booking và mở rộng agent tư vấn.

Thành công của ViVi vì vậy không nên được đánh giá bằng việc agent nói được bao nhiêu câu hay người dùng chat bao lâu. Chỉ số quan trọng nhất là liệu hệ thống có giúp nhiều booking thực sự chuyển thành một buổi lái thử được thực hiện hay không.