Weekly Business Review ecommerce: playbook KPI tree, P&L drivers và decision log

Weekly Business Review cho ecommerce không nên là buổi họp đọc lại dashboard. Một WBR tốt phải giúp team nhìn đúng performance, hiểu driver, chốt quyết định và theo dõi action đến kết quả. Nếu mỗi tuần team vẫn dành phần lớn thời gian để hỏi “số nào đúng?” hoặc “ai đang xử lý việc này?”, WBR chưa làm đúng vai trò.

Bài viết này là playbook thiết kế Weekly Business Review cho ecommerce: từ KPI tree, P&L drivers, agenda mẫu, pre-read, action log, decision log đến automation report.

Weekly Business Review ecommerce là gì?

Weekly Business Review là nhịp quản trị hàng tuần để đánh giá kết quả kinh doanh và đưa ra quyết định vận hành. Với ecommerce, WBR cần nối các nhóm dữ liệu: revenue, traffic, conversion, AOV, ads, promotion, inventory, margin, campaign calendar và action log.

Một WBR tốt cần trả lời:

• Tuần qua đạt/chưa đạt KPI nào?
• Driver chính là gì?
• Vấn đề nào cần quyết định?
• Action tuần trước đã xong chưa?
• Tuần tới ưu tiên gì?

Nếu WBR chỉ đọc số, nó không tạo nhiều giá trị.

Vì sao WBR ecommerce thường kém hiệu quả?

Có năm nguyên nhân phổ biến.

Thứ nhất, dữ liệu chưa thống nhất. Mỗi team mang một nguồn số khác nhau vào họp.

Thứ hai, không có pre-read. Người tham gia xem số ngay trong cuộc họp, khiến thời gian bị dùng để hiểu dữ liệu thay vì ra quyết định.

Thứ ba, thiếu KPI tree. Team biết revenue thấp nhưng không biết vì traffic, conversion, AOV, margin hay tồn kho.

Thứ tư, không có action log. Issue tuần trước bị nhắc lại nhưng không rõ owner, deadline, status.

Thứ năm, cuộc họp quá đông và agenda quá rộng. Không phải ai cũng cần tham gia mọi phần.

KPI tree cho WBR ecommerce

Revenue có thể bóc theo:

Revenue = Traffic × Conversion Rate × AOV

Profitability có thể bóc theo:

Contribution Profit = Revenue - COGS - Discount - Media Spend - Shipping Subsidy - Platform Fee - Return/Cancel Cost

Với ecommerce, chỉ nhìn revenue là chưa đủ. Một tuần revenue tăng nhưng margin giảm mạnh vì discount/media spend có thể không phải kết quả tốt.

KPI tree nên gồm:

• Revenue
• Orders
• AOV
• Traffic/sessions/product views
• Conversion rate
• Gross margin
• Discount rate
• Media spend
• ROAS/MER
• Stock availability
• Return/cancel rate
• Campaign performance

Agenda WBR mẫu

Một agenda 60–75 phút có thể như sau:

1. Executive summary — 5 phút

Tóm tắt tuần qua: đạt/chưa đạt KPI, issue lớn nhất, quyết định cần chốt.

2. KPI vs target — 10 phút

So sánh actual với target theo channel/sub-channel. Không đi quá sâu vào từng biểu đồ.

3. Driver diagnosis — 15 phút

Bóc driver: traffic, conversion, AOV, ads, promotion, inventory, margin.

4. Channel deep dive — 15 phút

Chỉ deep dive kênh có issue hoặc cơ hội lớn. Không review đều tất cả kênh nếu không cần.

5. Action review — 10 phút

Xem action tuần trước: done, delayed, blocked, impact.

6. Decision & next week priorities — 10 phút

Chốt quyết định, owner, deadline và expected impact.

Pre-read: thứ quyết định chất lượng cuộc họp

Pre-read nên gửi trước WBR ít nhất vài giờ. Nội dung gồm:

• KPI summary.
• Top 5 issue.
• Driver diagnosis.
• Action status.
• Decision needed.
• Data caveat nếu có.

Người tham gia phải đọc trước. Nếu không có pre-read, WBR thường biến thành buổi đọc dashboard trực tiếp.

Action log và decision log

Action log lưu việc cần làm. Decision log lưu quyết định đã chốt.

Action log nên có:

