Mẫu SOP cho team nhỏ vận hành nhiều store Shopify

Cách viết SOP cho team vận hành nhiều store Shopify: quy trình nào cần viết trước, mẫu SOP copy-paste, cách phân công owner và giữ SOP luôn cập nhật.

Cập nhật 2026-07-02

Một team 3 người hoàn toàn có thể vận hành 10 store Shopify — nhưng chỉ khi công việc nằm trong tài liệu, chứ không nằm trong đầu từng người. Khoảnh khắc bạn VA giỏi nhất nghỉ ốm, nghỉ việc, hay đơn giản là quên mất store số 7 xử lý hoàn tiền kiểu gì, thì quy trình không được ghi lại sẽ biến thành doanh thu bị mất. Bài này chỉ cho bạn cách viết SOP (quy trình vận hành chuẩn) thực sự được dùng: nên tài liệu hóa quy trình nào trước, một mẫu SOP copy-paste được ngay, cách phân công người phụ trách, và cách giữ cho kho SOP không mục nát theo thời gian.

Vì sao càng nhiều store, SOP càng quan trọng

Với một store, "kiến thức truyền miệng" vẫn chạy tốt. Founder trả lời mọi câu "cái này xử lý sao?" trong mười giây, và câu trả lời luôn nhất quán vì chỉ có một bộ não nắm nó.

Đến store thứ năm hay thứ mười, cùng một câu hỏi sẽ được trả lời khác nhau tùy vào việc bạn hỏi ai, hỏi về store nào, và hôm đó mọi người mệt đến đâu. Triệu chứng thì luôn giống nhau:

• Hoàn tiền xử lý theo ba kiểu khác nhau — một VA có restock hàng về kho, một VA không, VA thứ ba cấp store credit mà chẳng ai ghi lại.
• Listing trôi dạt — tiêu đề sản phẩm trên Store A theo quy ước đặt tên; tiêu đề trên Store B được viết lúc 2 giờ sáng và chẳng theo quy ước nào.
• Leo thang xử lý theo cảm tính — một chargeback nằm trong inbox của ai đó bốn ngày vì không ai chắc đó là việc của ai.
• Onboarding mất hàng tuần — nhân sự mới phải đi theo học việc cả tháng vì không có gì để đọc.

Một SOP biến quyết định bạn đã đưa ra một lần thành quy trình mà bất kỳ ai cũng thực thi được. Đó chính là bí quyết đằng sau việc quản lý 10+ store mà không rối loạn: ngừng quyết định lại từ đầu, bắt đầu thực thi.

Bài kiểm tra cho một SOP tốt rất phũ và rất đơn giản: một nhân sự mới có năng lực, chỉ dựa vào tài liệu và không hỏi ai, có hoàn thành đúng công việc không? Nếu chưa, SOP đó chưa xong.

Nên tài liệu hóa quy trình nào trước

Đừng cố viết tất cả cùng lúc. Hãy xếp hạng quy trình theo hai yếu tố: tần suất (việc đó xảy ra thường xuyên đến đâu) và mức sát thương (một sai sót tốn kém đến đâu). Viết trước những quy trình tần suất cao và sát thương lớn; phần còn lại có thể chờ.

Vài lưu ý cho bốn mục đầu:

Xử lý đơn hàng. Định nghĩa chính xác "xử lý một đơn" nghĩa là gì với team bạn: kiểm tra đơn ở đâu (admin từng store, hay một dashboard hợp nhất), thế nào thì tính là đơn cần gắn cờ (địa chỉ không khớp, đơn giá trị cao, khách từng chargeback), và đơn gắn cờ thì đi đâu tiếp. Nếu team bạn đang mở mười admin Shopify riêng biệt mỗi sáng, hãy ghi cả điều đó vào — rồi đọc hướng dẫn quản lý mọi store từ một dashboard duy nhất, vì riêng bước đó có lẽ đã là một tiếng mỗi ngày bạn có thể xóa bỏ.

Hoàn tiền. Đây là nơi sự thiếu nhất quán tốn tiền thật. SOP của bạn phải trả lời được: ai được phép hoàn tiền không cần duyệt, và tối đa bao nhiêu? Hoàn một phần hay toàn bộ? Có restock hàng về kho không? Có hoàn cả phí ship không? Luồng hoàn tiền của Shopify hỗ trợ hoàn một phần, tùy chọn restock, và hoàn phí ship riêng — và quan trọng nhất, một lệnh hoàn tiền đã khởi tạo thì không thể đảo ngược. Đó chính xác là loại "cánh cửa một chiều" mà SOP cần đặt một checklist chắn trước.

Leo thang. Hãy viết ra các điều kiện kích hoạt, không chỉ cách xử lý. "Leo thang lên chủ shop khi: nhận chargeback, đơn hàng trên 300 USD, khách dọa kiện hoặc dọa review công khai, đơn kẹt vận chuyển quá 10 ngày." Mỗi điều kiện cần một đích đến có tên cụ thể và một kỳ vọng thời gian phản hồi — phần này khớp thẳng với chính sách SLA hỗ trợ khách trên nhiều store của bạn.

Cập nhật listing. Nguyên tắc lõi cần mã hóa vào SOP: dữ liệu chỉ chảy một chiều. Quyết định nơi dữ liệu sản phẩm được chỉnh sửa (một sheet gốc, một PIM, hay một công cụ bulk) và cấm sửa lẻ trực tiếp trong admin từng store. Một câu duy nhất trong SOP — "không bao giờ sửa dữ liệu sản phẩm trực tiếp trong admin của một store riêng lẻ" — chặn được nhiều tháng trôi dạt âm thầm.

Mẫu SOP (khung copy-paste)

Mọi SOP trong team nên dùng chung một khung. Cấu trúc đồng nhất giúp ai cũng lướt được bất kỳ SOP nào và biết ngay các bước nằm đâu, ngoại lệ nằm đâu, và hỏi ai. Đây là mẫu chúng tôi khuyên dùng — dán vào Notion, Google Docs, hoặc thư mục sops/ trong repo:

# SOP: [Tên công việc — bắt đầu bằng động từ, ví dụ "Xử lý yêu cầu hoàn tiền"]

**Owner:** [một cái tên, không phải một team]
**Áp dụng cho:** [tất cả store / store cụ thể]
**Rà soát lần cuối:** [ngày]
**Thời gian hoàn thành:** [ước tính]

