Hướng dẫn gửi email xác nhận và theo dõi trạng thái đơn hàng Levela với Vibe Coding
Back To Blogs
Nguyễn Thị Thanh Tuyền - Chuyên viên Marketing
Ở bài trước, chúng ta đã mở rộng Landing Page Levela với giỏ hàng, Checkout và chức năng đặt hàng. Khách hàng có thể lựa chọn sản phẩm, thêm vào giỏ hàng, nhập thông tin cần thiết và tạo đơn hàng trên EzyPlatform.
Hành trình mua hàng lúc này đã đi đến:
- Khám phá sản phẩm
- →
- Thêm vào giỏ
- →
- Checkout
- →
- Đặt hàng
- →
- EzyPlatform tiếp nhận đơn
Tuy nhiên, sau khi đặt hàng, khách hàng vẫn cần biết đơn của mình đã được tiếp nhận hay chưa và trạng thái hiện tại như thế nào.
Vì vậy, trong bài này chúng ta sẽ tiếp tục sử dụng Vibe Coding kết hợp MCP Server để hoàn thiện hai phần còn thiếu:
- Gửi email xác nhận đơn hàng sau khi Ecommerce thực sự tạo đơn thành công.
- Cho phép khách hàng theo dõi trạng thái đơn hàng bằng dữ liệu thực tế từ EzyPlatform.
Trong bài này, chúng ta vẫn giữ nguyên nguyên tắc của những phần trước: không tự đoán API, không tự tạo dữ liệu trạng thái và không để frontend quyết định một thao tác đã thành công hay chưa.
1. Kiểm tra lại luồng đặt hàng hiện tại
Trước khi thêm email hoặc chức năng theo dõi đơn hàng, hãy để AI kiểm tra lại source code đã hoàn thiện ở bài trước. Mục tiêu là xác định chính xác dữ liệu nào đang có sau khi Ecommerce tạo đơn thành công.
Prompt mẫu
"Hãy kiểm tra source code và luồng đặt hàng Levela hiện tại.
Hãy xác định:
- Trang Checkout đang được xử lý ở đâu.
- Chức năng nào đang tạo đơn hàng.
- Dữ liệu server trả về sau khi tạo đơn thành công.
- Có mã đơn hàng hoặc ID đơn hàng hay không.
- Email khách hàng được lưu ở trường nào.
- Trạng thái đơn hàng được trả về như thế nào.
- Website hiện xử lý gì sau khi tạo đơn thành công.
- Project đã có chức năng gửi email xác nhận đơn hàng hay chưa.
- Project đã có chức năng tra cứu đơn hàng hay chưa.
Ưu tiên tái sử dụng chức năng hiện tại.
Không chỉnh sửa source code.
Sau khi kiểm tra, hãy liệt kê dữ liệu thực tế có thể sử dụng cho email xác nhận và theo dõi đơn hàng."
Kết quả của bước này giúp chúng ta xác định những dữ liệu có thể tiếp tục sử dụng.
2. Xác định đúng thời điểm gửi email xác nhận
Một điểm cần xử lý ngay từ đầu là thời điểm gửi email. Không nên gửi email ngay khi khách nhấn nút Đặt hàng, bởi lúc đó request tạo đơn vẫn có thể thất bại.
Ví dụ, nếu chúng ta thực hiện:
- Click Đặt hàng
- →
- Gửi email
- →
- Tạo đơn
thì có thể xảy ra trường hợp khách nhận được email xác nhận nhưng Ecommerce lại không tạo được đơn.
Luồng đúng phải là:
- Khách nhấn Đặt hàng
- →
- Gửi request
- →
- Ecommerce tạo đơn
- →
- Xác nhận thành công
- →
- Gửi email
Nguyên tắc này tương tự form tư vấn đã xây dựng với EzySupport: hệ thống tiếp nhận thành công trước, sau đó mới phản hồi cho khách. Như vậy dữ liệu giữa website, Ecommerce và email sẽ thống nhất với nhau.
3. Sử dụng MCP Server tìm chức năng gửi email
Sau khi biết vị trí cần gửi email, chúng ta cần xác định EzyPlatform đã có chức năng nào phù hợp. Không nên tự tạo thêm một API gửi email nếu hệ thống đã cung cấp chức năng tương ứng.
Hãy tiếp tục sử dụng MCP Server:
Prompt mẫu
"Hãy sử dụng MCP Server để kiểm tra các API hoặc Ezy Function hiện có trên EzyPlatform liên quan đến gửi email.
Tôi cần gửi email xác nhận sau khi một đơn hàng Levela được Ecommerce tạo thành công.
Hãy xác định:
- Chức năng gửi email phù hợp.
- Có hỗ trợ Mail Template hay không.
- Các tham số cần truyền.
- Các biến động có thể truyền vào template.
- Cách lấy email khách hàng từ đơn hàng.
- Cách gọi chức năng này ở phía server.
Ưu tiên chức năng hiện có trên EzyPlatform.
Không tự tạo API gửi email mới.
Không gửi email trực tiếp từ JavaScript phía trình duyệt.
Không chỉnh sửa source code ở bước này."
Sau khi MCP trả về kết quả, hãy kiểm tra kỹ các tham số mà chức năng gửi email hỗ trợ. Chúng ta chỉ sử dụng những dữ liệu thực tế có thể truyền từ đơn hàng sang email.
4. Tạo Mail Template xác nhận đơn hàng Levela
Khi đã biết những biến nào có thể sử dụng, chúng ta bắt đầu chuẩn bị Mail Template.
Email xác nhận không cần quá nhiều nội dung quảng cáo. Mục tiêu chính là giúp khách biết đơn hàng đã được tiếp nhận và có những thông tin để đối chiếu. Một email phù hợp có thể gồm:
- Logo Levela.
- Lời cảm ơn.
- Mã đơn hàng.
- Danh sách sản phẩm.
- Số lượng.
- Tổng giá trị đơn hàng.
- Phương thức thanh toán nếu có.
- Trạng thái đơn hàng nếu phù hợp.
- Hướng dẫn kiểm tra đơn hàng.
Tên template có thể đặt theo quy ước của project, ví dụ: levela_order_confirmation.
Sau đó sử dụng Vibe Coding để chuẩn bị nội dung:
Prompt mẫu
"Dựa trên chức năng gửi email và các biến Mail Template vừa tìm được, hãy chuẩn bị Mail Template xác nhận đơn hàng cho Levela.
Mục đích:
Gửi email cho khách sau khi Ecommerce xác nhận đơn hàng đã được tạo thành công.
Email ưu tiên hiển thị những dữ liệu mà hệ thống thực tế cung cấp:
- Tên khách hàng.
- Mã đơn hàng.
- Sản phẩm đã đặt.
- Số lượng.
- Tổng giá trị đơn hàng.
- Phương thức thanh toán.
- Trạng thái đơn hàng.
Yêu cầu:
- Chỉ sử dụng các biến thực tế đã được xác định.
- Không tự tạo biến template mới.
- Không tự tạo dữ liệu đơn hàng.
- Giữ Brand Identity Levela.
- Sử dụng màu sắc và phong cách hiện tại của Levela.
- Giao diện email đơn giản, dễ đọc trên desktop và mobile.
- Không đưa nội dung quảng cáo không cần thiết vào email xác nhận.
Chưa tích hợp chức năng gửi email."
Sau khi tạo template, hãy Preview email với dữ liệu thử để kiểm tra bố cục trước khi nối vào luồng đặt hàng.
5. Gửi email sau khi tạo đơn thành công
Khi Mail Template đã sẵn sàng, chúng ta có thể kết nối nó với luồng Ecommerce. Luồng cần đạt được là:
- Checkout
- →
- Tạo đơn Ecommerce
- →
- Xác nhận tạo đơn thành công
- →
- Gửi email xác nhận
Tiếp tục yêu cầu AI:
Prompt mẫu
"Hãy tích hợp email xác nhận vào luồng tạo đơn hàng Levela hiện tại.
Luồng cần đạt được:
Checkout → Tạo đơn Ecommerce → Xác nhận tạo đơn thành công → Gửi email xác nhận.
Yêu cầu:
- Chỉ gửi email sau khi Ecommerce xác nhận đơn đã được tạo.
- Sử dụng email thực tế của khách trong đơn hàng.
- Sử dụng Mail Template Levela vừa chuẩn bị.
- Truyền đúng các biến mà template hỗ trợ.
- Không gửi email trực tiếp từ browser.
- Không hard-code SMTP password, API key hoặc secret vào frontend.
- Không gửi email nhiều lần do khách click Đặt hàng liên tục.
- Không tạo lại đơn hàng chỉ để gửi lại email.
- Không làm thay đổi luồng Checkout hiện tại ngoài phần cần thiết.
Sau khi hoàn thành, hãy mô tả lại luồng xử lý và liệt kê những file đã thay đổi."
Sau khi AI hoàn thành, hãy tạo một đơn thử nghiệm. Lần này chúng ta cần kiểm tra ở hai nơi: đơn hàng vừa tạo trong Ecommerce.
Và hộp thư của khách hàng thử nghiệm. Thông tin trong email phải khớp với đơn hàng thực tế.
6. Sử dụng MCP Server tìm chức năng tra cứu đơn hàng
Email giúp khách biết đơn đã được tiếp nhận. Tuy nhiên, sau đó khách vẫn cần một cách để quay lại website và kiểm tra đơn hàng.
Thay vì tự xây dựng hệ thống tra cứu mới, trước tiên hãy kiểm tra những chức năng EzyPlatform Ecommerce đã cung cấp.
Prompt mẫu
"Hãy sử dụng MCP Server để tìm API hoặc Ezy Function hiện có trên EzyPlatform phục vụ tra cứu đơn hàng.
Tôi muốn khách hàng Levela có thể kiểm tra thông tin và trạng thái đơn sau khi đặt hàng.
Hãy xác định:
- Chức năng lấy thông tin một đơn hàng.
- Tham số cần truyền.
- Dữ liệu trả về.
- Các trạng thái đơn hàng thực tế mà hệ thống sử dụng.
- Cơ chế xác thực hoặc kiểm tra quyền truy cập nếu có.
- Thông tin nào có thể hiển thị an toàn cho khách hàng.
Ưu tiên chức năng hiện có trên EzyPlatform.
Không tự tạo API mới.
Không chỉnh sửa source code."
Ở bước này, ngoài việc tìm được API, cần đặc biệt chú ý đến quyền truy cập đơn hàng. Không nên mặc định rằng biết order_id là có thể xem được đơn hàng. Nếu làm như vậy, người khác có thể thử thay đổi ID trên URL để truy cập một đơn không thuộc về mình.
Do đó, sau khi MCP trả về kết quả, cần xác định ba yếu tố:
| Cần xác định | Mục đích |
|---|---|
| Thông tin nhận diện đơn | Xác định đúng đơn cần tra cứu |
| Cơ chế xác thực | Ngăn người khác xem trái phép đơn hàng |
| Dữ liệu trả về | Xác định thông tin nào có thể hiển thị cho khách |
Chỉ sau khi xác định được những thông tin này chúng ta mới chuyển sang phần giao diện.
7. Tạo trang theo dõi đơn hàng
Sau khi biết cách lấy dữ liệu đơn hàng an toàn, chúng ta có thể tạo trang theo dõi cho Levela. Không nên tự quyết định URL trước khi AI kiểm tra routing hiện tại.
Tùy cấu trúc project, đường dẫn có thể tương tự /levela/order/..., nhưng URL thực tế cần tuân theo routing của website.
Trang theo dõi không cần trở thành một hệ thống quản trị đơn hàng. Khách chỉ cần xem những thông tin cần thiết liên quan đến đơn của mình.
| Thông tin | Mục đích |
|---|---|
| Mã đơn | Giúp khách xác định đơn hàng |
| Ngày đặt | Đối chiếu thời điểm đặt hàng |
| Sản phẩm | Xem lại sản phẩm đã đặt |
| Số lượng | Đối chiếu số lượng |
| Tổng tiền | Đối chiếu giá trị đơn hàng |
| Thanh toán | Hiển thị thông tin phù hợp nếu hệ thống cung cấp |
| Trạng thái | Cho biết trạng thái hiện tại của đơn |
Tiếp tục Vibe Coding:
Prompt mẫu
"Dựa trên API/Ezy Function tra cứu đơn hàng vừa tìm được, hãy tạo chức năng theo dõi đơn hàng cho Levela.
Yêu cầu:
- Sử dụng routing hiện tại của project.
- Lấy dữ liệu đơn hàng thật từ EzyPlatform.
- Hiển thị mã đơn.
- Hiển thị ngày đặt nếu API cung cấp.
- Hiển thị danh sách sản phẩm và số lượng.
- Hiển thị tổng giá trị đơn.
- Hiển thị thông tin thanh toán phù hợp nếu có.
- Hiển thị trạng thái đơn hàng thực tế.
- Không hard-code trạng thái đơn.
- Không tự thay đổi trạng thái từ frontend.
- Không hiển thị dữ liệu cá nhân hoặc dữ liệu nhạy cảm không cần thiết.
- Tuân thủ cơ chế xác thực của API hiện tại.
- Xử lý trường hợp không tìm thấy đơn.
- Xử lý trường hợp người dùng không có quyền xem đơn.
- Giữ Brand Identity Levela.
- Responsive trên mobile.
Không thêm chức năng mới ngoài phạm vi theo dõi đơn hàng.
Sau khi hoàn thành, hãy liệt kê những file đã thay đổi và dừng lại để tôi Preview."
Sau khi AI hoàn thành, hãy sử dụng một đơn vừa tạo để kiểm tra. Website phải hiển thị đúng dữ liệu mà Ecommerce đang lưu.
8. Liên kết email với trang theo dõi đơn hàng
Đến đây chúng ta đã có hai phần hoạt động: email xác nhận đơn hàng và trang theo dõi đơn hàng. Bước tiếp theo là kết nối chúng thành một hành trình liên tục.
Nếu cơ chế tra cứu đơn hiện tại hỗ trợ tạo một đường dẫn an toàn, chúng ta có thể thêm CTA "Theo dõi đơn hàng" vào email xác nhận. Khi đó khách không cần quay lại website rồi tự tìm đơn.
Luồng sẽ trở thành:
- Đặt hàng
- →
- Nhận email
- →
- Click Theo dõi đơn hàng
- →
- Xem đơn trên Levela
Trước khi sửa Mail Template, hãy để AI kiểm tra khả năng liên kết an toàn.
Prompt mẫu
"Hãy kiểm tra xem chức năng theo dõi đơn hàng Levela hiện tại có thể được liên kết an toàn từ email xác nhận hay không.
Nếu có, hãy cập nhật Mail Template xác nhận đơn hàng Levela:
- Thêm CTA Theo dõi đơn hàng.
- CTA dẫn đến đúng đơn hàng của khách.
- Sử dụng URL hoặc thông tin xác thực do backend hiện tại cung cấp.
- Không tự ghép URL chỉ dựa trên order ID nếu có thể làm lộ dữ liệu đơn hàng.
- Không đưa token quản trị hoặc secret vào URL.
- Không làm thay đổi những thông tin xác nhận đơn hàng hiện có.
- Giữ Brand Identity Levela.
Nếu hệ thống hiện tại chưa hỗ trợ cách liên kết an toàn từ email, không tự tạo workaround.
Hãy báo lại giới hạn hiện tại thay vì tự thay đổi cơ chế bảo mật."
Nếu hệ thống hỗ trợ, hãy gửi lại một email thử nghiệm và click trực tiếp CTA để kiểm tra. Kết quả cần đạt:
- Email khách hàng
- →
- CTA Theo dõi đơn hàng
- →
- Đúng đơn hàng
Lưu ý: nếu EzyPlatform chưa cung cấp cơ chế liên kết an toàn, chúng ta không nên cố tạo một URL chỉ để hoàn thiện giao diện.
9. Kiểm tra toàn bộ trải nghiệm sau đặt hàng
Sau khi email xác nhận và chức năng theo dõi đơn đã hoạt động, chúng ta cần thực hiện một lần kiểm thử toàn bộ thay vì chỉ test từng chức năng riêng.
Kết luận
Như vậy, hành trình mua hàng của Levela không còn kết thúc khi khách nhấn Đặt hàng. Sau khi Ecommerce thực sự tiếp nhận đơn, hệ thống có thể gửi email xác nhận và khách hàng có thể tiếp tục kiểm tra đơn của mình trên website.
Quan trọng hơn, chúng ta không tạo một hệ thống theo dõi riêng biệt. Email, thông tin đơn hàng và trạng thái đều dựa trên dữ liệu thực tế từ EzyPlatform, giúp những gì khách nhìn thấy trên Levela thống nhất với dữ liệu mà doanh nghiệp đang quản lý.
Đến đây, phần lớn hành trình mà khách hàng trực tiếp trải nghiệm đã được hoàn thiện. Nhưng chúng ta vẫn chưa biết có bao nhiêu người thực sự đi qua từng bước: bao nhiêu người xem sản phẩm, đọc Blog, thêm vào giỏ, bắt đầu Checkout và cuối cùng đặt hàng thành công.