• issue
• owner
• deadline
• status
• expected impact
• actual result
• blocker

Decision log nên có:

• decision
• rationale
• owner
• date
• review date
• metric expected to move

Hai log này giúp WBR có tính kế thừa. Tuần sau không bắt đầu lại từ đầu.

Automation cho WBR

Automation có thể hỗ trợ WBR bằng cách:

• tự tổng hợp KPI theo tuần
• so sánh với target và tuần trước
• highlight anomaly
• kéo action chưa đóng
• tạo summary theo channel
• chuẩn bị pre-read
• gửi reminder owner

Nhưng automation không thay thế quyết định. Nó giúp cuộc họp tập trung vào trade-off và ưu tiên.

Dashboard WBR nên có gì?

Dashboard nên gồm:

• Weekly scorecard
• Channel performance
• P&L driver
• Campaign performance
• Inventory risk
• Customer/traffic insight
• Action log
• Decision needed

Mỗi chart nên có mục đích. Nếu chart không hỗ trợ quyết định, bỏ.

Cadence sau WBR

WBR không kết thúc khi cuộc họp kết thúc. Sau WBR cần:

• gửi decision summary
• update action log
• gửi owner reminder
• theo dõi high-priority action giữa tuần
• đưa issue chưa xong vào WBR tuần sau

Nếu không có follow-up, WBR chỉ là một buổi họp tốt nhưng không tạo thay đổi.

Common mistakes

Họp quá đông

Người không có vai trò quyết định hoặc owner action không cần tham gia toàn bộ. Có thể tách phần deep dive.

Agenda quá dài

WBR không nên review mọi thứ. Chỉ tập trung vào driver lớn và decision cần chốt.

Không có owner

Mọi action phải có owner. “Team sẽ xử lý” không phải owner.

Không đo impact

Action xong nhưng không đo kết quả thì team không học được gì.

Playbook triển khai 30 ngày

Tuần 1: chuẩn hóa KPI và agenda

Output:

• KPI tree
• WBR agenda
• participant list
• data source list

Tuần 2: xây pre-read dashboard

Output:

• weekly scorecard
• driver view
• action log template
• decision log template

Tuần 3: chạy WBR thử

Output:

• meeting notes
• decision log
• action owner/deadline
• feedback từ participants

Tuần 4: automation và tối ưu

Output:

• automated pre-read
• action reminder
• anomaly summary
• improved agenda

WBR operating principles

Một WBR tốt cần nguyên tắc rõ. Dữ liệu phải được chuẩn bị trước, mỗi phần trình bày phải dẫn đến decision hoặc action, issue phải có owner, action cũ phải được review và cuộc họp phải phân biệt diagnosis với decision.

Nếu không có các nguyên tắc này, WBR sẽ trượt về dạng đọc dashboard và nhắc việc chung chung.

P&L driver cho ecommerce WBR

WBR không nên chỉ nhìn doanh thu. Cần nhìn cả profitability. Một P&L driver tree đơn giản là net revenue trừ COGS, discount, media spend, platform fee, shipping subsidy và return/cancel cost để ra contribution profit.

Nếu revenue tăng nhờ discount sâu và media spend cao, contribution profit có thể giảm. WBR cần chỉ ra trade-off này.

Các câu hỏi nên có: revenue tăng/giảm do volume hay AOV, gross margin có thay đổi do product mix không, discount rate có vượt kế hoạch không, media spend có tạo doanh thu incremental không, return/cancel có ảnh hưởng net revenue không.

Pre-read template

Một pre-read WBR tốt nên dài 1–3 trang, không phải 30 slide. Cấu trúc gồm executive summary, KPI scorecard, driver diagnosis, issue list, action status và decision needed.

Pre-read nên được gửi đủ sớm để người tham gia đọc trước. Nếu không có pre-read, meeting owner đang dùng thời gian họp để làm việc đáng lẽ phải chuẩn bị trước.

Decision log nên viết thế nào?

Decision log cần có decision, context, options considered, rationale, owner, expected impact và review date. Ví dụ: giảm exposure SKU A trong campaign cuối tuần vì days of cover chỉ còn 2 ngày; owner là Marketplace Lead và Merchandise; review lại vào thứ Hai.

Decision log giúp tuần sau không tranh luận lại cùng một vấn đề và giúp team học từ quyết định cũ.

Action quality: action tốt và action xấu