## Khi nào dùng SOP này
[Điều kiện kích hoạt. Ví dụ: "Khách email hoặc nhắn tin xin hoàn tiền,
hoặc yêu cầu hoàn tiền xuất hiện trong inbox hỗ trợ."]

## Trước khi bắt đầu
- [ ] Quyền truy cập cần có: [công cụ/tài khoản/permission nào]
- [ ] Kiểm tra: [điều kiện tiên quyết — ví dụ "đơn đang Fulfilled hay Unfulfilled?"]

## Các bước
1. [Mỗi bước một hành động. Bắt đầu bằng động từ. Ghi rõ đường dẫn
   nút bấm: "Shopify admin → Orders → chọn đơn → Refund".]
2. [Thêm screenshot cho bất kỳ bước nào giao diện dễ gây nhầm.]
3. [Bước nào có quyết định thì viết thành nhánh rõ ràng:
   "Nếu đơn ≤ 50 USD → hoàn ngay.
    Nếu đơn > 50 USD → đăng vào #approvals và chờ 👍."]
4. ...

## Ngoại lệ
- **[Tình huống]:** [cách xử lý]
- **Khách thanh toán một phần bằng gift card:** [cách xử lý]
- **Bất cứ gì không có trong danh sách này:** leo thang (xem bên dưới),
  không tự ứng biến.

## Leo thang
- Leo thang đến: [tên/kênh]
- Leo thang khi: [điều kiện rõ ràng]
- Thời gian phản hồi kỳ vọng: [ví dụ: trong 4 giờ làm việc]

## Hoàn thành nghĩa là
- [ ] [Trạng thái cuối quan sát được — ví dụ "lệnh hoàn tiền hiện trong
      timeline đơn hàng trên Shopify"]
- [ ] [Ghi log — ví dụ "đã thêm dòng vào sheet log hoàn tiền"]
- [ ] [Đã báo khách bằng template X]

## Changelog
- [ngày] — [ai] — [sửa gì và vì sao]

Vì sao từng khối đều xứng đáng có mặt:

• Owner là một cái tên. "Team support phụ trách" nghĩa là không ai phụ trách.
• "Khi nào dùng" ngăn việc áp nhầm SOP cho một tình huống trông na ná.
• Các nhánh quyết định được viết thẳng vào bước, không để cho phán đoán cá nhân. Phán đoán là việc của mục leo thang.
• "Hoàn thành nghĩa là" là mục hay bị bỏ qua nhất và giá trị nhất. Nó biến "chắc là tôi xong rồi" thành một trạng thái kiểm tra được — và đây là chỗ bạn ép việc ghi log, thứ sẽ nuôi dashboard KPI của team sau này.
• Changelog giúp SOP kiểm toán được. Khi một lệnh hoàn tiền sai vào tháng 3, bạn xem lại được quy trình đúng như nó tồn tại ở tháng 3.

Giữ mỗi SOP dưới hai trang. Dài hơn nghĩa là nó thực ra là hai SOP.

Phân công owner (và quyền truy cập)

Một SOP không có owner là một trang wiki đang chờ chết. Giao mỗi SOP cho đúng một người với ba trách nhiệm:

1. Độ chính xác — các bước khớp với thực tế hôm nay, không phải quý trước.
2. Đào tạo — nhân sự mới học việc này từ owner, dựa trên tài liệu.
3. Rà soát — owner ký xác nhận ngày rà soát (chi tiết bên dưới).

Owner không nhất thiết phải là quản lý. Bạn VA xử lý hoàn tiền hằng ngày là owner SOP hoàn tiền tốt hơn founder — người lần cuối đụng vào một lệnh hoàn tiền từ tháng 1. Nếu bạn đang xây đội VA, hãy đưa việc sở hữu SOP vào lộ trình phát triển của họ — đó là một trong những tín hiệu rõ nhất trong quá trình tuyển và đào tạo VA vận hành Shopify cho thấy ai đó sẵn sàng nhận thêm trách nhiệm.

Khớp SOP với permission. Một quy trình ghi "VA được hoàn tiền đến 50 USD không cần duyệt" chỉ đứng vững nếu staff permission trên Shopify của VA đó thực sự dừng ở quyền hoàn tiền — chứ không âm thầm bao gồm cả quyền sửa cài đặt payout hay xóa sản phẩm. Staff permission của Shopify cho phép cấp quyền chi tiết theo từng store, nhưng với mười store thì đó là mười bộ permission riêng phải cấu hình và kiểm tra. Đây là một trong hai chỗ mà nền tảng quản lý đa store thực sự thay đổi cuộc chơi: StoreFleet cho phép bạn đặt permission theo từng store và từng tính năng cho mỗi nhân sự từ một nơi duy nhất, để mô hình phân quyền trong SOP và mô hình phân quyền ngoài thực tế là một.

Một bảng phân công đơn giản là đủ — một bảng, rà soát hằng tháng:

Giữ SOP luôn sống

Đa số kho SOP chết trong vòng sáu tháng. Không phải vì viết dở — mà vì không có gì buộc chúng phải đúng với thực tế. Bốn cơ chế sau khắc phục điều đó:

1. Ngày rà soát là deadline, không phải trang trí. Header của mọi SOP đều có "Rà soát lần cuối". Đặt luật: SOP nào quá hạn rà soát thì bị coi là không đáng tin và bị nêu tên trong buổi họp vận hành hằng tuần. Rà soát rất rẻ — owner chạy lại các bước một lần, sửa chỗ lệch, cập nhật ngày. Mười lăm phút mỗi SOP mỗi chu kỳ.

2. Gặp lỗi ở đâu, sửa tài liệu ở đó. Người đang thực thi SOP mà phát hiện một bước sai chỉ có một nhiệm vụ: sửa tài liệu (hoặc comment vào đó) trước khi kết thúc công việc. Cách này phân tán việc bảo trì cho cả team thay vì dồn hết lên owner.

3. Mọi sự cố đều phải cập nhật một SOP. Trễ deadline chargeback? Giao trùng một đơn? Buổi rút kinh nghiệm chưa kết thúc chừng nào bạn chưa chỉ ra được dòng đã thay đổi trong một SOP (hoặc một SOP mới toanh) để ngăn sự cố lặp lại. Nếu một sự cố không làm thay đổi bất kỳ tài liệu nào, nghĩa là bạn đã quyết định để nó xảy ra lần nữa.

4. Xóa mạnh tay. Một SOP cho quy trình bạn không còn chạy là nhiễu — nó khiến mọi người bớt tin cả kho tài liệu. Lưu trữ nó, đừng tích trữ nó.

Cuối cùng, hãy nối SOP vào nhịp làm việc hằng ngày. SOP mô tả cách làm từng việc; còn checklist vận hành hằng ngày và hằng tuần mô tả việc nào diễn ra lúc nào. Checklist nên link đến SOP tương ứng ở từng bước — đó là thứ giữ cho tài liệu được lưu thông thay vì nằm trong một thư mục không ai mở.

Kế hoạch triển khai trong 2 tuần

Bạn không cần một đợt "chạy nước rút tài liệu". Hai tuần, mỗi ngày một tiếng:

1. Ngày 1–2: Liệt kê mọi công việc lặp lại trên tất cả store. Xếp hạng theo tần suất × mức sát thương.
2. Ngày 3–7: Viết 4 SOP đầu bảng (đơn hàng, hoàn tiền, leo thang, listing) theo mẫu ở trên. Viết trong lúc đang làm việc đó — quay màn hình nếu cần.
3. Ngày 8–9: Phân công owner và backup. Đối chiếu staff permission với những gì mỗi SOP giả định.
4. Ngày 10–12: Nhờ một người không viết SOP đó thực thi nó từ con số không. Mỗi câu họ phải hỏi là một dòng còn thiếu — bổ sung ngay.
5. Ngày 13–14: Đặt ngày rà soát, link SOP từ checklist hằng ngày, và thêm "SOP lệch thực tế" thành mục cố định trong họp tuần.

Từ đó, mỗi tuần viết thêm một SOP cho đến khi hết danh sách đã xếp hạng. Những team làm việc này trước khi vượt mốc ba, bốn store sẽ onboard người mới trong vài ngày thay vì vài tuần — và nếu bạn còn ở giai đoạn sớm hơn, rất đáng đọc cách nợ quy trình cộng dồn khi scale từ 1 lên 10 store để viết tài liệu trước khi bạn cần nó trong tuyệt vọng.

Nguồn

• Shopify Help Center — Staff permissions
• Shopify Help Center — Refunding orders