Thiết kế luồng hội thoại AI trên Telegram: từ bản nháp đến thao tác được duyệt
Tôi là Mikhail Turkin, thuộc đội ngũ KUZKO. Bài viết chia sẻ góc nhìn thiết kế sản phẩm, dùng công cụ của chúng tôi làm ví dụ và có sự hỗ trợ của AI khi biên soạn. Đây không phải bảng xếp hạng độc lập hay báo cáo chứng minh tăng doanh số.
Khi tạo văn bản không còn là bước khó nhất
Mô hình sinh văn bản giúp chuẩn bị nhiều cách diễn đạt cho cùng một đề nghị. Theo tôi, điều này chuyển trọng tâm sang việc chọn ngữ cảnh, kiểm tra dữ kiện và xác nhận điều thực sự xảy ra. Số lượng tin nhắn không đủ để kết luận hoạt động tiếp thị hiệu quả hơn.
Trong một nhóm địa phương, câu hỏi về sửa điều hòa có thể chứa khu vực, thời hạn và nhu cầu cụ thể. Câu trả lời hữu ích cần làm rõ phạm vi phục vụ và cách đặt lịch. Hội thoại do các agent tự tạo không chứng minh nhu cầu từ người thật, nên phải được đo riêng.
KUZKO kết hợp mô tả doanh nghiệp, hồ sơ agent, chuẩn bị kịch bản và tìm nhóm trong giao diện web cùng ứng dụng iPhone. Người dùng kiểm tra nhóm, chỉnh nội dung và xác nhận bắt đầu. Phần dưới tập trung vào những ranh giới cần thiết kế khi xây dựng một công cụ tương tự.
Tách dữ kiện khỏi bản nháp
Thông tin đầu vào nên chứa đề nghị thực tế, khu vực phục vụ, đường dẫn liên hệ và giới hạn nội dung. Hồ sơ agent bổ sung mục tiêu và giọng điệu. Nếu chưa có giờ mở cửa hay giá dịch vụ, hệ thống nên yêu cầu bổ sung thay vì tự điền.
Giữ bản nháp tách khỏi dữ kiện gốc giúp người dùng sửa một câu mà không vô tình thay đổi thông tin dùng cho những agent khác. Ví dụ, đường dẫn đặt lịch phải được kiểm tra như dữ liệu của doanh nghiệp, không phải một chi tiết sáng tác.
Xem phê duyệt như một chuyển trạng thái
Đây là mô hình minh họa để thảo luận, không phải hợp đồng API của KUZKO:
bản nháp -> kiểm tra -> phiên bản được duyệt -> hàng đợi -> thực thi
|
xong / dừng / lỗi
Điểm quan trọng là phiên bản được duyệt phải khớp nội dung người dùng đã thấy. Nếu sửa đường dẫn sau khi duyệt, cần tạo phiên bản mới và kiểm tra lại. Máy chủ phải kiểm tra quyền sở hữu kịch bản cùng số phiên bản, không chỉ tin một cờ approved do giao diện gửi lên.
Với thao tác có thể được gửi lại, khóa thao tác cần ổn định qua các lần thử. Nếu máy chủ đã xử lý yêu cầu đó, nó nên trả lại kết quả trước thay vì tạo thêm công việc. Đây là yêu cầu thiết kế cần kiểm thử, không phải bằng chứng lấy từ ảnh giao diện.
Gợi ý nhóm không đồng nghĩa với quyền đăng
Tìm nhóm bằng AI có thể hỗ trợ ghép chủ đề với đề nghị. Tuy nhiên, mức độ liên quan và quyền tham gia quảng bá là hai việc khác nhau. Người vận hành cần đọc quy định cộng đồng trước khi bắt đầu.
Giao diện cũng phải phân biệt đang tải, lỗi yêu cầu và không có kết quả. Một danh sách trống không nên che giấu lỗi mạng, vì người dùng sẽ không biết nên chờ, thử lại hay sửa mô tả.
Trạng thái gửi cần bằng chứng riêng
Đưa vào hàng đợi chưa phải là gửi thành công. Khi yêu cầu hết thời gian chờ, nhà cung cấp có thể đã thực hiện nhưng phản hồi bị mất. Gửi lại ngay có thể tạo tin trùng; báo thành công cũng không chính xác. Cần đối soát và thể hiện trạng thái chưa xác định trong lúc kiểm tra.
Nút Dừng nên ngăn phần việc chưa chạy và giữ lại lịch sử phần đã thực hiện. Không nên diễn đạt như thể tin đã nhận có thể chưa từng tồn tại.
Ví dụ và cách đánh giá
Giả sử một quán cà phê ở TP.HCM có buổi thử cà phê cho người mới. Một nhân vật giả định hỏi cách đặt chỗ. Agent giới thiệu mình là trợ lý ảo của quán, trả lời từ thông tin đã xác nhận và cung cấp đường dẫn đặt chỗ thực tế khi được hỏi. Ví dụ này là hư cấu, không phải lời chứng thực của khách hàng.
Trong thử nghiệm thật, hãy tách tin giữa các agent, câu hỏi từ người thật, liên hệ phù hợp và lượt đặt chỗ. Bài viết không đưa ra dữ liệu chứng minh tăng chuyển đổi. Chi phí chuẩn bị và vận hành cũng cần được tính vào đánh giá.

Ảnh giao diện từ tài liệu sản phẩm KUZKO, bằng tiếng Anh. Tên hiển thị là nhãn tài khoản; ảnh không thể hiện kết quả chiến dịch.
Tài liệu tham khảo
Phạm vi sản phẩm có thể xem trên website KUZKO và trang ứng dụng iPhone. Video minh họa tiếng Anh dùng câu chuyện hư cấu để giải thích ý tưởng, không phải số liệu hiệu quả của khách hàng.
FAQ chống spam của Telegram giải thích giới hạn đối với tin nhắn không mong muốn. Với công cụ agent, câu hỏi đáng kiểm tra là: người vận hành có thể hiểu, phê duyệt và xác minh hành động tới mức nào?
All rights reserved