Dashboard KPI cho team vận hành ecommerce: theo dõi gì mỗi ngày, mỗi tuần, mỗi tháng
KPI nào team vận hành ecommerce đa store cần theo dõi hàng ngày, hàng tuần, hàng tháng — công thức, người phụ trách, ngưỡng an toàn và nhịp review.
Chạy một store, bạn có thể "cảm" được số liệu. Chạy 5, 10 hay 30 store, cảm giác hết tác dụng — một store có thể âm thầm chảy máu refund hoặc tồn đơn chưa fulfill cả tuần mà không ai phát hiện. Dashboard KPI cho team vận hành giải quyết đúng vấn đề này: một bộ chỉ số nhỏ, dùng chung, mỗi chỉ số có công thức, có người phụ trách và có nhịp review cố định. Bài này chỉ rõ team đa store nên theo dõi KPI nào theo ngày, tuần, tháng; ai chịu trách nhiệm từng con số; và khi nào Google Sheets là đủ, khi nào cần dashboard realtime.
Vì sao team đa store cần một bộ KPI chung, không phải 10 tab Analytics
Analytics có sẵn của Shopify thực ra rất tốt cho một store — cập nhật trong khoảng một phút, đủ số liệu về doanh thu, session, fulfillment. Vấn đề là nó tính theo từng store. Trừ khi bạn dùng Shopify Plus với organization analytics, không có màn hình native nào trả lời câu hỏi "sáng nay doanh thu, dispute đang mở và shipment kẹt trên cả 12 store là bao nhiêu".
Không có bộ KPI chung, chuyện gì xảy ra:
- Mỗi người quản store báo cáo theo cách riêng. Người tính refund rate theo số đơn, người tính theo tiền. Số không so sánh được với nhau, cuộc họp tuần biến thành tranh cãi về định nghĩa thay vì ra quyết định.
- Vấn đề lộ ra quá muộn. Dispute rate bò dần về phía ngưỡng của mạng thẻ mà không ai thấy, cho đến khi email cảnh báo tới. Store số 7 tồn đơn chỉ lộ khi khách bắt đầu email hỏi.
- Không ai chịu trách nhiệm. Khi "ai đó" theo dõi refund, nghĩa là không ai theo dõi cả.
Giải pháp không phải là thêm dữ liệu, mà là ít con số hơn, định nghĩa một lần, gắn tên người cụ thể và review theo nhịp cố định. Team nào đã quản lý tất cả store Shopify trên một dashboard thì có lợi thế vì dữ liệu thô đã gom sẵn — nhưng kỷ luật KPI vẫn quan trọng kể cả khi bạn bắt đầu bằng spreadsheet.
Bảng KPI cốt lõi
Đây là bộ KPI thực chiến cho team vận hành đa store. Công thức là chính xác; còn cột "ngưỡng tham khảo" là kinh nghiệm vận hành, không phải benchmark ngành — ngách hàng, giá bán và tuyến vận chuyển của bạn sẽ làm các con số này xê dịch, nên hãy coi chúng là ngưỡng báo động ban đầu rồi hiệu chỉnh theo baseline 90 ngày gần nhất của chính mình.
| KPI | Công thức | Nhịp | Ngưỡng tham khảo | Người phụ trách |
|---|---|---|---|---|
| Doanh thu theo store | Gross sales − discount − return, theo store theo ngày | Hàng ngày | Trong ±25% trung bình 7 ngày gần nhất | Ops manager |
| Độ trễ fulfillment | Số giờ trung bình từ lúc đơn thanh toán → tạo fulfillment | Hàng ngày | Dưới 24–48h; trên 72h phải điều tra | Trưởng fulfillment |
| Đơn chưa fulfill > 48h | Số đơn đã thanh toán, chưa fulfill, quá 48h | Hàng ngày | Về gần 0 mỗi sáng | Trưởng fulfillment |
| Shipment kẹt | Tracking không có scan mới của carrier trong 7 ngày (nội địa) / 12–14 ngày (quốc tế) | Hàng ngày | < 2–3% số shipment đang vận chuyển | Logistics/ops |
| MER theo store | Tổng doanh thu ÷ tổng chi phí ads, theo store | Hàng ngày | Đặt theo margin từng store; báo động khi giảm 3 ngày liên tiếp | Media buyer |
| Thời gian phản hồi đầu tiên | Thời gian trung bình từ lúc tạo ticket → phản hồi đầu tiên của người thật | Hàng ngày | Dưới 24h với email | Trưởng support |
| Refund rate | Số tiền refund ÷ gross sales (30 ngày gần nhất) | Hàng tuần | Nhìn xu hướng; tuần nào tăng > 30% so với tuần trước phải tìm nguyên nhân gốc | Ops manager |
| Dispute rate | Số dispute ÷ số giao dịch (tháng gần nhất) | Hàng tuần | Cách xa ngưỡng mạng thẻ (xem bên dưới) | Ops manager / finance |
| Tỷ lệ đạt SLA | % ticket trả lời trong thời hạn cam kết ÷ tổng ticket | Hàng tuần | ≥ 90% so với mục tiêu tự đặt | Trưởng support |
| Tỷ lệ thắng dispute | Dispute thắng ÷ dispute đã phản hồi | Hàng tháng | Cải thiện theo quý | Ops manager |
| Net margin theo store | (Doanh thu − COGS − ship − phí − ads − refund) ÷ doanh thu | Hàng tháng | Dương và ổn định; xếp hạng store theo chỉ số này | Finance |
| Đối soát payout | Số payout khớp với tiền về tài khoản ÷ tổng payout | Hàng tháng | 100%, không ngoại lệ | Finance |
Vài chỉ số cần nói kỹ hơn.
Độ trễ fulfillment và shipment kẹt
Độ trễ fulfillment là chỉ báo sớm nhất: refund, dispute và ticket "đơn của tôi đâu" đều bắt đầu từ việc fulfill chậm. Hãy đo từ lúc thanh toán đến lúc tạo fulfillment, không phải đến lúc giao hàng — vì khoảng đầu là thứ bạn kiểm soát trực tiếp.
Shipment kẹt là chỉ báo sớm thứ hai. Một mã tracking không có chuyển động của carrier suốt một tuần chính là một chargeback trong tương lai kèm dấu thời gian. Kiểm tra thủ công hàng nghìn shipment là bất khả thi, nên theo dõi vận đơn hàng loạt qua 17TRACK với cảnh báo shipment kẹt tự động là một trong những automation đáng làm đầu tiên khi vận hành đa store. Câu hỏi mỗi sáng rất đơn giản: bao nhiêu shipment đang kẹt, ở store nào, với carrier nào?
Dispute rate — KPI duy nhất có ngưỡng cứng từ bên ngoài
Phần lớn ngưỡng KPI do bạn tự đặt. Dispute rate thì khác, vì mạng thẻ đặt hộ bạn. Theo tài liệu của Stripe về các chương trình giám sát của mạng thẻ, chương trình giám sát dispute của Visa đưa merchant vào diện theo dõi mức Standard khi tỷ lệ dispute chạm 0,9% (kèm tối thiểu 100 dispute trong tháng), và mức Excessive ở 1,8%. PayPal thì áp phí High Volume Dispute cho seller có trên 100 giao dịch bán trong 3 tháng liền trước và dispute rate từ 1,5% trở lên — ở diện này bạn trả phí cho mọi dispute bất kể thắng thua.
Bài học vận hành: đừng quản trị theo mốc 0,9%. Hãy đặt báo động nội bộ ở một phần của nó — nhiều operator dùng 0,3–0,5% làm vạch "toàn team vào việc" (nhắc lại: kinh nghiệm, không phải chuẩn công bố) — vì dispute rate là chỉ số trễ, lúc nó in ra con số cao thì những đơn gây ra nó đã ship từ nhiều tuần trước. Và phải theo dõi theo từng store: một store tệ có thể nấp sau mức trung bình "chấp nhận được" của cả danh mục trong khi tài khoản thanh toán của riêng nó đang tiến thẳng vào diện giám sát.
Refund rate
Đừng cố so refund rate của mình với một con số đọc được ở đâu đó. Refund rate khác nhau rất xa theo ngành hàng — quần áo với chuyện đổi size không giống ốp điện thoại. Thứ luôn có giá trị chẩn đoán là xu hướng: refund rate nhảy vọt tuần này so với tuần trước luôn trỏ về một nguyên nhân cụ thể (lô hàng lỗi từ supplier, creative mới gây hiểu lầm, carrier vỡ trận trên một tuyến). Theo dõi theo store và theo sản phẩm nếu được, và coi mỗi cú tăng đột biến là một bài tập tìm nguyên nhân gốc, không phải "chi phí kinh doanh". Nếu volume đã lớn, hãy nối refund vào hệ thống theo dõi lợi nhuận theo từng store để một store "có lãi" không âm thầm trả lại hết lãi qua refund.
Mỗi KPI có đúng một người phụ trách
KPI không có tên người đi kèm chỉ là hình nền màn hình. Gắn mỗi con số cho một người — không phải một team — và người đó phải biết vì sao số nhích trước khi cuộc họp review bắt đầu.
- Trưởng fulfillment phụ trách độ trễ và số đơn chưa fulfill. Buổi sáng của họ bắt đầu từ đơn chưa fulfill cũ nhất trong toàn danh mục.
- Logistics/ops phụ trách shipment kẹt và hiệu suất carrier theo tuyến.
- Media buyer phụ trách MER từng store và chịu trách nhiệm về chi tiêu so với sàn margin, không chỉ ROAS.
- Trưởng support phụ trách thời gian phản hồi và tỷ lệ đạt SLA. Nếu muốn làm bài bản, hãy định nghĩa SLA hỗ trợ khách hàng chạy được trên tất cả store trước, rồi mới đo theo nó.
- Ops manager phụ trách dispute rate, refund rate và chính cái dashboard — trách nhiệm "meta" là giữ định nghĩa nhất quán và dữ liệu chảy đều.
- Finance phụ trách net margin theo store và đối soát payout.
Một người đội ba cái mũ trong danh sách này cũng không sao — ở quy mô 5 store thì đó là chuyện bình thường. Điểm mấu chốt là khi dispute rate nhích lên, có đúng một người phải đến họp với lời giải thích. Việc gắn tên người còn giúp bàn giao và tuyển dụng sạch sẽ hơn: danh sách KPI chính là bản mô tả công việc khi bạn tuyển và đào tạo VA vận hành store.
Nhịp review: quét hàng ngày, họp hàng tuần, mổ xẻ hàng tháng
KPI chỉ thay đổi hành vi khi gắn vào một nhịp cố định.
Hàng ngày (10 phút, không họp). Mỗi người phụ trách quét các chỉ số nhịp ngày của mình vào đầu buổi và post một dòng cho mỗi bất thường vào kênh chung: "Store 4 độ trễ 61h — 3PL thiếu người, xử lý xong trước thứ Năm." Không họp. Kỷ luật ở đây là im lặng nghĩa là "tất cả xanh", nên sự im lặng phải đáng tin. Bước quét này nằm gọn trong checklist vận hành store theo ngày và tuần rộng hơn.
Hàng tuần (45 phút, cả team). Agenda cố định, tuần nào cũng đúng thứ tự đó:
- Toàn cảnh danh mục (5 phút): doanh thu, MER và hướng đi của margin trên tất cả store. Chưa thảo luận.
- Chỉ số đỏ (20 phút): KPI nào vượt ngưỡng. Người phụ trách trình bày nguyên nhân và cách xử lý; cả nhóm chỉ quyết khi vấn đề liên phòng ban.
- Xu hướng (10 phút): bất cứ thứ gì đi một hướng suốt 3 tuần, kể cả khi vẫn "xanh". Đây là chỗ bạn bắt được dispute rate ở 0,4% thay vì 0,9%.
- Quyết định và người làm (10 phút): mọi việc rời phòng họp đều kèm một cái tên và một hạn chót, ghi vào cùng một tài liệu mỗi tuần.
Hàng tháng (90 phút, các trưởng nhóm + finance). Review P&L từng store, tỷ lệ thắng dispute, đối soát payout, và một câu hỏi mang tính cơ cấu: store nào rót thêm, store nào phải sửa, store nào đóng. Hàng tháng cũng là lúc hiệu chỉnh lại "ngưỡng tham khảo" theo dữ liệu thực tế.
Viết agenda ra giấy và giữ nguyên mỗi tuần — nhịp đều thắng cường độ. Nếu team đã vận hành theo quy trình văn bản hoá, buổi review KPI chỉ là thêm một trang trong bộ SOP cho team đa store của bạn.
Spreadsheet hay dashboard realtime: so sánh sòng phẳng
Bạn không cần phần mềm để bắt đầu. Bạn cần định nghĩa, người phụ trách và nhịp review. Nhưng câu hỏi công cụ sẽ đến rất nhanh, nên đây là so sánh thẳng thắn.
| Spreadsheet | Dashboard realtime | |
|---|---|---|
| Chi phí khởi đầu | Miễn phí | Tool trả phí hoặc tự build |
| Thời gian setup | Một buổi chiều | Vài ngày đến vài tuần |
| Độ tươi của dữ liệu | Tính đến lần export gần nhất — thường là hôm qua | Vài phút |
| KPI nhịp ngày | Cực nhọc; sáng nào cũng phải có người export | Có sẵn |
| KPI tuần/tháng | Rất tốt — phân tích linh hoạt, pivot thoải mái | Thường yếu hơn cho phân tích ad-hoc |
| Cảnh báo (shipment kẹt, dispute mới) | Không có | Lý do chính để nâng cấp |
| Sụp đổ khi… | Thêm store thứ 6, hoặc người giữ file đi nghỉ | Sync của vendor lỗi (hỏi kỹ về uptime) |
Câu trả lời thực tế cho đa số team là cả hai, theo trình tự rồi song song:
- Dưới ~3–5 store: spreadsheet nuôi bằng export hàng tuần hoàn toàn ổn cho KPI tuần và tháng. Điểm yếu là lớp hàng ngày — không ai duy trì nổi thói quen export thủ công mỗi sáng, nên KPI hàng ngày âm thầm hết còn "hàng ngày".
- Vượt mốc đó: lớp hàng ngày phải tự động. Đây chính là khoảng trống mà các tool như StoreFleet sinh ra để lấp — một dashboard realtime cho đơn hàng, doanh thu và vận chuyển trên hàng chục store Shopify, kèm cảnh báo shipment kẹt và dispute xếp theo hạn nộp bằng chứng, để "buổi quét sáng" là đọc một màn hình thay vì tự ghép một màn hình.
- Vẫn giữ spreadsheet. Finance và phân tích xu hướng sống khoẻ trong Sheets; mẹo là cho dữ liệu tự chảy vào thay vì gõ tay. Tự động sync đơn Shopify về Google Sheets cho bạn lớp phân tích linh hoạt mà không tốn "thuế export thủ công".
Sai lầm cần tránh là làm ngược thứ tự: mua dashboard trước khi định nghĩa KPI và gắn người phụ trách. Một màn hình realtime hiển thị những con số không ai chịu trách nhiệm chỉ là một cái hình nền đắt tiền hơn.
Bắt đầu với 5 con số
Nếu bảng đầy đủ thấy nặng, thứ Hai này hãy bắt đầu với 5 chỉ số: doanh thu theo store, đơn chưa fulfill > 48h, shipment kẹt, dispute rate và thời gian phản hồi đầu tiên. Gắn 5 cái tên, đặt lịch họp 45 phút hàng tuần, chạy đủ 4 tuần rồi mới thêm bất cứ thứ gì. Một dashboard nhỏ mà team thực sự review mỗi tuần ăn đứt một dashboard đầy đủ không ai mở — và khi nhịp đã thành thói quen, mở rộng bảng KPI là phần dễ nhất.