Action xấu là “team kiểm tra Shopee”. Action tốt là “Marketplace Lead kiểm tra Lazada campaign exposure và ads pacing cho campaign 6.6 trước 11h ngày mai; nếu traffic vẫn dưới 70% expected pacing, đề xuất tăng ads budget hoặc đổi placement.”

Action tốt có owner, phạm vi, deadline, điều kiện và hướng xử lý.

Dashboard automation cho WBR

Automation nên chuẩn bị KPI summary, so sánh target/last week, top anomaly, driver tree diagnosis, action overdue, decision pending và suggested agenda.

Nếu có AI, AI nên tóm tắt issue và gợi ý câu hỏi cho WBR, không tự quyết định thay team.

WBR metrics để đo chất lượng cuộc họp

Bản thân WBR cũng cần đo hiệu quả: % action hoàn thành đúng hạn, số decision được chốt, số issue lặp lại quá 3 tuần, thời gian họp trung bình, % thời gian dành cho decision, số action không có owner và số data issue phát sinh trong họp.

Nếu WBR càng ngày càng dài nhưng action completion thấp, meeting format đang có vấn đề.

Ví dụ WBR cho ecommerce multi-channel

Tuần này revenue đạt 96% target, nhưng contribution profit chỉ đạt 82%. Driver tree cho thấy marketplace GMV tốt nhờ discount sâu nhưng margin giảm và media spend tăng. Official web/app conversion giảm do traffic paid kém chất lượng. Inventory có 3 SKU hero sắp hết hàng trước campaign tuần tới.

Decision cần chốt là có tiếp tục discount sâu không, có giảm spend ở campaign ROAS thấp không, có chuyển stock sang SKU hero không và tuần tới ưu tiên margin hay revenue.

Đây là giá trị của WBR: đưa trade-off lên bàn và chốt quyết định.

FAQ

WBR nên kéo dài bao lâu?

Thường 60–75 phút là đủ nếu có pre-read tốt. Nếu kéo dài hơn, thường là do dữ liệu chưa chuẩn hoặc agenda quá rộng.

Ai nên tham gia WBR?

Người phụ trách channel, marketing/performance, commercial, merchandise/inventory, finance/BI nếu cần và decision owner. Không nên mời quá đông.

Có nên họp WBR mỗi tuần không?

Có nếu business thay đổi nhanh và team có action cần theo dõi. Nếu tuần nào cũng không có quyết định, format WBR cần xem lại.

WBR khác daily meeting thế nào?

Daily meeting xử lý issue ngắn hạn. WBR nhìn driver theo tuần, trade-off, quyết định ưu tiên và action có impact lớn hơn.

Kết luận

Weekly Business Review tốt giúp team ecommerce họp ít hơn nhưng quyết định tốt hơn. Chìa khóa không nằm ở số lượng biểu đồ, mà ở KPI tree, pre-read, driver diagnosis, action log và decision log. Khi automation chuẩn bị dữ liệu và highlight issue trước, WBR có thể tập trung vào phần con người làm tốt nhất: chọn ưu tiên, xử lý trade-off và chịu trách nhiệm với kết quả.

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ủ đề **ecommerce weekly business review** là các quyết định vận hành đặc thù, không phải automation chung chung.

KPI tree

Trong ngữ cảnh ecommerce weekly business review, `KPI 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 KPI 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 KPI 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.

P&L drivers

Trong ngữ cảnh ecommerce weekly business review, `P&L drivers` 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 P&L drivers.
• 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 P&L drivers 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.

pre-read

Trong ngữ cảnh ecommerce weekly business review, `pre-read` 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 pre-read.
• 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 pre-read 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.

agenda WBR

Trong ngữ cảnh ecommerce weekly business review, `agenda WBR` 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 agenda WBR.
• 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 agenda WBR 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.

action log

Trong ngữ cảnh ecommerce weekly business review, `action log` 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 action log.
• 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 action log 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.

decision log

Trong ngữ cảnh ecommerce weekly business review, `decision log` 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 decision log.
• 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 decision log 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.

meeting metrics

Trong ngữ cảnh ecommerce weekly business review, `meeting metrics` 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 meeting metrics.
• 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 meeting metrics 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.

automation summary

Trong ngữ cảnh ecommerce weekly business review, `automation summary` 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 automation summary.
• 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 automation summary 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.