Bài 52 — Domain e-commerce: 30 thuật ngữ và flow — Sinh Viên Mới Ra Trường: Bắt Đầu Nghề BA

Mở đầu — vì sao bài này quan trọng

Nếu bạn đang tìm việc BA fresher tại Việt Nam năm 2026, e-commerce (thương mại điện tử) gần như chắc chắn nằm trong danh sách domain bạn sẽ gặp. Shopee, Lazada, Tiki, các sàn B2B như Alibaba, các nền tảng bán hàng của FPT, MoMo, ZaloPay, cho tới hàng nghìn website bán lẻ vừa và nhỏ — tất cả đều cần BA hiểu cách một đơn hàng đi từ lúc khách bấm "Thêm vào giỏ" cho tới khi shipper giao hàng và tiền về tài khoản người bán.

Vấn đề của nhiều fresher là: bạn dùng Shopee mỗi ngày với tư cách người mua, nhưng khi vào phỏng vấn hoặc dự án thật, người ta hỏi bạn về SKU, fulfillment, cart abandonment, reconciliation — và bạn ú ớ. Biết domain không phải để tỏ ra thông minh, mà để bạn nói cùng ngôn ngữ với product owner, với đội vận hành kho, với bên thanh toán. Một BA hiểu domain sẽ viết requirement chính xác hơn, đặt câu hỏi elicitation sắc bén hơn, và ít bị stakeholder "qua mặt".

Bài này trang bị cho bạn 30 thuật ngữ cốt lõi của e-commerce, chia theo 6 nhóm chức năng, cộng với flow xương sống của một sàn thương mại điện tử — thứ mà bạn có thể vẽ ra ngay trong buổi phỏng vấn. Đây không phải từ điển để học thuộc, mà là bản đồ tư duy để bạn hiểu tại sao hệ thống được thiết kế như vậy.

Khái niệm cốt lõi

Nhóm 1 — Catalog (danh mục sản phẩm)

Đây là "trái tim dữ liệu" của mọi sàn. Nếu catalog sai, mọi thứ phía sau sai theo.

SKU (Stock Keeping Unit): đơn vị tồn kho nhỏ nhất có thể bán và đếm được. Áo thun màu đỏ size M là một SKU; cũng cái áo đó màu đỏ size L là một SKU khác. Đây là khái niệm fresher hay nhầm nhất — SKU không phải "sản phẩm", mà là biến thể cụ thể có thể quản lý tồn kho riêng.
Product (SPU / sản phẩm): mức khái niệm cao hơn SKU. "Áo thun Uniqlo cổ tròn" là một product, bên dưới có nhiều SKU theo màu/size. Ở nhiều sàn gọi là SPU (Standard Product Unit).
Variant (biến thể): các phiên bản khác nhau của cùng một product theo thuộc tính như size, màu, dung lượng. Mỗi tổ hợp variant thường ánh xạ tới một SKU.
Attribute (thuộc tính): đặc điểm mô tả sản phẩm — màu sắc, chất liệu, thương hiệu. Chia làm hai loại: attribute tạo ra variant (size, màu) và attribute chỉ để mô tả/lọc (chất liệu, xuất xứ).
Bundle (combo/gói): nhóm nhiều SKU bán chung với một giá, ví dụ "mua 1 điện thoại tặng ốp lưng + cường lực". BA cần làm rõ: bundle trừ tồn kho từng SKU thành phần hay có SKU riêng?
Category (ngành hàng): cấu trúc phân cấp để phân loại sản phẩm (Điện tử > Điện thoại > iPhone). Ảnh hưởng trực tiếp tới điều hướng, tìm kiếm và cả phí sàn.
Listing (bài đăng bán hàng): là một sản phẩm được một người bán cụ thể đăng lên sàn. Trên sàn marketplace, cùng một iPhone có thể có hàng trăm listing từ nhiều seller.
Inventory / Stock (tồn kho): số lượng thực tế còn có thể bán của mỗi SKU tại từng kho. Phân biệt: available (còn bán được), reserved (đã giữ cho đơn chưa thanh toán xong), on-hand (đang thực có trong kho).

Nhóm 2 — Cart & Checkout (giỏ hàng và thanh toán)

Cart (giỏ hàng): nơi tạm chứa các SKU khách định mua. Lưu ý cart có thể tồn tại cả khi khách chưa đăng nhập (guest cart) rồi merge khi login.
Cart abandonment (bỏ giỏ): khách thêm hàng vào giỏ nhưng không hoàn tất mua. Tỷ lệ này ở e-commerce thường 60–75%. Là chỉ số cực quan trọng cho các chiến dịch remarketing.
Checkout (quy trình thanh toán): chuỗi bước từ giỏ hàng đến đặt hàng thành công — chọn địa chỉ, chọn vận chuyển, chọn thanh toán, áp mã, xác nhận.
Coupon / Voucher (mã giảm giá): công cụ khuyến mãi. BA cần nắm rõ luật áp dụng: điều kiện tối thiểu, số lần dùng, có cộng dồn được không, ai chịu chi phí (sàn hay seller).
Payment gateway (cổng thanh toán): bên trung gian xử lý giao dịch — tại VN phổ biến là VNPay, MoMo, ZaloPay, cùng thẻ nội địa (Napas) và thẻ quốc tế.
COD (Cash on Delivery): thanh toán khi nhận hàng. Vẫn chiếm tỷ trọng rất lớn ở VN, kéo theo bài toán đối soát tiền mặt phức tạp giữa sàn — shipper — seller.

Nhóm 3 — Order & Fulfillment (đơn hàng và hoàn tất đơn)

Order (đơn hàng): bản ghi cam kết mua bán, có vòng đời qua nhiều order status (chờ xác nhận → đã xác nhận → đang đóng gói → đang giao → đã giao → hoàn thành / hủy / hoàn).
Fulfillment (hoàn tất đơn): toàn bộ quy trình từ khi có đơn tới khi hàng tới tay khách — pick (lấy hàng), pack (đóng gói), ship (giao).
3PL (Third-Party Logistics): đơn vị vận chuyển/kho bên thứ ba như GHN, GHTK, Viettel Post, J&T. Sàn tích hợp API với các 3PL này.
Fulfillment model: sàn tự vận hành kho (fulfilled by platform, ví dụ Lazada LazMall/FBL) hay seller tự gửi hàng (fulfilled by seller). Ảnh hưởng lớn tới SLA và luồng dữ liệu.
Return / RMA (đổi trả hàng): quy trình khách trả hàng và được hoàn tiền hoặc đổi. RMA = Return Merchandise Authorization, mã cho phép trả hàng.

Nhóm 4 — Pricing & Promotion (giá và khuyến mãi)

List price vs Sale price: giá niêm yết và giá bán thực sau giảm. BA phải làm rõ giá nào dùng để tính hoa hồng, tính thuế.
Flash sale: khuyến mãi giới hạn thời gian + số lượng, tạo áp lực mua. Về kỹ thuật đây là bài toán khó vì tải cao đột biến và tranh chấp tồn kho.

Nhóm 5 — Seller & Marketplace (người bán và mô hình sàn)

Marketplace vs Retail (1P vs 3P): sàn tự nhập hàng bán (1P/retail như Tiki Trading) hay chỉ làm nền tảng cho seller bên thứ ba bán (3P/marketplace như Shopee). Nhiều sàn là mô hình lai.
Commission / Take rate (phí hoa hồng): phần trăm sàn thu trên mỗi đơn. Đây là nguồn doanh thu chính của marketplace.
Settlement / Payout (đối soát và giải ngân): quy trình sàn tính toán số tiền phải trả cho seller sau khi trừ phí, rồi chuyển tiền theo chu kỳ.
Reconciliation (đối soát): khớp tiền giữa các hệ thống — tiền COD shipper thu, tiền cổng thanh toán ghi nhận, tiền sàn ghi sổ, tiền trả seller. Sai lệch ở đây gây tranh chấp tiền bạc thật, nên requirement phải cực kỳ chặt.

Nhóm 6 — Chỉ số & vận hành

GMV (Gross Merchandise Value): tổng giá trị hàng hóa giao dịch qua sàn trong một kỳ. Chỉ số "sức khỏe" số một của e-commerce.
Conversion rate (tỷ lệ chuyển đổi): tỷ lệ khách ghé thăm thực sự mua hàng.
AOV (Average Order Value): giá trị đơn trung bình. Bundle và up-sell chính là để tăng AOV.

Tình huống thực tế

Ví dụ 1 — SKU và bài toán oversell tại một shop thời trang trên Shopee

Chị Lan bán quần áo trên Shopee, cùng lúc bán tại cửa hàng vật lý và một website riêng. Một chiếc áo blazer màu be size M chỉ còn 3 cái trong kho. Cuối tuần flash sale, hệ thống Shopee bán được 3 đơn, nhưng cửa hàng offline cũng vừa bán 1 chiếc size M. Kết quả: một khách trên Shopee đặt thành công nhưng không còn hàng để giao — gọi là oversell.

Diễn giải: gốc rễ vấn đề là tồn kho được quản lý theo product ("áo blazer") thay vì theo SKU ("blazer-be-M"), và không có hệ thống đồng bộ tồn kho tập trung giữa các kênh. Khi BA nhận yêu cầu "làm sao để hết oversell", requirement thật không phải "thêm nút cảnh báo", mà là: định nghĩa SKU chuẩn, xây một nguồn tồn kho duy nhất (single source of truth), và cơ chế reserve tồn kho ngay khi khách checkout chứ không đợi thanh toán xong.

Bài học: hiểu đúng SKU vs product giúp BA nhìn ra nguyên nhân thật thay vì vá triệu chứng. Đây là câu hỏi phỏng vấn kinh điển.

Ví dụ 2 — Cart abandonment tại một sàn nội thất giả định "NhaViet"

Sàn nội thất NhaViet có 100.000 lượt thêm vào giỏ mỗi tháng nhưng chỉ 28.000 đơn hoàn tất — tỷ lệ bỏ giỏ 72%. Product owner giao cho BA fresher phân tích. Bằng cách vẽ lại checkout flow và gắn số liệu rớt ở từng bước, BA phát hiện 40% khách rời đi ngay ở bước nhập địa chỉ vì form quá dài, và 25% rời ở bước thanh toán vì phí ship chỉ hiện ra ở phút chót (gây "cú sốc phí ship").

Diễn giải: BA đề xuất hai requirement — rút gọn form địa chỉ (tự động điền từ số điện thoại đã lưu) và hiển thị ước tính phí ship ngay từ trang giỏ hàng. Sau ba tháng, tỷ lệ hoàn tất tăng từ 28% lên 34%, tương đương thêm khoảng 6.000 đơn/tháng.

Bài học: hiểu khái niệm cart abandonment và checkout flow cho phép BA biến một câu hỏi mơ hồ ("sao khách không mua?") thành phân tích theo từng bước có số liệu — đúng chất công việc BA.

Ví dụ 3 — Reconciliation COD gây lệch tiền

Một sàn thời trang tích hợp với GHN để giao COD. Cuối tháng, phòng tài chính báo lệch 47 triệu đồng giữa số tiền GHN báo đã thu và số tiền hệ thống sàn ghi nhận. Nguyên nhân: một số đơn khách trả một phần (nhận 2/3 món, trả lại 1 món ngay tại cửa), shipper thu tiền theo thực nhận nhưng hệ thống sàn vẫn ghi nguyên giá trị đơn gốc.

Diễn giải: BA phải bổ sung requirement cho luồng partial delivery / partial return: trạng thái đơn phải hỗ trợ "giao một phần", và dữ liệu số tiền thực thu phải được đồng bộ từ 3PL về để reconciliation khớp theo từng dòng đơn, không chỉ theo tổng.

Bài học: reconciliation là nơi sai sót gây thiệt hại tiền thật. BA fresher cần biết rằng "đơn hàng" không phải trạng thái đơn giản đúng/sai, mà có các nhánh phức tạp như giao một phần, hoàn một phần.

Hướng dẫn từng bước

Cách để bạn dùng được domain này, không chỉ thuộc:

Vẽ được flow xương sống. Tập vẽ đi vẽ lại luồng chính: Duyệt sản phẩm → Thêm vào giỏ → Checkout (địa chỉ, vận chuyển, thanh toán, mã giảm) → Đặt hàng → Xác nhận & giữ tồn kho → Đóng gói (fulfillment) → Giao qua 3PL → Giao thành công → Đối soát & giải ngân cho seller. Nếu vẽ được luồng này bằng bút trên giấy trong 3 phút, bạn đã hơn phần lớn fresher.

Với mỗi thuật ngữ, hỏi 3 câu: Nó là dữ liệu hay quy trình? Ai là stakeholder liên quan? Nếu nó sai thì hậu quả là gì? Ví dụ SKU sai → oversell → mất uy tín. Cách này biến từ điển thành hiểu biết vận hành.

Liên kết thuật ngữ với chỉ số. Bundle và up-sell → tăng AOV. Rút gọn checkout → giảm cart abandonment → tăng conversion. Tất cả cộng lại → tăng GMV. Khi bạn nói được chuỗi nhân quả này, bạn tư duy như một BA có định hướng kinh doanh.

Tạo một glossary cá nhân. Mở một file (Notion/Sheet), mỗi thuật ngữ ghi: định nghĩa của bạn + một ví dụ thật bạn tự bịa + câu hỏi elicitation liên quan. Đây cũng là artifact bạn có thể show trong portfolio.

Đối chiếu với sàn thật. Mở Shopee/Tiki, tự đặt một đơn nhỏ, quan sát từng màn hình và tự gọi tên: "đây là bước checkout, đây là chọn voucher, đây là chọn 3PL". Học domain qua trải nghiệm thật đóng đinh kiến thức tốt hơn đọc lý thuyết.

Lỗi thường gặp & mẹo

Nhầm SKU với product. Lỗi phổ biến nhất. Nhớ: cái gì đếm được tồn kho riêng thì là SKU.
Nghĩ order chỉ có "thành công / thất bại". Thực tế order là một state machine với hàng chục trạng thái và nhiều nhánh (hủy, hoàn, giao một phần). Requirement thiếu trạng thái là lỗ hổng nghiêm trọng.
Bỏ qua luồng tiền. Fresher thường chỉ chú ý luồng hàng mà quên luồng tiền (payment, settlement, reconciliation). Ở sàn thật, tiền lệch là sự cố nghiêm trọng hơn cả UI xấu.
Coi voucher là chuyện đơn giản. Luật khuyến mãi (cộng dồn, điều kiện, ai chịu chi phí) là một trong những nguồn bug và tranh chấp lớn nhất. Luôn đào sâu business rule của promotion.
Mẹo: khi vào dự án mới, xin ngay một đơn hàng mẫu và "đi bộ" qua toàn bộ vòng đời của nó trong hệ thống. Không gì dạy domain nhanh bằng việc trace một đơn thật từ đầu đến cuối.
Mẹo: học từ tiếng Anh kèm định nghĩa, đừng dịch cứng sang tiếng Việt. Trong dự án thật, mọi người nói "fulfillment", "payout", "SKU" chứ hiếm khi dùng từ thuần Việt.

Bài tập thực hành

Vẽ flow: Bằng draw.io hoặc giấy, vẽ luồng đơn hàng xương sống từ "Thêm vào giỏ" tới "Giải ngân cho seller", đánh dấu rõ đâu là điểm giữ tồn kho (reserve) và đâu là điểm đối soát.
Phân loại 30 thuật ngữ: Tự chia lại 30 thuật ngữ trong bài thành hai cột — "Dữ liệu" và "Quy trình". Với 5 thuật ngữ bất kỳ, viết một câu hỏi elicitation bạn sẽ hỏi stakeholder.
Tình huống order status: Liệt kê tối thiểu 8 trạng thái đơn hàng cho một sàn thời trang có COD, kèm điều kiện chuyển giữa các trạng thái (ví dụ: từ "đang giao" có thể sang "giao thành công", "hoàn hàng", hoặc "giao một phần").
Case oversell: Viết một đoạn 150 từ mô tả requirement để chống oversell cho shop chị Lan ở Ví dụ 1, dùng đúng các thuật ngữ SKU, reserved inventory, single source of truth.
Glossary: Tạo file glossary cá nhân với đủ 30 thuật ngữ, mỗi cái một ví dụ tự nghĩ trong bối cảnh Việt Nam.

Tóm tắt

E-commerce là một trong những domain "béo bở" nhất cho BA fresher tại Việt Nam vì nhu cầu tuyển dụng cao và bạn đã có sẵn trải nghiệm người dùng. Ba nhóm kiến thức cần đóng đinh: catalog (SKU vs product vs variant — hiểu sai gây oversell), order & fulfillment (đơn hàng là state machine nhiều nhánh, không phải đúng/sai), và luồng tiền (payment, settlement, reconciliation — nơi sai sót gây thiệt hại thật). Đừng học thuộc từ điển; hãy vẽ được flow xương sống, gắn mỗi thuật ngữ với stakeholder và hậu quả nếu nó sai, rồi liên kết với các chỉ số GMV, conversion, AOV. Khi bạn nói được chuỗi nhân quả "bundle tăng AOV, giảm cart abandonment tăng conversion, tất cả tăng GMV", bạn không còn là fresher chỉ biết dùng Shopee — bạn đã tư duy như một BA hiểu domain.