Dự báo tồn kho ecommerce: playbook sales velocity, days of cover và campaign uplift

Dự báo tồn kho ecommerce không phải là cố đoán chính xác 100% nhu cầu tương lai. Mục tiêu thực tế hơn là giúp team phát hiện sớm SKU có nguy cơ hết hàng, SKU đang tồn chết, SKU cần bổ sung trước campaign và SKU cần xả bằng promotion. Nếu làm đúng, forecast giúp giảm mất doanh thu vì stockout và giảm vốn bị kẹt trong hàng bán chậm.

Bài viết này cung cấp playbook triển khai dự báo tồn kho ecommerce bằng các chỉ số dễ bắt đầu: sales velocity, days of cover, lead time, safety stock, sell-through rate, campaign uplift và reorder point.

Dự báo tồn kho ecommerce là gì?

Dự báo tồn kho ecommerce là quá trình ước tính nhu cầu bán ra và trạng thái tồn kho tương lai dựa trên dữ liệu bán hàng, tồn kho, lịch campaign và thời gian bổ sung hàng. Trong môi trường ecommerce, forecast cần phản ứng nhanh hơn retail truyền thống vì traffic, ads, flash sale và marketplace campaign có thể làm nhu cầu thay đổi mạnh trong vài giờ hoặc vài ngày.

Một hệ thống forecast tốt cần trả lời:

• SKU nào có nguy cơ hết hàng?
• SKU nào đang tồn quá lâu?
• SKU nào cần nhập thêm trước campaign?
• SKU nào nên giảm exposure vì stock thấp?
• SKU nào nên xả bằng promotion?

Vì sao ecommerce dễ hết hàng và tồn chết?

Ecommerce có hai cực rủi ro cùng lúc. Một bên là SKU bán chạy hết hàng đúng lúc traffic tăng. Bên còn lại là SKU chậm bán bị tồn lâu vì forecast quá lạc quan hoặc campaign không đạt kỳ vọng.

Nguyên nhân thường gặp:

• Sales velocity thay đổi mạnh do campaign.
• Ads hoặc livestream tạo spike bất ngờ.
• Lead time bổ sung hàng dài hơn thời gian bán hết.
• Tồn kho bị chia giữa nhiều kho/sàn/shop.
• Dữ liệu available stock không phân biệt reserved stock.
• Planning không nối với campaign calendar.

Forecast tốt không chỉ nhìn lịch sử bán hàng. Nó cần nối lịch sử với bối cảnh campaign, tồn kho và lead time.

Metric tree cho inventory forecasting

Các metric nền tảng:

• Available stock: tồn có thể bán.
• Reserved stock: tồn đã giữ cho đơn/campaign/kênh khác.
• Average daily sales: số bán trung bình theo ngày.
• Sales velocity: tốc độ bán, thường tính 7/14/28 ngày.
• Days of cover: số ngày tồn kho còn đủ bán.
• Lead time: thời gian bổ sung hàng.
• Safety stock: tồn an toàn.
• Sell-through rate: tỷ lệ bán qua tồn.
• Stockout risk: rủi ro hết hàng.
• Dead stock risk: rủi ro tồn chết.

Công thức cơ bản:

Days of cover = Available stock / Average daily sales

Reorder point = Average daily sales × Lead time + Safety stock

Sell-through rate = Units sold / Units available

Nếu days of cover thấp hơn lead time cộng campaign buffer, SKU có nguy cơ hết hàng.

Chọn sales velocity thế nào?

Không nên dùng một average duy nhất cho mọi SKU. Có ít nhất ba loại velocity:

• 7-day velocity: phản ứng nhanh với biến động mới.
• 14-day velocity: cân bằng giữa ngắn hạn và ổn định.
• 28-day velocity: ổn hơn cho SKU ít biến động.

Với SKU bán nhanh hoặc đang campaign, nên ưu tiên 7-day/14-day. Với SKU bán chậm, 28-day có thể ổn hơn. Với SKU mùa vụ, cần so sánh cùng kỳ hoặc cùng loại campaign.

Một cách thực dụng:

• Hero SKU: dùng max(7-day velocity, 14-day velocity) để tránh đánh giá thấp nhu cầu.
• Normal SKU: dùng weighted average giữa 14-day và 28-day.
• Slow-moving SKU: dùng 28-day và theo dõi sell-through.

