Cách vẽ sơ đồ use case website bán hàng từng bước

Để vẽ sơ đồ use case cho website bán hàng, trước tiên cần xác định ranh giới hệ thống, các tác nhân tham gia và nhóm chức năng mà từng tác nhân được phép sử dụng. Actor thường gồm khách truy cập, khách hàng đã đăng nhập, quản trị viên, nhân viên bán hàng, chăm sóc khách hàng cùng các hệ thống ngoài như cổng thanh toán, đơn vị vận chuyển, email, SMS, CRM và nền tảng quảng cáo.

Tiếp theo, liệt kê các use case theo hành trình thực tế: tìm kiếm, lọc, xem và so sánh sản phẩm; thêm giỏ hàng, áp mã giảm giá, đặt hàng, thanh toán; theo dõi đơn, đổi trả, bảo hành và đánh giá. Ở phía quản trị là quản lý sản phẩm, biến thể, tồn kho, đơn hàng, khách hàng, nội dung, khuyến mãi, phân quyền và báo cáo.

Sau khi nhóm chức năng, đặt toàn bộ use case bên trong system boundary, còn actor nằm bên ngoài rồi nối bằng quan hệ association. Những chức năng luôn được dùng chung có thể biểu diễn bằng include, còn bước chỉ phát sinh theo điều kiện như thanh toán online, OTP hoặc hoàn tiền nên dùng extend.

Cuối cùng, cần rà soát lại quyền hạn, điểm tích hợp, chức năng trùng lặp và phạm vi dự án. Sơ đồ hoàn chỉnh sẽ trở thành bản đồ chức năng chung cho chủ shop, UX/UI, lập trình, kiểm thử, SEO và marketing trước khi phát triển luồng chi tiết, database và giao diện.

Sơ đồ use case website bán hàng mô tả ai dùng hệ thống và dùng để làm gì?

Sơ đồ use case website bán hàng mô tả tổng thể mối quan hệ giữa các tác nhân như khách hàng, quản trị viên, hệ thống thanh toán, đơn vị vận chuyển… với các chức năng cốt lõi mà website cung cấp. Thông qua đó, có thể thấy rõ ai sử dụng hệ thống, sử dụng chức năng nào và các điểm tích hợp kỹ thuật quan trọng. Ở góc độ phân tích yêu cầu, sơ đồ này giúp xác định phạm vi chức năng, phân nhóm use case theo hành trình mua sắm, quản lý đơn hàng, quản trị nội dung, cũng như các luồng trao đổi dữ liệu với hệ thống bên ngoài. Nhờ tính trực quan, sơ đồ use case trở thành “bản đồ chức năng” chung cho phân tích nghiệp vụ, thiết kế, lập trình, SEO và marketing. Khi triển khai thiết kế website, sơ đồ use case giúp đội ngũ xác định rõ nhóm người dùng, quyền truy cập và chức năng cần phát triển. Cách tiếp cận này hạn chế bỏ sót yêu cầu, giảm sửa đổi trong quá trình lập trình và bảo đảm website vận hành đúng mục tiêu kinh doanh.

Use case diagram thể hiện tác nhân, chức năng và ranh giới hệ thống website bán hàng

Sơ đồ use case website bán hàng là một biểu đồ UML mô tả mối quan hệ giữa tác nhân sử dụng hệ thống (actor) và các chức năng mà hệ thống cung cấp (use case) trong phạm vi một ranh giới hệ thống (system boundary) rõ ràng. Đối với website bán hàng, sơ đồ này trả lời hai câu hỏi cốt lõi: ai sử dụng website và sử dụng để làm gì. Thay vì đi sâu vào chi tiết giao diện hay cấu trúc database, sơ đồ use case tập trung vào hành vi ở mức nghiệp vụ, giúp đội ngũ hiểu được website cần hỗ trợ những luồng công việc nào cho khách hàng, quản trị viên và các hệ thống tích hợp.

Ở mức chuyên sâu hơn, mỗi actor trong sơ đồ use case không chỉ là một “người dùng” chung chung mà đại diện cho một vai trò nghiệp vụ với mục tiêu, quyền hạn và ràng buộc riêng. Ví dụ, “Khách hàng chưa đăng nhập” có tập chức năng khác với “Khách hàng thành viên”, “Nhân viên chăm sóc khách hàng” khác với “Quản trị viên hệ thống”. Việc phân tách rõ các actor này giúp mô hình hóa chính xác hơn các kịch bản sử dụng, phân quyền và bảo mật.

Ranh giới hệ thống (system boundary) trong sơ đồ use case website bán hàng cũng cần được xác định một cách tường minh: đâu là chức năng nằm bên trong website, đâu là chức năng thuộc về các hệ thống bên ngoài như cổng thanh toán, đơn vị vận chuyển, CRM, hệ thống kế toán. Các hệ thống bên ngoài này thường được mô hình hóa như các actor kỹ thuật (external system actor), ví dụ: “Cổng thanh toán”, “Hệ thống vận chuyển”, “Hệ thống email/SMS”, “Nền tảng quảng cáo”. Nhờ đó, sơ đồ use case thể hiện rõ các điểm tích hợp và luồng trao đổi thông tin giữa website và môi trường xung quanh.

Trong bối cảnh thương mại điện tử, sơ đồ use case thường bao gồm các nhóm chức năng như: tìm kiếm và khám phá sản phẩm, quản lý giỏ hàng, đặt hàng và thanh toán, quản lý đơn hàng, quản trị nội dung và sản phẩm, cùng với các tương tác với hệ thống thanh toán, vận chuyển, email, SMS, CRM, nền tảng quảng cáo. Ở mức chi tiết hơn, mỗi nhóm chức năng có thể được phân rã thành nhiều use case con, ví dụ:

• Tìm kiếm và khám phá sản phẩm
  • Xem danh sách sản phẩm theo danh mục
  • Lọc sản phẩm theo thuộc tính (giá, thương hiệu, kích thước, màu sắc…)
  • Tìm kiếm sản phẩm theo từ khóa
  • Xem chi tiết sản phẩm, đánh giá, câu hỏi & trả lời
  • Xem sản phẩm liên quan, gợi ý cá nhân hóa
• Quản lý giỏ hàng
  • Thêm sản phẩm vào giỏ
  • Cập nhật số lượng, thuộc tính sản phẩm trong giỏ
  • Xóa sản phẩm khỏi giỏ
  • Lưu giỏ hàng cho lần truy cập sau
  • Áp dụng mã giảm giá, voucher, điểm thưởng
• Đặt hàng và thanh toán
  • Nhập thông tin giao hàng, lựa chọn phương thức vận chuyển
  • Lựa chọn phương thức thanh toán (COD, thẻ, ví điện tử…)
  • Thanh toán trực tuyến qua cổng thanh toán
  • Xác nhận đơn hàng, gửi email/SMS thông báo
  • Xử lý trạng thái thanh toán thành công/thất bại
• Quản lý đơn hàng
  • Khách hàng xem lịch sử đơn hàng, trạng thái giao hàng
  • Yêu cầu hủy đơn, đổi trả, hoàn tiền
  • Nhân viên xử lý yêu cầu đổi trả, cập nhật trạng thái
  • Đồng bộ trạng thái giao hàng với đơn vị vận chuyển
• Quản trị nội dung và sản phẩm
  • Quản lý danh mục, thuộc tính sản phẩm
  • Thêm/sửa/xóa sản phẩm, quản lý tồn kho
  • Quản lý nội dung trang, banner, landing page
  • Quản lý chương trình khuyến mãi, mã giảm giá
  • Quản lý tài khoản người dùng, phân quyền

Nhờ đó, sơ đồ use case trở thành bản đồ tổng quan cho toàn bộ hành trình sử dụng website từ nhiều góc nhìn khác nhau, đồng thời vẫn đủ chi tiết để truy vết từng chức năng về actor tương ứng, mục tiêu nghiệp vụ và các hệ thống liên quan. Khi cần, mỗi use case trong sơ đồ có thể được đặc tả sâu hơn bằng tài liệu Use Case Specification (mô tả tiền điều kiện, hậu điều kiện, luồng chính, luồng phụ, ngoại lệ), nhưng sơ đồ vẫn giữ vai trò là lớp nhìn tổng thể.

Sơ đồ use case giúp đội thiết kế, lập trình, SEO, marketing và chủ shop thống nhất yêu cầu

Trong một dự án website bán hàng, mỗi bên liên quan thường có góc nhìn và ưu tiên khác nhau: chủ shop quan tâm doanh thu và quy trình vận hành, lập trình viên chú ý kiến trúc và kỹ thuật, đội SEO tập trung vào cấu trúc nội dung và crawl, đội marketing chú ý tracking và chuyển đổi. Sơ đồ use case đóng vai trò như một ngôn ngữ chung giúp tất cả các bên cùng nhìn vào một bức tranh tổng thể về chức năng hệ thống, tránh hiểu sai hoặc bỏ sót yêu cầu quan trọng. Các nghiên cứu về kỹ nghệ yêu cầu xác định use case là công cụ quan trọng để chuyển nhu cầu của các bên liên quan thành mô tả chức năng có cấu trúc, trong đó mỗi trường hợp sử dụng liên kết một actor với mục tiêu và kết quả nghiệp vụ cụ thể. Nhờ sử dụng hệ thống thuật ngữ thống nhất, use case có thể giảm khác biệt trong cách hiểu giữa khách hàng, chuyên gia nghiệp vụ, nhà thiết kế và lập trình viên, nhất là trong các dự án có nhiều nhóm tham gia. Tuy nhiên, hiệu quả này phụ thuộc vào việc actor, mục tiêu, điều kiện và phạm vi hệ thống được mô tả nhất quán, tránh những tên chức năng chung chung hoặc thiên về giao diện kỹ thuật (El-Attar & Miller, 2015).

Ở mức chuyên môn sâu hơn, sơ đồ use case còn hỗ trợ:

• Phân tích phạm vi (scope) dự án: mỗi use case tương ứng với một “đơn vị giá trị” mà hệ thống mang lại cho actor. Bằng cách liệt kê và nhóm các use case, đội ngũ có thể xác định phạm vi phiên bản MVP, các chức năng ưu tiên cao, trung bình, thấp, từ đó lập kế hoạch phát triển theo giai đoạn.
• Ước lượng và lập kế hoạch kỹ thuật: lập trình viên và kiến trúc sư hệ thống có thể dựa trên sơ đồ use case để ước lượng khối lượng công việc, xác định các module, service, API cần thiết, cũng như các điểm tích hợp với hệ thống bên ngoài.
• Thiết kế trải nghiệm người dùng (UX): chuyên gia UX có thể chuyển từng use case thành user flow, wireframe, prototype. Việc biết rõ actor nào thực hiện use case nào giúp thiết kế giao diện phù hợp với ngữ cảnh sử dụng, mức độ phức tạp và kỳ vọng của người dùng.
• Thiết kế nội dung và SEO: đội SEO và content mapping các use case sang cấu trúc URL, schema dữ liệu, nội dung trang, breadcrumb, internal link. Ví dụ, use case “Tìm kiếm sản phẩm theo từ khóa” liên quan trực tiếp đến cấu trúc trang kết quả tìm kiếm, tối ưu title, meta, canonical, xử lý faceted navigation.
• Marketing và đo lường hiệu quả: đội marketing xác định các điểm chạm (touchpoint) quan trọng trong từng use case để gắn tracking (event, conversion, funnel), thiết lập kịch bản remarketing, email automation. Use case “Bỏ giỏ hàng chưa thanh toán” là cơ sở để xây dựng chiến dịch nhắc nhở, ưu đãi.
• Quản lý vận hành và chăm sóc khách hàng: chủ shop và bộ phận vận hành kiểm tra xem các nhu cầu như quản lý tồn kho, xử lý đổi trả, ghi nhận khiếu nại, phân loại khách hàng, chương trình khách hàng thân thiết đã được mô hình hóa thành use case rõ ràng hay chưa.

Khi use case được vẽ rõ ràng, từng nhóm có thể dễ dàng xác định phần việc của mình: thiết kế UI/UX dựa trên các luồng use case chính, lập trình chia module theo nhóm use case, SEO mapping từ use case sang cấu trúc URL và nội dung, marketing xác định điểm chạm để gắn tracking và tối ưu chuyển đổi. Chủ shop cũng có thể kiểm tra xem các nhu cầu thực tế như quản lý tồn kho, xử lý đổi trả, chăm sóc khách hàng, remarketing đã được thể hiện đầy đủ trong sơ đồ hay chưa.

Ở góc độ quản lý yêu cầu (requirements management), sơ đồ use case còn là cơ sở để:

• Liên kết giữa yêu cầu nghiệp vụ (business requirement) và yêu cầu chức năng (functional requirement).
• Xây dựng ma trận truy vết (traceability matrix) từ use case sang test case, đảm bảo mỗi chức năng quan trọng đều được kiểm thử.
• Giao tiếp với các bên không chuyên kỹ thuật bằng ngôn ngữ trực quan, dễ hiểu, hạn chế tranh luận mơ hồ.

Ma trận truy vết không chỉ xác nhận một chức năng đã có test case mà còn giúp đánh giá tác động dây chuyền khi yêu cầu, quy trình nghiệp vụ hoặc thành phần phần mềm thay đổi. Ramesh và Jarke chỉ ra rằng truy vết yêu cầu cần bao phủ mối liên hệ từ nguồn phát sinh yêu cầu đến mô hình phân tích, thiết kế, mã nguồn và sản phẩm triển khai (Ramesh & Jarke, 2001). Nghiên cứu thực nghiệm cũng cho thấy tính đầy đủ của liên kết truy vết có quan hệ tích cực với khả năng ngăn ngừa lỗi phần mềm (Rempel & Mäder, 2017). Vì vậy, mỗi use case quan trọng nên có mã định danh và được liên kết với tiêu chí chấp nhận, module, API, dữ liệu cùng các trường hợp kiểm thử tương ứng.

Use case website bán hàng khác sơ đồ quy trình mua hàng và sơ đồ database như thế nào?

Sơ đồ use case thường bị nhầm lẫn với sơ đồ quy trình mua hàng (process flow) hoặc sơ đồ database (ERD). Điểm khác biệt cốt lõi nằm ở mức độ trừu tượng và góc nhìn. Use case mô tả ai tương tác với hệ thống và tương tác để làm gì, trong khi sơ đồ quy trình mô tả trình tự các bước chi tiết và sơ đồ database mô tả cấu trúc dữ liệu. Use case không đi sâu vào thứ tự bước cụ thể, điều kiện rẽ nhánh chi tiết hay bảng dữ liệu, mà chỉ tập trung vào các chức năng có ý nghĩa nghiệp vụ và mối liên hệ giữa actor và chức năng. Việc duy trì nhiều lớp mô hình là cần thiết vì không một loại sơ đồ riêng lẻ nào thể hiện đầy đủ mục tiêu, trình tự xử lý và cấu trúc dữ liệu của hệ thống. Use case lưu giữ mục tiêu của actor; BPMN hoặc activity diagram làm rõ thứ tự, điều kiện và trách nhiệm thực hiện; ERD mô tả dữ liệu được tạo, lưu trữ và liên kết. Các nghiên cứu về truy vết mô hình cho thấy liên kết giữa nhiều mức trừu tượng giúp kiểm tra tính nhất quán và phát hiện khoảng trống yêu cầu (Wang et al., 2020). Chẳng hạn, bước hoàn tiền trong quy trình phải truy được về use case đổi trả, đồng thời liên kết với các thực

Ở mức chuyên sâu, có thể phân biệt ba loại sơ đồ này theo một số tiêu chí:

• Góc nhìn
  • Use case: góc nhìn từ phía người dùng/vai trò nghiệp vụ, tập trung vào mục tiêu họ muốn đạt được khi tương tác với hệ thống.
  • Process flow/BPMN: góc nhìn quy trình, mô tả luồng công việc chi tiết, bao gồm cả bước thủ công, bước ngoài hệ thống.
  • ERD: góc nhìn dữ liệu, mô tả các thực thể (entity), thuộc tính và mối quan hệ giữa chúng.
• Mức độ chi tiết
  • Use case: mức khái quát trung bình, tập trung vào “chức năng” và “kết quả” hơn là từng bước thao tác.
  • Process flow: mức chi tiết cao về trình tự, điều kiện rẽ nhánh, vòng lặp, điểm bắt đầu/kết thúc.
  • ERD: chi tiết về cấu trúc bảng, khóa chính, khóa ngoại, ràng buộc dữ liệu.
• Mục đích sử dụng
  • Use case: phân tích yêu cầu, giao tiếp với stakeholder, xác định phạm vi chức năng.
  • Process flow: tối ưu quy trình, phân tích bottleneck, thiết kế nghiệp vụ chi tiết.
  • ERD: thiết kế cơ sở dữ liệu, tối ưu truy vấn, đảm bảo toàn vẹn dữ liệu.

Trong thực tế triển khai, sơ đồ use case thường được dùng ở giai đoạn phân tích yêu cầu, sau đó mới chi tiết hóa thành user flow, wireframe, BPMN, ERD. Nếu cố gắng đưa quá nhiều chi tiết quy trình hoặc cấu trúc dữ liệu vào sơ đồ use case, biểu đồ sẽ trở nên rối rắm, khó đọc và mất đi giá trị là một bản đồ tổng quan. Ngược lại, nếu chỉ dùng sơ đồ quy trình hoặc database mà bỏ qua use case, đội ngũ dễ bị thiếu góc nhìn về ai là người dùng chính và họ thực sự cần chức năng gì.

Đối với website bán hàng, cách tiếp cận hiệu quả thường là:

• Bước 1: Xây dựng sơ đồ use case tổng thể, xác định actor, nhóm chức năng chính, ranh giới hệ thống.
• Bước 2: Chọn các use case quan trọng (ví dụ: Đặt hàng, Thanh toán, Đổi trả) để đặc tả chi tiết và vẽ process flow/BPMN cho từng use case.
• Bước 3: Từ các use case và process flow, trích xuất yêu cầu dữ liệu, thiết kế ERD tương ứng (bảng Sản phẩm, Đơn hàng, Khách hàng, Thanh toán, Vận chuyển…).
• Bước 4: Liên tục đối chiếu ba loại sơ đồ để đảm bảo tính nhất quán: mỗi bước trong process flow phải thuộc về một use case, và mỗi dữ liệu quan trọng trong use case phải có thực thể tương ứng trong ERD.

Cách phân tầng này giúp giữ cho sơ đồ use case website bán hàng luôn ở đúng “độ cao” cần thiết: đủ trừu tượng để dễ hiểu với mọi bên liên quan, nhưng vẫn là nền tảng vững chắc để phát triển chi tiết sang quy trình, giao diện và cơ sở dữ liệu.

Thành phần cần có trong sơ đồ use case website bán hàng

Trong sơ đồ use case website bán hàng, cần mô tả đầy đủ các actor như khách truy cập, khách hàng, quản trị viên, nhân viên nội bộ và các hệ thống bên ngoài. Mỗi actor thể hiện mục tiêu, quyền hạn riêng khi tương tác với hệ thống, hỗ trợ thiết kế phân quyền và bảo mật rõ ràng. Các use case phải đại diện cho chuỗi hành động có ý nghĩa: từ xem, tìm kiếm, so sánh, mua hàng, thanh toán đến quản trị, marketing và phân tích dữ liệu. Tất cả được đặt trong system boundary để xác định phạm vi chức năng thuộc website, phân biệt với phần do hệ thống tích hợp xử lý. Cuối cùng, quan hệ association, include, extend giúp thể hiện mức độ phụ thuộc, tái sử dụng và các nhánh điều kiện giữa các chức năng.

Actor đại diện cho khách hàng, quản trị viên, nhân viên bán hàng và hệ thống bên ngoài

Trong phân tích use case, actor được hiểu là một vai trò (role) tương tác với hệ thống, không gắn với một cá nhân cụ thể. Một người thật có thể đảm nhiệm nhiều actor khác nhau trong các ngữ cảnh khác nhau, và ngược lại, một actor có thể đại diện cho cả một nhóm người hoặc một hệ thống phần mềm. Điều quan trọng là actor phải thể hiện được mục tiêu và quyền hạn khi làm việc với website bán hàng. Cách xác định actor theo vai trò phù hợp với mô hình kiểm soát truy cập dựa trên vai trò, trong đó quyền hệ thống được tổ chức thành các nhóm nghiệp vụ thay vì cấp riêng lẻ cho từng tài khoản. Mỗi actor phải gắn với phạm vi trách nhiệm và tập quyền cần thiết để hoàn thành nhiệm vụ, chẳng hạn nhân viên kho được điều chỉnh tồn kho, nhân viên chăm sóc khách hàng được tra cứu đơn và kế toán được đối soát thanh toán. Cách tiếp cận này làm giảm số lượng quan hệ cấp quyền phải quản lý và hỗ trợ kiểm toán hoạt động người dùng (Sandhu et al., 1996). Các ràng buộc vai trò còn giúp ngăn một cá nhân đồng thời tạo, phê duyệt và hoàn tất cùng một giao dịch nhạy cảm (Ahn & Sandhu, 2000).

Đối với website bán hàng, có thể phân loại actor chi tiết hơn theo nhóm chức năng và mức độ quyền hạn:

• Khách truy cập (Visitor): người dùng chưa đăng nhập, chỉ có thể:
  • Xem danh sách sản phẩm, chi tiết sản phẩm, bài viết blog, FAQ
  • Tìm kiếm, lọc, sắp xếp sản phẩm
  • Xem đánh giá, bình luận (nếu được phép công khai)
  • Thêm sản phẩm vào giỏ tạm (session-based cart)
• Khách hàng (Customer): đã đăng ký và đăng nhập, ngoài các quyền của khách truy cập còn có:
  • Quản lý hồ sơ cá nhân, địa chỉ giao hàng, phương thức thanh toán mặc định
  • Đặt hàng, thanh toán, theo dõi trạng thái đơn hàng
  • Viết đánh giá, bình luận, gửi yêu cầu hỗ trợ
  • Xem lịch sử mua hàng, tích điểm, sử dụng voucher, mã giảm giá
• Quản trị viên (Admin): có quyền cao nhất trong hệ thống:
  • Quản lý người dùng, phân quyền cho nhân viên
  • Cấu hình hệ thống, cài đặt thanh toán, vận chuyển, thuế, ngôn ngữ
  • Quản lý danh mục sản phẩm, thương hiệu, thuộc tính sản phẩm
  • Thiết lập chính sách khuyến mãi, chương trình khách hàng thân thiết
  • Giám sát log hệ thống, phân tích bảo mật, sao lưu và khôi phục dữ liệu
• Nhân viên bán hàng (Sales Staff):
  • Tạo đơn hàng hộ khách (qua điện thoại, chat, tại cửa hàng)
  • Chỉnh sửa đơn hàng trong phạm vi cho phép (thay đổi địa chỉ, ghi chú)
  • Tư vấn sản phẩm, gợi ý upsell, cross-sell dựa trên dữ liệu khách hàng
  • Kiểm tra tồn kho, tình trạng nhập hàng, dự kiến giao hàng
• Nhân viên chăm sóc khách hàng (CS Staff):
  • Tiếp nhận và xử lý khiếu nại, yêu cầu đổi trả, hoàn tiền
  • Tra cứu lịch sử tương tác, lịch sử mua hàng của khách
  • Gửi thông báo, email, SMS chăm sóc sau bán
  • Ghi nhận ticket hỗ trợ, phân loại mức độ ưu tiên
• Các hệ thống bên ngoài (External Systems):
  • Cổng thanh toán (Payment Gateway): xử lý giao dịch thẻ, ví điện tử, chuyển khoản
  • Đơn vị vận chuyển (Shipping/Logistics): nhận yêu cầu giao hàng, trả về mã vận đơn, trạng thái giao
  • Hệ thống email, SMS: gửi thông báo đơn hàng, OTP, marketing campaign
  • CRM: đồng bộ thông tin khách hàng, lịch sử tương tác, phân khúc khách
  • Nền tảng quảng cáo, tracking, mạng xã hội: nhận dữ liệu sự kiện (event), chuyển đổi (conversion)

Actor được vẽ dưới dạng hình người hoặc biểu tượng tương đương, đặt bên ngoài ranh giới hệ thống. Mỗi actor đại diện cho một tập hợp use case có chung mục tiêu và quyền hạn. Việc phân tách rõ ràng actor giúp:

• Tránh nhầm lẫn giữa chức năng dành cho khách hàng và chức năng nội bộ
• Thiết kế phân quyền (authorization) và xác thực (authentication) rõ ràng
• Dễ dàng mở rộng hệ thống khi thêm vai trò mới (ví dụ: đối tác, nhà cung cấp)
• Hỗ trợ phân tích bảo mật: actor nào được phép truy cập dữ liệu nào, theo cơ chế nào

Use case đại diện cho hành động như xem sản phẩm, thêm giỏ hàng, đặt hàng và thanh toán

Use case là một chức năng mang lại giá trị hoàn chỉnh cho actor, được mô tả từ góc nhìn của actor, không phải từ góc nhìn kỹ thuật hay giao diện. Tên use case nên là một cụm động từ thể hiện mục tiêu, ví dụ: “Xem chi tiết sản phẩm”, “Tìm kiếm sản phẩm”, “Đặt hàng”, “Thanh toán online”, “Quản lý tồn kho”, “Xuất báo cáo doanh thu”.

Use case không phải là một “màn hình” hay một “nút bấm” đơn lẻ, mà là một chuỗi tương tác có ý nghĩa dẫn đến kết quả cụ thể. Mỗi use case nên có:

• Mục tiêu (goal) rõ ràng của actor
• Điều kiện tiên quyết (precondition), ví dụ: “Khách hàng đã đăng nhập”
• Kết quả sau cùng (postcondition), ví dụ: “Đơn hàng được tạo ở trạng thái Chờ thanh toán”
• Các luồng chính (main flow) và luồng phụ (alternative flow) nếu cần (mô tả chi tiết trong tài liệu kèm sơ đồ)

Trong website bán hàng, có thể nhóm use case theo từng loại actor:

• Nhóm use case cho khách truy cập/khách hàng:
  • Tìm kiếm, khám phá, so sánh sản phẩm:
    • “Tìm kiếm sản phẩm theo từ khóa”
    • “Lọc sản phẩm theo thuộc tính” (giá, thương hiệu, kích thước, màu sắc)
    • “So sánh nhiều sản phẩm”
  • Mua hàng:
    • “Xem chi tiết sản phẩm”
    • “Thêm sản phẩm vào giỏ hàng”
    • “Cập nhật giỏ hàng” (thay đổi số lượng, xóa sản phẩm)
    • “Đặt hàng” (checkout)
    • “Thanh toán online” hoặc “Chọn thanh toán khi nhận hàng”
  • Sau bán:
    • “Theo dõi trạng thái đơn hàng”
    • “Yêu cầu hủy đơn / đổi trả”
    • “Đánh giá sản phẩm”
    • “Gửi yêu cầu hỗ trợ”
• Nhóm use case cho quản trị viên:
  • “Quản lý sản phẩm” (thêm, sửa, xóa, ẩn/hiện, quản lý tồn kho)
  • “Quản lý đơn hàng” (xác nhận, cập nhật trạng thái, xử lý hoàn tiền)
  • “Quản lý khách hàng” (xem hồ sơ, khóa tài khoản, phân nhóm)
  • “Quản lý nội dung” (banner, trang tĩnh, blog, FAQ)
  • “Quản lý khuyến mãi, mã giảm giá, voucher”
  • “Cấu hình hệ thống” (cổng thanh toán, vận chuyển, thuế, SEO cơ bản)
  • “Xuất báo cáo doanh thu, lợi nhuận, tồn kho, hiệu quả chiến dịch”
• Nhóm use case cho marketing, SEO, tracking:
  • “Cấu hình mã tracking” (Google Analytics, Facebook Pixel, v.v.)
  • “Thiết lập chiến dịch khuyến mãi theo kênh”
  • “Theo dõi hiệu quả chiến dịch, nguồn traffic, tỉ lệ chuyển đổi”
  • “Thiết lập quy tắc chống click tặc quảng cáo” (nếu hệ thống hỗ trợ)

Các use case liên quan đến marketing, SEO, tracking, chống click tặc nên được mô tả rõ nếu mục tiêu của dự án là vận hành và tối ưu dài hạn. Điều này giúp đội ngũ phát triển hiểu được các yêu cầu về đo lường, phân tích dữ liệu và tối ưu chi phí quảng cáo, không chỉ dừng lại ở chức năng bán hàng cơ bản.

System boundary xác định phạm vi chức năng thuộc website bán hàng

System boundary là đường bao (thường là một hình chữ nhật) chứa toàn bộ các use case thuộc về hệ thống đang phân tích. Mọi actor, hệ thống bên ngoài được đặt bên ngoài đường bao này. Việc xác định ranh giới hệ thống là bước quan trọng để:

• Phân biệt chức năng nào do website chịu trách nhiệm xử lý
• Chức năng nào được ủy thác cho hệ thống tích hợp (payment gateway, logistics, CRM)
• Chức năng nào nằm ngoài phạm vi dự án hiện tại (out of scope)

Đối với website bán hàng, system boundary thường bao gồm:

• Frontend khách hàng:
  • Các trang danh mục, chi tiết sản phẩm, giỏ hàng, thanh toán
  • Trang tài khoản, lịch sử đơn hàng, đánh giá, hỗ trợ
  • Các trang nội dung marketing, blog, landing page
• Backend quản trị:
  • Module quản lý sản phẩm, đơn hàng, khách hàng, nội dung
  • Module quản lý khuyến mãi, voucher, chương trình tích điểm
  • Module phân quyền, quản lý người dùng nội bộ, log hoạt động
• Các module marketing, SEO, tracking, chống click tặc (nếu được xây dựng trong cùng hệ thống):
  • Quản lý mã tracking, cấu hình event gửi sang nền tảng quảng cáo
  • Quản lý chiến dịch, banner, popup, A/B testing
  • Các thuật toán phát hiện hành vi bất thường (click tặc, bot)

Các cổng thanh toán, đơn vị vận chuyển, nền tảng email, SMS, CRM, quảng cáo thường được mô hình hóa là hệ thống bên ngoài. Website bán hàng tương tác với chúng thông qua API, webhook hoặc các giao thức tích hợp khác. Trong sơ đồ use case, các chức năng như “Xử lý thanh toán thẻ” có thể được chia thành:

• Use case bên trong system boundary: “Gửi yêu cầu thanh toán đến cổng thanh toán”, “Nhận kết quả thanh toán”
• Hành vi bên ngoài: việc xác thực thẻ, xử lý giao dịch thực tế do cổng thanh toán đảm nhiệm

Việc vẽ system boundary rõ ràng giúp đội dự án thống nhất phạm vi công việc, tránh hiểu nhầm rằng website phải tự xử lý những nghiệp vụ vốn thuộc về hệ thống chuyên biệt (ví dụ: tính phí vận chuyển chi tiết theo vùng, theo khối lượng có thể do API của đơn vị vận chuyển trả về).

Quan hệ include, extend và association thể hiện mức độ phụ thuộc giữa các chức năng

Trong sơ đồ use case, các loại quan hệ chính gồm association, include và extend. Việc sử dụng đúng các quan hệ này giúp sơ đồ rõ ràng, tránh trùng lặp và thể hiện được các nhánh điều kiện trong quy trình nghiệp vụ.

Association là đường nối đơn giản giữa actor và use case, thể hiện actor có thể khởi tạo hoặc tham gia vào use case đó. Một actor có thể liên kết với nhiều use case, và một use case có thể được nhiều actor sử dụng. Ví dụ:

• Actor “Khách hàng” — association — use case “Đặt hàng”
• Actor “Nhân viên chăm sóc khách hàng” — association — use case “Cập nhật trạng thái đơn hàng”

Include thể hiện một use case luôn bao gồm một use case khác như một phần bắt buộc trong luồng xử lý. Use case được include thường là một chức năng chung, được tái sử dụng ở nhiều nơi. Ví dụ trong website bán hàng:

• Use case “Đặt hàng” include “Xác thực thông tin khách hàng”:
  • Dù khách là người mới hay đã đăng nhập, hệ thống vẫn phải kiểm tra tính hợp lệ của địa chỉ, số điện thoại, email
• Use case “Thanh toán online” include “Tính tổng tiền đơn hàng”:
  • Trước khi gửi yêu cầu sang cổng thanh toán, hệ thống phải tính toán chính xác tổng tiền, thuế, phí vận chuyển, giảm giá
• Use case “Áp dụng mã giảm giá” có thể được include trong nhiều use case:
  • “Đặt hàng” include “Áp dụng mã giảm giá”
  • “Tạo đơn hàng hộ khách” (cho nhân viên bán hàng) cũng include “Áp dụng mã giảm giá”

Extend thể hiện một use case mở rộng (extension) được thực hiện có điều kiện, dựa trên một điểm mở rộng (extension point) trong use case gốc. Use case mở rộng không phải lúc nào cũng xảy ra. Ví dụ:

• Use case “Thanh toán online” extend “Đặt hàng”:
  • Chỉ khi khách chọn phương thức thanh toán online thì luồng mở rộng này mới được kích hoạt
• Use case “Xác minh OTP” extend “Đăng nhập”:
  • Chỉ áp dụng khi tài khoản bật xác thực hai lớp (2FA)
• Use case “Gửi email xác nhận đơn hàng” extend “Đặt hàng thành công”:
  • Có thể cấu hình bật/tắt hoặc thay đổi kênh thông báo (email, SMS, push notification)

Việc tách các chức năng chung như “Đăng nhập”, “Xác thực thông tin khách hàng”, “Gửi thông báo”, “Áp mã giảm giá” thành các use case riêng và sử dụng include giúp tránh lặp lại cùng một logic ở nhiều nơi trong sơ đồ. Đồng thời, sử dụng extend cho các nhánh điều kiện (nhiều phương thức thanh toán, nhiều kịch bản giao hàng, nhiều loại khuyến mãi) giúp sơ đồ dễ đọc, dễ bảo trì, phản ánh đúng sự phức tạp nghiệp vụ mà không làm rối luồng chính.

Xác định actor chính trong website bán hàng trước khi vẽ use case

Trong website bán hàng, cần phân loại rõ các actor để mô hình hóa use case một cách mạch lạc và dễ bảo trì. Nhóm người dùng chính gồm khách truy cập, khách hàng đã đăng nhập và quản trị viên nội bộ; mỗi nhóm gắn với một giai đoạn khác nhau trong hành trình khách hàng và mức độ truy cập dữ liệu tăng dần. Bên cạnh đó là các hệ thống bên ngoài như cổng thanh toán, đơn vị vận chuyển, email/SMS, CRM, nền tảng quảng cáo và mạng xã hội, đóng vai trò actor kỹ thuật tương tác hai chiều qua API. Việc xác định đúng actor, ranh giới hệ thống và quyền hạn giúp thiết kế phễu chuyển đổi, trải nghiệm người dùng, phân quyền bảo mật và luồng tích hợp một cách nhất quán và giảm rủi ro vận hành.

Khách truy cập tìm kiếm sản phẩm, xem danh mục, đọc bài tư vấn và đăng ký nhận ưu đãi

Khách truy cập (visitor) là actor đầu tiên cần xác định vì đây là nguồn traffic mới đến website và là điểm khởi đầu của toàn bộ phễu chuyển đổi. Họ chưa đăng nhập, thường chưa có lịch sử tương tác, có thể đến từ Google (SEO, Google Ads), mạng xã hội, quảng cáo hiển thị, referral hoặc direct. Việc mô hình hóa đúng actor này giúp đội ngũ phân tích nghiệp vụ hiểu rõ các luồng hành vi khám phá ban đầu và tối ưu hóa trải nghiệm trước khi người dùng trở thành lead hoặc khách hàng.

Các use case chính của khách truy cập thường bao phủ toàn bộ giai đoạn Awareness và Consideration trong hành trình khách hàng:

• Tìm kiếm sản phẩm: sử dụng thanh search, bộ lọc (filter), sắp xếp (sort), gợi ý tìm kiếm (search suggestion, autocomplete), tìm theo từ khóa, theo thuộc tính (giá, thương hiệu, kích thước, màu sắc, rating).
• Xem danh mục: duyệt category, sub-category, collection, tag; chuyển trang (pagination), xem dạng lưới/danh sách, áp dụng filter nâng cao (khoảng giá, tồn kho, khuyến mãi).
• Xem chi tiết sản phẩm: xem hình ảnh, video, mô tả chi tiết, thông số kỹ thuật, đánh giá, hỏi đáp, sản phẩm liên quan (related, upsell, cross-sell), giá sau khuyến mãi, phí vận chuyển ước tính.
• Đọc bài viết tư vấn: bài blog, cẩm nang, review, so sánh sản phẩm, hướng dẫn sử dụng; từ đó dẫn link sang trang sản phẩm hoặc landing page.
• Xem landing page khuyến mãi: trang campaign, flash sale, combo, voucher; có thể chứa countdown, điều kiện áp dụng, danh sách sản phẩm ưu đãi.
• Đăng ký nhận ưu đãi qua email hoặc SMS: form pop-up, form trong footer, form trong bài viết; có thể kèm checkbox đồng ý nhận marketing, đồng ý điều khoản.
• Thêm sản phẩm vào giỏ tạm: thêm vào cart khi chưa đăng nhập; hệ thống có thể lưu bằng cookie, local storage hoặc session ẩn danh.

Đối với actor này, sơ đồ use case cần thể hiện rõ các chức năng hỗ trợ khám phá sản phẩm và thu lead. Một số use case nên gắn trực tiếp với khách truy cập để thể hiện rõ mục tiêu chuyển đổi từ anonymous visitor sang identifiable lead:

• Đăng ký nhận bản tin (newsletter subscription): lưu email, số điện thoại, nguồn đăng ký (source), gắn tag hoặc segment ban đầu.
• Đăng ký nhận mã giảm giá lần đầu: sau khi nhập email/SMS, hệ thống sinh mã giảm giá (coupon) và gửi qua email/SMS, đồng thời ghi nhận lead vào CRM hoặc hệ thống email marketing.
• Tải ebook tư vấn: form thu thập thông tin (tên, email, ngành hàng quan tâm), sau đó gửi link tải ebook; đây là use case quan trọng để phân loại lead theo nhu cầu.

Trong sơ đồ use case, nên làm rõ ranh giới hệ thống (system boundary) giữa website và các hệ thống marketing phía sau. Khi khách truy cập thực hiện các use case thu lead, hệ thống có thể:

• Tạo bản ghi lead trong CRM hoặc email marketing.
• Gắn cookie hoặc ID ẩn danh để phục vụ remarketing.
• Gửi sự kiện (event) sang nền tảng quảng cáo để tối ưu chiến dịch.

Việc mô tả chi tiết các use case của khách truy cập giúp đội UX/UI thiết kế luồng điều hướng, vị trí form, pop-up, banner hợp lý; đồng thời giúp đội marketing xác định rõ các điểm chạm (touchpoint) để tối ưu tỉ lệ chuyển đổi từ traffic sang lead.

Khách hàng đăng nhập quản lý tài khoản, giỏ hàng, đơn hàng, địa chỉ và lịch sử mua

Khách hàng (customer) là actor đã có tài khoản và đăng nhập vào hệ thống. So với khách truy cập, họ đã có dữ liệu định danh (email, số điện thoại, ít nhất một đơn hàng hoặc thông tin profile). Các use case của khách hàng trải dài từ giai đoạn Consideration, Purchase đến Post-purchase, do đó mức độ phức tạp và yêu cầu bảo mật, toàn vẹn dữ liệu cao hơn.

Các use case chính của khách hàng bao gồm:

• Quản lý thông tin tài khoản: cập nhật họ tên, email, số điện thoại, mật khẩu, avatar; thiết lập bảo mật hai lớp (2FA) nếu có; quản lý đồng ý nhận marketing.
• Quản lý địa chỉ giao hàng: thêm/sửa/xóa địa chỉ, đánh dấu địa chỉ mặc định, lưu ghi chú giao hàng; có thể tích hợp auto-complete địa chỉ, mã bưu chính.
• Xem và cập nhật giỏ hàng: xem danh sách sản phẩm trong cart, thay đổi số lượng, xóa sản phẩm, áp dụng mã giảm giá, ước tính phí ship; đồng bộ giỏ hàng giữa nhiều thiết bị.
• Đặt hàng: chọn địa chỉ giao hàng, phương thức vận chuyển, phương thức thanh toán (COD, online), áp dụng voucher, xác nhận đơn; tạo đơn hàng trong hệ thống.
• Theo dõi trạng thái đơn hàng: xem trạng thái (chờ xác nhận, đang xử lý, đang giao, hoàn thành, hủy), xem mã vận đơn, tracking link.
• Xem lịch sử mua hàng: danh sách đơn hàng cũ, chi tiết từng đơn, tổng tiền, trạng thái thanh toán, link tải hóa đơn.
• Đánh giá sản phẩm: gửi rating, review, hình ảnh; có thể kèm tag “đã mua hàng” để tăng độ tin cậy.
• Tải hóa đơn: tải file PDF hóa đơn điện tử, xem thông tin xuất hóa đơn (cá nhân/doanh nghiệp).
• Quản lý điểm thưởng hoặc ví điện tử nội bộ (nếu có): xem số điểm hiện tại, lịch sử cộng/trừ điểm, quy đổi điểm; xem số dư ví, lịch sử giao dịch.

Trong sơ đồ use case, khách hàng thường được nối với các use case liên quan đến hậu mua hàng, phản ánh các quy trình dịch vụ sau bán:

• Yêu cầu đổi trả: chọn đơn hàng, chọn sản phẩm cần đổi/trả, lý do, hình thức hoàn tiền; hệ thống tạo yêu cầu RMA (Return Merchandise Authorization).
• Gửi yêu cầu bảo hành: chọn sản phẩm, nhập thông tin lỗi, thời gian mua; hệ thống ghi nhận ticket bảo hành.
• Gửi yêu cầu hỗ trợ: tạo ticket hỗ trợ, chat với CSKH, gửi file đính kèm; theo dõi trạng thái xử lý.
• Nhận thông báo trạng thái đơn hàng: cấu hình nhận thông báo qua email, SMS, push notification; xem log thông báo đã gửi.

Việc phân biệt rõ khách truy cập và khách hàng trong sơ đồ use case giúp:

• Thiết kế hệ thống phân quyền (authorization) rõ ràng: use case nào chỉ cho phép khi đã đăng nhập, use case nào mở cho mọi người.
• Xây dựng trải nghiệm cá nhân hóa: gợi ý sản phẩm theo lịch sử mua, ưu đãi theo hạng thành viên, nhắc lại giỏ hàng bỏ quên.
• Thiết kế kịch bản remarketing: gửi email/SMS nhắc đơn hàng chưa hoàn tất, đề xuất mua lại sản phẩm tiêu hao, cross-sell sau mua.

Quản trị viên quản lý sản phẩm, danh mục, đơn hàng, khách hàng, mã giảm giá và nội dung

Quản trị viên (admin) là actor có quyền cao nhất trong hệ thống backend, chịu trách nhiệm cấu hình và vận hành toàn bộ website bán hàng. Actor này thường đại diện cho nhiều vai trò nội bộ: chủ shop, nhân viên kinh doanh, nhân viên kho, kế toán, marketing, kỹ thuật. Khi phân tích use case, cần làm rõ phạm vi quyền của từng nhóm để tránh lạm quyền và đảm bảo tuân thủ quy định nội bộ.

Các use case chính của quản trị viên bao gồm:

• Quản lý danh mục: tạo/sửa/xóa category, sắp xếp thứ tự hiển thị, thiết lập SEO (title, meta, slug), gắn banner cho từng danh mục.
• Quản lý sản phẩm: tạo sản phẩm mới, cập nhật thông tin, giá, hình ảnh, thuộc tính; bật/tắt hiển thị; gắn sản phẩm vào nhiều danh mục hoặc collection.
• Quản lý biến thể và tồn kho: cấu hình size, màu, phiên bản; quản lý SKU, tồn kho theo biến thể; thiết lập cảnh báo hết hàng, tự động ẩn sản phẩm khi hết tồn.
• Quản lý đơn hàng: xem danh sách đơn, lọc theo trạng thái, cập nhật trạng thái, ghi chú nội bộ, in phiếu giao hàng, xử lý hủy đơn, hoàn tiền.
• Quản lý khách hàng: xem hồ sơ khách, lịch sử mua, phân nhóm (segment), gắn tag, khóa/mở tài khoản nếu vi phạm.
• Quản lý mã giảm giá: tạo voucher theo điều kiện (theo đơn hàng, theo sản phẩm, theo nhóm khách), giới hạn thời gian, số lần sử dụng, kênh áp dụng.
• Quản lý nội dung trang, banner, landing page, bài viết: chỉnh sửa trang tĩnh (About, FAQ), cấu hình banner trang chủ, tạo landing page chiến dịch, viết và xuất bản bài blog.
• Quản lý cấu hình thanh toán, vận chuyển, email, SMS: cấu hình cổng thanh toán, thiết lập phí ship theo khu vực, cấu hình template email/SMS, thiết lập domain gửi mail.
• Quản lý phân quyền nhân viên: tạo tài khoản nội bộ, gán role (CSKH, kho, marketing, kế toán), thiết lập quyền truy cập từng module.

Trong nhiều hệ thống, quản trị viên còn có use case liên quan đến báo cáo và phân tích, phục vụ quản trị và ra quyết định:

• Xem báo cáo doanh thu: doanh thu theo ngày/tuần/tháng, theo kênh, theo danh mục, theo chiến dịch; tỷ lệ hoàn đơn, tỷ lệ thanh toán online.
• Xem báo cáo tồn kho: tồn kho hiện tại, sản phẩm bán chạy, sản phẩm bán chậm, cảnh báo sắp hết hàng.
• Xem báo cáo hiệu quả chiến dịch: doanh thu theo campaign, theo voucher, theo landing page; chi phí và ROI nếu có tích hợp dữ liệu marketing.
• Xem báo cáo traffic và chuyển đổi: số phiên truy cập, nguồn traffic, tỉ lệ chuyển đổi theo kênh, tỉ lệ bỏ giỏ (cart abandonment).

Khi vẽ sơ đồ use case, nên tách rõ:

• Quản trị viên hệ thống (system admin): cấu hình kỹ thuật, phân quyền, tích hợp, bảo mật, backup. Nguyên tắc ít quyền nhất yêu cầu mỗi tài khoản chỉ được cấp tập quyền tối thiểu cần thiết để hoàn thành nhiệm vụ trong phạm vi được giao. Vì vậy, quyền cấu hình cổng thanh toán, xuất dữ liệu khách hàng, hoàn tiền, xóa sản phẩm hoặc thay đổi phân quyền cần tách khỏi các thao tác vận hành thông thường. Nghiên cứu về kiểm soát truy cập dựa trên vai trò cho thấy việc phân quyền theo chức năng làm giảm độ phức tạp quản trị và hạn chế hậu quả khi tài khoản bị sử dụng sai mục đích (Sandhu et al., 1996). Ngoài phân vai, website cần ghi log người thực hiện, thời điểm, dữ liệu trước và sau thay đổi, đồng thời định kỳ rà soát quyền để loại bỏ quyền tích lũy không còn phù hợp.
• Quản trị viên kinh doanh (business admin): quản lý sản phẩm, đơn hàng, khuyến mãi, nội dung, báo cáo kinh doanh.

Cách tách này giúp mô hình hóa chính xác hơn các luồng phê duyệt (approval flow), giảm rủi ro thao tác nhầm và hỗ trợ kiểm soát truy cập theo nguyên tắc “ít quyền nhất” (least privilege).

Hệ thống thanh toán, vận chuyển, email, SMS, CRM và mạng xã hội là actor bên ngoài

Các hệ thống bên ngoài đóng vai trò actor đặc biệt trong sơ đồ use case website bán hàng. Chúng không phải con người nhưng tương tác hai chiều với website thông qua API, webhook hoặc các giao thức tích hợp khác. Việc coi chúng là actor giúp làm rõ ranh giới trách nhiệm giữa hệ thống nội bộ và bên thứ ba, cũng như xác định các điểm phụ thuộc (dependency) quan trọng. Mỗi actor hệ thống bên ngoài nên được mô tả cùng hợp đồng giao tiếp, dữ liệu đầu vào, kết quả đầu ra, cơ chế xác thực và kịch bản thất bại. Chẳng hạn, cổng thanh toán có thể trả kết quả tạm thời khi chuyển hướng khách hàng nhưng chỉ gửi webhook xác nhận cuối cùng sau đó; đơn vị vận chuyển cũng có thể gửi lặp trạng thái hoặc phản hồi chậm. Vì vậy, website cần có use case nhận callback, xác minh chữ ký, chống xử lý trùng, thử lại và đối soát. Nghiên cứu về kiến trúc phần mềm hướng dịch vụ nhấn mạnh rằng hợp đồng dịch vụ rõ ràng giúp kiểm soát phụ thuộc, khả năng tương tác và trách nhiệm giữa các thành phần phân tán (Papazoglou et al., 2007).

Các actor phổ biến gồm:

• Cổng thanh toán online (cổng thẻ, ví điện tử): xử lý thanh toán thẻ nội địa, thẻ quốc tế, ví điện tử, chuyển khoản nhanh; trả về kết quả thành công/thất bại, mã giao dịch.
• Đơn vị vận chuyển: nhận thông tin đơn hàng, địa chỉ, khối lượng, kích thước; trả về mã vận đơn, phí ship, trạng thái giao hàng.
• Hệ thống email marketing: nhận danh sách lead/khách hàng, trigger gửi email tự động (welcome, abandoned cart, post-purchase), thống kê open/click.
• Hệ thống SMS: gửi OTP, gửi thông báo trạng thái đơn hàng, gửi mã giảm giá; nhận phản hồi trạng thái gửi (delivered, failed).
• CRM: lưu trữ lead, khách hàng, lịch sử tương tác; đồng bộ thông tin đơn hàng, giá trị vòng đời (LTV), pipeline bán hàng.
• Nền tảng quảng cáo (Google Ads, Facebook Ads): nhận sự kiện chuyển đổi (purchase, addtocart, lead), dữ liệu remarketing; hỗ trợ tối ưu chiến dịch.
• Mạng xã hội (Facebook, Zalo, TikTok, Instagram): nhận nội dung sản phẩm để đăng tự động, nhận comment/inbox để xử lý đơn, đồng bộ catalog.

Trong sơ đồ use case, các actor này thường được nối với các use case như:

• Xử lý thanh toán online: website chuyển khách sang cổng thanh toán, nhận callback kết quả, cập nhật trạng thái đơn hàng, ghi log giao dịch.
• Tạo vận đơn: khi đơn hàng được xác nhận, hệ thống gọi API đơn vị vận chuyển để tạo vận đơn, nhận mã tracking, in tem giao hàng.
• Gửi email thông báo đơn hàng: sau khi tạo đơn, hệ thống gửi request sang email marketing hoặc SMTP để gửi email xác nhận, email cập nhật trạng thái.
• Gửi SMS mã xác thực: khi đăng ký, đăng nhập, đổi mật khẩu hoặc xác nhận đơn COD, hệ thống gọi API SMS để gửi OTP.
• Đồng bộ khách hàng sang CRM: khi có lead mới, đơn hàng mới hoặc cập nhật thông tin khách, hệ thống push dữ liệu sang CRM để chăm sóc.
• Gửi sự kiện chuyển đổi quảng cáo: khi khách hoàn tất mua hàng hoặc thực hiện hành động quan trọng, hệ thống gửi event đến nền tảng quảng cáo để ghi nhận conversion.
• Tự động đăng bài sản phẩm lên mạng xã hội: khi tạo sản phẩm mới hoặc chạy campaign, hệ thống gửi nội dung, hình ảnh, link sang mạng xã hội để đăng bài.

Việc thể hiện rõ các actor bên ngoài trong sơ đồ use case giúp đội kỹ thuật và chủ shop hiểu được phạm vi tích hợp, các điểm có thể xảy ra lỗi (timeout, lỗi xác thực, thay đổi API), cũng như các yêu cầu về bảo mật dữ liệu (mã hóa, token, chữ ký số). Đồng thời, nó hỗ trợ lập kế hoạch fallback: xử lý thế nào khi cổng thanh toán lỗi, khi đơn vị vận chuyển không phản hồi, hoặc khi hệ thống email/SMS bị gián đoạn.

Liệt kê chức năng bán hàng cốt lõi cho khách hàng trên website

Các chức năng bán hàng cốt lõi trên website xoay quanh bốn nhóm chính: khám phá sản phẩm, quản lý giỏ hàng, quy trình đặt hàng và chăm sóc sau mua. Ở bước khám phá, khách có thể tìm kiếm, lọc, so sánh, xem chi tiết, đánh giá, sản phẩm liên quan, combo và gợi ý cá nhân hóa, giúp tối ưu khả năng khám phá và tăng tỷ lệ chuyển đổi. Giỏ hàng tập trung vào thêm/xóa/cập nhật số lượng, áp mã giảm giá, ước tính phí vận chuyển, lưu và chia sẻ giỏ, gắn chặt với logic giá, khuyến mãi, tồn kho. Quy trình đặt hàng bao gồm chọn địa chỉ, phương thức giao hàng, thanh toán (COD hoặc online), xác nhận đơn và ghi chú giao hàng, tích hợp nhiều hệ thống. Sau mua, khách theo dõi đơn, yêu cầu hủy/đổi trả/bảo hành, đánh giá sản phẩm và gửi phản hồi để hoàn thiện trải nghiệm.

Tìm kiếm, lọc, so sánh và xem chi tiết sản phẩm theo nhu cầu mua

Nhóm use case cốt lõi đầu tiên cho khách hàng là tìm kiếm và khám phá sản phẩm. Ở mức độ phân tích chi tiết, có thể tách thành các nhóm chức năng sau, mỗi nhóm gắn với các luồng nghiệp vụ và quy tắc riêng:

• Tìm kiếm sản phẩm theo từ khóa
• Hỗ trợ tìm kiếm toàn văn (full-text search) theo tên, mã SKU, mô tả, thuộc tính kỹ thuật.
• Có cơ chế gợi ý từ khóa (search suggestion, autocomplete) dựa trên lịch sử tìm kiếm phổ biến, từ khóa hot, hoặc hành vi cá nhân.
• Hỗ trợ sửa lỗi chính tả, gợi ý “Có phải bạn muốn tìm…” để giảm tỷ lệ không tìm thấy kết quả.
• Có thể phân biệt tìm kiếm theo danh mục (category-based search) và tìm kiếm toàn site.

Tìm kiếm sản phẩm nên được đánh giá bằng cả chỉ số kỹ thuật và kết quả hành vi, gồm tỷ lệ truy vấn không có kết quả, tỷ lệ nhấp sau tìm kiếm, thời gian tìm thấy sản phẩm và tỷ lệ mua sau khi tìm. Kết quả liên quan nhưng thiếu khả năng thu hẹp vẫn có thể tạo quá tải lựa chọn, đặc biệt trong danh mục có nhiều sản phẩm tương tự. Nghiên cứu về tìm kiếm theo khía cạnh cho thấy faceted search hỗ trợ người dùng khám phá tập dữ liệu lớn bằng cách kết hợp truy vấn với các thuộc tính phân loại rõ ràng (Tunkelang, 2009). Vì vậy, autocomplete, sửa lỗi chính tả, bộ lọc, sắp xếp và gợi ý sản phẩm cần hoạt động thống nhất thay vì trở thành những chức năng tách rời.

• Lọc sản phẩm theo thuộc tính (faceted search)
  • Lọc theo giá (khoảng giá, slider), thương hiệu, kích thước, màu sắc, chất liệu, tính năng, xuất xứ, tình trạng khuyến mãi.
  • Hỗ trợ kết hợp nhiều bộ lọc đồng thời (multi-facet) và hiển thị số lượng sản phẩm tương ứng với mỗi giá trị lọc.
  • Cho phép reset bộ lọc nhanh, lưu bộ lọc ưa thích nếu người dùng đăng nhập.
  • Đảm bảo hiệu năng khi số lượng sản phẩm lớn (sử dụng chỉ mục tìm kiếm, caching, phân trang hợp lý).
• Sắp xếp sản phẩm
  • Các tiêu chí phổ biến: giá tăng/giảm, độ phổ biến (best seller), sản phẩm mới nhất, sản phẩm được đánh giá cao, mức độ liên quan với từ khóa.
  • Quy tắc sắp xếp có thể kết hợp với ưu tiên kinh doanh (đẩy sản phẩm có tồn kho cao, biên lợi nhuận tốt lên trước).
  • Use case “Sắp xếp sản phẩm” thường include logic phân trang, tính tổng số trang, và ghi nhận hành vi người dùng cho mục đích phân tích.
• So sánh sản phẩm
  • Cho phép chọn nhiều sản phẩm (thường 2–4) để so sánh song song các thuộc tính kỹ thuật, giá, khuyến mãi, bảo hành.
  • Use case này có thể include “Xem chi tiết sản phẩm rút gọn” cho từng item trong bảng so sánh.
  • Cần xác định rõ nhóm sản phẩm nào được phép so sánh (cùng danh mục, cùng loại) để tránh trải nghiệm khó hiểu.
• Xem chi tiết sản phẩm
  • Hiển thị đầy đủ thông tin: hình ảnh, video, mô tả, thông số kỹ thuật, giá, tồn kho theo chi nhánh, chính sách bảo hành, đổi trả.
  • Hỗ trợ lựa chọn biến thể (màu, size, dung lượng) và cập nhật giá, tồn kho theo từng biến thể.
  • Use case “Xem chi tiết sản phẩm” thường include “Xem đánh giá và nhận xét”, “Xem sản phẩm liên quan hoặc gợi ý”.
• Xem đánh giá và nhận xét
  • Hiển thị điểm đánh giá trung bình, phân bố số sao, và danh sách nhận xét có thể kèm hình ảnh, video.
  • Cho phép lọc đánh giá theo số sao, theo đánh giá có hình ảnh, theo người đã mua hàng xác thực.
  • Use case này có thể include “Báo cáo đánh giá không phù hợp” để đảm bảo chất lượng nội dung.
• Xem sản phẩm liên quan hoặc gợi ý
  • Các loại gợi ý: sản phẩm tương tự, sản phẩm bổ trợ (cross-sell), sản phẩm nâng cấp (up-sell), combo khuyến mãi.
  • Có thể dựa trên rule tĩnh (do merchandiser cấu hình) hoặc engine gợi ý động (machine learning, collaborative filtering).
  • Use case này ảnh hưởng trực tiếp đến giá trị đơn hàng trung bình (AOV), nên cần được mô hình hóa rõ điểm chèn logic đề xuất.
• Xem sản phẩm đã xem gần đây
  • Lưu lịch sử xem sản phẩm theo session hoặc theo tài khoản, đồng bộ đa thiết bị nếu người dùng đăng nhập.
  • Use case này thường include “Theo dõi hành vi duyệt web” và liên kết với hệ thống phân tích (analytics).
• Xem sản phẩm gợi ý theo hành vi
  • Dựa trên lịch sử xem, tìm kiếm, thêm vào giỏ, mua hàng để cá nhân hóa danh sách gợi ý. Hệ thống gợi ý không nên chỉ tối ưu độ chính xác dự đoán mà còn phải cân bằng tính mới, độ đa dạng, mức độ phù hợp và khả năng giải thích đề xuất. Tổng quan nghiên cứu về recommender systems cho thấy các thuật toán dựa trên nội dung, lọc cộng tác và phương pháp lai đều có ưu điểm riêng nhưng có thể gặp hạn chế như dữ liệu thưa, người dùng mới và đề xuất quá đồng nhất (Adomavicius & Tuzhilin, 2005). Vì vậy, website nên kết hợp lịch sử xem, tìm kiếm, thêm giỏ và mua hàng với tồn kho, giá, danh mục cùng mục tiêu kinh doanh. Những giải thích như “dựa trên sản phẩm bạn đã xem” cũng giúp người dùng hiểu nguyên nhân xuất hiện của đề xuất và tăng khả năng kiểm soát trải nghiệm.
  • Có thể xuất hiện ở trang chủ, trang danh mục, trang chi tiết sản phẩm, trang giỏ hàng.
  • Trong sơ đồ use case, thường có association với actor “Hệ thống gợi ý” hoặc “Recommendation Engine”.
• Xem combo hoặc gói sản phẩm
  • Hiển thị các gói sản phẩm được đóng gói sẵn với giá ưu đãi, hoặc cho phép khách tự cấu hình combo.
  • Use case này thường include “Tính giá combo sau khuyến mãi” và “Kiểm tra tồn kho từng thành phần”.

Các chức năng trên cần được ưu tiên trong quá trình phân tích và thiết kế vì chúng tác động trực tiếp đến tỷ lệ chuyển đổi, khả năng khám phá sản phẩm và mức độ hài lòng khi duyệt web.

Thêm sản phẩm vào giỏ hàng, cập nhật số lượng và áp mã giảm giá

Giỏ hàng là trung tâm của hành vi mua sắm trên website, là nơi hội tụ nhiều quy tắc nghiệp vụ về giá, khuyến mãi, tồn kho. Nhóm use case liên quan có thể phân rã chi tiết như sau:

• Thêm sản phẩm vào giỏ hàng
• Hỗ trợ thêm từ trang danh mục, trang chi tiết sản phẩm, trang combo, hoặc từ danh sách yêu thích.
• Kiểm tra tồn kho theo biến thể, giới hạn số lượng tối đa mỗi sản phẩm, mỗi đơn hàng.
• Use case này thường include “Tính lại tổng tiền giỏ hàng”, “Áp dụng khuyến mãi tự động nếu đủ điều kiện”.

Giỏ hàng không luôn thể hiện cam kết mua ngay vì người dùng còn sử dụng nó để lưu sản phẩm, so sánh giá, tính tổng chi phí hoặc chờ thời điểm phù hợp. Phân tích dữ liệu clickstream cho thấy hành vi bỏ giỏ chịu ảnh hưởng bởi mục tiêu sử dụng giỏ, tiến trình mua hàng và mức độ tương tác trước đó với nhà bán lẻ (Kukar-Kinney et al., 2022). Vì vậy, website không nên phân loại mọi giỏ bị bỏ theo cùng một nguyên nhân. Hệ thống cần ghi nhận thời điểm thêm sản phẩm, thay đổi giá, phí vận chuyển, thiết bị, nguồn truy cập và bước cuối đã hoàn thành để phân biệt giỏ lưu tạm với trường hợp khách gặp trở ngại trong quá trình thanh toán.

• Cập nhật số lượng trong giỏ
  • Cho phép tăng/giảm số lượng, nhập trực tiếp số lượng mong muốn.
  • Kiểm tra lại tồn kho, giới hạn mua, và cập nhật lại giá sau khuyến mãi.
  • Trong sơ đồ use case, có thể include “Kiểm tra điều kiện khuyến mãi theo số lượng/giá trị giỏ”.
• Xóa sản phẩm khỏi giỏ
  • Xóa từng sản phẩm hoặc xóa toàn bộ giỏ.
  • Có thể ghi nhận lý do xóa (không còn nhu cầu, giá cao, phí ship cao) phục vụ phân tích.
• Áp mã giảm giá
  • Nhập mã coupon/voucher, kiểm tra tính hợp lệ (thời gian, đối tượng, danh mục áp dụng, giá trị tối thiểu).
  • Tính toán mức giảm (theo % hoặc số tiền cố định), giới hạn mức giảm tối đa, và cập nhật tổng tiền.
  • Use case “Áp mã giảm giá” thường được mô hình hóa với quan hệ include hoặc extend với “Đặt hàng” hoặc “Thanh toán”:
    • include nếu đây là bước bắt buộc trong quy trình tính giá cuối cùng.
    • extend nếu là bước tùy chọn, chỉ xảy ra khi khách nhập mã.
  • Cách mô hình hóa này giúp đội phát triển xác định rõ điểm chèn logic khuyến mãi, nơi cần gọi đến hệ thống quản lý voucher hoặc engine khuyến mãi.
• Ước tính phí vận chuyển
  • Cho phép nhập địa chỉ hoặc mã bưu chính để tính phí ship tạm tính.
  • Use case này thường include “Tính phí vận chuyển” và có association với actor “Hệ thống vận chuyển” hoặc “Đối tác giao hàng”.
• Lưu giỏ hàng cho lần sau
  • Lưu giỏ theo tài khoản hoặc theo cookie/session cho khách chưa đăng nhập.
  • Đồng bộ giỏ hàng giữa các thiết bị khi khách đăng nhập.
  • Cần làm rõ chính sách hết hạn giỏ, xử lý khi sản phẩm hết hàng hoặc thay đổi giá.
• Chia sẻ giỏ hàng (nếu hệ thống hỗ trợ)
  • Tạo link chia sẻ hoặc gửi qua email, mạng xã hội.
  • Use case này có thể include “Tạo snapshot giỏ hàng” để đảm bảo nội dung giỏ không thay đổi ngoài ý muốn.

Các chức năng giỏ hàng cần được gắn với cả actor “Khách truy cập” và “Khách hàng đăng nhập”, tùy theo chính sách lưu giỏ và đồng bộ dữ liệu. Việc mô hình hóa rõ ràng giúp đội phát triển hiểu được các trạng thái giỏ (tạm, đã lưu, đã chuyển thành đơn) và các điểm tích hợp với hệ thống khuyến mãi, tồn kho.

Đặt hàng, chọn phương thức thanh toán, nhập địa chỉ và ghi chú giao hàng

Quy trình đặt hàng là chuỗi use case quan trọng nhất, kết nối nhiều hệ thống: tồn kho, thanh toán, vận chuyển, CRM. Use case “Đặt hàng” thường là trung tâm và được phân rã như sau:

• Tiến hành đặt hàng từ giỏ
• Chuyển từ trạng thái “Giỏ hàng” sang “Đơn hàng nháp” hoặc “Đơn hàng chờ xác nhận”.
• Use case này thường include “Xác thực thông tin khách hàng” (đăng nhập, đăng ký nhanh, hoặc đặt hàng không cần tài khoản).

Các nghiên cứu tổng quan về bỏ giỏ hàng xác định nhiều nguyên nhân xuất hiện tại checkout, gồm chi phí phát sinh, quy trình dài, yêu cầu tạo tài khoản, lo ngại bảo mật và thiếu phương thức thanh toán phù hợp (Chopra et al., 2024). Mỗi trường dữ liệu, bước chuyển trang hoặc yêu cầu xác thực đều làm tăng chi phí nhận thức và khả năng rời bỏ, đặc biệt với khách hàng chưa có mức cam kết cao. Vì vậy, quy trình nên hỗ trợ đặt hàng không cần tài khoản, tự động điền dữ liệu hợp lệ, báo lỗi tại trường nhập, công khai phí trước bước cuối và giữ nguyên giỏ khi thanh toán thất bại. Những trạng thái như giao dịch thất bại, bị hủy hoặc chờ xác minh phải được mô hình hóa thành luồng nghiệp vụ chính thức.

• Nhập hoặc chọn địa chỉ giao hàng
  • Chọn từ danh sách địa chỉ đã lưu hoặc nhập địa chỉ mới.
  • Kiểm tra tính hợp lệ của địa chỉ (tỉnh/thành, quận/huyện, phường/xã, mã bưu chính).
  • Use case này thường include “Chuẩn hóa địa chỉ” để phục vụ hệ thống vận chuyển.
• Chọn phương thức giao hàng
  • Các lựa chọn: giao tiêu chuẩn, giao nhanh, nhận tại cửa hàng, giao trong ngày…
  • Mỗi phương thức có thời gian dự kiến, phí ship, và điều kiện áp dụng riêng.
  • Use case này include “Tính phí vận chuyển” dựa trên địa chỉ, khối lượng, kích thước, và chính sách khuyến mãi vận chuyển.
• Chọn phương thức thanh toán
  • Các lựa chọn: thanh toán khi nhận hàng (COD), thanh toán online qua cổng thanh toán, chuyển khoản ngân hàng, ví điện tử.
  • Use case “Thanh toán online” thường extend “Đặt hàng” khi khách chọn phương thức online, và có association với actor “Cổng thanh toán”.
  • Trong nhánh “Thanh toán online”, cần mô hình hóa các bước: tạo yêu cầu thanh toán, chuyển hướng sang cổng, nhận callback, xác nhận trạng thái thanh toán.
• Xác nhận thông tin đơn hàng
  • Hiển thị tóm tắt: sản phẩm, số lượng, giá, phí ship, giảm giá, tổng thanh toán, địa chỉ giao hàng, phương thức giao hàng, phương thức thanh toán.
  • Cho phép quay lại chỉnh sửa từng bước (địa chỉ, phương thức giao hàng, thanh toán) trước khi chốt đơn.
  • Use case này include “Tính tổng tiền sau khuyến mãi” để đảm bảo số liệu cuối cùng chính xác.
• Thanh toán online hoặc chọn thanh toán khi nhận hàng
  • Với COD: đánh dấu đơn ở trạng thái “Chờ xử lý” hoặc “Chờ xác nhận”, không cần bước xác nhận thanh toán.
  • Với online: cần xử lý các trạng thái thành công, thất bại, hủy, treo; cập nhật trạng thái đơn hàng tương ứng.
  • Use case “Thanh toán online” có thể include “Gửi email/SMS thông báo trạng thái thanh toán”.
• Nhập ghi chú giao hàng
  • Cho phép khách nhập yêu cầu đặc biệt: thời gian giao, hướng dẫn liên hệ, lưu ý cho shipper.
  • Thông tin này cần được truyền sang hệ thống vận chuyển hoặc hiển thị cho bộ phận xử lý đơn.

Trong sơ đồ use case, “Đặt hàng” thường include các use case kỹ thuật như “Xác thực thông tin khách hàng”, “Tính phí vận chuyển”, “Tính tổng tiền sau khuyến mãi”, “Gửi email xác nhận đơn hàng”. Cách mô hình hóa này giúp thể hiện rõ các nhánh quy trình (COD vs online, địa chỉ mới vs địa chỉ cũ) mà không làm sơ đồ bị trùng lặp, đồng thời chỉ ra các điểm tích hợp với hệ thống thanh toán, vận chuyển, CRM.

Theo dõi trạng thái đơn hàng, đánh giá sản phẩm và gửi yêu cầu hỗ trợ

Sau khi đặt hàng, khách hàng cần các chức năng để theo dõi và tương tác với đơn hàng, cũng như xử lý các vấn đề phát sinh. Nhóm use case này có vai trò quan trọng trong trải nghiệm sau mua và giữ chân khách hàng:

• Xem danh sách đơn hàng
• Hiển thị tất cả đơn hàng của khách, có thể lọc theo trạng thái (đang xử lý, đang giao, đã giao, đã hủy, đổi trả).
• Cho phép tìm kiếm theo mã đơn, khoảng thời gian, kênh đặt hàng (web, app, cửa hàng nếu có đồng bộ).

Trải nghiệm sau mua tạo ra dữ liệu quan trọng để đánh giá chất lượng thực tế của sản phẩm, giao hàng và dịch vụ hỗ trợ. Website nên ghi nhận thời gian phản hồi, thời gian xử lý, số lần chuyển bộ phận, nguyên nhân đổi trả, kết quả hoàn tiền và mức hài lòng sau khi đóng yêu cầu. Nghiên cứu về chất lượng dịch vụ điện tử cho thấy khả năng thực hiện cam kết, tính sẵn sàng của hệ thống, quyền riêng tư và hiệu quả xử lý vấn đề là những thành phần quan trọng của trải nghiệm khách hàng trực tuyến (Parasuraman et al., 2005). Do đó, trạng thái đơn hàng và yêu cầu hỗ trợ cần được trình bày minh bạch, đồng thời lịch sử tương tác phải được lưu đầy đủ để nhân viên xử lý nhất quán.

• Xem chi tiết đơn hàng
  • Hiển thị thông tin sản phẩm, giá, phí ship, giảm giá, địa chỉ giao hàng, phương thức thanh toán, lịch sử trạng thái.
  • Use case này thường include “Theo dõi trạng thái đơn hàng” và “Gửi email/SMS thông báo” khi có thay đổi.
• Theo dõi trạng thái đơn hàng
  • Hiển thị timeline các mốc: tiếp nhận, đóng gói, bàn giao vận chuyển, đang giao, giao thành công, thất bại.
  • Có thể tích hợp tracking của đối tác vận chuyển, hiển thị link hoặc thông tin chi tiết hành trình.
• Yêu cầu hủy đơn
  • Cho phép khách gửi yêu cầu hủy khi đơn chưa qua một mốc xử lý nhất định (ví dụ: chưa đóng gói, chưa giao cho hãng vận chuyển).
  • Use case này có thể include “Tạo ticket hỗ trợ trong CRM” nếu cần nhân viên duyệt thủ công.
• Yêu cầu đổi trả
  • Khách chọn sản phẩm cần đổi/trả, lý do, hình thức xử lý (đổi sản phẩm, hoàn tiền, voucher).
  • Use case này thường include “Tạo ticket hỗ trợ trong CRM” và “Gửi email/SMS thông báo” về tiến độ xử lý.
• Gửi yêu cầu bảo hành
  • Khách cung cấp thông tin sản phẩm, số serial (nếu có), mô tả lỗi, hình ảnh/video minh họa.
  • Có thể tích hợp với hệ thống bảo hành của hãng hoặc trung tâm dịch vụ.
• Đánh giá sản phẩm
  • Cho phép khách đã mua hàng đánh giá bằng số sao, nội dung nhận xét, hình ảnh/video.
  • Use case này có thể include “Xác thực quyền đánh giá” (chỉ khách đã mua mới được đánh giá) và “Kiểm duyệt nội dung”.
• Gửi phản hồi hoặc khiếu nại
  • Khách gửi phản hồi về chất lượng sản phẩm, dịch vụ giao hàng, chăm sóc khách hàng, hoặc khiếu nại cụ thể.
  • Trong sơ đồ use case, chức năng này thường có association với actor “Khách hàng” và include “Tạo ticket hỗ trợ trong CRM”.

Trong sơ đồ use case, các chức năng hỗ trợ sau mua thường có association với actor “Khách hàng” và có thể include các use case kỹ thuật như “Gửi email thông báo”, “Gửi SMS thông báo”, “Tạo ticket hỗ trợ trong CRM”. Cách mô hình hóa này làm rõ kết nối giữa website và hệ thống chăm sóc khách hàng, giúp đội ngũ thiết kế quy trình xử lý nội bộ, phân quyền cho nhân viên, và xây dựng SLA phù hợp cho từng loại yêu cầu (hủy, đổi trả, bảo hành, khiếu nại).

Liệt kê chức năng quản trị website bán hàng cho admin và nhân viên

Nhóm chức năng quản trị website bán hàng cho admin và nhân viên bao quát toàn bộ vòng đời vận hành: từ sản phẩm, đơn hàng, khách hàng đến nội dung marketing. Hệ thống cần cho phép quản lý chi tiết danh mục, sản phẩm, biến thể, tồn kho, giá bán và media, đảm bảo dữ liệu nhất quán và hỗ trợ mở rộng quy mô. Song song, các chức năng xử lý đơn hàng, thanh toán, vận chuyển, đổi trả và bảo hành phải được chuẩn hóa theo quy trình, có log thao tác và tích hợp với đơn vị vận chuyển, cổng thanh toán. Về mặt con người, mô hình RBAC giúp phân quyền nhân viên, kiểm soát truy cập và lịch sử thao tác. Cuối cùng, module nội dung, banner, landing page, bài viết SEO và khuyến mãi hỗ trợ đội marketing triển khai chiến dịch linh hoạt mà vẫn tuân thủ cấu trúc kỹ thuật.

Quản lý danh mục, sản phẩm, biến thể, tồn kho, giá bán và hình ảnh

Nhóm use case quản trị sản phẩm là nền tảng cốt lõi của mọi website bán hàng, quyết định trực tiếp đến khả năng mở rộng danh mục, tối ưu vận hành và trải nghiệm tìm kiếm của khách. Ở mức chuyên sâu, hệ thống thường tách thành các phân hệ: quản lý danh mục (category), quản lý sản phẩm (product), quản lý biến thể (variant/SKU), quản lý tồn kho (inventory), quản lý giá (pricing) và quản lý media (asset). Mỗi phân hệ tương ứng với một nhóm use case riêng, nhưng có quan hệ chặt chẽ với nhau thông qua các ràng buộc dữ liệu và quy tắc nghiệp vụ.

Với danh mục sản phẩm, các use case chi tiết thường bao gồm:

• Tạo danh mục sản phẩm: cho phép admin định nghĩa cấu trúc cây danh mục nhiều cấp (category tree), thiết lập slug SEO, meta title, meta description, URL thân thiện, trạng thái hiển thị và thứ tự ưu tiên. Có thể hỗ trợ gắn icon, banner riêng cho từng danh mục.
• Cập nhật danh mục: chỉnh sửa tên, mô tả, thuộc tính SEO, thay đổi danh mục cha, chuyển nhánh trong cây danh mục mà không làm mất liên kết sản phẩm; hệ thống cần xử lý redirect 301 tự động để tránh lỗi SEO.
• Sắp xếp thứ tự danh mục: kéo thả (drag & drop) hoặc nhập thứ tự hiển thị, có thể cấu hình thứ tự riêng cho menu desktop, mobile, footer; hỗ trợ ẩn/hiện từng danh mục theo kênh bán (web, app, marketplace).

Với sản phẩm, hệ thống thường phân biệt giữa product master (sản phẩm cha) và product variant (biến thể). Các use case chuyên sâu gồm:

• Tạo sản phẩm mới: nhập mã sản phẩm (SKU cha), tên, mô tả chi tiết (có thể hỗ trợ rich text/HTML), thuộc tính kỹ thuật, danh mục chính và danh mục phụ, thương hiệu, tag, trạng thái hiển thị, đơn vị tính, trọng lượng, kích thước để phục vụ tính phí vận chuyển.
• Cập nhật thông tin sản phẩm: chỉnh sửa nội dung mô tả, thông số kỹ thuật, thuộc tính lọc (filterable attributes như màu, chất liệu, thương hiệu), tối ưu SEO onpage, cấu hình sản phẩm liên quan (related products), sản phẩm gợi ý (upsell/cross-sell).
• Quản lý biến thể sản phẩm: định nghĩa tập thuộc tính biến thể (màu, size, dung lượng, phiên bản), sinh tự động các biến thể từ ma trận thuộc tính, gán SKU riêng cho từng biến thể, cấu hình giá, tồn kho, mã vạch (barcode), hình ảnh riêng cho từng biến thể.

Use case Quản lý tồn kho thường được thiết kế như một phân hệ gần với ERP, bao gồm:

• Nhập kho: tạo phiếu nhập kho theo nhà cung cấp, đơn mua hàng (PO) hoặc nhập điều chỉnh; ghi nhận số lượng, giá vốn, kho đích, ngày nhập; có thể include bước “Duyệt phiếu nhập” để kiểm soát nội bộ.
• Xuất kho: xuất kho theo đơn hàng, xuất điều chuyển giữa các kho, xuất hủy; hệ thống tự động trừ tồn theo từng SKU/biến thể, ghi nhận lý do xuất và người thực hiện.
• Điều chỉnh tồn kho: điều chỉnh chênh lệch sau kiểm kê, khóa tồn kho tạm thời cho các chiến dịch flash sale, cấu hình tồn tối thiểu/tối đa để cảnh báo đặt hàng.
• Xem lịch sử tồn kho: truy vết mọi biến động tồn kho theo thời gian, theo kho, theo SKU; hỗ trợ lọc theo loại chứng từ (nhập, xuất, điều chỉnh), export báo cáo để đối soát với hệ thống kế toán hoặc ERP.

Về quản lý giá bán và giá khuyến mãi, hệ thống thường hỗ trợ:

• Giá niêm yết (list price), giá bán thực tế (sale price), giá theo kênh (online/offline), giá theo nhóm khách hàng (B2B/B2C, VIP, đại lý).
• Thiết lập khoảng thời gian hiệu lực cho giá khuyến mãi, ưu tiên giữa nhiều chương trình giảm giá, quy tắc làm tròn giá, hiển thị phần trăm giảm hoặc số tiền giảm.
• Quản lý lịch sử thay đổi giá để phân tích biên lợi nhuận và kiểm soát rủi ro thao tác sai.

Use case Quản lý hình ảnh và video sản phẩm bao gồm upload nhiều ảnh, sắp xếp thứ tự, gắn alt text phục vụ SEO, chọn ảnh đại diện cho từng biến thể, nhúng video (YouTube, file nội bộ), tối ưu dung lượng và tự động sinh các kích thước ảnh khác nhau cho từng vị trí hiển thị. Chức năng Ẩn/hiện sản phẩm trên website thường đi kèm các rule như ẩn khi hết hàng, ẩn theo kênh, hoặc chỉ hiển thị với một số nhóm khách hàng.

Trong sơ đồ use case, các chức năng trên gắn với actor “Quản trị viên” và “Nhân viên bán hàng” hoặc “Nhân viên quản lý sản phẩm”. Có thể bổ sung các mối quan hệ include/extend như: “Tạo sản phẩm mới” include “Upload hình ảnh”, “Thiết lập giá”, “Gán danh mục”; “Quản lý tồn kho” include “Nhập kho”, “Xuất kho”, “Điều chỉnh tồn kho”, “Xem lịch sử tồn kho”, thể hiện rõ chuỗi nghiệp vụ vận hành kho.

Quản lý đơn hàng, thanh toán, vận chuyển, đổi trả và bảo hành

Nhóm use case quản lý đơn hàng là trung tâm của luồng doanh thu, liên quan trực tiếp đến trải nghiệm khách hàng và hiệu quả vận hành. Hệ thống thường chia vòng đời đơn hàng thành nhiều trạng thái: mới tạo, đã xác nhận, đang chuẩn bị hàng, đang giao, giao thành công, giao thất bại, đã hủy, đang đổi trả, đã hoàn tiền. Mỗi trạng thái tương ứng với các thao tác và quyền hạn khác nhau của admin và nhân viên.

Các chức năng chi tiết gồm:

• Xem danh sách đơn hàng: hiển thị bảng đơn hàng với các cột quan trọng (mã đơn, khách hàng, kênh đặt, tổng tiền, trạng thái thanh toán, trạng thái giao hàng, ngày tạo, nhân viên phụ trách); hỗ trợ cấu hình cột hiển thị theo từng vai trò.
• Lọc và tìm kiếm đơn hàng: tìm theo mã đơn, số điện thoại, email, tên khách, SKU sản phẩm trong đơn, khoảng thời gian, trạng thái, kênh bán, mã voucher; hỗ trợ lưu bộ lọc để dùng lại.
• Cập nhật trạng thái đơn hàng: chuyển trạng thái theo workflow được cấu hình sẵn, có thể yêu cầu lý do khi hủy hoặc khi chuyển sang trạng thái đặc biệt (ví dụ: chờ xác minh).
• Xác nhận thanh toán: ghi nhận thanh toán online tự động từ cổng thanh toán, hoặc xác nhận thanh toán thủ công (chuyển khoản, tiền mặt); hỗ trợ thanh toán một phần, nhiều lần, hoàn tiền một phần.
• Tạo vận đơn với đơn vị vận chuyển: kết nối API với các hãng vận chuyển, tự động đẩy thông tin đơn hàng, địa chỉ, trọng lượng, kích thước, dịch vụ giao hàng; nhận lại mã vận đơn và phí ship.
• Cập nhật mã vận đơn: lưu mã vận đơn, trạng thái giao hàng, thời gian giao dự kiến; đồng bộ hai chiều với hệ thống vận chuyển nếu có tích hợp.
• Xử lý yêu cầu hủy đơn: tiếp nhận yêu cầu từ khách hoặc nội bộ, kiểm tra trạng thái (đã đóng gói, đã giao cho hãng hay chưa), áp dụng chính sách hủy, hoàn tiền, cập nhật tồn kho.
• Xử lý yêu cầu đổi trả: tạo phiếu yêu cầu đổi/ trả, ghi nhận lý do, tình trạng hàng, phương thức xử lý (đổi sản phẩm, hoàn tiền, cấp mã giảm giá), liên kết với phiếu nhập kho hàng trả về.
• Xử lý yêu cầu bảo hành: quản lý phiếu bảo hành, thời hạn, lịch sử sửa chữa/thay thế, trạng thái xử lý; có thể liên kết với trung tâm bảo hành hoặc nhà cung cấp.
• Xuất hóa đơn hoặc chứng từ: xuất hóa đơn điện tử, phiếu giao hàng, phiếu thu; tích hợp với hệ thống hóa đơn điện tử và kế toán để đồng bộ dữ liệu.

Trong sơ đồ use case, use case tổng “Quản lý đơn hàng” thường include:

• Gửi email thông báo trạng thái: gửi tự động khi đơn được tạo, xác nhận, giao thành công, hủy, hoàn tiền; nội dung email có thể cấu hình theo template.
• Gửi SMS thông báo: gửi SMS ngắn gọn về mã đơn, trạng thái, mã vận đơn; thường dùng cho các mốc quan trọng như giao hàng thành công hoặc giao thất bại.
• Đồng bộ trạng thái đơn hàng sang CRM: cập nhật hành vi mua hàng, giá trị đơn, sản phẩm đã mua vào hồ sơ khách hàng trong CRM để phục vụ chăm sóc và remarketing.
• Ghi log lịch sử thao tác: lưu lại mọi thao tác của nhân viên trên đơn hàng (ai, lúc nào, thay đổi gì), hỗ trợ kiểm soát nội bộ và xử lý khiếu nại.

Actor “Đơn vị vận chuyển” có association với use case “Tạo vận đơn” và “Cập nhật trạng thái giao hàng”, thể hiện luồng thông tin hai chiều giữa website và hệ thống vận chuyển. Trong các hệ thống phức tạp, có thể mô hình thêm actor “Cổng thanh toán” liên quan đến use case “Xác nhận thanh toán” và “Hoàn tiền”, nhưng vẫn giữ nguyên cấu trúc use case tổng “Quản lý đơn hàng”.

Quản lý khách hàng, phân quyền nhân viên, vai trò truy cập và lịch sử thao tác

Quản lý khách hàng và phân quyền là nhóm use case then chốt cho bảo mật, tuân thủ và tối ưu chăm sóc khách hàng. Hệ thống thường xây dựng mô hình dữ liệu khách hàng (customer profile) với các trường thông tin cá nhân, lịch sử tương tác, lịch sử mua hàng, điểm tích lũy, hạng thành viên. Song song, mô hình phân quyền (RBAC – Role Based Access Control) được áp dụng cho nhân viên để kiểm soát truy cập.

Các chức năng quản lý khách hàng bao gồm:

• Xem danh sách khách hàng: hiển thị danh sách với các thông tin cơ bản (tên, email, số điện thoại, ngày đăng ký, tổng giá trị mua, hạng thành viên, trạng thái tài khoản); hỗ trợ lọc theo hành vi mua hàng.
• Xem lịch sử mua hàng của khách: liệt kê toàn bộ đơn hàng, sản phẩm đã mua, kênh mua, phương thức thanh toán, tần suất mua; phục vụ phân tích CLV (Customer Lifetime Value).
• Cập nhật thông tin khách hàng: chỉnh sửa thông tin cá nhân, địa chỉ giao hàng, ghi chú nội bộ, gắn nhân viên phụ trách; cần ghi log thay đổi để đảm bảo tuân thủ bảo mật dữ liệu.
• Gắn tag hoặc phân nhóm khách hàng: gắn tag theo hành vi (mua lần đầu, khách VIP, khách hay hoàn trả), theo nguồn (Facebook, Google, offline), hoặc phân nhóm tự động dựa trên rule (RFM, doanh thu, ngành nghề).
• Khóa hoặc mở khóa tài khoản khách hàng: xử lý các trường hợp gian lận, spam, vi phạm chính sách; có thể kết hợp với cơ chế cảnh báo và xác minh bổ sung.

Về phân quyền nhân viên, các use case chuyên sâu gồm:

• Tạo tài khoản nhân viên: tạo user nội bộ, gán thông tin cơ bản, phòng ban, chi nhánh, trạng thái hoạt động; có thể tích hợp SSO hoặc LDAP trong các hệ thống lớn.
• Gán vai trò và quyền hạn: gán role (Admin, Nhân viên bán hàng, Nhân viên CSKH, Nhân viên kho, Kế toán), mỗi role đi kèm tập quyền chi tiết trên từng module (xem, tạo, sửa, xóa, export, duyệt).
• Cấu hình quyền truy cập theo vai trò: thiết lập ma trận quyền, giới hạn truy cập theo chi nhánh/kho, ẩn một số dữ liệu nhạy cảm (giá vốn, biên lợi nhuận, thông tin thanh toán) với một số role.
• Xem lịch sử thao tác của nhân viên: ghi nhận mọi hành động quan trọng (đổi giá, đổi trạng thái đơn, hoàn tiền, điều chỉnh tồn kho, chỉnh sửa thông tin khách), cho phép lọc theo nhân viên, theo thời gian, theo loại thao tác.

Trong sơ đồ use case, actor “Quản trị viên” thường có quyền với toàn bộ các use case này, trong khi “Nhân viên bán hàng”, “Nhân viên CSKH”, “Nhân viên kho”, “Kế toán” chỉ được gắn với một phần chức năng phù hợp với vai trò. Use case “Xem lịch sử thao tác” đóng vai trò như một lớp kiểm soát chéo, giúp tăng tính minh bạch, hỗ trợ audit nội bộ và đáp ứng các yêu cầu về bảo mật, bảo vệ dữ liệu cá nhân.

Quản lý nội dung, banner, landing page, bài viết SEO và chương trình khuyến mãi

Website bán hàng hiện đại hoạt động như một nền tảng nội dung và marketing tích hợp, nơi đội marketing có thể triển khai chiến dịch mà không phụ thuộc quá nhiều vào đội kỹ thuật. Vì vậy, nhóm use case quản trị nội dung thường được thiết kế theo hướng CMS (Content Management System) với khả năng kéo thả, cấu hình linh hoạt và gắn tracking.

Các use case quản trị nội dung bao gồm:

• Quản lý banner trang chủ: tạo, sửa, sắp xếp banner theo vị trí (hero, sidebar, footer), cấu hình link đích, thời gian hiển thị, phân phối theo thiết bị (desktop/mobile), A/B test nhiều phiên bản banner.
• Quản lý slider: tạo slider nhiều ảnh, thiết lập thứ tự, hiệu ứng chuyển, tốc độ, điều kiện hiển thị theo chiến dịch; có thể gắn tag để chỉ hiển thị cho một số nhóm khách hàng.
• Tạo và chỉnh sửa landing page: sử dụng builder kéo thả để tạo trang chiến dịch, trang thu lead, trang giới thiệu bộ sưu tập; không cần can thiệp code.
• Quản lý bài viết blog: tạo bài viết SEO, gắn danh mục blog, tag, tối ưu meta, schema, internal link đến sản phẩm; hỗ trợ lịch đăng (schedule) và trạng thái nháp/xuất bản.
• Quản lý trang giới thiệu, chính sách: chỉnh sửa nội dung các trang tĩnh như Giới thiệu, Chính sách bảo mật, Chính sách đổi trả, Điều khoản sử dụng; đảm bảo cập nhật kịp thời theo quy định pháp lý.
• Quản lý chương trình khuyến mãi: cấu hình chương trình giảm giá theo sản phẩm, danh mục, giỏ hàng; thiết lập điều kiện áp dụng, thời gian, ngân sách, ưu tiên giữa các chương trình.
• Cấu hình mã giảm giá: tạo coupon theo mã, theo link, giới hạn số lần sử dụng, giới hạn theo khách hàng, theo kênh, theo giá trị đơn; hỗ trợ nhiều loại giảm (theo %, theo số tiền, freeship).
• Cấu hình flash sale: thiết lập khung giờ, số lượng giới hạn, giá đặc biệt, cơ chế giữ hàng trong giỏ, hiển thị đồng hồ đếm ngược; đồng bộ chặt với hệ thống tồn kho để tránh oversell.
• Cấu hình combo sản phẩm: tạo combo mua kèm, mua theo bộ, giảm giá khi mua nhiều; cấu hình logic tính giá, hiển thị gợi ý combo trên trang sản phẩm và trong giỏ hàng.

Use case Tạo landing page thường include các bước:

• Chọn template: chọn mẫu layout có sẵn theo mục tiêu (bán hàng, thu lead, giới thiệu sản phẩm mới), tối ưu cho mobile-first.
• Kéo thả block nội dung: thêm/sắp xếp các block như banner, gallery, danh sách sản phẩm, testimonial, form, countdown, FAQ; cấu hình nội dung, màu sắc, font theo brand.
• Gắn form thu lead: chèn form đăng ký, nhận ưu đãi, đăng ký sự kiện; kết nối với CRM hoặc email marketing để nuôi dưỡng lead.
• Gắn tracking và pixel: chèn mã theo dõi (Google Analytics, Facebook Pixel, các thẻ remarketing khác), gắn UTM cho link, cấu hình event để đo lường hiệu quả chiến dịch.

Những use case này gắn với actor “Quản trị viên” và “Nhân viên marketing”. Trong sơ đồ use case, có thể mô tả mối liên hệ giữa nội dung, marketing và kỹ thuật thông qua các association với hệ thống bên ngoài (công cụ phân tích, quảng cáo), nhưng vẫn giữ nguyên số lượng heading và cấu trúc nhóm chức năng như trên.

Bổ sung use case marketing cho website bán hàng hiện đại

Use case marketing cho website bán hàng hiện đại cần được mô tả như một hệ sinh thái khép kín, bao phủ toàn bộ hành trình khách hàng từ lúc tiếp cận, tương tác, mua hàng đến tái mua và giới thiệu. Trọng tâm là khả năng tự chủ của đội marketing trong việc tạo landing page, thu lead, nuôi dưỡng và đo lường mà không phụ thuộc quá nhiều vào kỹ thuật, nhưng vẫn đảm bảo các ràng buộc về thương hiệu, hiệu năng và bảo mật. Hệ thống phải hỗ trợ tích hợp sâu với email, SMS, CRM, mạng xã hội và nền tảng quảng cáo, đồng thời chuẩn hóa luồng dữ liệu, tracking và báo cáo. Nhờ đó, website trở thành nền tảng trung tâm cho cả bán hàng lẫn vận hành marketing, tối ưu chi phí và tăng trưởng doanh thu bền vững.

Tạo landing page kéo thả cho chiến dịch quảng cáo, flash sale và sản phẩm chủ lực

Đối với website bán hàng hiện đại, khả năng tự tạo landing page cho từng chiến dịch là một lợi thế lớn, đặc biệt khi doanh nghiệp triển khai nhiều kênh quảng cáo trả phí (Facebook Ads, Google Ads, TikTok Ads, Zalo Ads…). Use case “Tạo landing page kéo thả” không chỉ dừng ở mức kéo thả giao diện mà còn cần mô tả rõ các bước nghiệp vụ, quyền hạn người dùng và các ràng buộc kỹ thuật để đảm bảo tính nhất quán thương hiệu và hiệu quả chuyển đổi.

Về mặt nghiệp vụ, nhân viên marketing thường cần thực hiện chuỗi thao tác sau:

• Chọn template layout theo mục tiêu chiến dịch (thu lead, bán sản phẩm đơn, flash sale, pre-order, ra mắt bộ sưu tập mới).
• Kéo thả các block: banner hero, slider, danh sách sản phẩm, combo sản phẩm, block ưu đãi, block social proof (testimonial, rating, số lượt mua), FAQ, form thu lead, countdown, bản đồ cửa hàng.
• Cấu hình nội dung chi tiết cho từng block: tiêu đề, mô tả, hình ảnh, video, giá, giá khuyến mãi, tag, badge (Best Seller, New, Limited, Flash Sale…).
• Thiết lập logic hiển thị theo điều kiện: hiển thị/ẩn block theo thiết bị (desktop/mobile), theo khung giờ, theo nguồn traffic (ví dụ chỉ hiện popup ưu đãi cho khách đến từ Facebook Ads).
• Gắn mã giảm giá riêng cho landing page, giới hạn số lần sử dụng, thời gian hiệu lực và điều kiện áp dụng (giá trị đơn tối thiểu, nhóm sản phẩm, khách hàng mới).

Trong sơ đồ use case, actor “Nhân viên marketing” được nối với use case “Tạo landing page kéo thả” và các use case liên quan như:

• Include “Gắn tracking chiến dịch”: cho phép gắn UTM, script theo dõi (Google Analytics, Facebook Pixel, TikTok Pixel, thẻ remarketing) ở cấp độ landing page, đảm bảo phân biệt được hiệu quả từng chiến dịch, từng nguồn traffic.
• Include “Cấu hình SEO cơ bản cho landing page”: chỉnh sửa title, meta description, slug URL, thẻ OG cho mạng xã hội, canonical URL, thẻ heading, ảnh đại diện khi share, giúp landing page vẫn có thể tận dụng organic traffic.
• Include “Xuất bản landing page với URL thân thiện”: cho phép chọn cấu trúc URL (theo chiến dịch, theo sản phẩm, theo kênh), thiết lập trạng thái nháp/xuất bản, lên lịch xuất bản và hết hạn landing page.

Ở mức độ chuyên sâu hơn, use case này có thể mở rộng thêm các ràng buộc:

• Quyền hạn theo vai trò: nhân viên marketing được tạo và chỉnh sửa landing page, nhưng chỉ quản trị viên mới được quyền xuất bản trên môi trường production.
• Quản lý phiên bản (versioning): lưu lịch sử chỉnh sửa landing page, cho phép rollback về phiên bản trước khi chạy A/B test thất bại.
• Hỗ trợ A/B testing: tạo nhiều biến thể landing page (thay đổi headline, CTA, bố cục), phân bổ traffic theo tỷ lệ và ghi nhận kết quả chuyển đổi cho từng biến thể.

Nhờ mô tả chi tiết trong sơ đồ use case, đội phát triển có thể hiểu rõ yêu cầu về tối ưu chuyển đổi, còn đội marketing nắm được các điểm chạm cần cấu hình để mỗi chiến dịch đều được đo lường chính xác và dễ dàng tối ưu.

Thu lead, gửi email, SMS, remarketing và chăm sóc lại khách bỏ giỏ hàng

Nhóm use case marketing liên quan đến thu lead và nuôi dưỡng khách hàng đóng vai trò trung tâm trong chiến lược tăng LTV (Lifetime Value) và giảm chi phí quảng cáo trên mỗi đơn hàng. Không chỉ dừng lại ở việc tạo form, hệ thống cần mô tả rõ luồng dữ liệu từ lúc khách để lại thông tin cho đến khi trở thành khách hàng trung thành.

Các use case chính bao gồm:

• “Tạo form thu lead”: định nghĩa trường dữ liệu (tên, email, số điện thoại, nguồn quan tâm, sản phẩm quan tâm, ngân sách…), thiết lập trường bắt buộc, xác thực định dạng, chính sách đồng ý nhận marketing (opt-in).
• “Gắn form vào landing page hoặc popup”: chọn vị trí hiển thị (giữa trang, cuối bài, sidebar), loại popup (exit-intent, scroll, time-based), tần suất hiển thị cho cùng một người dùng.
• “Đồng bộ lead sang hệ thống email marketing hoặc CRM”: mapping trường dữ liệu giữa website và CRM, xử lý trùng lặp (merge, update), gắn tag hoặc segment theo nguồn chiến dịch.
• “Gửi email tự động”: thiết lập workflow gửi email chào mừng, email cung cấp tài liệu, email nhắc giỏ hàng, email upsell/cross-sell, kịch bản re-engagement cho lead không tương tác.
• “Gửi SMS tự động”: gửi mã OTP, mã giảm giá, thông báo đơn hàng, nhắc thanh toán, nhắc giỏ hàng, giới hạn tần suất để tránh spam.
• “Thiết lập kịch bản chăm sóc khách bỏ giỏ hàng”: xác định trigger (add to cart nhưng không thanh toán sau X phút/giờ), số bước nhắc nhở, nội dung ưu đãi kèm theo.
• “Thiết lập kịch bản chăm sóc khách chưa hoàn tất thanh toán”: tập trung vào bước checkout bị bỏ dở, có thể gửi link thanh toán lại, gợi ý hỗ trợ qua hotline/chat.
• “Thiết lập kịch bản chăm sóc khách sau mua”: gửi email/SMS cảm ơn, hướng dẫn sử dụng, đề nghị đánh giá sản phẩm, đề xuất sản phẩm liên quan, chương trình khách hàng thân thiết.

Trong sơ đồ use case, actor “Hệ thống email”, “Hệ thống SMS”, “CRM” sẽ có association với các use case như “Gửi email tự động”, “Gửi SMS tự động”, “Đồng bộ lead”. Điều này thể hiện rõ các tích hợp bên thứ ba và luồng dữ liệu hai chiều giữa website và hệ thống marketing automation.

Use case “Chăm sóc khách bỏ giỏ hàng” thường include các use case con:

• “Gửi email nhắc nhở”: gửi 1–3 email theo timeline (ví dụ sau 1 giờ, 24 giờ, 72 giờ), có thể kèm ưu đãi tăng dần.
• “Gửi SMS nhắc nhở”: dùng cho các giỏ hàng giá trị cao hoặc khách hàng VIP, nội dung ngắn gọn kèm link quay lại giỏ.
• “Gửi thông báo đẩy nếu có app hoặc web push”: tận dụng push notification để kéo khách quay lại nhanh, đặc biệt hiệu quả trên mobile.

Ở mức chuyên sâu, sơ đồ use case nên thể hiện thêm:

• Điều kiện loại trừ: khách đã hoàn tất đơn thì dừng toàn bộ kịch bản nhắc giỏ, tránh gửi nhầm.
• Ưu tiên kênh: nếu khách đã mở email thì không gửi thêm SMS trong cùng một khoảng thời gian, tối ưu chi phí.
• Phân nhóm lead: lead mới, lead nóng (vừa xem nhiều sản phẩm), lead ngủ quên; mỗi nhóm có kịch bản chăm sóc khác nhau.

Tự động đăng bài mạng xã hội từ sản phẩm, bài viết và chương trình khuyến mãi

Để tối ưu thời gian vận hành, nhiều website bán hàng tích hợp chức năng tự động đăng bài lên mạng xã hội và coi website như một “content hub” trung tâm. Use case này giúp giảm thao tác lặp lại khi phải đăng cùng một nội dung lên nhiều nền tảng khác nhau, đồng thời đảm bảo thông tin sản phẩm và khuyến mãi luôn đồng bộ.

Các use case liên quan gồm:

• “Kết nối tài khoản mạng xã hội”: xác thực OAuth với Facebook, Instagram, Zalo, TikTok; lưu token, xử lý token hết hạn, chọn fanpage/profile cần đăng.
• “Cấu hình lịch đăng bài”: chọn múi giờ, khung giờ vàng theo từng kênh, tần suất đăng, ưu tiên loại nội dung (sản phẩm mới, bài blog, chương trình khuyến mãi).
• “Chọn sản phẩm hoặc bài viết để đăng”: lọc theo danh mục, tag, tồn kho, mức độ ưu tiên marketing; cho phép tạo queue nội dung.
• “Tự động đăng bài sản phẩm lên Facebook, Instagram, Zalo, TikTok”: sinh caption từ template (chèn tên sản phẩm, giá, mã giảm giá, link), chọn ảnh/video, gắn hashtag.
• “Tự động đăng chương trình khuyến mãi”: tạo post giới thiệu flash sale, voucher, combo, countdown, link về landing page chiến dịch.

Trong sơ đồ use case, actor “Mạng xã hội” sẽ có association với use case “Đăng bài tự động”, thể hiện vai trò của các nền tảng bên ngoài nhận nội dung từ website. Actor “Nhân viên marketing” được nối với use case “Cấu hình lịch đăng” và “Chọn nội dung đăng”, cho thấy người dùng chịu trách nhiệm chiến lược nội dung và lịch trình.

Ở mức chi tiết hơn, có thể bổ sung các ràng buộc và kịch bản lỗi:

• Xử lý khi API mạng xã hội lỗi hoặc giới hạn tần suất: hệ thống tự retry, log lỗi, thông báo cho nhân viên marketing.
• Quản lý trạng thái bài đăng: đã lên lịch, đã đăng, lỗi đăng, cần duyệt; cho phép hủy hoặc chỉnh sửa bài đã lên lịch.
• Đồng bộ link tracking: tự động gắn UTM theo kênh (utmsource=facebook, utmmedium=social, utmcampaign=flashsalex), giúp đo lường hiệu quả từng bài đăng.

Actor “Nền tảng quảng cáo” có association với use case “Nhận sự kiện chuyển đổi”, thể hiện việc website gửi event (purchase, lead, addtocart…) sang các nền tảng như Facebook, Google, TikTok. Sơ đồ use case nên làm rõ:

• Luồng dữ liệu một chiều (website → nền tảng quảng cáo) và các tham số được gửi (eventname, eventtime, eventid, value, currency, userdata như email hash, phone hash).
• Cách xử lý trùng lặp event (dựa trên eventid) khi dùng song song pixel và server-side tracking.
• Phân tách môi trường test và production để tránh làm bẩn dữ liệu chiến dịch thật.

Use case “Xem báo cáo hiệu quả chiến dịch” ở mức chuyên sâu có thể bao gồm:

• Lọc theo nguồn traffic (organic, direct, referral, paid), theo kênh quảng cáo (Facebook Ads, Google Ads, TikTok Ads), theo campaign/UTM.
• Phân tích theo landing page: số phiên, tỷ lệ thoát, tỷ lệ chuyển đổi, doanh thu, giá trị trung bình đơn hàng.
• So sánh trước – sau khi tối ưu (A/B test landing page, thay đổi kịch bản remarketing), hỗ trợ quyết định phân bổ ngân sách.

Nhờ đó, sơ đồ thể hiện rõ chuỗi giá trị từ traffic đến chuyển đổi và cách dữ liệu được gửi qua lại giữa website và nền tảng quảng cáo, giúp đội ngũ kỹ thuật, marketing và quản trị có cùng một “bản đồ” chung khi thiết kế và tối ưu hệ thống.

Bổ sung use case SEO kỹ thuật và tối ưu toàn trang

Hệ thống SEO kỹ thuật cần được thiết kế như một nền tảng quản trị đồng bộ, nơi mọi yếu tố onpage quan trọng đều được mô hình hóa thành use case rõ ràng cho từng loại trang. Từ việc quản lý title, meta, URL, heading, alt ảnh đến cấu hình schema, mỗi thao tác đều gắn với quy trình, quyền hạn và cơ chế kiểm soát chất lượng. Song song, một module audit SEO toàn trang đảm nhiệm quét index, phát hiện liên kết hỏng, nội dung trùng lặp, trang mỏng và xuất báo cáo ưu tiên xử lý. Lớp cấu hình sitemap, robots.txt, canonical, noindex và structured data được quản lý tập trung, tự động đồng bộ với trạng thái dữ liệu. Cuối cùng, các báo cáo traffic organic, truy vấn và chuyển đổi giúp kết nối hoạt động SEO với mục tiêu doanh thu, tối ưu phễu chuyển đổi một cách định lượng.

Quản lý title, meta description, URL, heading, alt ảnh và schema cho từng trang

SEO kỹ thuật và onpage trong website bán hàng không chỉ dừng ở mức “cho phép chỉnh sửa” mà cần được thiết kế như một hệ thống quản trị có quy trình, quyền hạn và kiểm soát chất lượng rõ ràng. Mỗi loại trang (trang chủ, danh mục, sản phẩm, bài viết blog, trang khuyến mãi, trang hệ thống như giỏ hàng, thanh toán) nên có bộ quy tắc SEO riêng, được mô hình hóa thành các use case chi tiết để đội phát triển dễ dàng triển khai.

Các use case quan trọng có thể được mở rộng như sau:

• Chỉnh sửa title và meta description cho từng trang:
  • Cho phép “Nhân viên SEO” cấu hình template động (sử dụng biến như {tênsảnphẩm}, {têndanhmục}, {thương_hiệu}) cho nhóm trang lớn, đồng thời vẫn cho phép override thủ công trên từng trang cụ thể.
  • Hệ thống nên có cơ chế kiểm tra độ dài (pixel width hoặc ký tự) và cảnh báo khi title/meta quá dài hoặc quá ngắn, cũng như phát hiện trùng lặp title/meta giữa các URL.
  • Use case phụ: “Xem lịch sử chỉnh sửa title/meta” giúp truy vết thay đổi khi hiệu suất SEO biến động.
• Tùy chỉnh URL thân thiện:
  • Hỗ trợ cấu trúc URL phân cấp theo danh mục (ví dụ: /dien-thoai/smartphone/iphone-15) và cho phép cấu hình pattern ở mức hệ thống.
  • Use case “Quản lý slug trùng lặp” để tự động thêm hậu tố phân biệt (ví dụ: -1, -2) hoặc gợi ý slug khác khi có xung đột.
  • Use case “Tạo redirect 301 khi đổi URL” nên được include trong “Tùy chỉnh URL thân thiện” để tránh mất traffic và tín hiệu SEO khi thay đổi đường dẫn.
• Quản lý heading H1, H2, H3 trên trang sản phẩm và bài viết:
  • Hệ thống cần đảm bảo mỗi trang chỉ có một H1, thường là tên sản phẩm hoặc tiêu đề bài viết, và cung cấp giao diện để “Nhân viên SEO” kiểm tra nhanh cấu trúc heading.
  • Use case “Xem sơ đồ heading của trang” cho phép hiển thị cây H1–H2–H3 để phát hiện lỗi như thiếu H1, nhảy cấp H3 không có H2, hoặc lạm dụng heading cho mục đích trình bày.
  • Đối với trang sản phẩm, các khối nội dung như “Mô tả chi tiết”, “Thông số kỹ thuật”, “Hướng dẫn sử dụng”, “Câu hỏi thường gặp” nên được gắn heading chuẩn để hỗ trợ cả SEO lẫn khả năng đọc.
• Quản lý thẻ alt cho hình ảnh:
  • Use case “Tự động sinh alt ảnh từ thuộc tính sản phẩm” (tên sản phẩm, màu sắc, mã SKU) giúp đảm bảo tất cả ảnh sản phẩm đều có alt mà không cần nhập tay từng ảnh.
  • Use case “Danh sách ảnh thiếu alt” cho phép “Nhân viên SEO” lọc và bổ sung alt cho các ảnh quan trọng (banner, infographic, hình hướng dẫn).
  • Hệ thống nên phân biệt alt cho ảnh trang trí (decorative) và ảnh nội dung chính, cho phép đánh dấu role=presentational hoặc để alt trống với ảnh không cần SEO.
• Cấu hình schema cho sản phẩm, bài viết, breadcrumb, FAQ:
  • Use case “Cấu hình schema sản phẩm” include:
    • Chọn loại schema (Product, Offer, AggregateRating, Review) tùy theo loại trang và dữ liệu sẵn có.
    • Điền thuộc tính bắt buộc như name, image, description, sku, brand, offers.price, offers.priceCurrency, offers.availability.
    • Điền thuộc tính khuyến nghị như aggregateRating, review, gtin, mpn để tăng khả năng hiển thị rich result.
    • Kiểm tra lỗi schema bằng cách tích hợp API kiểm tra hoặc xuất JSON-LD để “Nhân viên SEO” test trên công cụ bên ngoài.
  • Use case “Cấu hình schema breadcrumb” giúp tạo đường dẫn điều hướng rõ ràng, đồng bộ với cấu trúc URL và menu, hỗ trợ hiển thị breadcrumb trên SERP.
  • Use case “Cấu hình schema FAQ” cho phép gắn markup cho các khối Hỏi–Đáp trên trang sản phẩm hoặc bài viết hướng dẫn, tăng khả năng xuất hiện rich result dạng FAQ.

Trong sơ đồ use case, actor “Nhân viên SEO” hoặc “Nhân viên marketing” được nối với các use case trên. Ngoài ra, có thể chi tiết hóa mối quan hệ include/extend, ví dụ: use case “Chỉnh sửa trang sản phẩm” extend “Chỉnh sửa title và meta description”, “Quản lý heading”, “Cấu hình schema sản phẩm”, giúp đội phát triển hiểu rằng các thao tác SEO là một phần không thể tách rời của quy trình quản trị nội dung.

Phát hiện lỗi SEO toàn trang như index, liên kết hỏng, nội dung trùng lặp và trang mỏng

Để duy trì sức khỏe SEO, website cần một lớp giám sát kỹ thuật hoạt động định kỳ (theo lịch) hoặc theo sự kiện (khi tạo/sửa/xóa trang). Các use case kiểm tra và cảnh báo lỗi nên được thiết kế như một “module audit SEO” có thể mở rộng, với khả năng ghi log, phân quyền xem/sửa và tích hợp với hệ thống thông báo nội bộ.

Các chức năng có thể được chi tiết hóa:

• Quét trạng thái index của trang:
  • Use case “Kiểm tra chỉ thị index/noindex” đọc thẻ meta robots, header HTTP và file robots.txt để xác định trang có được phép index hay không.
  • Use case “Đối chiếu trạng thái index với công cụ tìm kiếm” (thông qua tích hợp API hoặc dữ liệu đồng bộ) giúp phát hiện trang được phép index nhưng chưa được index, hoặc ngược lại.
  • Hệ thống có thể gắn nhãn trang theo trạng thái: Indexable, Noindex, Blocked by robots, Canonicalized, hỗ trợ “Nhân viên SEO” ưu tiên xử lý.
• Phát hiện liên kết hỏng (404) và redirect lỗi:
  • Use case “Quét liên kết nội bộ” thu thập tất cả URL được liên kết trong menu, footer, nội dung, sitemap để kiểm tra mã phản hồi HTTP.
  • Use case “Phát hiện redirect lỗi” bao gồm:
    • Phát hiện chuỗi redirect (redirect chain) gây chậm và mất tín hiệu.
    • Phát hiện vòng lặp redirect (redirect loop) gây lỗi truy cập.
    • Phân loại redirect 301/302 để “Nhân viên SEO” đánh giá tính phù hợp.
  • Use case “Đề xuất sửa liên kết hỏng” có thể gợi ý URL thay thế dựa trên nội dung tương tự hoặc cấu trúc danh mục.
• Phát hiện nội dung trùng lặp:
  • Hệ thống nên so sánh:
    • Trùng lặp URL (cùng nội dung nhưng nhiều tham số, phiên bản có/không có slash, http/https, www/non-www).
    • Trùng lặp nội dung phần lớn (near-duplicate) giữa các trang sản phẩm tương tự, trang phân trang, trang lọc.
  • Use case “Nhóm trang trùng lặp” giúp gom các URL tương tự vào một cluster, gợi ý URL chuẩn để gắn canonical hoặc hợp nhất nội dung.
  • “Nhân viên SEO” có thể xem báo cáo chi tiết: mức độ trùng lặp (%), đoạn nội dung trùng, đề xuất xử lý (canonical, noindex, gộp trang).
• Phát hiện trang mỏng nội dung:
  • Use case “Đánh giá độ dày nội dung” dựa trên số lượng từ, số heading, số ảnh, thời gian onpage trung bình (nếu có dữ liệu), và loại trang.
  • Hệ thống có thể thiết lập ngưỡng khác nhau cho từng loại trang (ví dụ: trang sản phẩm tối thiểu X từ, bài blog tối thiểu Y từ).
  • Use case “Gắn nhãn trang mỏng” giúp “Nhân viên SEO” lập kế hoạch bổ sung nội dung, hợp nhất hoặc noindex các trang không mang lại giá trị.
• Xuất báo cáo lỗi SEO:
  • Báo cáo nên cho phép lọc theo loại lỗi (index, 404, redirect, trùng lặp, thin content), mức độ ưu tiên (cao, trung bình, thấp) và loại trang.
  • Use case “Xuất báo cáo lỗi SEO” có thể hỗ trợ nhiều định dạng (CSV, XLSX, PDF) để chia sẻ cho đội phát triển hoặc ban quản lý.
  • Use case “Lên lịch quét SEO định kỳ” giúp tự động cập nhật báo cáo, gửi email thông báo khi số lượng lỗi vượt ngưỡng.

Trong sơ đồ use case, actor “Nhân viên SEO” được nối với use case “Xem báo cáo lỗi SEO”, trong khi actor “Công cụ SEO bên ngoài” (nếu có) được nối với use case “Đồng bộ dữ liệu crawl”. Điều này nhấn mạnh rằng hệ thống nội bộ và công cụ bên ngoài cần phối hợp: dữ liệu crawl chi tiết từ bên ngoài kết hợp với hiểu biết ngữ cảnh từ hệ thống (loại trang, trạng thái xuất bản, quyền truy cập) để tạo nên một hệ thống giám sát kỹ thuật liên tục và đáng tin cậy.

Tạo sitemap, robots.txt, canonical và dữ liệu có cấu trúc cho sản phẩm, danh mục, bài viết

Các cấu hình kỹ thuật SEO cốt lõi như sitemap XML, robots.txt, canonical và structured data cần được quản lý tập trung, có giao diện cấu hình rõ ràng và cơ chế kiểm tra lỗi. Thay vì chỉnh sửa thủ công file tĩnh, hệ thống nên sinh động dựa trên trạng thái dữ liệu và quy tắc do “Quản trị viên” hoặc “Nhân viên SEO” thiết lập.

Các use case chính:

• Tạo và cập nhật sitemap XML:
  • Use case “Chọn loại nội dung đưa vào sitemap” cho phép bật/tắt:
    • Trang sản phẩm, danh mục, bài viết blog, trang tĩnh.
    • Trang khuyến mãi, landing page, trang tag (nếu cần).
  • Use case “Thiết lập tần suất cập nhật” (daily, weekly, real-time) và ưu tiên (priority) cho từng loại nội dung.
  • Use case “Gửi sitemap lên công cụ tìm kiếm” nếu hệ thống hỗ trợ tích hợp, hoặc ít nhất hiển thị URL sitemap để “Nhân viên SEO” submit thủ công.
  • Hệ thống nên tự động loại trừ trang noindex, trang bị chặn bởi robots.txt hoặc trang lỗi khỏi sitemap, tránh gửi tín hiệu mâu thuẫn.
• Cấu hình robots.txt:
  • Use case “Chỉnh sửa robots.txt an toàn” cho phép cấu hình qua giao diện, có kiểm tra cú pháp và cảnh báo khi chặn nhầm toàn bộ site hoặc thư mục quan trọng.
  • Hỗ trợ tạo rule riêng cho từng user-agent (Googlebot, Bingbot, AdsBot…) nếu cần tinh chỉnh.
  • Use case “Xem mô phỏng truy cập của bot” giúp “Nhân viên SEO” kiểm tra nhanh một URL cụ thể có bị chặn hay không.
• Cấu hình thẻ canonical cho trang sản phẩm, danh mục, bài viết:
  • Hệ thống nên tự động sinh canonical mặc định dựa trên URL chuẩn, đồng thời cho phép override trong trường hợp đặc biệt (ví dụ: landing page A canonical về trang sản phẩm B).
  • Use case “Quản lý canonical cho trang phân trang và trang lọc” để tránh trùng lặp nội dung do tham số lọc, sắp xếp, phân trang.
  • Use case “Kiểm tra xung đột canonical” phát hiện các trường hợp canonical trỏ vòng, canonical trỏ tới URL noindex hoặc khác domain.
• Cấu hình noindex cho trang không cần index:
  • Cho phép đánh dấu noindex theo loại trang (giỏ hàng, thanh toán, tài khoản, trang tìm kiếm nội bộ, trang lọc không có giá trị SEO).
  • Use case “Danh sách trang noindex” giúp “Nhân viên SEO” kiểm soát và rà soát định kỳ, tránh noindex nhầm trang quan trọng.
  • Hệ thống nên đồng bộ logic noindex với sitemap và internal link để không đẩy mạnh liên kết tới các trang đã noindex.
• Cấu hình dữ liệu có cấu trúc cho sản phẩm, danh mục, bài viết:
  • Đối với sản phẩm: ngoài schema Product, có thể cấu hình thêm Offer, AggregateRating, Review như đã nêu, đảm bảo tuân thủ guideline để tăng khả năng hiển thị rich result.
  • Đối với danh mục: use case “Cấu hình schema CollectionPage hoặc ItemList” giúp công cụ tìm kiếm hiểu đây là trang liệt kê sản phẩm, hỗ trợ hiển thị tốt hơn trong kết quả tìm kiếm.
  • Đối với bài viết: use case “Cấu hình schema Article/BlogPosting” với các thuộc tính như headline, author, datePublished, dateModified, image, giúp tăng độ tin cậy và khả năng xuất hiện trong Google Discover hoặc rich result.
  • Use case “Kiểm tra tính hợp lệ của structured data” có thể hiển thị cảnh báo khi thiếu thuộc tính bắt buộc hoặc dùng định dạng sai (ví dụ: sai định dạng ngày, giá không phải số).

Trong sơ đồ use case, actor “Quản trị viên” và “Nhân viên SEO” được nối với các use case cấu hình này. Use case “Tạo sitemap XML” include “Chọn loại nội dung đưa vào sitemap”, “Thiết lập tần suất cập nhật”, “Gửi sitemap lên công cụ tìm kiếm” nếu hệ thống hỗ trợ. Cách mô hình hóa này giúp đội phát triển nhận thức rằng nền tảng SEO kỹ thuật không chỉ là vài trường nhập liệu, mà là một tập hợp các quy tắc, quy trình và công cụ kiểm soát nhằm xây dựng một nền tảng SEO kỹ thuật vững chắc cho website bán hàng.

Theo dõi traffic organic, truy vấn tìm kiếm và tỷ lệ chuyển đổi từ SEO

Đo lường hiệu quả SEO cần được gắn chặt với mục tiêu kinh doanh, đặc biệt là doanh thu và tỷ lệ chuyển đổi. Các use case phân tích nên hỗ trợ “Nhân viên SEO” và “Nhân viên marketing” không chỉ xem số phiên organic, mà còn hiểu được hành vi người dùng, hiệu suất từng nhóm trang và đóng góp của SEO trong toàn bộ phễu chuyển đổi.

Các use case chính có thể được mở rộng:

• Xem báo cáo traffic organic:
  • Phân tách theo:
    • Loại trang (sản phẩm, danh mục, bài viết, landing page).
    • Thiết bị (desktop, mobile, tablet).
    • Kênh phụ (organic brand vs non-brand nếu có dữ liệu từ truy vấn).
  • Use case “So sánh traffic organic với các kênh khác” (direct, paid, social, referral) để đánh giá vai trò tương đối của SEO.
• Xem truy vấn tìm kiếm dẫn traffic:
  • Tích hợp với Google Search Console hoặc công cụ tương đương để lấy:
    • Truy vấn, số lần hiển thị, số lần nhấp, CTR, vị trí trung bình.
    • Trang đích tương ứng với từng truy vấn.
  • Use case “Nhóm truy vấn theo chủ đề” (brand, sản phẩm, vấn đề, so sánh, review) giúp “Nhân viên SEO” hiểu insight người dùng và tối ưu nội dung theo cụm chủ đề.
  • Use case “Phát hiện cơ hội tăng CTR” bằng cách lọc các truy vấn có vị trí tốt nhưng CTR thấp, gợi ý tối ưu title/meta, rich snippet.
• Xem trang đích organic hàng đầu:
  • Hiển thị danh sách trang đích theo traffic, thời gian onpage, tỷ lệ thoát, số phiên dẫn đến chuyển đổi.
  • Use case “So sánh hiệu suất trang đích trước và sau tối ưu” cho phép chọn khoảng thời gian, ghi chú các lần triển khai SEO (annotation) để đánh giá tác động.
  • “Nhân viên SEO” có thể lọc theo loại trang để xem, ví dụ: trang sản phẩm nào mang lại nhiều phiên organic nhưng tỷ lệ chuyển đổi thấp, từ đó phối hợp với UX và đội sản phẩm để cải thiện.
• Xem tỷ lệ chuyển đổi từ organic:
  • Tích hợp với hệ thống đo lường (Google Analytics hoặc công cụ phân tích khác) để theo dõi:
    • Doanh thu từ organic, số đơn hàng, giá trị đơn hàng trung bình.
    • Tỷ lệ chuyển đổi theo loại trang đích, theo thiết bị, theo chiến dịch nội dung.
  • Use case “Gán mục tiêu (goal) cho hành vi quan trọng” như thêm vào giỏ, bắt đầu thanh toán, đăng ký tài khoản, đăng ký nhận bản tin, để đo lường đóng góp của SEO trong từng bước của phễu.
  • Use case “Phân bổ doanh thu theo truy vấn hoặc nhóm truy vấn” (nếu dữ liệu cho phép) giúp hiểu truy vấn nào mang lại giá trị kinh doanh cao nhất.
• So sánh hiệu quả SEO theo thời gian:
  • Cho phép so sánh theo:
    • Tháng/Quý/Năm, hoặc trước–sau khi triển khai chiến dịch SEO lớn.
    • So sánh cùng kỳ năm trước để loại bỏ yếu tố mùa vụ.
  • Use case “Gắn mốc sự kiện” (triển khai redesign, thay đổi cấu trúc URL, cập nhật thuật toán lớn) để phân tích biến động traffic và chuyển đổi.
  • Use case “Xuất báo cáo SEO cho ban quản lý” tập trung vào chỉ số kinh doanh (doanh thu organic, chi phí ước tính nếu mua traffic tương đương qua quảng cáo) nhằm chứng minh ROI của SEO.

Trong sơ đồ use case, actor “Nhân viên SEO” và “Nhân viên marketing” được nối với use case “Xem báo cáo SEO”. Actor “Công cụ phân tích” có association với use case “Nhận dữ liệu traffic và truy vấn”. Cách thiết kế này giúp đảm bảo rằng SEO không chỉ dừng ở việc tối ưu kỹ thuật và nội dung, mà còn được đo lường một cách định lượng, gắn trực tiếp với doanh thu và hiệu quả kinh doanh, từ đó ưu tiên nguồn lực và ra quyết định chiến lược một cách chính xác hơn.

Bổ sung use case bảo vệ quảng cáo và chống click tặc

Use case này mở rộng hệ thống chống click tặc thành một lớp bảo vệ toàn diện cho ngân sách quảng cáo trả phí. Trọng tâm là theo dõi sâu hành vi click theo IP, thiết bị, vị trí, tần suất và ngữ cảnh chiến dịch để phân biệt click sạch và click gian lận. Dữ liệu log chi tiết được phân tích theo thời gian thực nhằm phát hiện pattern bất thường, sau đó chuyển thành hành động: chặn IP, tạo blacklist, đồng bộ danh sách loại trừ sang Google Ads, Facebook Ads… và kích hoạt cảnh báo khi tỷ lệ click nghi ngờ hoặc chi phí lãng phí vượt ngưỡng. Lớp báo cáo và tích hợp giúp đội marketing vừa giám sát hiệu quả bảo vệ, vừa tối ưu chiến dịch dựa trên insight về nguồn traffic kém chất lượng.

Theo dõi lượt click quảng cáo theo IP, thiết bị, vị trí, tần suất và hành vi bất thường

Để bảo vệ ngân sách quảng cáo trả tiền (Google Ads, Facebook Ads, TikTok Ads, Display Network…), hệ thống chống click tặc cần được thiết kế như một lớp giám sát chuyên sâu trên toàn bộ hành trình click. Không chỉ dừng ở việc “đếm số lượt click”, hệ thống phải thu thập và tương quan nhiều trường dữ liệu kỹ thuật nhằm nhận diện mẫu hành vi bất thường theo thời gian thực.

Các use case chi tiết có thể mở rộng như sau:

• Ghi nhận lượt click quảng cáo: Mỗi khi người dùng click vào quảng cáo, hệ thống ghi log với các trường:
  • ID chiến dịch, ID nhóm quảng cáo, ID quảng cáo, từ khóa (nếu có)
  • Thời gian click (timestamp chuẩn UTC, kèm timezone)
  • Referrer, UTM source/medium/campaign/content/term
  • Loại thiết bị (desktop, mobile, tablet), hệ điều hành, trình duyệt, phiên bản
  • User agent đầy đủ để phục vụ phân tích bot/script
  • Địa chỉ IP, country, region, city, ISP, ASN (Autonomous System Number)
  • Fingerprint thiết bị (nếu có): độ phân giải màn hình, ngôn ngữ trình duyệt, timezone, canvas fingerprint…
• Theo dõi IP, thiết bị, vị trí, thời gian: Hệ thống xây dựng hồ sơ hành vi cho từng:
  • IP hoặc dải IP (subnet)
  • Thiết bị (device ID, fingerprint)
  • Vị trí địa lý (geo profile theo quốc gia/thành phố)
  • Khung giờ hoạt động (time-of-day pattern)

  Mục tiêu là phát hiện các pattern như: IP từ một quốc gia không nằm trong target nhưng lại có tần suất click cao, hoặc một thiết bị duy nhất click vào nhiều chiến dịch khác nhau trong thời gian ngắn.

• Phân tích tần suất click: Use case này không chỉ đếm số click mà còn:
  • Tính toán số click trên mỗi:
    • IP / thiết bị / user agent / vị trí
    • Chiến dịch / nhóm quảng cáo / từ khóa
    • Khoảng thời gian (phút, giờ, ngày)
  • Xác định ngưỡng tần suất bình thường dựa trên dữ liệu lịch sử
  • Phát hiện spike bất thường (sudden burst) theo thời gian thực
• Phát hiện hành vi bất thường: Hệ thống có thể áp dụng rule-based hoặc machine learning:
  • Click lặp lại từ cùng IP hoặc cùng fingerprint trong khoảng thời gian rất ngắn (ví dụ < 10 giây)
  • Chuỗi click dày đặc nhưng không có:
    • Thời gian on-site tối thiểu (time on page < 3–5 giây)
    • Scroll, click nội bộ, xem nhiều trang, thêm giỏ, gửi form
  • Click đến từ các dải IP đã được cộng đồng hoặc nội bộ đánh dấu là data center, proxy, VPN, botnet
  • Hành vi “quét” nhiều quảng cáo khác nhau trong cùng một phiên trình duyệt
  • Mẫu hành vi lặp lại theo chu kỳ (ví dụ cứ mỗi 5 phút lại có 10 click từ cùng một ASN)

Trong sơ đồ use case, actor “Nền tảng quảng cáo” được nối với use case “Nhận thông tin chiến dịch” để hệ thống chống click tặc nắm được cấu trúc chiến dịch, ngân sách, target. Actor “Hệ thống chống click tặc” (nếu là module riêng) được nối với use case “Phân tích hành vi click”, thể hiện vai trò xử lý dữ liệu log và áp dụng thuật toán phát hiện gian lận. Actor “Nhân viên marketing” được nối với use case “Xem báo cáo click bất thường”, cho phép họ truy cập dashboard hiển thị:

• Danh sách IP/thiết bị nghi ngờ
• Biểu đồ tần suất click theo thời gian
• Bản đồ nhiệt (heatmap) vị trí click
• Tỷ lệ click nghi ngờ trên từng chiến dịch

Cách mô hình hóa này giúp phân tách rõ vai trò: nền tảng cung cấp dữ liệu chiến dịch, hệ thống chống click tặc phân tích, và đội marketing ra quyết định tối ưu.

Chặn click nghi ngờ, tạo danh sách loại trừ và cảnh báo ngân sách quảng cáo bị lãng phí

Sau khi phát hiện hành vi bất thường, lớp xử lý là nơi chuyển đổi kết quả phân tích thành hành động cụ thể để giảm thiểu thiệt hại. Các use case xử lý cần được thiết kế theo hướng tự động hóa tối đa nhưng vẫn cho phép nhân viên marketing kiểm soát và can thiệp khi cần.

• Chặn click từ IP nghi ngờ:
  • Tự động tạo rule chặn ở:
    • Layer ứng dụng (web server, WAF, reverse proxy)
    • Layer nền tảng quảng cáo (IP exclusion, block list)
  • Cho phép cấu hình:
    • Thời gian chặn (tạm thời hoặc vĩnh viễn)
    • Ngưỡng trước khi chặn (ví dụ: > 5 click/giờ không có session hợp lệ)
• Tạo danh sách IP loại trừ:
  • Tự động gom nhóm IP nghi ngờ thành:
    • Danh sách IP đơn lẻ
    • Dải IP (CIDR) nếu phát hiện pattern theo subnet
  • Phân loại danh sách:
    • Danh sách tạm thời (temporary blacklist)
    • Danh sách vĩnh viễn (permanent blacklist)
  • Ghi log lý do bị đưa vào danh sách (rule vi phạm, chiến dịch liên quan, thời điểm)
• Đồng bộ danh sách loại trừ sang nền tảng quảng cáo:
  • Use case này kết nối với API của Google Ads, Facebook Ads… để:
    • Push danh sách IP loại trừ vào từng tài khoản/quảng cáo
    • Đảm bảo đồng bộ hai chiều: nếu IP đã bị loại trừ ở nền tảng, hệ thống cũng cập nhật trạng thái
  • Quản lý version của danh sách loại trừ để có thể rollback khi cấu hình sai
• Gửi cảnh báo khi tỷ lệ click nghi ngờ vượt ngưỡng:
  • Cho phép “Nhân viên marketing” cấu hình:
    • Ngưỡng tỷ lệ click nghi ngờ (ví dụ > 15% tổng click trong 1 giờ)
    • Ngưỡng số lượng tuyệt đối (ví dụ > 50 click nghi ngờ/giờ)
    • Kênh cảnh báo: email, SMS, Slack, webhook
  • Cảnh báo có thể chi tiết theo:
    • Chiến dịch / nhóm quảng cáo / từ khóa
    • Khu vực địa lý hoặc nguồn traffic
• Gửi cảnh báo khi ngân sách có dấu hiệu bị lãng phí:
  • So sánh:
    • Chi phí quảng cáo tiêu thụ vs. số phiên chất lượng (session có tương tác)
    • Chi phí vs. số chuyển đổi (conversion) hoặc micro-conversion
  • Phát hiện chiến dịch có:
    • CTR cao nhưng conversion rate thấp bất thường
    • Tỷ lệ click nghi ngờ tăng song song với chi phí

Trong sơ đồ use case, actor “Nhân viên marketing” được nối với use case “Cấu hình ngưỡng cảnh báo” và “Quản lý danh sách loại trừ”, thể hiện quyền chủ động điều chỉnh chiến lược bảo vệ. Actor “Nền tảng quảng cáo” có association với use case “Nhận danh sách loại trừ”, cho thấy luồng dữ liệu từ hệ thống chống click tặc sang tài khoản quảng cáo. Cách mô hình hóa này làm rõ vòng lặp phát hiện – xử lý – tối ưu, trong đó phát hiện dựa trên dữ liệu click, xử lý bằng cơ chế chặn và loại trừ, và tối ưu thông qua điều chỉnh ngưỡng, chiến dịch và ngân sách.

Xuất báo cáo click sạch, click nghi ngờ và nguồn traffic kém chất lượng

Layer báo cáo là nơi tổng hợp và trực quan hóa dữ liệu để đội marketing và quản lý có thể đánh giá hiệu quả chống click tặc, đồng thời ra quyết định tối ưu chiến dịch. Báo cáo cần phân tách rõ giữa click sạch, click nghi ngờ và nguồn traffic kém chất lượng (low-quality traffic source).

• Xem báo cáo tổng quan click:
  • Biểu đồ tổng số click theo thời gian, phân tách:
    • Click sạch
    • Click nghi ngờ
    • Click đã bị chặn
  • Chỉ số tổng hợp:
    • Tỷ lệ click nghi ngờ trên tổng click
    • Chi phí ước tính bị lãng phí do click tặc
• Xem tỷ lệ click sạch và click nghi ngờ:
  • Phân tích theo:
    • Chiến dịch, nhóm quảng cáo, quảng cáo, từ khóa
    • Kênh quảng cáo (Google, Facebook, Display, Affiliate…)
    • Thiết bị, vị trí địa lý, ISP, ASN
  • So sánh trước và sau khi áp dụng rule chống click tặc để đo hiệu quả.
• Xem nguồn traffic kém chất lượng:
  • Danh sách:
    • IP/dải IP có tỷ lệ click nghi ngờ cao
    • Website referral hoặc placement có chất lượng thấp
    • Khu vực địa lý thường xuyên phát sinh click tặc
  • Gợi ý hành động:
    • Giảm bid hoặc loại trừ khu vực/placement
    • Điều chỉnh target thiết bị hoặc network
• Xuất báo cáo chi tiết theo chiến dịch, nhóm quảng cáo, từ khóa:
  • Cho phép lọc:
    • Khoảng thời gian
    • Kênh quảng cáo
    • Loại click (sạch, nghi ngờ, bị chặn)
  • Xuất file:
    • CSV, XLSX, PDF (tùy cấu hình)
    • Có thể ẩn/hiện các cột kỹ thuật như IP, user agent, ASN
• Xuất báo cáo theo IP hoặc dải IP:
  • Phục vụ:
    • Điều tra nội bộ
    • Làm bằng chứng khi khiếu nại với nền tảng quảng cáo
  • Chi tiết:
    • Timeline click của IP đó
    • Các chiến dịch bị ảnh hưởng
    • Chi phí ước tính liên quan đến IP/dải IP

Trong sơ đồ use case, actor “Nhân viên marketing” được nối với use case “Xuất báo cáo click”. Use case này có thể include các use case con như “Chọn khoảng thời gian”, “Chọn chiến dịch hoặc kênh quảng cáo”, “Chọn định dạng xuất file”. Nhờ đó, dữ liệu chống click tặc có thể được chia sẻ với đối tác, bộ phận tài chính, hoặc dùng làm bằng chứng khi khiếu nại với nền tảng quảng cáo về việc hoàn tiền cho click không hợp lệ.

Đồng bộ dữ liệu click với chiến dịch Google Ads, Facebook Ads hoặc kênh quảng cáo liên quan

Để hệ thống chống click tặc thực sự trở thành trung tâm điều phối dữ liệu quảng cáo, lớp tích hợp với các nền tảng quảng cáo là bắt buộc. Use case “Đồng bộ dữ liệu click với chiến dịch quảng cáo” đảm bảo dữ liệu được trao đổi hai chiều, giúp tối ưu cả ở phía website lẫn phía tài khoản quảng cáo.

• Kết nối tài khoản Google Ads, Facebook Ads:
  • Quy trình OAuth để cấp quyền truy cập:
    • Đọc danh sách chiến dịch, nhóm quảng cáo, quảng cáo
    • Gửi danh sách IP loại trừ
    • Gửi sự kiện hoặc conversion tùy chỉnh (nếu cần)
  • Quản lý nhiều tài khoản, nhiều MCC/Business Manager trong cùng một hệ thống.
• Lấy danh sách chiến dịch và nhóm quảng cáo:
  • Đồng bộ định kỳ hoặc theo yêu cầu:
    • Tên chiến dịch, trạng thái, ngân sách, bid strategy
    • Nhóm quảng cáo, từ khóa, placement
  • Mapping ID chiến dịch từ nền tảng với ID nội bộ của hệ thống chống click tặc.
• Gắn mã theo dõi vào URL quảng cáo:
  • Tự động thêm:
    • UTM parameters
    • Click ID riêng (ví dụ: cid, click_id) để liên kết log click với session trên website
  • Đảm bảo không phá vỡ tracking hiện có (Google Analytics, Facebook Pixel…).
• Gửi danh sách IP loại trừ:
  • Đồng bộ:
    • Danh sách IP bị chặn mới
    • Cập nhật hoặc gỡ bỏ IP khỏi danh sách loại trừ khi hết thời hạn chặn
  • Ghi nhận phản hồi từ API nền tảng (thành công/thất bại) để hiển thị trong giao diện quản trị.
• Gửi sự kiện click nghi ngờ:
  • Đánh dấu các click nghi ngờ như một loại event riêng:
    • Có thể dùng cho tối ưu bidding hoặc làm tín hiệu cho các hệ thống khác
  • Cho phép tắt/bật việc gửi sự kiện này theo từng kênh quảng cáo để tránh ảnh hưởng đến thuật toán tối ưu của nền tảng.

Trong sơ đồ use case, actor “Nền tảng quảng cáo” được nối với use case “Đồng bộ chiến dịch” và “Nhận danh sách loại trừ”, thể hiện luồng dữ liệu chiến dịch đi vào và danh sách IP bị loại trừ đi ra. Actor “Nhân viên marketing” được nối với use case “Cấu hình kết nối quảng cáo”, bao gồm việc chọn tài khoản, phân quyền, thiết lập tần suất đồng bộ và quy tắc áp dụng danh sách loại trừ. Nhờ đó, website bán hàng không chỉ là điểm đến của traffic mà trở thành một hub dữ liệu, nơi tập trung log click, phân tích gian lận, điều phối danh sách loại trừ và cung cấp insight ngược lại cho các nền tảng quảng cáo.

Vẽ sơ đồ use case website bán hàng từng bước từ yêu cầu đến bản hoàn chỉnh

Sơ đồ use case cho website bán hàng cần được xây dựng như một bản phân tích nghiệp vụ, phản ánh rõ mục tiêu kinh doanh, phạm vi triển khai và từng nhóm người dùng. Từ đó, xác định đầy đủ actor chính, actor phụ và các hệ thống tích hợp như cổng thanh toán, vận chuyển, CRM, email/SMS. Các use case nên được gom theo domain: mua hàng, quản trị, marketing, SEO, thanh toán và vận chuyển để dễ tách module và phân công phát triển. Tiếp theo, nối actor với use case bằng association, kiểm tra chức năng bị thiếu, dùng include cho các luồng dùng chung (đăng nhập, tính phí, gửi thông báo) và extend cho các nhánh tùy chọn (thanh toán online, mã giảm giá). Cuối cùng, rà soát toàn bộ sơ đồ theo hành trình khách hàng, vận hành nội bộ và mục tiêu marketing – SEO để đảm bảo tính đầy đủ và nhất quán.

Bước 1: xác định mục tiêu website bán hàng, phạm vi hệ thống và nhóm người dùng

Để vẽ sơ đồ use case một cách chuyên nghiệp, cần bắt đầu như một bài toán phân tích nghiệp vụ chứ không chỉ là vẽ hình. Ở bước này, nên làm rõ ba trục chính: mục tiêu kinh doanh, phạm vi hệ thống và nhóm người dùng. Mỗi quyết định ở bước này sẽ chi phối trực tiếp đến việc chọn actor, chọn use case, mức độ chi tiết và cả cách tách sơ đồ thành các module.

1. Mục tiêu kinh doanh: không chỉ dừng ở “bán được hàng”, mà cần cụ thể hóa:

• B2C bán lẻ: tập trung vào trải nghiệm người dùng cuối, tối ưu chuyển đổi, khuyến mãi, upsell, cross-sell, SEO, remarketing.
• B2B bán sỉ: nhấn mạnh vào bảng giá theo cấp đại lý, quy trình duyệt đơn, công nợ, báo giá, đặt hàng theo lô, hạn mức tín dụng.
• Omni-channel (online – offline): cần thêm các use case liên quan đến đồng bộ tồn kho, đồng bộ giá, click & collect, đổi trả tại cửa hàng.
• Marketplace: phải mô hình hóa thêm actor Nhà bán hàng, use case quản lý gian hàng, quản lý hoa hồng, đối soát, phê duyệt sản phẩm.

Mỗi mô hình kinh doanh sẽ kéo theo một “bộ use case lõi” khác nhau. Khi phân tích, nên ghi chú rõ mô hình được chọn để tránh trộn lẫn yêu cầu của nhiều mô hình trong cùng một sơ đồ.

2. Phạm vi giai đoạn (scope): cần phân biệt rõ MVP, phiên bản pilot, và phiên bản full feature. Với mỗi giai đoạn, mức độ chi tiết của use case và số lượng actor có thể khác nhau:

• MVP: tập trung vào luồng mua hàng tối thiểu: duyệt sản phẩm, giỏ hàng, đặt hàng, thanh toán cơ bản, quản trị đơn hàng và sản phẩm.
• Giai đoạn mở rộng: bổ sung loyalty, voucher phức tạp, affiliate, tích hợp CRM, marketing automation, phân tích hành vi.
• Full feature: bao phủ toàn bộ quy trình từ marketing, bán hàng, chăm sóc sau bán, báo cáo tài chính, kho, logistics.

Việc “đóng khung” phạm vi giúp tránh việc sơ đồ use case bị phình to, khó đọc, khó triển khai. Những chức năng nằm ngoài phạm vi có thể ghi chú như future scope thay vì đưa vào sơ đồ chính.

3. Nhóm người dùng: cần phân biệt rõ nhóm người dùng theo vai trò nghiệp vụ và theo quyền hệ thống. Một người có thể đóng nhiều vai trò, nhưng trong sơ đồ use case nên tách thành các actor độc lập để dễ phân tích:

• Khách truy cập (Visitor): chưa đăng nhập, chủ yếu xem nội dung, tìm kiếm, thêm vào giỏ, đăng ký nhận tin.
• Khách hàng (Customer): đã có tài khoản hoặc đã từng mua, có thể quản lý đơn, thông tin cá nhân, điểm thưởng, đánh giá sản phẩm.
• Admin hệ thống: quản trị toàn bộ, cấu hình hệ thống, phân quyền, giám sát log, backup, bảo mật.
• Nhân viên CSKH, nhân viên bán hàng, kế toán, kho: mỗi nhóm có tập use case nghiệp vụ riêng, liên quan đến quy trình nội bộ.

Bảng minh họa xác định mục tiêu và phạm vi:

Bước 2: liệt kê actor chính, actor phụ và hệ thống tích hợp bên ngoài

Sau khi đã có bức tranh tổng thể, bước tiếp theo là phân loại actor một cách có hệ thống. Actor trong UML là bất kỳ thực thể nào tương tác với hệ thống để đạt được một mục tiêu, không chỉ là con người. Ở website bán hàng, cần chú ý ba nhóm: người dùng bên ngoài, người dùng nội bộ và hệ thống tích hợp.

1. Actor chính (primary actors): là những actor khởi xướng các luồng nghiệp vụ quan trọng, thường liên quan trực tiếp đến doanh thu hoặc trải nghiệm khách hàng:

• Khách truy cập: khởi xướng luồng khám phá sản phẩm, tìm kiếm, xem nội dung, đăng ký tài khoản.
• Khách hàng: khởi xướng luồng đặt hàng, thanh toán, đánh giá, yêu cầu hỗ trợ.
• Quản trị viên: khởi xướng các luồng cấu hình hệ thống, quản lý người dùng, phân quyền, quản lý nội dung.
• Nhân viên CSKH / bán hàng: khởi xướng luồng tạo đơn hộ khách, xử lý khiếu nại, hỗ trợ đổi trả.

2. Actor phụ (secondary actors): thường không khởi xướng luồng chính nhưng tham gia hỗ trợ, cung cấp dữ liệu hoặc xử lý hậu trường:

• Nhân viên marketing: tạo chiến dịch, cấu hình banner, popup, chương trình khuyến mãi, tracking.
• Nhân viên SEO: tối ưu metadata, URL, schema, sitemap, theo dõi báo cáo organic.
• Kế toán: đối soát thanh toán, xuất hóa đơn, xử lý hoàn tiền, ghi nhận doanh thu.
• Nhân viên kho: xác nhận tồn kho, xử lý xuất – nhập, kiểm kê, đồng bộ với hệ thống bán hàng.

3. Hệ thống tích hợp bên ngoài: là các actor dạng hệ thống, thường giao tiếp qua API, webhook, file batch. Khi mô hình hóa, nên coi chúng như actor độc lập để thể hiện rõ ràng ranh giới hệ thống:

• Cổng thanh toán: xử lý giao dịch online, trả về trạng thái thành công/thất bại, mã giao dịch.
• Đơn vị vận chuyển: nhận yêu cầu tạo vận đơn, trả về mã vận đơn, trạng thái giao hàng.
• Hệ thống email, SMS: gửi thông báo đơn hàng, OTP, chăm sóc sau bán.
• CRM, nền tảng quảng cáo, mạng xã hội: nhận dữ liệu lead, event tracking, đồng bộ tệp khách hàng.

Bảng phân loại actor:

Bước 3: gom nhóm use case theo mua hàng, quản trị, marketing, SEO, thanh toán và vận chuyển

Khi đã có danh sách actor, bước tiếp theo là “map” các mục tiêu nghiệp vụ thành các use case và gom nhóm chúng theo domain chức năng. Cách gom nhóm hợp lý giúp sơ đồ dễ đọc, dễ bảo trì và thuận tiện cho việc phân chia module phát triển.

1. Nhóm Mua hàng (Shopping & Ordering):

• Khám phá & tìm kiếm: duyệt danh mục, tìm kiếm theo từ khóa, lọc, sắp xếp, xem chi tiết sản phẩm, xem sản phẩm liên quan.
• Giỏ hàng & wishlist: thêm/xóa/sửa số lượng, lưu giỏ, lưu danh sách yêu thích, ước tính phí vận chuyển.
• Đặt hàng: chọn địa chỉ giao hàng, chọn phương thức thanh toán, chọn phương thức vận chuyển, xác nhận đơn.
• Sau mua: theo dõi trạng thái đơn, yêu cầu hủy, yêu cầu đổi trả, đánh giá sản phẩm.

2. Nhóm Quản trị (Back-office & Operations):

• Quản lý sản phẩm: CRUD sản phẩm, biến thể, giá, tồn kho, thuộc tính, danh mục, tag.
• Quản lý đơn hàng: xem, cập nhật trạng thái, ghi chú nội bộ, xử lý hủy/đổi/trả, xuất file.
• Quản lý khách hàng: hồ sơ khách, phân nhóm, lịch sử mua, ghi chú CSKH.
• Quản lý nội dung: banner, landing page, blog, FAQ, trang chính sách.
• Phân quyền & bảo mật: tạo role, gán quyền, khóa/mở tài khoản nội bộ.

3. Nhóm Marketing:

• Quản lý chiến dịch: tạo chiến dịch, gắn UTM, cấu hình popup, banner theo kênh.
• Thu lead: form đăng ký, thu thập email/phone, đồng bộ CRM.
• Automation: kịch bản email/SMS chăm sóc, nhắc giỏ bỏ quên, winback khách cũ.
• Tracking: cấu hình pixel, event, conversion, xuất báo cáo hiệu quả kênh.

4. Nhóm SEO:

• SEO onpage: chỉnh title, meta description, slug, heading, alt image.
• SEO kỹ thuật: sitemap, robots.txt, canonical, schema, redirect.
• Báo cáo SEO: theo dõi organic traffic, từ khóa, landing page, lỗi crawl.

5. Nhóm Thanh toán & Vận chuyển:

• Thanh toán: COD, thanh toán online, lưu token thẻ (nếu có), xử lý hoàn tiền.
• Vận chuyển: tạo vận đơn, in nhãn, đồng bộ trạng thái giao hàng, tính phí theo vùng.
• Chống click tặc (nếu có): ghi nhận click, phát hiện bất thường, chặn IP, báo cáo.

Việc gom nhóm này không chỉ phục vụ sơ đồ use case mà còn là cơ sở để tách module hệ thống, phân chia team phát triển, và thiết kế kiến trúc microservice nếu cần.

Bước 4: nối actor với use case bằng association và kiểm tra chức năng bị thiếu

Khi đã có danh sách use case theo nhóm, bước tiếp theo là vẽ các đường association giữa actor và use case. Đây là lúc kiểm tra lại tính hợp lý của phân quyền và đảm bảo không bỏ sót nhu cầu của bất kỳ actor nào.

1. Quy tắc nối association:

• Khách truy cập: chỉ được nối với các use case không yêu cầu đăng nhập như xem sản phẩm, tìm kiếm, thêm vào giỏ, đăng ký tài khoản, đăng ký nhận tin.
• Khách hàng: được nối với các use case liên quan đến tài khoản, đơn hàng, đánh giá, quản lý địa chỉ, điểm thưởng.
• Quản trị viên, nhân viên nội bộ: nối với các use case quản trị, vận hành, báo cáo, nhưng cần phân biệt rõ ai được quyền gì để tránh “over-privilege”.
• Hệ thống bên ngoài: nối với các use case tích hợp như “Xử lý thanh toán online”, “Tạo vận đơn”, “Gửi email thông báo”.

2. Kiểm tra use case mồ côi và actor “nhàn rỗi”:

• Use case không gắn với actor nào: thường là chức năng thừa, hoặc mô tả chưa rõ ai là người sử dụng/thụ hưởng. Cần làm rõ lại với stakeholder.
• Actor có quá ít use case: có thể là do phân tích thiếu nhu cầu, hoặc actor đó thực sự không cần xuất hiện trong phạm vi giai đoạn này.

3. Kiểm tra tính nhất quán phân quyền: khi nối association, nên rà lại ma trận phân quyền (nếu có) để đảm bảo sơ đồ use case phản ánh đúng chính sách bảo mật. Ví dụ, nhân viên CSKH có thể xem nhưng không được xóa đơn; nhân viên marketing có thể cấu hình chiến dịch nhưng không được thay đổi cấu hình hệ thống.

Bước 5: thêm include, extend cho đăng nhập, thanh toán, áp mã giảm giá và gửi thông báo

Sau khi hoàn thành association cơ bản, cần tối ưu sơ đồ bằng cách sử dụng include và extend để tránh lặp lại và thể hiện rõ các nhánh điều kiện. Đây là bước mang tính “kỹ thuật UML” nhiều hơn, nhưng ảnh hưởng lớn đến khả năng đọc hiểu và tái sử dụng.

1. Use case dùng chung – dùng include:

• Đăng nhập / Xác thực: được nhiều luồng như “Đặt hàng”, “Quản lý tài khoản”, “Quản trị hệ thống” include.
• Xác thực thông tin khách hàng: kiểm tra địa chỉ, số điện thoại, email, điều kiện giao hàng.
• Tính phí vận chuyển: dùng chung cho giỏ hàng, trang thanh toán, ước tính phí.
• Tính khuyến mãi: áp dụng rule khuyến mãi, voucher, combo, giá theo nhóm khách.
• Gửi thông báo: “Gửi email thông báo”, “Gửi SMS thông báo” được include bởi các use case như “Đặt hàng thành công”, “Cập nhật trạng thái đơn”.

2. Use case tùy chọn – dùng extend:

• Thanh toán online: extend từ “Đặt hàng” khi khách chọn phương thức online.
• Áp mã giảm giá: extend khi khách nhập mã voucher, có thể kèm theo luồng lỗi khi mã không hợp lệ.
• Chọn gói vận chuyển nhanh: extend khi khách chọn dịch vụ giao nhanh, giao trong ngày.
• Nhận hóa đơn VAT: extend khi khách yêu cầu xuất hóa đơn, bổ sung thông tin công ty.

Ví dụ: use case “Đặt hàng” include “Xác thực thông tin khách hàng” và “Tính phí vận chuyển”, extend “Thanh toán online” khi khách chọn phương thức online, extend “Áp mã giảm giá” khi khách nhập mã. Cách mô hình hóa này giúp sơ đồ tránh lặp lại các bước chung và thể hiện rõ các nhánh tùy chọn trong quy trình, đồng thời hỗ trợ đội phát triển tách các module dùng chung thành service độc lập.

Bước 6: rà soát sơ đồ theo hành trình khách hàng, vận hành nội bộ và mục tiêu marketing

Bước cuối cùng là kiểm thử sơ đồ use case ở mức nghiệp vụ, bằng cách soi chiếu theo ba góc nhìn: hành trình khách hàng, vận hành nội bộ và marketing – SEO. Mục tiêu là đảm bảo sơ đồ không chỉ đúng về mặt kỹ thuật UML mà còn đầy đủ về mặt kinh doanh.

1. Góc nhìn hành trình khách hàng (Customer Journey):

• Giai đoạn nhận biết: khách truy cập từ quảng cáo, mạng xã hội, organic – có đủ use case cho landing page, tracking, thu lead chưa?
• Giai đoạn cân nhắc: khách so sánh sản phẩm, đọc review, xem FAQ – đã có use case cho đánh giá, Q&A, so sánh sản phẩm?
• Giai đoạn mua: luồng giỏ hàng, thanh toán, lựa chọn vận chuyển – có đầy đủ các nhánh COD, online, voucher, phí ship?
• Giai đoạn sau mua: theo dõi đơn, đổi trả, bảo hành, chăm sóc – đã mô hình hóa các use case hỗ trợ sau bán?

2. Góc nhìn vận hành nội bộ:

• Quy trình xử lý đơn: từ khi đơn được tạo đến khi giao thành công/hủy – có đủ use case cho từng trạng thái, từng bộ phận liên quan?
• Kho & logistics: nhập hàng, xuất hàng, kiểm kê, đối soát với đơn vị vận chuyển – đã có các use case tương ứng?
• Kế toán & tài chính: ghi nhận doanh thu, công nợ, hoàn tiền – sơ đồ đã phản ánh các nhu cầu này?
• Quản trị & bảo mật: phân quyền, log hoạt động, cảnh báo bất thường – đã được mô hình hóa?

3. Góc nhìn marketing – SEO:

• Thu lead & nuôi dưỡng: form, popup, automation – có đủ use case để marketing triển khai chiến lược?
• Tracking & đo lường: event, conversion, báo cáo – sơ đồ đã thể hiện các điểm chạm cần tracking?
• SEO: tối ưu onpage, kỹ thuật, báo cáo – actor SEO có đủ use case để thực hiện công việc hàng ngày?

Trong quá trình rà soát, nên liên tục đặt câu hỏi: khách hàng có thể làm gì ở mỗi giai đoạn? Nhân viên cần chức năng gì để xử lý tình huống A, B, C? Marketing và SEO cần dữ liệu gì để đo lường và tối ưu? Nếu câu trả lời dẫn đến chức năng mới, cần bổ sung use case và association tương ứng để sơ đồ phản ánh đúng nhu cầu của tất cả bên liên quan.

Ví dụ cấu trúc sơ đồ use case website bán hàng cơ bản và nâng cao

Sơ đồ use case website bán hàng cơ bản và nâng cao nên được xây dựng xoay quanh các nhóm actor chính, thể hiện rõ vai trò nghiệp vụ và luồng tương tác với hệ thống. Ở mức cơ bản, tập trung vào khách truy cập, khách hàng, quản trị viên, cổng thanh toán và đơn vị vận chuyển, làm rõ các nhóm chức năng: khám phá sản phẩm, giỏ hàng, đặt hàng, thanh toán, theo dõi đơn và quản trị nội bộ. Các quan hệ include, extend được dùng để mô tả hành vi dùng chung và các tình huống mở rộng.

Ở mức nâng cao, sơ đồ mở rộng thêm marketing, SEO, social, nền tảng quảng cáo và hệ thống chống click tặc, biến website thành nền tảng thương mại điện tử toàn diện. Cần tách thành nhiều sơ đồ con theo actor hoặc chủ đề, giữ tên use case nhất quán, ưu tiên đặt tên bằng động từ hành động để dễ hiểu, dễ triển khai code và thuận lợi cho bảo trì, mở rộng.

Sơ đồ use case website bán hàng cơ bản với khách hàng, admin, thanh toán và vận chuyển

Trong phiên bản cơ bản, sơ đồ use case website bán hàng không chỉ dừng ở việc liệt kê actor và vài chức năng tổng quát, mà cần mô tả rõ mối quan hệ giữa các actor, các use case chính, các use case mở rộng (extend) và các use case được dùng chung (include). Các actor thường gặp gồm: “Khách truy cập”, “Khách hàng”, “Quản trị viên”, “Cổng thanh toán”, “Đơn vị vận chuyển”. Mỗi actor sẽ tương tác với một tập use case riêng, phản ánh đúng vai trò nghiệp vụ của họ trong hệ thống.

Với nhóm actor phía khách (Khách truy cập, Khách hàng), các nhóm use case chính thường bao gồm:

• Tìm kiếm và khám phá sản phẩm: “Tìm kiếm sản phẩm”, “Lọc sản phẩm theo thuộc tính”, “Xem danh sách sản phẩm”, “Xem chi tiết sản phẩm”, “Xem đánh giá và nhận xét”.
• Giỏ hàng và yêu thích: “Thêm vào giỏ hàng”, “Cập nhật số lượng trong giỏ”, “Xóa sản phẩm khỏi giỏ”, “Lưu sản phẩm yêu thích”, “Ước tính phí vận chuyển và thuế”.
• Đặt hàng: “Đăng ký tài khoản”, “Đăng nhập”, “Nhập địa chỉ giao hàng”, “Chọn phương thức vận chuyển”, “Chọn phương thức thanh toán”, “Xác nhận đơn hàng”.
• Thanh toán: “Thanh toán online”, “Thanh toán COD”, “Áp dụng mã giảm giá / voucher”, “Kiểm tra phí vận chuyển”, “Xử lý thanh toán qua cổng thanh toán” (use case này thường include trong “Thanh toán online”).
• Theo dõi đơn hàng và hậu mãi: “Xem lịch sử đơn hàng”, “Theo dõi trạng thái đơn hàng”, “Yêu cầu hủy đơn”, “Yêu cầu đổi trả”, “Gửi đánh giá sau mua”.

Với nhóm actor phía quản trị (Quản trị viên), sơ đồ use case cơ bản cần thể hiện rõ các nhóm chức năng quản trị cốt lõi:

• Quản lý sản phẩm: “Thêm sản phẩm”, “Cập nhật sản phẩm”, “Ẩn / hiển thị sản phẩm”, “Quản lý tồn kho”, “Quản lý danh mục và thuộc tính sản phẩm”.
• Quản lý đơn hàng: “Xem danh sách đơn hàng”, “Cập nhật trạng thái đơn hàng”, “Xử lý yêu cầu hủy / đổi trả”, “In hóa đơn / phiếu giao hàng”.
• Quản lý khách hàng: “Xem hồ sơ khách hàng”, “Cập nhật thông tin khách hàng”, “Khóa / mở khóa tài khoản”, “Xem lịch sử mua hàng”.
• Cấu hình thanh toán và vận chuyển: “Cấu hình cổng thanh toán”, “Cấu hình phương thức vận chuyển”, “Thiết lập bảng phí vận chuyển”, “Thiết lập thuế và phụ phí”.

Trong sơ đồ use case cơ bản, các actor hệ thống bên ngoài như “Cổng thanh toán” và “Đơn vị vận chuyển” thường được mô tả như các actor ngoại vi, tương tác với các use case kiểu “Gửi yêu cầu thanh toán”, “Nhận kết quả thanh toán”, “Gửi yêu cầu tạo vận đơn”, “Nhận mã vận đơn và trạng thái giao hàng”. Các use case này giúp làm rõ luồng tích hợp giữa hệ thống bán hàng và các dịch vụ thứ ba.

Mặc dù chưa có các module marketing, SEO hay chống click tặc, sơ đồ vẫn cần thể hiện rõ các use case liên quan đến trải nghiệm khách hàng sau khi đặt hàng, chẳng hạn:

• “Gửi email xác nhận đơn hàng” (thường là use case include trong “Đặt hàng thành công”).
• “Gửi thông báo trạng thái đơn hàng” (có thể được extend từ “Cập nhật trạng thái đơn hàng”).
• “Gửi thông báo qua SMS / push notification” nếu hệ thống có tích hợp.

Các use case này nên được mô tả rõ điều kiện kích hoạt (khi đơn hàng chuyển trạng thái, khi thanh toán thành công, khi đơn được giao thành công…) để đội phát triển có thể thiết kế luồng xử lý sự kiện (event-driven) hoặc cron job phù hợp. Cấu trúc sơ đồ use case cơ bản như vậy giúp hệ thống tập trung vào chức năng bán hàng cốt lõi nhưng vẫn đảm bảo trải nghiệm người dùng trọn vẹn từ lúc xem sản phẩm đến sau khi nhận hàng.

Sơ đồ use case website bán hàng nâng cao với SEO, landing page, social automation và chống click tặc

Trong phiên bản nâng cao, sơ đồ use case được mở rộng để phản ánh website như một nền tảng thương mại điện tử tích hợp marketing, SEO, phân tích dữ liệu và bảo vệ ngân sách quảng cáo. Các actor mới như “Nhân viên marketing”, “Nhân viên SEO”, “Nền tảng quảng cáo”, “Mạng xã hội”, “Hệ thống chống click tặc” làm tăng độ phức tạp của sơ đồ, nhưng cũng giúp mô hình hóa đầy đủ hơn các luồng nghiệp vụ thực tế.

Với actor “Nhân viên marketing”, các nhóm use case bổ sung thường bao gồm:

• Tạo và quản lý landing page: “Tạo landing page kéo thả”, “Chỉnh sửa layout landing page”, “Quản lý template landing page”, “Xuất bản / gỡ bỏ landing page”.
• Thu lead và automation: “Tạo form thu lead”, “Cấu hình kịch bản email automation”, “Gắn lead vào chiến dịch”, “Đồng bộ lead sang CRM”.
• Gắn tracking và pixel: “Gắn mã tracking chiến dịch”, “Gắn pixel quảng cáo”, “Thiết lập sự kiện chuyển đổi”, “Kiểm tra hoạt động tracking”.
• Social automation: “Kết nối tài khoản mạng xã hội”, “Lên lịch đăng bài”, “Tự động đăng sản phẩm mới lên mạng xã hội”, “Theo dõi hiệu quả tương tác”.

Với actor “Nhân viên SEO”, sơ đồ use case nâng cao cần thể hiện các nhóm chức năng chuyên sâu hơn về tối ưu hóa công cụ tìm kiếm:

• Quản lý SEO onpage: “Chỉnh sửa thẻ meta title / description”, “Tùy chỉnh URL thân thiện”, “Quản lý thẻ heading”, “Tối ưu internal link”, “Quản lý schema markup cho sản phẩm và bài viết”.
• SEO kỹ thuật: “Tạo và cập nhật sitemap”, “Quản lý robots.txt”, “Kiểm tra tốc độ tải trang”, “Phát hiện lỗi 404 và chuyển hướng 301”, “Kiểm tra tính thân thiện với mobile”.
• Báo cáo SEO: “Xem báo cáo thứ hạng từ khóa”, “Xem báo cáo traffic organic”, “Xem báo cáo crawl error”, “Xuất báo cáo SEO định kỳ”.

Actor “Nền tảng quảng cáo” (ví dụ Google Ads, Facebook Ads) và “Mạng xã hội” thường tương tác với các use case liên quan đến đồng bộ dữ liệu và đo lường hiệu quả:

• “Đồng bộ dữ liệu chuyển đổi về nền tảng quảng cáo”.
• “Đồng bộ danh sách khách hàng / lead cho chiến dịch remarketing”.
• “Nhận dữ liệu chi phí quảng cáo để tính ROAS, ROI”.
• “Đăng nội dung tự động lên fanpage / tài khoản mạng xã hội”.

Với actor “Hệ thống chống click tặc”, sơ đồ use case nâng cao cần mô tả rõ các luồng giám sát và phản ứng:

• Theo dõi click: “Ghi nhận click từ quảng cáo”, “Phân tích hành vi click”, “Phát hiện mẫu click bất thường”.
• Chặn click tặc: “Chặn IP nghi ngờ”, “Chặn dải IP”, “Chặn thiết bị / user agent bất thường”, “Thông báo cho nhân viên marketing khi phát hiện click tặc”.
• Báo cáo và tối ưu: “Xem báo cáo click hợp lệ / không hợp lệ”, “Xem báo cáo chi phí lãng phí do click tặc”, “Đề xuất điều chỉnh chiến dịch quảng cáo”.

Các use case như “Đồng bộ dữ liệu với nền tảng quảng cáo” thường được thiết kế như use case trung gian, include trong nhiều luồng khác nhau (ví dụ sau khi ghi nhận chuyển đổi, sau khi cập nhật trạng thái đơn hàng, sau khi xác định lead đủ điều kiện). Điều này giúp đảm bảo dữ liệu giữa hệ thống bán hàng và nền tảng quảng cáo luôn nhất quán, phục vụ cho việc tối ưu chiến dịch.

Cấu trúc sơ đồ use case nâng cao như vậy phản ánh website bán hàng như một nền tảng thương mại điện tử toàn diện, nơi các luồng bán hàng, marketing, SEO, phân tích dữ liệu và bảo vệ quảng cáo được tích hợp chặt chẽ. Khi thiết kế sơ đồ, nên chú ý phân tách rõ ràng các nhóm use case theo actor, sử dụng quan hệ include và extend hợp lý để tránh trùng lặp và giúp đội ngũ kiến trúc sư hệ thống định hình kiến trúc ngay từ đầu, thay vì phải “vá” thêm các module rời rạc về sau.

Cách đặt tên use case bằng động từ hành động để dễ hiểu và dễ triển khai code

Đặt tên use case là bước quan trọng để sơ đồ use case trở thành cầu nối hiệu quả giữa người nghiệp vụ và đội kỹ thuật. Nguyên tắc chung là dùng động từ hành động + đối tượng, ví dụ: “Xem chi tiết sản phẩm”, “Thêm vào giỏ hàng”, “Đặt hàng”, “Thanh toán online”, “Quản lý sản phẩm”, “Tạo landing page”, “Gắn tracking chiến dịch”, “Xem báo cáo SEO”. Cách đặt tên này giúp mô tả rõ ràng hành động chính và đối tượng tác động, tránh mơ hồ.

Một số lưu ý chuyên sâu khi đặt tên use case:

• Tránh dùng tên quá kỹ thuật như “Xử lý dữ liệu”, “Module A”, “Chức năng B”, vì không phản ánh nghiệp vụ và gây khó hiểu cho stakeholder không chuyên kỹ thuật.
• Thống nhất cách chia nhỏ use case: ví dụ tách “Đặt hàng” thành “Xác nhận giỏ hàng”, “Nhập thông tin giao hàng”, “Chọn phương thức thanh toán”, “Xác nhận đơn hàng”, hoặc gộp lại thành một use case lớn “Đặt hàng” với các bước chi tiết trong tài liệu đặc tả.
• Phân biệt use case nghiệp vụ và use case kỹ thuật: các use case như “Đồng bộ dữ liệu với nền tảng quảng cáo”, “Gửi webhook” có thể là use case kỹ thuật, nên được mô tả nhưng không trộn lẫn với use case nghiệp vụ dành cho người dùng cuối.
• Giữ tên nhất quán giữa sơ đồ và code: tên use case nên có thể map tương đối trực tiếp sang tên module, service, API hoặc class trong code, ví dụ use case “Tạo landing page” tương ứng với service “LandingPageService.create()”.

Đặt tên rõ ràng giúp chủ shop và người không chuyên dễ hiểu sơ đồ, đội phân tích nghiệp vụ dễ viết tài liệu chi tiết, đội lập trình dễ mapping use case với module, class, API, và đội kiểm thử dễ viết test case. Ngoài ra, khi hệ thống mở rộng, tên use case rõ ràng giúp tránh trùng lặp chức năng, ví dụ phân biệt “Tạo landing page” với “Nhân bản landing page”, hay “Xem báo cáo SEO tổng quan” với “Xem báo cáo SEO chi tiết theo URL”.

Cách tách sơ đồ lớn thành nhiều sơ đồ nhỏ để tránh rối và dễ trình bày

Khi website bán hàng phát triển nhiều module, sơ đồ use case tổng thể dễ trở nên quá tải với quá nhiều actor và đường kết nối. Để tránh rối, nên tách thành nhiều sơ đồ con theo chủ đề hoặc theo nhóm actor. Cách tiếp cận phổ biến là chia thành:

• Sơ đồ use case cho khách hàng (mua hàng, tài khoản, hậu mãi).
• Sơ đồ use case cho quản trị (admin: sản phẩm, đơn hàng, khách hàng, cấu hình hệ thống).
• Sơ đồ use case cho marketing (landing page, lead, automation, social).
• Sơ đồ use case cho SEO (onpage, kỹ thuật, báo cáo).
• Sơ đồ use case cho chống click tặc và tích hợp quảng cáo.

Mỗi sơ đồ con tập trung vào một nhóm actor và use case liên quan, giúp:

• Dễ trình bày cho từng nhóm stakeholder: khách hàng nội bộ, ban giám đốc, đội marketing, đội kỹ thuật.
• Dễ cập nhật khi một module thay đổi, không ảnh hưởng đến toàn bộ sơ đồ.
• Tránh rối mắt khi in hoặc trình chiếu, đặc biệt trong các buổi workshop hoặc review yêu cầu.

Tuy nhiên, vẫn nên giữ một sơ đồ tổng quan ở mức cao, chỉ liệt kê actor chính và nhóm use case lớn (ví dụ “Quy trình mua hàng”, “Quản trị sản phẩm”, “Marketing & SEO”, “Chống click tặc & tích hợp quảng cáo”), để mọi người có cái nhìn toàn cảnh về hệ thống. Sơ đồ tổng quan này đóng vai trò bản đồ định hướng, trong khi các sơ đồ con đóng vai trò chi tiết hóa từng khu vực chức năng.

Khi tách sơ đồ, nên tuân thủ một số nguyên tắc:

• Không thay đổi ý nghĩa use case khi chuyển từ sơ đồ tổng quan sang sơ đồ con; chỉ bổ sung chi tiết hoặc phân rã thêm nếu cần.
• Giữ tên actor và use case nhất quán giữa các sơ đồ để tránh nhầm lẫn (ví dụ luôn dùng “Nhân viên marketing”, không lúc thì “Marketing”, lúc thì “Marketer”).
• Ghi chú mối liên hệ giữa các sơ đồ trong tài liệu đi kèm (ví dụ: use case “Đặt hàng” trong sơ đồ khách hàng có liên quan đến use case “Cập nhật trạng thái đơn hàng” trong sơ đồ admin và use case “Gửi dữ liệu chuyển đổi” trong sơ đồ marketing).

Lỗi thường gặp khi vẽ use case website bán hàng

Khi vẽ use case cho website bán hàng, cần tập trung vào bản chất nghiệp vụ thay vì cấu trúc tổ chức hay chi tiết kỹ thuật. Actor phải được hiểu là vai trò bên ngoài hệ thống trực tiếp gửi yêu cầu và nhận phản hồi, không phải phòng ban hay module nội bộ. Use case nên mô tả mục tiêu nghiệp vụ như “Đặt hàng”, “Thanh toán đơn hàng”, tránh liệt kê thao tác UI, bảng dữ liệu hoặc thuật toán cụ thể. Đồng thời, cần bổ sung đầy đủ các actor hệ thống bên ngoài như cổng thanh toán, đơn vị vận chuyển, dịch vụ email/SMS, nền tảng quảng cáo để thể hiện đúng mức độ tích hợp. Cuối cùng, sử dụng hợp lý quan hệ include và extend giúp tái sử dụng bước chung, mô hình hóa điều kiện rõ ràng và giữ sơ đồ gọn, dễ bảo trì.

Nhầm actor với phòng ban, chức năng kỹ thuật hoặc module trong hệ thống

Một lỗi phổ biến và mang tính “gốc rễ” khi phân tích use case cho website bán hàng là nhầm lẫn giữa actor với các khái niệm tổ chức hoặc kỹ thuật như phòng ban, module, subsystem. Về mặt chuẩn UML, actor là một vai trò bên ngoài hệ thống có tương tác thông qua việc gửi yêu cầu và nhận phản hồi. Actor không phải là:

• Cơ cấu tổ chức: “Phòng kinh doanh”, “Phòng marketing”, “Ban giám đốc”
• Thành phần kỹ thuật: “Module thanh toán”, “Module vận chuyển”, “Module báo cáo”
• Tên hệ thống nội bộ chung chung: “Hệ thống ERP”, “Hệ thống CRM” (nếu không chỉ rõ vai trò tương tác)

Trong bối cảnh website bán hàng, cần phân biệt rõ:

• Actor đúng (mang tính vai trò):
  • “Khách hàng vãng lai” (Guest)
  • “Khách hàng đã đăng ký” (Registered Customer)
  • “Nhân viên bán hàng” (Sales Staff)
  • “Nhân viên marketing” (Marketing Staff)
  • “Cổng thanh toán” (Payment Gateway)
  • “Đơn vị vận chuyển” (Shipping Provider)
• Actor sai (mang tính tổ chức hoặc module):
  • “Phòng kinh doanh” (Sales Department)
  • “Phòng marketing” (Marketing Department)
  • “Module thanh toán” (Payment Module)
  • “Module vận chuyển” (Shipping Module)

Nhầm lẫn này dẫn đến nhiều hệ quả chuyên môn:

• Sơ đồ use case khó mapping với quy trình nghiệp vụ thực tế, vì không thể gán trách nhiệm cho từng cá nhân hoặc hệ thống cụ thể.
• Khó phân quyền và thiết kế security, do actor không phản ánh đúng “ai” thực sự thao tác trên hệ thống.
• Gây mơ hồ trong giao tiếp giữa BA, dev và stakeholder: mỗi bên hiểu “phòng kinh doanh” theo một cách khác nhau.

Cách khắc phục mang tính hệ thống là áp dụng một câu hỏi kiểm tra đơn giản nhưng chặt chẽ: “Thực thể này có trực tiếp gửi request hoặc nhận response từ hệ thống không?”

• Nếu có:
  • Đó là actor hợp lệ. Ví dụ: “Nhân viên bán hàng” đăng nhập vào backend để tạo đơn hàng; “Cổng thanh toán” gửi callback kết quả thanh toán.
• Nếu không:
  • Đó chỉ là tên phòng ban, tổ chức hoặc module nội bộ. Cần phân rã thành các actor cụ thể hơn, tương ứng với vai trò thực sự tương tác.

Trong thực hành chuyên sâu, nên:

• Xây dựng danh sách vai trò (role catalog) trước khi vẽ sơ đồ use case, ví dụ:
  • Customer, Guest, Registered User
  • Sales Staff, Customer Support, Warehouse Staff
  • Marketing Staff, Admin System
  • Payment Gateway, Shipping Provider, Email Service
• Mapping từng vai trò với phòng ban tương ứng trong tài liệu mô tả, nhưng không đưa phòng ban lên sơ đồ như actor.
• Với hệ thống nội bộ (ERP, CRM), xác định rõ vai trò tương tác, ví dụ:
  • “ERP System (Order Receiver)” thay vì chỉ “ERP” chung chung.

Đưa quá nhiều chi tiết giao diện, database và thuật toán vào sơ đồ use case

Một sai lầm khác mang tính “thiết kế thay vì phân tích” là nhồi nhét chi tiết UI, database và logic kỹ thuật vào sơ đồ use case. Use case ở mức chuẩn UML là mô hình hành vi ở mức nghiệp vụ, không phải mô hình thiết kế giao diện hay kiến trúc dữ liệu.

Các chi tiết sau thường bị đưa nhầm vào sơ đồ:

• Chi tiết giao diện:
  • “Nhập email”
  • “Nhập mật khẩu”
  • “Nhấn nút Đăng ký”
  • “Chọn checkbox Đồng ý điều khoản”
• Chi tiết database:
  • “Lưu vào bảng Users”
  • “Cập nhật cột status trong bảng Orders”
  • “Tạo record mới trong bảng OrderItems”
• Chi tiết thuật toán/kỹ thuật:
  • “Mã hóa mật khẩu bằng bcrypt”
  • “Gọi API tính phí vận chuyển”
  • “Tạo token JWT”

Ở mức use case, chỉ cần mô tả các mục tiêu nghiệp vụ chính như:

• “Đăng ký tài khoản”
• “Đăng nhập”
• “Quản lý tài khoản”
• “Đặt hàng”
• “Thanh toán đơn hàng”
• “Quản lý sản phẩm”

Đưa quá nhiều chi tiết kỹ thuật vào sơ đồ gây ra các vấn đề:

• Sơ đồ trở nên rối rắm, khó đọc, đặc biệt với stakeholder không kỹ thuật.
• Mất tính trừu tượng, khiến việc thay đổi UI hoặc công nghệ lưu trữ kéo theo phải sửa sơ đồ use case, trong khi về bản chất nghiệp vụ không đổi.
• Trộn lẫn các tầng phân tích (business) và thiết kế (design), làm mờ ranh giới trách nhiệm giữa BA, UX và dev.

Cách tiếp cận chuyên nghiệp là phân tầng tài liệu:

• Sơ đồ use case: mô tả phạm vi chức năng và mối quan hệ giữa actor và use case ở mức khái quát.
• Tài liệu đặc tả use case (Use Case Specification):
  • Mô tả luồng chính, luồng phụ, điều kiện tiền đề, hậu điều kiện, rule nghiệp vụ.
  • Có thể đề cập đến các bước tương tác, nhưng vẫn ở mức khái niệm, không gắn chặt với layout UI.
• User flow / Flowchart:
  • Mô tả chi tiết các bước người dùng đi qua trong giao diện.
• Wireframe / Prototype:
  • Thể hiện bố cục màn hình, vị trí nút, field nhập liệu.
• ERD (Entity Relationship Diagram):
  • Mô hình hóa bảng, quan hệ, khóa chính, khóa ngoại.

Quy tắc thực hành tốt là: “Nếu một chi tiết thay đổi khi đổi UI framework hoặc đổi DB engine, đừng đưa nó vào sơ đồ use case.” Use case nên ổn định theo thời gian, phản ánh mục tiêu nghiệp vụ chứ không phải giải pháp kỹ thuật cụ thể.

Thiếu actor bên ngoài như thanh toán, vận chuyển, email, SMS và nền tảng quảng cáo

Trong các dự án website bán hàng, một lỗi thường gặp là chỉ mô hình hóa actor “Khách hàng” và “Admin” mà bỏ qua các actor hệ thống bên ngoài. Điều này làm sơ đồ không thể hiện đúng mức độ tích hợp và phụ thuộc vào bên thứ ba, trong khi đây là yếu tố then chốt của thương mại điện tử hiện đại.

Các actor bên ngoài thường bị bỏ sót gồm:

• Cổng thanh toán:
  • Payment Gateway (VNPay, MoMo, PayPal, Stripe, …)
  • Ngân hàng phát hành thẻ (trong một số mô hình tích hợp đặc thù)
• Đơn vị vận chuyển:
  • Shipping Provider (GHN, GHTK, Viettel Post, …)
  • Đối tác fulfillment hoặc kho bên thứ ba (3PL)
• Hệ thống giao tiếp:
  • Email Service (SMTP server, dịch vụ gửi email marketing)
  • SMS Gateway
  • Push Notification Service
• Hệ thống marketing và phân tích:
  • Nền tảng quảng cáo (Facebook Ads, Google Ads, TikTok Ads, …)
  • Hệ thống tracking/analytics (Google Analytics, Tag Manager, CDP)
  • CRM hoặc Marketing Automation

Khi thiếu các actor này, sơ đồ use case không thể hiện được:

• Các luồng thanh toán online và rủi ro liên quan (thanh toán thất bại, hoàn tiền, chargeback).
• Quy trình tạo vận đơn, cập nhật trạng thái giao hàng, xử lý giao hàng thất bại.
• Luồng gửi email/SMS thông báo đơn hàng, khuyến mãi, OTP.
• Luồng gửi sự kiện chuyển đổi cho nền tảng quảng cáo, ảnh hưởng trực tiếp đến tối ưu chiến dịch.

Để khắc phục, cần thực hiện một bước phân tích tích hợp (integration analysis):

• Rà soát toàn bộ quy trình mua hàng:
  • Từ lúc khách hàng tiếp cận qua quảng cáo, truy cập website, xem sản phẩm, thêm vào giỏ, đặt hàng, thanh toán, giao hàng, hậu mãi.
• Liệt kê mọi hệ thống bên ngoài có tương tác với website:
  • Cổng thanh toán, đơn vị vận chuyển, hệ thống email/SMS, CRM, nền tảng quảng cáo, hệ thống kế toán, ERP.
• Thêm chúng vào sơ đồ như actor, kết nối với các use case tương ứng:
  • “Xử lý thanh toán online”
  • “Tạo vận đơn”
  • “Cập nhật trạng thái giao hàng”
  • “Gửi email”
  • “Gửi SMS”
  • “Gửi sự kiện chuyển đổi quảng cáo”

Việc thể hiện rõ các actor bên ngoài giúp:

• Đánh giá rủi ro phụ thuộc (dependency risk) và lên kế hoạch fallback khi hệ thống thứ ba gặp sự cố.
• Thiết kế kiến trúc tích hợp (API, queue, webhook) rõ ràng hơn.
• Giao tiếp với đối tác tích hợp (payment, shipping, marketing) một cách minh bạch về phạm vi và trách nhiệm.

Không thể hiện quan hệ include, extend khiến sơ đồ khó hiểu khi chức năng có điều kiện

Nhiều sơ đồ use case chỉ sử dụng association đơn giản giữa actor và use case, bỏ qua hai quan hệ quan trọng là include và extend. Điều này dẫn đến:

• Lặp lại các chức năng chung trong nhiều use case khác nhau.
• Khó mô hình hóa các nhánh điều kiện, tùy chọn hoặc hành vi mở rộng.
• Sơ đồ phình to, khó bảo trì, khó thay đổi khi nghiệp vụ điều chỉnh.

Trong website bán hàng, ví dụ điển hình là quy trình đặt hàng:

• Nếu tạo riêng các use case:
  • “Đặt hàng COD”
  • “Đặt hàng online”
• Mỗi use case lại chứa các bước giống nhau:
  • “Xác thực thông tin khách hàng”
  • “Tính phí vận chuyển”
  • “Kiểm tra tồn kho”

Cách mô hình hóa tốt hơn là:

• Tạo use case tổng quát “Đặt hàng”.
• Use case “Đặt hàng” include các use case con:
  • “Xác thực thông tin khách hàng”
  • “Tính phí vận chuyển”
  • “Kiểm tra tồn kho”
• Sau đó sử dụng extend cho các hành vi tùy chọn hoặc phụ thuộc điều kiện:
  • “Thanh toán online” (extend từ “Đặt hàng” khi khách chọn phương thức online).
  • “Thanh toán COD” (extend từ “Đặt hàng” khi khách chọn thanh toán khi nhận hàng).

Tương tự, use case “Áp mã giảm giá” thường bị lặp lại trong nhiều use case như “Đặt hàng”, “Thanh toán”, “Thanh toán lại đơn hàng”. Thay vì copy logic, có thể:

• Tạo use case “Áp mã giảm giá”.
• Dùng include nếu việc áp mã là bước bắt buộc trong một luồng cụ thể.
• Dùng extend nếu việc áp mã là tùy chọn, chỉ xảy ra khi khách nhập mã.

Nguyên tắc chuyên môn khi dùng include/extend:

• Include:
  • Dùng cho các chức năng con luôn luôn xảy ra trong luồng chính.
  • Giúp tái sử dụng các bước chung, giảm trùng lặp.
  • Ví dụ: “Xác thực thông tin khách hàng” được include bởi “Đặt hàng”, “Cập nhật thông tin tài khoản”.
• Extend:
  • Dùng cho các hành vi mở rộng, chỉ xảy ra trong một số điều kiện.
  • Giúp tách biệt logic tùy chọn, làm sơ đồ rõ ràng hơn.
  • Ví dụ: “Gửi email xác nhận” extend từ “Đăng ký tài khoản” khi cấu hình yêu cầu xác thực email.

Khi áp dụng đúng include và extend, sơ đồ use case cho website bán hàng sẽ:

• Phản ánh chính xác cấu trúc nghiệp vụ, phân tách rõ phần lõi và phần mở rộng.
• Dễ dàng bảo trì: thay đổi một use case con sẽ tự động áp dụng cho mọi nơi include nó.
• Hỗ trợ tốt hơn cho việc thiết kế kiến trúc dịch vụ (service decomposition), vì mỗi use case con có thể mapping với một service hoặc API riêng.

FAQ về cách vẽ sơ đồ use case website bán hàng

Sơ đồ use case cho website bán hàng nên bao quát cả ba nhóm actor: người dùng bên ngoài, nhân sự nội bộ và các hệ thống tích hợp. Việc phân tách rõ Visitor, Customer, Admin, nhân viên bán hàng, marketing, SEO giúp mô hình hóa đúng luồng nghiệp vụ, phân quyền và bảo mật. Ngay cả website nhỏ vẫn nên có sơ đồ use case tối giản để làm rõ scope, giảm hiểu sai yêu cầu và hỗ trợ ước lượng chi phí, thời gian. Về mặt kỹ thuật UML, cần xác định use case nào bắt buộc đăng nhập, khi nào dùng quan hệ include cho các bước chung (xác thực, kiểm tra tồn kho, tính phí) và extend cho luồng tùy chọn (thanh toán online, áp mã giảm giá, xuất hóa đơn VAT). Sơ đồ không thay thế đặc tả chi tiết mà là nền tảng để phát triển tài liệu nghiệp vụ, API và kiến trúc hệ thống.

Sơ đồ use case website bán hàng cần những actor nào?

Sơ đồ use case cho website bán hàng nên được phân tích theo từng nhóm actor để tránh thiếu sót và giúp việc phân quyền, bảo mật, logging rõ ràng hơn. Thông thường, có thể chia thành các nhóm actor chính sau:

1. Nhóm người dùng bên ngoài (External Users)

• Khách truy cập (Visitor): người chưa đăng ký hoặc chưa đăng nhập, chỉ có thể:
  • Xem danh mục sản phẩm, chi tiết sản phẩm, bài viết blog/tin tức
  • Tìm kiếm, lọc sản phẩm, xem đánh giá (nếu cho phép)
  • Thêm sản phẩm vào giỏ tạm, đăng ký nhận bản tin, gửi form liên hệ
  Actor này rất quan trọng để mô hình hóa các use case liên quan đến chuyển đổi từ traffic sang lead hoặc khách hàng.
• Khách hàng (Customer): người đã đăng ký tài khoản hoặc đã cung cấp thông tin đủ để hệ thống nhận diện. Các use case thường gắn với actor này:
  • Quản lý tài khoản, địa chỉ giao hàng, phương thức thanh toán ưa thích
  • Đặt hàng, theo dõi đơn hàng, yêu cầu đổi trả/bảo hành
  • Quản lý điểm thưởng, ví điện tử nội bộ, mã giảm giá cá nhân
  • Quản lý danh sách yêu thích, lịch sử xem sản phẩm, đánh giá sản phẩm

2. Nhóm vận hành nội bộ (Internal Staff)

• Quản trị viên (Admin): actor có quyền cao nhất, thường liên quan đến:
  • Quản lý người dùng, phân quyền, cấu hình hệ thống, cấu hình thanh toán – vận chuyển
  • Quản lý danh mục sản phẩm, thuộc tính, thương hiệu, cấu hình SEO tổng thể
  • Quản lý nội dung trang, banner, popup, menu, landing page hệ thống
  • Quản lý log hệ thống, backup, tích hợp với hệ thống bên ngoài
• Nhân viên bán hàng / CSKH: trong sơ đồ có thể tách hoặc gộp tùy mức độ chi tiết, thường có các use case:
  • Tạo đơn hàng hộ khách (qua điện thoại, chat, mạng xã hội)
  • Chỉnh sửa đơn hàng, cập nhật trạng thái, xử lý đổi trả, hoàn tiền
  • Ghi chú trao đổi với khách, cập nhật ticket hỗ trợ
  • Tra cứu lịch sử mua hàng, lịch sử tương tác của khách
• Nhân viên marketing: tập trung vào các use case:
  • Tạo và quản lý chiến dịch khuyến mãi, mã giảm giá, voucher
  • Tạo landing page, cấu hình tracking (UTM, pixel, event)
  • Thiết lập automation marketing (email, SMS, push notification)
  • Xem và phân tích báo cáo chiến dịch, tỷ lệ chuyển đổi, chi phí/đơn hàng
• Nhân viên SEO (khi có module SEO riêng): thường liên quan đến:
  • Quản lý meta title, meta description, URL thân thiện, canonical
  • Quản lý sitemap, robots.txt, redirect, schema markup
  • Kiểm tra lỗi crawl, index, tốc độ trang, core web vitals (nếu có tích hợp)
  • Xem báo cáo organic traffic, từ khóa, landing page SEO

3. Nhóm hệ thống bên ngoài (External Systems)

• Cổng thanh toán (Payment Gateway): xử lý thanh toán online (thẻ, ví điện tử, chuyển khoản nhanh).
• Đơn vị vận chuyển (Shipping/Logistics): nhận thông tin vận đơn, trả về mã vận đơn, trạng thái giao hàng.
• Hệ thống email (Email Service): gửi email xác nhận đơn, thông báo trạng thái, chiến dịch marketing.
• Hệ thống SMS: gửi OTP, thông báo đơn hàng, nhắc thanh toán, chiến dịch SMS marketing.
• CRM: đồng bộ thông tin khách hàng, lịch sử mua hàng, điểm chạm marketing – sales.
• Nền tảng quảng cáo (Ads Platform): Facebook Ads, Google Ads, v.v. để tracking chuyển đổi, remarketing.
• Mạng xã hội: đăng nhập social login, chia sẻ sản phẩm, đồng bộ inbox (nếu có).
• Hệ thống chống click tặc: nhận dữ liệu click, đánh giá rủi ro, chặn IP hoặc cảnh báo.

Khi vẽ sơ đồ, nên đặt các actor hệ thống bên ngoài bên ngoài system boundary và thể hiện rõ các association với các use case tích hợp để đội phát triển dễ xác định phạm vi API, luồng dữ liệu và điểm lỗi tiềm ẩn.

Website bán hàng nhỏ có cần vẽ use case không?

Ngay cả với website bán hàng nhỏ, sơ đồ use case vẫn mang lại giá trị lớn về mặt phân tích và giao tiếp. Lợi ích chuyên môn có thể nhìn ở các khía cạnh:

• Làm rõ phạm vi (scope) ngay từ đầu: xác định chính xác:
  • Những actor nào sẽ sử dụng hệ thống trong giai đoạn đầu
  • Những chức năng nào bắt buộc phải có trong phiên bản MVP
  • Những chức năng nào có thể để lại cho phase sau
• Giảm rủi ro hiểu sai yêu cầu: chủ shop, đơn vị triển khai, đội thiết kế UI/UX và đội dev thường dùng ngôn ngữ khác nhau. Sơ đồ use case đóng vai trò như “ngôn ngữ chung” trực quan, giúp:
  • Tránh bỏ sót các chức năng quan trọng như: theo dõi đơn, đổi trả, thông báo email/SMS, quản lý tồn kho cơ bản
  • Giảm tranh cãi về “có thỏa thuận chức năng này từ đầu hay không”
• Hỗ trợ ước lượng chi phí và thời gian: khi các use case được liệt kê rõ, đội phát triển có thể:
  • Ước lượng effort cho từng nhóm chức năng
  • Ưu tiên theo giá trị kinh doanh (ví dụ: ưu tiên luồng đặt hàng, thanh toán, thông báo trước các tính năng nâng cao)

Với website nhỏ, sơ đồ có thể tối giản, chỉ tập trung vào: Khách truy cập, Khách hàng, Quản trị viên và một vài hệ thống bên ngoài quan trọng (cổng thanh toán, đơn vị vận chuyển). Tuy nhiên, vẫn nên thể hiện rõ các use case cốt lõi như: đăng ký/đăng nhập, xem sản phẩm, giỏ hàng, đặt hàng, thanh toán, theo dõi đơn, thông báo.

Use case đăng nhập nên nối với khách hàng hay tất cả actor?

Về mặt mô hình UML, use case “Đăng nhập” là một chức năng dùng chung cho mọi actor cần xác thực. Có hai cách thể hiện phổ biến:

• Cách 1 – Nối trực tiếp “Đăng nhập” với tất cả actor cần xác thực:
  • Khách hàng, Quản trị viên, Nhân viên bán hàng, Nhân viên marketing, Nhân viên SEO đều có association với use case “Đăng nhập”.
  • Cách này trực quan, dễ hiểu với người không chuyên UML, nhưng sơ đồ có thể bị rối nếu số actor nhiều.
• Cách 2 – Dùng “Đăng nhập” như use case dùng chung được include:
  • Các use case như “Quản lý đơn hàng”, “Quản lý sản phẩm”, “Quản lý chiến dịch marketing” sẽ include “Đăng nhập”.
  • Actor (ví dụ: Quản trị viên) chỉ nối với use case nghiệp vụ chính; “Đăng nhập” được thể hiện như một bước bắt buộc trước khi thực hiện các use case đó.

Về mặt phân tích nghiệp vụ, điều quan trọng là:

• Xác định rõ actor nào bắt buộc phải đăng nhập (ví dụ: Quản trị viên, Nhân viên nội bộ, Khách hàng khi xem lịch sử đơn hàng).
• Xác định use case nào cho phép truy cập không cần đăng nhập (ví dụ: xem sản phẩm, thêm vào giỏ, tính phí vận chuyển ước tính).

Trong tài liệu chi tiết use case, nên mô tả rõ điều kiện tiền đề (pre-condition) “Người dùng đã đăng nhập” cho các use case yêu cầu xác thực, thay vì chỉ dựa vào sơ đồ.

Khi nào dùng include và extend trong use case website bán hàng?

Trong bối cảnh website bán hàng, việc sử dụng include và extend giúp tách bạch các phần xử lý bắt buộc và tùy chọn, từ đó:

• Tái sử dụng logic chung (ví dụ: xác thực, tính phí, kiểm tra tồn kho)
• Giảm trùng lặp trong tài liệu và sơ đồ
• Dễ bảo trì khi nghiệp vụ thay đổi

1. Dùng include khi use case B luôn là một phần bắt buộc của use case A

Ví dụ chuyên sâu cho use case “Đặt hàng”:

• “Đặt hàng” include “Xác thực thông tin khách hàng”:
  • Kiểm tra thông tin giao hàng, số điện thoại, email hợp lệ
  • Đối với khách đã đăng nhập, tự động điền thông tin từ hồ sơ
• “Đặt hàng” include “Kiểm tra tồn kho”:
  • Đảm bảo số lượng đặt không vượt quá tồn kho khả dụng
  • Xử lý trường hợp tồn kho thay đổi trong lúc khách đang thao tác
• “Đặt hàng” include “Tính phí vận chuyển”:
  • Tính phí dựa trên địa chỉ, khối lượng, đơn vị vận chuyển, cấu hình khuyến mãi vận chuyển
• “Đặt hàng” include “Tính khuyến mãi”:
  • Áp dụng khuyến mãi theo chương trình đang chạy, theo nhóm khách hàng, theo kênh marketing

2. Dùng extend khi use case B chỉ xảy ra trong một số điều kiện

Ví dụ chi tiết:

• “Thanh toán online” extend “Đặt hàng”:
  • Điều kiện mở rộng: khách chọn phương thức thanh toán online
  • Luồng mở rộng: chuyển sang cổng thanh toán, xử lý callback, xác nhận trạng thái thanh toán
• “Áp mã giảm giá” extend “Đặt hàng”:
  • Điều kiện mở rộng: khách nhập mã giảm giá
  • Luồng mở rộng: kiểm tra hiệu lực mã, điều kiện áp dụng, giới hạn số lần sử dụng
• “Nhận hóa đơn VAT” extend “Đặt hàng”:
  • Điều kiện mở rộng: khách chọn yêu cầu xuất hóa đơn VAT
  • Luồng mở rộng: thu thập thông tin công ty, mã số thuế, địa chỉ, email nhận hóa đơn

Việc phân biệt rõ include/extend giúp đội phát triển hiểu đâu là phần bắt buộc trong mọi đơn hàng, đâu là phần tùy chọn, từ đó thiết kế kiến trúc và giao diện linh hoạt hơn.

Có nên đưa thanh toán online và đơn vị vận chuyển vào sơ đồ use case không?

Nên đưa cả thanh toán online và đơn vị vận chuyển vào sơ đồ use case như các actor hệ thống bên ngoài, vì:

• Thể hiện rõ sự phụ thuộc của hệ thống vào dịch vụ bên thứ ba
• Giúp nhận diện các điểm rủi ro (ví dụ: cổng thanh toán lỗi, API vận chuyển chậm)
• Hỗ trợ thiết kế luồng xử lý lỗi, retry, thông báo cho người dùng

Một số use case tiêu biểu:

• “Xử lý thanh toán online” – association với “Cổng thanh toán”:
  • Gửi yêu cầu thanh toán (số tiền, đơn hàng, callback URL)
  • Nhận kết quả thanh toán (thành công, thất bại, pending)
  • Đồng bộ trạng thái thanh toán với trạng thái đơn hàng
• “Tạo vận đơn” – association với “Đơn vị vận chuyển”:
  • Gửi thông tin đơn hàng, địa chỉ, khối lượng, dịch vụ vận chuyển
  • Nhận mã vận đơn, phí vận chuyển chính xác, thời gian dự kiến giao
• “Cập nhật trạng thái giao hàng” – association với “Đơn vị vận chuyển”:
  • Nhận webhook hoặc pull API trạng thái giao hàng
  • Cập nhật trạng thái đơn hàng trong hệ thống (đang giao, giao thành công, giao thất bại)
  • Gửi thông báo cho khách hàng khi trạng thái thay đổi

Trong sơ đồ, nên đặt các actor này bên ngoài system boundary và nối với các use case tương ứng, tránh gom toàn bộ logic thanh toán/vận chuyển vào một use case duy nhất gây khó hiểu.

Sơ đồ use case có thay thế được đặc tả yêu cầu phần mềm không?

Sơ đồ use case chỉ là bước đầu trong quá trình phân tích yêu cầu, không thể thay thế tài liệu đặc tả chi tiết. Vai trò của sơ đồ use case:

• Giúp các bên liên quan nắm nhanh bức tranh tổng thể về:
  • Ai sử dụng hệ thống (actor)
  • Họ làm được gì (use case)
  • Hệ thống tương tác với những dịch vụ bên ngoài nào
• Hỗ trợ phân nhóm chức năng, phân chia module, phân công đội phát triển

Sau khi thống nhất sơ đồ use case, cần có các tài liệu chuyên sâu hơn:

• Đặc tả chi tiết cho từng use case:
  • Luồng chính (main flow), luồng phụ (alternative flow), luồng lỗi (exception flow)
  • Điều kiện tiền đề (pre-condition), điều kiện kết thúc (post-condition)
  • Quy tắc nghiệp vụ (business rules), ràng buộc dữ liệu, quy tắc tính giá/khuyến mãi
• User flow: mô tả hành trình người dùng qua nhiều màn hình, nhiều use case liên tiếp.
• Wireframe / prototype: thể hiện giao diện, bố cục, thành phần tương tác.
• ERD (Entity Relationship Diagram): mô hình dữ liệu, quan hệ giữa bảng sản phẩm, đơn hàng, khách hàng, khuyến mãi, v.v.
• Tài liệu API: cho các tích hợp với cổng thanh toán, đơn vị vận chuyển, CRM, nền tảng quảng cáo, v.v.

Sự kết hợp giữa sơ đồ use case và các tài liệu này giúp đội phát triển và kiểm thử triển khai chính xác, giảm tối đa việc hiểu sai hoặc bỏ sót nghiệp vụ.

Nên dùng công cụ nào để vẽ sơ đồ use case website bán hàng?

Lựa chọn công cụ phụ thuộc vào quy mô dự án, quy trình làm việc và mức độ quen thuộc của đội với UML. Một số tiêu chí chuyên môn nên cân nhắc:

• Hỗ trợ đầy đủ ký pháp UML cơ bản: actor, use case, system boundary, association, include, extend.
• Dễ chỉnh sửa, cộng tác: hỗ trợ làm việc nhóm, comment, versioning.
• Khả năng xuất bản: xuất hình ảnh, PDF, hoặc nhúng vào tài liệu đặc tả.

Một số nhóm công cụ thường dùng:

• Công cụ UML chuyên dụng (Visual Paradigm, Enterprise Architect):
  • Phù hợp với dự án lớn, cần nhiều loại sơ đồ (use case, class, sequence, activity, ERD).
  • Có khả năng sinh code hoặc sinh skeleton tài liệu từ sơ đồ.
• Công cụ online (draw.io, Lucidchart, Creately):
  • Dễ truy cập, không cần cài đặt, hỗ trợ cộng tác thời gian thực.
  • Đủ tốt cho hầu hết dự án website bán hàng nhỏ và vừa.
• Công cụ thiết kế tổng hợp (Figma, Miro):
  • Thuận tiện khi đội UX/UI đã dùng sẵn cho wireframe, prototype.
  • Có thể đặt sơ đồ use case cạnh wireframe để thảo luận trong cùng một không gian.

Điểm quan trọng là tính nhất quán: chọn một công cụ và quy ước ký pháp rõ ràng, dùng xuyên suốt dự án để mọi thành viên dễ đọc và cập nhật.

Sơ đồ use case website bán hàng nâng cao cần thêm marketing và SEO không?

Với website bán hàng hướng tới tăng trưởng dài hạn, việc đưa các use case về marketing và SEO vào sơ đồ use case nâng cao là rất cần thiết, vì chúng ảnh hưởng trực tiếp đến:

• Khả năng thu hút traffic (organic, paid, social)
• Khả năng tối ưu chuyển đổi (từ visitor thành lead, từ lead thành khách hàng)
• Khả năng đo lường và tối ưu hiệu quả chiến dịch

1. Use case liên quan đến marketing

• Tạo và quản lý landing page cho từng chiến dịch, từng nhóm sản phẩm.
• Thu lead: form đăng ký, popup, lead magnet, đồng bộ lead sang CRM.
• Thiết lập automation (email, SMS, push) theo hành vi:
  • Bỏ giỏ hàng, xem sản phẩm nhiều lần, không quay lại sau X ngày
  • Chúc mừng sinh nhật, nhắc gia hạn, nhắc mua lại
• Tracking và báo cáo chiến dịch:
  • Gắn UTM, mapping nguồn traffic với đơn hàng
  • Báo cáo chi phí/đơn hàng, ROAS, LTV theo kênh

2. Use case liên quan đến SEO

• Quản lý onpage:
  • Chỉnh sửa meta, heading, URL, internal link cho từng trang
  • Quản lý nội dung blog, category, tag phục vụ SEO
• SEO kỹ thuật:
  • Quản lý sitemap, robots.txt, redirect, canonical
  • Cấu hình schema cho sản phẩm, bài viết, breadcrumb
• Báo cáo organic:
  • Thống kê traffic organic, từ khóa, landing page chính
  • Theo dõi chuyển đổi từ organic, giá trị đơn hàng, hành vi người dùng

Khi các use case marketing và SEO được đưa vào sơ đồ, đội phát triển sẽ nhận thức rõ đây là yêu cầu ngay từ đầu, tránh tình trạng hệ thống chỉ phục vụ bán hàng cơ bản rồi sau đó phải sửa kiến trúc để đáp ứng nhu cầu tăng trưởng.