surfup

Dịch vụ giao đồ ăn

Bot Telegram tích hợp AI xử lý 78% yêu cầu hỗ trợ

Giao hàng · Chatbot · AI (RAG) · Tự động hóa
Bối cảnh dự án

Khách hàng là dịch vụ giao đồ ăn chế biến sẵn theo gói đăng ký hoặc đặt từng lần: hàng chục nghìn đơn mỗi tháng, tải tăng cao vào các buổi tối trong tuần. Bộ phận hỗ trợ dựa vào tổng đài và chat; vào giờ cao điểm khách phải đợi tới 40 phút, tuyển thêm nhân viên làm giảm biên lợi nhuận, trong khi 70% yêu cầu chỉ lặp lại những tình huống quen thuộc: «đơn hàng của tôi ở đâu», «đổi địa chỉ thế nào», «món ăn gồm những gì» và «dời lịch giao ra sao». Hầu hết khách hàng sử dụng Telegram, nên chuyển dịch vụ hỗ trợ sang đó là lựa chọn hợp lý.

01 · Thách thức

Tự động hóa các yêu cầu thường gặp mà không giảm chất lượng dịch vụ:

bot trả lời tự nhiên, xem được thông tin đơn hàng cụ thể, có thể đổi lịch giao và thanh toán gói đăng ký ngay trong chat, đồng thời chuyển khách cho nhân viên một cách phù hợp khi tình huống phức tạp. Tiêu chuẩn chất lượng rất nghiêm ngặt: nếu bot chỉ «giả vờ hỗ trợ» thay vì giải quyết vấn đề thì dự án được xem là thất bại.

02 · Công việc đã thực hiện

Chúng tôi không xây bot như một «chatbot có menu» mà như một nhân viên hỗ trợ thực thụ: có quyền truy cập dữ liệu đơn hàng, được phép thực hiện thao tác thường gặp và có giới hạn chuyển tiếp rõ ràng.

  • Phân tích yêu cầu hỗ trợ trong ba tháng: xác định 50 kịch bản thường gặp, tỷ trọng từng loại, cách khách hàng thực sự diễn đạt và các lỗi nhân viên thường mắc.
  • Xây dựng cơ sở tri thức dịch vụ: quy định giao hàng, thành phần món ăn, giá gói đăng ký và quy trình hoàn tiền — các dữ kiện được cấu trúc để mô hình trả lời.
  • Phát triển lõi hội thoại: mô hình ngôn ngữ tìm kiếm trong cơ sở tri thức (RAG), không được trả lời vượt ra ngoài dữ kiện của dịch vụ và giữ thống nhất giọng điệu thương hiệu.
  • Kết nối bot với hệ thống vận hành qua API: trạng thái và lịch sử đơn hàng, đổi địa chỉ và thời gian giao, tạm dừng hoặc thanh toán gói đăng ký.
  • Thiết kế quy trình chuyển tiếp: yêu cầu phức tạp hoặc nhạy cảm được chuyển cho nhân viên cùng ngữ cảnh hội thoại để khách không phải kể lại.
  • Thiết lập phân tích hội thoại: lý do chuyển tiếp, tình huống bot chưa trả lời được và nội dung cần bổ sung vào cơ sở tri thức; bot được cải thiện dựa trên các cuộc trò chuyện thực tế.

Nguyên tắc chính của dự án là khách không nên nhận ra tự động hóa. Bot phản hồi trong vài giây, giải quyết vấn đề trong một hoặc hai tin nhắn và không bao giờ mắc kẹt trong vòng lặp: nếu tình huống khác thường, nhân viên lập tức tiếp nhận với đầy đủ ngữ cảnh. Vì vậy, điểm đánh giá dịch vụ tăng từ 3,4 lên 4,7 — khách đánh giá tốc độ và kết quả chứ không phân biệt «robot hay con người». Chính kỷ luật này tạo nên khác biệt giữa bot hữu ích và bot gây bực bội.

03 · Kết quả

Xét về hiệu quả kinh tế, lượng yêu cầu tăng gấp ba trong một năm cùng với quy mô dịch vụ nhưng đội ngũ nhân viên vẫn giữ nguyên — bot xử lý toàn bộ phần tăng thêm. Thời gian nhân viên được giải phóng chuyển sang các tình huống phức tạp và có giá trị cao, như giữ chân khách hàng, vốn trước đây không thể xử lý trong ca làm. Bot còn trở thành kênh bán hàng: nhắc gia hạn gói và bán thêm trong hội thoại đóng góp phần doanh thu đáng kể, biến hỗ trợ từ trung tâm chi phí thành kênh tăng trưởng.

