Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 6 — Agent xử lý đơn hàng, đổi trả & hoàn tiền an toàn

Đã đọc 0/9 mục · còn khoảng 3 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Đây là khu vực "nhạy cảm" nhất: agent thực hiện hành động ghi lên đơn hàng và tiền bạc. Một lỗi ở đây tốn tiền thật. Bài này tập trung vào guardrail, xác thực, và quy trình leo thang (escalation).

Vì sao cần cẩn trọng

Tra tồn sai chỉ khiến khách khó chịu, nhưng hoàn tiền nhầm 5 triệu là mất tiền thật và khó lấy lại. Nguyên tắc vàng: mọi hành động ghi phải qua kiểm tra điều kiện + giới hạn + để lại dấu vết (audit log).

Các bước xây dựng luồng đổi/trả

  • Xác thực danh tính khách với đơn hàng.
  • Kiểm tra điều kiện chính sách (thời hạn, tình trạng hàng).
  • Áp guardrail giá trị (ngưỡng tự động vs. cần người duyệt).
  • Thực hiện hành động + ghi audit log.
  • Leo thang cho người khi vượt ngưỡng hoặc bất thường.

Bước 1 — Xác thực

def verify_owner(order_id, phone_or_email):
    order = get_order(order_id)
    return order and order["contact"] == phone_or_email

Không xác thực = bất kỳ ai có mã đơn cũng hủy/đổi được đơn người khác.

Bước 2 & 3 — Chính sách + guardrail

REFUND_AUTO_LIMIT = 500000  # tự động tối đa 500k

def can_return(order):
    if days_since(order["delivered_at"]) > 7:
        return False, "Quá hạn đổi trả 7 ngày"
    if order["status"] in ("refunded", "cancelled"):
        return False, "Đơn đã xử lý trước đó"
    return True, "OK"

def refund(order, amount):
    if amount > REFUND_AUTO_LIMIT:
        return escalate(order, amount)  # chuyển người duyệt
    do_refund(order, amount)
    audit_log("refund", order["id"], amount)

Bước 4 — Audit log

Mỗi hành động ghi phải log: ai (agent/khách), làm gì, đơn nào, giá trị, thời điểm. Đây là bằng chứng khi có tranh chấp.

Khung tư duy: "3 lớp phòng thủ"

  • Xác thực — đúng người mới được thao tác.
  • Điều kiện — đúng chính sách mới cho phép (thời hạn, trạng thái).
  • Ngưỡng + con người — dưới ngưỡng thì tự động, trên ngưỡng thì người duyệt.
Mọi hành động ghi phải xuyên qua đủ 3 lớp.

Checklist an toàn hành động ghi

  • [ ] Có xác thực khách sở hữu đơn trước mọi thao tác?
  • [ ] Có kiểm tra thời hạn + trạng thái đơn theo chính sách?
  • [ ] Có ngưỡng giá trị tự động, trên ngưỡng thì escalate?
  • [ ] Có audit log đầy đủ cho mỗi hành động?
  • [ ] Có chặn thao tác lặp (double refund) bằng idempotency key?
  • [ ] Có thông báo rõ cho khách kết quả cuối cùng?

Sai lầm thường gặp

  • Không xác thực chủ đơn. Lỗ hổng IDOR: chỉ cần đoán mã đơn là thao tác được đơn người khác.
  • Không có ngưỡng hoàn tiền. Agent tự hoàn số lớn khi bị khách "lừa prompt" (prompt injection) — mất tiền thật.
  • Thiếu idempotency. Khách bấm/nhắn 2 lần → hoàn tiền 2 lần. Dùng khóa chống lặp theo đơn.
  • Không ghi audit log. Khi có khiếu nại, không truy được ai làm gì, không thể phân xử.
  • Bỏ qua escalation. Ca phức tạp (hàng hỏng, tranh chấp) cần người; ép agent tự quyết sẽ sai.
  • Tin lời khách vô điều kiện. "Shop hứa hoàn full mà" — phải kiểm tra hệ thống, không hành động chỉ vì khách nói.
Bài 7 sẽ khép vòng vận hành: agent theo dõi và cảnh báo tồn kho, chủ động thay vì bị động.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi