Cách mình xây hệ thống hỗ trợ người dùng bằng email cho Festia

Bài toán support qua email cho Festia

Festia cần một kênh để user góp ý hoặc báo lỗi. Đồng thời, mình cũng mong muốn có thể phản hồi lại cho họ, nhưng không muốn họ phải mở một ứng dụng mạng xã hội để nhắn tin cho một người lạ, là mình.

Lựa chọn email thay vì ứng dụng chat cho hệ thống hỗ trợ Festia

Đóng vai trò là một user, mình hiểu cảm giác ngại khi phải mở một ứng dụng mạng xã hội để kết nối với một người lạ trên Internet. Có thể chỉ mình cảm thấy như vậy, nhưng mình nghĩ không phải user nào cũng thoải mái với trải nghiệm này.

Còn nếu tự xây dựng nguyên một hệ thống chat thì có vẻ hơi over-engineering. Support của Festia vốn không cần realtime. Nếu làm chat, mình còn phải xử lý kết nối realtime, thông báo, trạng thái online và nhiều thứ khác.

Vì vậy, email là lựa chọn phù hợp hơn.

UX trên Festia

Trên Festia, mình đã làm một nút góp ý. Khi user bấm vào, một modal sẽ hiện lên để họ điền thông tin như một form thông thường.

User không cần quan tâm nội dung đó sẽ được gửi đi đâu. Họ chỉ cần điền form, bấm gửi và tiếp tục sử dụng ứng dụng.

Bức tranh toàn cảnh

Khi user gửi feedback:

User → Festia feedback form modal → Backend API → Tạo thread/ticket trong database → Resend gửi notification cho admin → Resend gửi email xác nhận cho user

Mỗi ticket có một ID riêng. Email gửi cho user có thể reply qua địa chỉ:
[email protected].
Thread và các message được lưu trong Supabase. Resend đảm nhiệm việc gửi email và nhận email inbound.

Khi admin phản hồi
Khi mình muốn thông báo rằng lỗi đã được sửa hoặc trả lời góp ý của user:

Mình → Admin Support View → Backend API thêm message vào thread/ticket → Resend gửi email cho user

Email này vẫn có subject dạng Re: và các header như In-Reply-To và References, giúp Gmail hoặc các mail client khác hiển thị những email liên quan trong cùng một conversation.

Khi user trả lời lại thì sao?
Trong email gửi cho user đã có:
Reply-To: [email protected]
Khi user bấm trả lời, flow sẽ là:

User → Mail client gửi tới [email protected] → Resend nhận email inbound → Resend gọi webhook của backend → Backend xác thực webhook → Parse ticket_id từ địa chỉ email → Lưu email thành message trong đúng thread

Ở đây, backend không dùng In-Reply-To để xác định ticket. Backend lấy ticket_id từ địa chỉ support+ticket_id@..., sau đó map email vào thread tương ứng.

Tại sao mình không dùng In-Reply-To để xác định ticket?

Thực ra Festia vẫn dùng In-Reply-To và References trong email outbound. Mục đích của chúng là giúp mail client như Gmail hoặc Outlook gom các email vào cùng một conversation.

Tuy nhiên, backend không dùng các header này làm cơ chế chính để xác định ticket.
Nếu dùng In-Reply-To, backend sẽ phải xử lý thêm nhiều trường hợp:

• Mail client có thể gửi thiếu header.
• Header có thể bị thay đổi khi email được forward.
• Cần lưu và đối chiếu Message-ID giữa các email.
• Cần xử lý các format header khác nhau.
• Cần có cơ chế fallback và chống duplicate message.

Các hệ thống support lớn như Zendesk có thể dùng In-Reply-To kết hợp với Message-ID, ticket ID trong subject và một số kỹ thuật khác. Tuy nhiên, với nhu cầu hiện tại của Festia, mình chọn plus-addressing:
[email protected]

Ưu điểm

• Dễ triển khai.
• Chỉ cần parse regex để lấy ticket ID.
• Ít phụ thuộc vào việc mail client có gửi đầy đủ header hay không.
• Dễ debug khi có lỗi.

Nhược điểm

• Hệ thống phải tự định nghĩa và duy trì convention này.
• Có thể khó tích hợp trực tiếp với các nền tảng bên thứ ba như Zendesk.
• Nếu có co-author, mình cần giải thích rõ flow hoạt động.

Có lỗ hổng nào không?

Có, và chắc chắn vẫn còn nhiều điểm cần cải thiện.
Đây là lần đầu mình trực tiếp xây dựng một hệ thống có liên quan đến email inbound, email headers và email threading. Trong quá trình làm, có những phần mình chưa hiểu đầy đủ, có phần hiểu chưa chính xác và cũng có sự hỗ trợ từ AI agent.

Tuy nhiên, hiện tại hệ thống đang hoạt động ổn với nhu cầu của Festia, nên mình sẽ tạm thời chưa sửa. Có lẽ đến một ngày nào đó, khi hiểu rõ hơn về luồng hoạt động của email, mình sẽ quay lại làm cho hệ thống chuẩn chỉnh hơn.

Qua bài viết này, mình muốn chia sẻ một giải pháp nhỏ nhưng hiệu quả đối với Festia trong việc xây dựng kênh hỗ trợ người dùng.
Cảm ơn mọi người đã dành thời gian đọc bài viết này ạ ^^