Kết hợp campaign calendar

Forecast chỉ dựa vào lịch sử bán thường bị sai trong giai đoạn campaign. Team cần thêm campaign uplift.

Ví dụ:

Baseline daily sales = 100 units/day

Campaign uplift expected = 50%

Campaign velocity = 150 units/day

Nếu available stock = 500 units, days of cover theo baseline là 5 ngày. Nhưng trong campaign, days of cover chỉ còn 3.3 ngày. Nếu lead time là 5 ngày, SKU này có rủi ro hết hàng trước khi bổ sung kịp.

Campaign uplift nên dựa trên:

• Lịch sử campaign tương tự.
• Mức discount.
• Media support.
• Marketplace placement.
• Livestream/affiliate plan.
• Product seasonality.

Phân nhóm SKU để ra quyết định

Không phải SKU nào cũng cần xử lý giống nhau. Dashboard forecast nên chia nhóm.

Nhóm 1: Hero SKU risk

SKU bán chạy, đóng góp GMV lớn, days of cover thấp. Action: bổ sung hàng, chuyển stock, giảm risk campaign hoặc thay SKU substitute.

Nhóm 2: Campaign conflict SKU

SKU sắp vào campaign nhưng stock không đủ. Action: điều chỉnh allocation, giảm exposure hoặc đổi mechanics.

Nhóm 3: Slow-moving SKU

SKU bán chậm, sell-through thấp, tồn lâu. Action: bundle, markdown, campaign xả hoặc ngừng nhập thêm.

Nhóm 4: Healthy SKU

SKU có stock đủ và velocity ổn. Action: giữ monitoring.

Nhóm 5: Data issue SKU

SKU thiếu dữ liệu stock, mapping sai hoặc velocity bất thường. Action: kiểm tra data trước khi forecast.

Dashboard tồn kho nên có gì?

Một dashboard inventory forecasting nên có:

• Overview stock health.
• Top SKU stockout risk.
• Top SKU dead stock risk.
• Days of cover distribution.
• Campaign conflict table.
• Reorder suggestion.
• Stock allocation by channel/shop.
• Issue/action log.

Bảng quan trọng nhất là SKU risk table. Nó nên có:

• SKU
• Product name
• Category
• Available stock
• Sales velocity 7/14/28 ngày
• Days of cover
• Lead time
• Campaign upcoming
• Risk level
• Suggested action
• Owner

Alert logic cho tồn kho

Các alert nên bắt đầu đơn giản.

Alert 1: Stockout risk

Điều kiện: days of cover < lead time + campaign buffer.

Context:

• available stock
• sales velocity
• lead time
• campaign upcoming
• suggested reorder quantity

Alert 2: Hero SKU low stock

Điều kiện: SKU thuộc top GMV hoặc top traffic có stock dưới ngưỡng.

Action:

• ưu tiên bổ sung
• chuyển stock
• giảm campaign exposure nếu cần

Alert 3: Dead stock risk

Điều kiện: sell-through thấp, tồn lâu và không có campaign sắp tới.

Action:

• markdown
• bundle
• xả qua kênh phù hợp
• ngừng nhập thêm

Alert 4: Data mismatch

Điều kiện: SKU có order nhưng stock bằng 0, hoặc stock thay đổi bất thường.

Action:

• kiểm tra mapping
• kiểm tra sync inventory
• xác nhận reserved/available stock

Playbook triển khai 30 ngày

Tuần 1: chuẩn hóa dữ liệu SKU và tồn kho

Output:

• SKU master.
• Mapping SKU theo kênh/shop.
• Available/reserved stock definition.
• Lead time theo nhóm hàng.
• Campaign calendar.

Tuần 2: tính velocity và days of cover

Output:

• velocity 7/14/28 ngày.
• days of cover.
• SKU risk table bản đầu.
• data quality issue list.

Tuần 3: thêm campaign uplift và alert

Output:

• campaign buffer logic.
• stockout risk alert.
• dead stock alert.
• owner map.

Tuần 4: vận hành routine

Output:

• daily inventory risk check.
• weekly stock review.
• action log.
• đo stockout/dead stock improvement.

Common mistakes

Dùng average quá dài

Average 90 ngày có thể làm mờ biến động campaign. Với ecommerce, cần velocity ngắn hơn cho SKU bán nhanh.

Không phân biệt available và reserved stock

Nếu 500 units đã reserved cho kênh khác nhưng dashboard vẫn coi là available, forecast sẽ sai.

Không nối campaign calendar

SKU đủ hàng trong ngày thường có thể hết hàng trong campaign. Forecast không có campaign calendar thường đánh giá thấp rủi ro.

Không tính lead time

Biết SKU còn 3 ngày hàng không đủ nếu lead time bổ sung là 10 ngày. Lead time là biến bắt buộc.

Forecast theo nhóm SKU: không dùng một công thức cho tất cả

Một sai lầm phổ biến là áp cùng một công thức forecast cho mọi SKU. Ecommerce thường có nhiều nhóm sản phẩm với hành vi khác nhau.

Hero SKU cần forecast bảo thủ theo hướng tránh stockout. Slow-moving SKU cần forecast theo hướng tránh nhập thêm và kiểm soát tồn. Seasonal SKU cần so với cùng kỳ hoặc campaign tương tự. New SKU thiếu lịch sử cần dùng proxy từ sản phẩm tương tự.

Gợi ý phân nhóm: hero SKU, campaign SKU, long-tail SKU, new SKU và end-of-season SKU. Mỗi nhóm cần rule riêng về velocity, safety stock, reorder và markdown.

Decision tree cho stockout risk

Khi hệ thống báo SKU có rủi ro hết hàng, owner nên đi theo decision tree: kiểm tra stock data, kiểm tra velocity outlier, kiểm tra lead time, kiểm tra campaign uplift, rồi mới chọn action.

Action có thể là reorder, transfer stock, substitute SKU, giảm ads/campaign exposure hoặc điều chỉnh promotion mechanics. Điều quan trọng là alert phải đi kèm bối cảnh, không chỉ nói “SKU sắp hết hàng”.

Reorder quantity tính thế nào ở mức đơn giản?

Một công thức khởi đầu:

Reorder quantity = Expected demand during lead time + Safety stock - Available stock - Incoming stock

Expected demand during lead time = Forecast daily sales × Lead time.

Safety stock có thể bắt đầu bằng 20–30% expected demand trong giai đoạn chưa có model phức tạp. Với SKU biến động mạnh, safety stock cao hơn. Với SKU chậm hoặc cuối mùa, safety stock thấp hơn.

Ví dụ forecast daily sales 120 units/day, lead time 7 ngày, expected demand 840 units, safety stock 168 units, available stock 500, incoming stock 100. Reorder quantity = 840 + 168 - 500 - 100 = 408 units.

Dead stock không chỉ là hàng bán chậm

Dead stock risk cần nhìn theo thời gian, margin và cơ hội xả hàng. Một SKU bán chậm nhưng còn trong mùa và có campaign sắp tới chưa chắc là dead stock. Một SKU bán chậm, hết mùa, margin thấp và không có campaign hỗ trợ mới là rủi ro lớn.

Các tín hiệu dead stock gồm sell-through thấp, days of inventory quá cao, không có campaign upcoming, product lifecycle sắp hết, giá bán cần markdown sâu và chi phí vốn/lưu kho cao.

Dashboard inventory cho weekly review

Weekly inventory review nên có top stockout risk SKU, top dead stock risk SKU, campaign conflict SKU, reorder recommendation, sell-through by category, stock allocation by channel và issue/action log.

Mục tiêu không phải review tất cả SKU. Mục tiêu là chọn đúng nhóm SKU cần quyết định trong tuần.

Data quality checks bắt buộc

Forecast rất nhạy với dữ liệu sai. Cần check SKU mapping missing, available stock âm, SKU có sales nhưng không có stock record, stock không cập nhật quá X giờ, sales spike bất thường, incoming stock thiếu ETA và campaign SKU không có forecast uplift.

Nếu data quality fail, hệ thống nên cảnh báo data issue trước khi đưa ra reorder suggestion.

FAQ

Forecast đơn giản có đủ không?

Có thể đủ cho giai đoạn đầu nếu mục tiêu là phát hiện risk sớm. Không cần model phức tạp trước khi data và routine ổn.

Nên forecast theo SKU hay category?

Rủi ro stockout nên theo SKU. Planning tổng có thể theo category, nhưng action bổ sung/xả hàng cần SKU-level.

Bao lâu nên cập nhật forecast?

SKU bán nhanh nên cập nhật hằng ngày, thậm chí nhiều lần trong campaign lớn. SKU chậm có thể theo tuần.

Kết luận

Dự báo tồn kho ecommerce tốt nhất khi nó gắn với hành động. Đừng chỉ xây forecast để xem số. Hãy dùng forecast để quyết định nhập thêm, chuyển stock, giảm exposure campaign, xả hàng chậm và bảo vệ SKU hero. Khi sales velocity, days of cover, lead time và campaign calendar được nối lại, team có thể giảm cả stockout lẫn tồn chết.

Research-first specialization pack

Phần này được viết lại để bài không còn dùng khung chung. Trọng tâm của chủ đề **dự báo tồn kho ecommerce** là các quyết định vận hành đặc thù, không phải automation chung chung.

sales velocity 7/14/28 ngày

Trong ngữ cảnh dự báo tồn kho ecommerce, `sales velocity 7/14/28 ngày` là một khái niệm cần được định nghĩa bằng dữ liệu, owner và action cụ thể. Người đọc không chỉ cần biết thuật ngữ, mà cần biết khi chỉ số này thay đổi thì phải quyết định gì.

Cách áp dụng thực tế:

• Xác định nguồn dữ liệu chính cho sales velocity 7/14/28 ngày.
• Xác định công thức hoặc rule tính.
• Đặt ngưỡng cảnh báo theo business context.
• Gắn owner chịu trách nhiệm.
• Ghi action vào log để weekly review không bị mất dấu.

Ví dụ vận hành: nếu sales velocity 7/14/28 ngày lệch khỏi ngưỡng, team không nên chỉ ghi nhận trong dashboard. Alert phải nói rõ driver, mức độ ảnh hưởng, owner và hành động đề xuất.

days of cover

Trong ngữ cảnh dự báo tồn kho ecommerce, `days of cover` là một khái niệm cần được định nghĩa bằng dữ liệu, owner và action cụ thể. Người đọc không chỉ cần biết thuật ngữ, mà cần biết khi chỉ số này thay đổi thì phải quyết định gì.

Cách áp dụng thực tế:

• Xác định nguồn dữ liệu chính cho days of cover.
• Xác định công thức hoặc rule tính.
• Đặt ngưỡng cảnh báo theo business context.
• Gắn owner chịu trách nhiệm.
• Ghi action vào log để weekly review không bị mất dấu.

Ví dụ vận hành: nếu days of cover lệch khỏi ngưỡng, team không nên chỉ ghi nhận trong dashboard. Alert phải nói rõ driver, mức độ ảnh hưởng, owner và hành động đề xuất.

reorder point

Trong ngữ cảnh dự báo tồn kho ecommerce, `reorder point` là một khái niệm cần được định nghĩa bằng dữ liệu, owner và action cụ thể. Người đọc không chỉ cần biết thuật ngữ, mà cần biết khi chỉ số này thay đổi thì phải quyết định gì.

Cách áp dụng thực tế:

• Xác định nguồn dữ liệu chính cho reorder point.
• Xác định công thức hoặc rule tính.
• Đặt ngưỡng cảnh báo theo business context.
• Gắn owner chịu trách nhiệm.
• Ghi action vào log để weekly review không bị mất dấu.

Ví dụ vận hành: nếu reorder point lệch khỏi ngưỡng, team không nên chỉ ghi nhận trong dashboard. Alert phải nói rõ driver, mức độ ảnh hưởng, owner và hành động đề xuất.

safety stock

Trong ngữ cảnh dự báo tồn kho ecommerce, `safety stock` là một khái niệm cần được định nghĩa bằng dữ liệu, owner và action cụ thể. Người đọc không chỉ cần biết thuật ngữ, mà cần biết khi chỉ số này thay đổi thì phải quyết định gì.

Cách áp dụng thực tế:

• Xác định nguồn dữ liệu chính cho safety stock.
• Xác định công thức hoặc rule tính.
• Đặt ngưỡng cảnh báo theo business context.
• Gắn owner chịu trách nhiệm.
• Ghi action vào log để weekly review không bị mất dấu.

Ví dụ vận hành: nếu safety stock lệch khỏi ngưỡng, team không nên chỉ ghi nhận trong dashboard. Alert phải nói rõ driver, mức độ ảnh hưởng, owner và hành động đề xuất.

campaign uplift

Trong ngữ cảnh dự báo tồn kho ecommerce, `campaign uplift` là một khái niệm cần được định nghĩa bằng dữ liệu, owner và action cụ thể. Người đọc không chỉ cần biết thuật ngữ, mà cần biết khi chỉ số này thay đổi thì phải quyết định gì.

Cách áp dụng thực tế:

• Xác định nguồn dữ liệu chính cho campaign uplift.
• Xác định công thức hoặc rule tính.
• Đặt ngưỡng cảnh báo theo business context.
• Gắn owner chịu trách nhiệm.
• Ghi action vào log để weekly review không bị mất dấu.

Ví dụ vận hành: nếu campaign uplift lệch khỏi ngưỡng, team không nên chỉ ghi nhận trong dashboard. Alert phải nói rõ driver, mức độ ảnh hưởng, owner và hành động đề xuất.

dead stock risk

Trong ngữ cảnh dự báo tồn kho ecommerce, `dead stock risk` là một khái niệm cần được định nghĩa bằng dữ liệu, owner và action cụ thể. Người đọc không chỉ cần biết thuật ngữ, mà cần biết khi chỉ số này thay đổi thì phải quyết định gì.

Cách áp dụng thực tế:

• Xác định nguồn dữ liệu chính cho dead stock risk.
• Xác định công thức hoặc rule tính.
• Đặt ngưỡng cảnh báo theo business context.
• Gắn owner chịu trách nhiệm.
• Ghi action vào log để weekly review không bị mất dấu.

Ví dụ vận hành: nếu dead stock risk lệch khỏi ngưỡng, team không nên chỉ ghi nhận trong dashboard. Alert phải nói rõ driver, mức độ ảnh hưởng, owner và hành động đề xuất.

stockout decision tree

Trong ngữ cảnh dự báo tồn kho ecommerce, `stockout decision tree` là một khái niệm cần được định nghĩa bằng dữ liệu, owner và action cụ thể. Người đọc không chỉ cần biết thuật ngữ, mà cần biết khi chỉ số này thay đổi thì phải quyết định gì.

Cách áp dụng thực tế:

• Xác định nguồn dữ liệu chính cho stockout decision tree.
• Xác định công thức hoặc rule tính.
• Đặt ngưỡng cảnh báo theo business context.
• Gắn owner chịu trách nhiệm.
• Ghi action vào log để weekly review không bị mất dấu.

Ví dụ vận hành: nếu stockout decision tree lệch khỏi ngưỡng, team không nên chỉ ghi nhận trong dashboard. Alert phải nói rõ driver, mức độ ảnh hưởng, owner và hành động đề xuất.

data quality checks

Trong ngữ cảnh dự báo tồn kho ecommerce, `data quality checks` là một khái niệm cần được định nghĩa bằng dữ liệu, owner và action cụ thể. Người đọc không chỉ cần biết thuật ngữ, mà cần biết khi chỉ số này thay đổi thì phải quyết định gì.

Cách áp dụng thực tế:

• Xác định nguồn dữ liệu chính cho data quality checks.
• Xác định công thức hoặc rule tính.
• Đặt ngưỡng cảnh báo theo business context.
• Gắn owner chịu trách nhiệm.
• Ghi action vào log để weekly review không bị mất dấu.

Ví dụ vận hành: nếu data quality checks lệch khỏi ngưỡng, team không nên chỉ ghi nhận trong dashboard. Alert phải nói rõ driver, mức độ ảnh hưởng, owner và hành động đề xuất.

Topic-specific checklist

• Có source of truth riêng cho metric chính chưa?
• Có công thức hoặc rule rõ chưa?
• Có owner chưa?
• Có ví dụ áp dụng vào marketplace/web/app/ads/inventory chưa?
• Có action log để theo dõi không?
• Có đo hiệu quả sau khi triển khai không?

FAQ chuyên sâu

Bắt đầu từ đâu?

Bắt đầu từ một use case có dữ liệu sẵn, pain rõ và owner rõ. Không bắt đầu bằng dashboard quá rộng.

Khi nào nên tự động hóa?

Khi rule đã được kiểm chứng thủ công ít nhất vài chu kỳ và team hiểu rõ false positive/false negative.

Đo thành công bằng gì?

Đo bằng thời gian phát hiện vấn đề, action completion rate, business impact và mức giảm issue lặp lại.