04 · Kết quả chính
Chỉ sốKết quả
Yêu cầu được xử lý mà không cần nhân viên0% → 78%
Thời gian phản hồi đầu tiênTối đa 40 phút vào giờ cao điểm → 3–5 giây
Chi phí xử lý mỗi yêu cầu≈90 ₽ → ≈7 ₽
CSAT của bộ phận hỗ trợ3,4 → 4,7

Các chỉ số được chuyển từ tài liệu gốc của case study. Khoảng thời gian được ghi khi nguồn có nêu.

Ba tháng sau khi bot đi vào hoạt động
yêu cầu được giải quyết mà không cần nhân viên
78%
phản hồi đầu tiên (trước đây mất tới 40 phút vào giờ cao điểm)
3–5 giây
chi phí mỗi yêu cầu (trước đây khoảng 90 ₽)
≈7 ₽
CSAT hỗ trợ (trước đây là 3,4)
4,7
Trước và sau
Yêu cầu không cần nhân viên xử lý
Trước0%
Sau78%
Thời gian phản hồi đầu tiên
Trướctối đa 40 phút
Sau3–5 giây
Giá trị thấp hơn là tốt hơn
Chi phí mỗi yêu cầu
Trước≈90 ₽
Sau≈7 ₽
Giá trị thấp hơn là tốt hơn
Điểm đánh giá hỗ trợ (CSAT)
Trước3,4
Sau4,7

Phản hồi đầu tiên: 40 phút = 2400 giây so với cận trên 5 giây. CSAT được chấm theo thang điểm 5.

Bot đang hoạt động (bản dựng đã ẩn danh)

Khách hàngĐơn hàng của tôi ở đâu?

BotĐơn hàng đang trên đường giao. Bạn có muốn đổi giờ giao không?

Khách hàngCó, chuyển sang buổi tối giúp tôi

BotĐã xong, thời gian giao hàng đã được đổi.

Quy trình xử lý yêu cầu
  1. 01Yêu cầu qua Telegram
  2. 02AI + cơ sở tri thứcvà dữ liệu đơn hàng qua API
  3. 03Tình huống thường gặp — xử lý ngay trong chat
  4. 04Tình huống phức tạp — nhân viên hỗ trợkèm ngữ cảnh hội thoại
Các bước tiếp theo

Các hướng phát triển tiếp theo cho bot:

  • Đa kênh: đưa các kịch bản tương tự lên WhatsApp và VK, dùng chung cơ sở tri thức và lõi xử lý.
  • Thông báo chủ động: cảnh báo chậm trễ trước khi khách phải hỏi.
  • Trợ lý giọng nói: đặt món và quản lý gói đăng ký bằng giọng nói trong ứng dụng di động của dịch vụ.
Lời chia sẻ
Bot trả lời nhanh hơn bất kỳ nhân viên nào và không nghỉ ngày nào. Quan trọng nhất là bot giải quyết vấn đề chứ không giả vờ hỗ trợ: khách không nhận ra và chấm cho chúng tôi điểm «năm» tối đa.

— Quản lý dịch vụ giao đồ ăn

Tài liệu mới nhất

Tất cả tài liệu

Bài viết và hướng dẫn thực tiễn từ SurfUp.

Hướng dẫn · 10 phút

Trang “là gì?” và câu trả lời AI: mất lượt nhấp hay nhu cầu giảm?

Chuyên mục tham khảo của một ngân hàng mất 24% lượt truy cập khi nhu cầu giảm 13%. Cách phân biệt lượt nhấp bị khối AI lấy mất với nhu cầu giảm và cách đo lường.

Đọc
Hướng dẫn · 8 phút

Lưu lượng giảm sau một bản cập nhật Google

Cách xác định mức giảm lưu lượng là do bản cập nhật Google, tính mùa vụ hay lỗi website. Lịch cập nhật năm 2026, bài kiểm tra sáu câu hỏi và kế hoạch cho 14 ngày đầu.

Đọc
Hướng dẫn · 9 phút

Nhu cầu giảm hay website mất lưu lượng: đối chiếu lượt truy cập với Wordstat

Nhu cầu tiền gửi giảm 75%, lưu lượng giảm 37%; với thẻ, nhu cầu giảm 35% còn lưu lượng giảm 63%. Cách đối chiếu lưu lượng với nhu cầu để không đổ lỗi cho website khi nguyên nhân nằm ở thị trường.

Đọc