BRD nội bộ, bản 0.1, viết cho anh Hà
Nền tảng vận hành kho và đơn hàng cho SME, làm việc bằng group chat
Tài liệu chốt bốn việc trước khi viết dòng code đầu tiên: bán cho ai trước, mỗi phân khúc cần đúng bộ tính năng nào, đóng gói modular ra sao, và khác biệt cốt lõi nằm ở đâu. Khác biệt đó là người trong kho, tài xế, người mua hàng làm việc ngay trong nhóm chat, còn trợ lý AI trong nhóm ghi số liệu, chạy quy trình, ra kế hoạch và báo cáo tại chỗ.
Ví dụ trên là hư cấu, dùng xuyên suốt tài liệu (công ty "Nhà Lá Home"). Tên sản phẩm để trống: tài liệu gọi là "nền tảng" hoặc "sản phẩm" cho tới khi anh đặt tên.
1Vì sao có tài liệu này, nó dựa trên gì, và giới hạn của nó
Tài liệu deep-dive trước đã trả lời Smartlog và TKELog bán gì, cho ai. Câu hỏi "xây đối thủ hay mua WMS" đã được anh Hà chốt là xây. Tài liệu này chuyển quyết định đó thành một sản phẩm có người mua cụ thể và một phạm vi đủ chặt để làm MVP.
Anh Hà đặt hướng bằng bốn ý, tài liệu đi theo đúng bốn ý đó:
- Rõ phân khúc trước. SME bán lẻ hoặc sản xuất là hai thế giới vận hành khác nhau. Mục 3 định nghĩa sáu phân khúc bằng tiêu chí mà người bán hàng hỏi được trong một buổi gặp, chấm điểm và chọn một phân khúc để thắng trước.
- Ma trận tính năng theo phân khúc. Mục 4 ghi mỗi phân khúc mất tiền ở đâu; mục 6 là ma trận tính năng × phân khúc, mỗi ô Must phải truy được về một nỗi đau ở mục 4.
- Nền tảng modular, cấu hình theo nhu cầu. Mục 5 tách Core, module và extension, vẽ phụ thuộc, và định nghĩa "profile phân khúc"; mục 7 đóng gói thành ba gói thương mại cộng add-on.
- Cộng tác bằng group chat là khác biệt cốt lõi. Mục 8–10 là phần dài nhất: mô hình nhóm, thẻ hành động trong chat, trợ lý AI và guardrail, rồi từng quy trình kho viết lại cho chat. Các điểm còn lại (barcode, đa kho, lô/hạn dùng, kết nối sàn) được ghi rõ là parity hoặc cải thiện UX.
1.1 Phương pháp
| Phần | Dựa trên | Mức tin cậy |
|---|---|---|
| Dữ kiện đối thủ (Smartlog, TKELog) | Kế thừa nguyên tài liệu deep-dive ngày 13/11/2026: website, bộ hướng dẫn SSM 728 trang của Smartlog, khoảng 143 bài viết của TKELog, kho ứng dụng, đoạn trích PDF cũ. Giữ nguyên mã nguồn s1–s62 để anh đối chiếu được. | Dữ kiện nhưng là số tự công bố, không kiểm toán; nhiều con số lệch nhau giữa các trang |
| Thị trường, hành vi SME | Không có nghiên cứu thị trường mới trong build này. Mô tả phân khúc, nỗi đau và hành vi mua là suy luận từ cách hai đối thủ tự định vị và từ thực tế vận hành phổ biến của SME bán lẻ, sản xuất tại Việt Nam. | Suy luận cần kiểm bằng phỏng vấn |
| Sản phẩm của ta | Mọi ngưỡng, gói, mức tự chủ của AI, mục tiêu go-live, NFR là lựa chọn thiết kế. | Đề xuất chờ anh duyệt |
| Màn hình mẫu (mục 12) | Dựng bằng HTML/CSS thật, kiểm ở 1280 px và 390 px. Công ty, người, số liệu là hư cấu. | Minh hoạ để chốt thiết kế |
- Không dùng thử sản phẩm của đối thủ. Không có tài khoản demo của Smartlog hay TKELog; mọi nhận xét về họ dựa trên tài liệu công khai đã ghi nguồn.
- Không có số liệu thị trường. Tài liệu không đưa ra quy mô thị trường, số doanh nghiệp SME hay doanh thu của ai. Chỗ nào cần con số thì ghi Chưa công bố hoặc nêu là việc cần đo.
- Chưa phỏng vấn khách hàng. Toàn bộ mục 3–4 là giả thuyết có cấu trúc. Bước kiểm đầu tiên là 3–5 khách thiết kế (design partner) ở phân khúc beachhead (mục 14).
- Không có giá. Mục 7 chỉ đề xuất cấu trúc gói và mô hình tính giá; con số chốt sau khách thiết kế.
1.2 Cách đọc nhãn
- Dữ kiện
- Có nguồn công khai, số trong ngoặc vuông dẫn tới phụ lục nguồn ở mục 14 (cùng mã với tài liệu deep-dive).
- Đề xuất
- Một lựa chọn về sản phẩm của ta: ngưỡng, gói, mục tiêu, quy tắc. Anh có thể đổi; tài liệu ghi cái gì thay đổi theo.
- Suy luận
- Suy luận về khách hàng hoặc thị trường, chưa có nguồn, cần kiểm.
- Chưa công bố
- Đã tìm, không thấy công bố.
- Must Should Could Tắt
- Mức ưu tiên MoSCoW trong ma trận mục 6 và yêu cầu mục 13. "Tắt" nghĩa là module không bật trong profile mặc định của phân khúc đó.
2Thị trường, và vì sao SME là chỗ trống
Hai đối thủ nội địa mạnh nhất đều lớn lên từ khách hàng có kho chuyên nghiệp: 3PL, nhà phân phối, tập đoàn. Cách họ bán, triển khai và tính giá phản ánh điều đó. Một SME có 1–3 kho và không có người chuyên về WMS không hấp thụ được mô hình này.
Mục này chỉ dùng dữ kiện có nguồn từ tài liệu deep-dive. Tài liệu không có số liệu quy mô thị trường SME bán lẻ hay sản xuất ở Việt Nam; chỗ đó để Chưa công bố và đưa vào việc cần đo ở mục 14.
2.1 Đối thủ tự định vị thế nào
| Tín hiệu | Smartlog | TKELog |
|---|---|---|
| Bán cho ai | Khách doanh nghiệp, trang chủ ghi 200+1. Logo khách gồm nhiều hãng đa quốc gia và 3PL10. | "3PL, Phân phối, tập đoàn", thành lập 201041. |
| Quy mô tự công bố | Hơn 1,4 triệu đơn/tháng, hơn 5 triệu m² kho trên hệ sinh thái1. | 4.500.000+ m² kho, 450.000+ đơn/ngày, 990+ phương tiện40. Số khách lệch nhau: 100+41, 41 (PDF, chỉ còn đoạn trích)48, 40 năm 202149. |
| Gói cho SME | Có: SSM ra mắt 20232, ghép STM + SWM + SOM + Admin + Workspace12. Giá nằm sau đăng nhập Workspace, thanh toán VNPay21. | Không thấy gói SME công khai. Số "260+ tính năng cấu hình" (đoạn trích PDF)48 cho thấy hướng cấu hình sâu theo từng loại kho. |
| Thời gian triển khai | SWM "thường 6–10 tuần cho một kho mới"3; STM 4–8 tuần4; SOM 3–6 tuần5; một ca dầu nhớt khoảng 6 tháng23. | "10 ngày" trong nhiều bài 2025–26; Abbott dưới 35 ngày làm việc cho kho đầu tiên61. Dựa vào đội triển khai của TKELog cho từng khách. |
| Giá | Không có bảng giá, chỉ mô tả cách tính: SWM theo "quy mô kho, số người dùng và mô-đun"3; STM theo số phương tiện hoặc số đơn4; SOM theo số đơn và số kênh5. | "Liên hệ". Con số duy nhất công bố là phí sửa tính năng gấp trong 24 giờ: 5.000.000 đ/tính năng; thêm tính năng mới 3–5 ngày miễn phí42,43. |
| Mobile cho SME | App SWM Pro SME: 50+ lượt tải trên Android, cập nhật cuối 10/202230; iOS 1 đánh giá31. | Không thấy app trên kho ứng dụng; tin tuyển dụng 2022 nêu mobile viết bằng Xamarin59. |
| AI | Trợ lý AI theo vai trò trên control tower SCT, hỏi bằng tiếng Việt nhận biểu đồ; cảnh báo qua email, Zalo OA, Slack, Teams, webhook8. Chatbot phân tích Excel trong SCP9. | "AI Report" công bố cho 2026, chưa có mô tả61. |
| API cho bên thứ ba | Trang "Lịch sử truy cập Public API" của SOM để trống20. | Không thấy tài liệu API công khai Chưa công bố. |
2.2 Chỗ trống mang tính cấu trúc
Bốn đặc điểm chung của cả hai, mỗi cái đều hợp lý với khách lớn, cộng lại thành một bức tường với SME Suy luận:
Bán từ trên xuống
Bán qua gặp mặt, demo, tư vấn. Người mua là giám đốc vận hành hoặc CIO có ngân sách dự án. SME không có vai trò đó: chủ doanh nghiệp quyết, và quyết nhanh hoặc không quyết.
Triển khai nặng
Tuần đến tháng, có đội triển khai của vendor đi cùng3,61. SME không có người rảnh để ngồi cùng đội triển khai hàng tuần, và không trả nổi chi phí nhân sự đó trong giá.
2.3 Đối thủ thật của ta là Zalo cộng Excel
Ở phân khúc SME, khách hàng tiềm năng hầu như không dùng WMS của ai cả. Công cụ vận hành hằng ngày của họ là Suy luận:
- Nhóm Zalo theo kho, theo cửa hàng, với tài xế, với nhà cung cấp. Mọi cập nhật ("đã nhận", "thiếu 2 thùng", "khách không nghe máy") nằm ở đây, nhưng không thành số liệu.
- Excel làm sổ tồn, kế hoạch giao, đối soát COD; thường mỗi người giữ một bản.
- Phần quản lý người bán trên sàn và POS cửa hàng, mỗi bên có tồn riêng, đồng bộ bằng tay.
- Phần mềm kế toán (MISA, Fast…) nhận số liệu cuối tháng, sau khi đã lệch.
Đây là lý do khác biệt cốt lõi là chat: không phải vì chat là xu hướng, mà vì nó là nơi SME đã làm việc. Mục 8–10 thiết kế để giữ nguyên thói quen đó và thêm phần còn thiếu: dữ liệu có cấu trúc, xác nhận, nhật ký kiểm toán. Câu hỏi có nên chạy trên Zalo hay app riêng là câu hỏi mở số 2 ở mục 14.
2.4 Những gì chưa biết
- Số SME bán lẻ đa kênh và sản xuất nhỏ có kho riêng tại Việt Nam, phân theo quy mô Chưa công bố.
- Họ đang trả bao nhiêu cho POS, OMS, phần mềm kế toán mỗi tháng (trần giá thực tế) Chưa công bố.
- Tỉ lệ đã từng mua rồi bỏ một phần mềm kho, và lý do.
- Các công cụ POS/OMS phổ thông cho SME có phủ được nhu cầu kho đến đâu. Tài liệu này chưa nghiên cứu nhóm đối thủ đó; đây là khoảng trống lớn nhất của phần thị trường.
5Kiến trúc sản phẩm modular
Một codebase, một mô hình dữ liệu, bật tắt theo tenant. Core luôn bật và đã chứa chat cùng trợ lý AI, vì đó là khác biệt; mọi thứ còn lại là module có phụ thuộc rõ ràng. Phân khúc không phải là một bản sản phẩm khác, mà là một profile: bộ module, cài đặt, nhóm chat và quy trình mặc định.
5.1 Ba tầng
Core: luôn bật
- C1 Dữ liệu gốc: SKU, đơn vị tính và quy đổi, vị trí, đối tác
- C2 Sổ cái tồn kho: chỉ ghi thêm, không sửa
- C3 Chứng từ: phiếu nhập, xuất, chuyển, điều chỉnh và dòng
- C4 Người dùng, vai trò, nhóm
- C5 Nhật ký kiểm toán
- C6 Không gian chat: nhóm, thẻ, luồng
- C7 Trợ lý AI
Module: bật theo profile hoặc mua thêm
- M01 Nhập hàng/GRN · M02 Cất hàng
- M03 Xuất hàng: soạn, đóng, giao
- M04 Barcode/RF · M05 Đa kho, đa điểm
- M06 Lô, serial, hạn dùng
- M07 Hàng trả/RMA · M08 Kiểm kê vòng
- M09 Giao tuyến + POD · M10 Van sales
- M11 Sản xuất nhẹ: BOM, lệnh sản xuất
- M12 3PL đa chủ hàng + tính phí
- M13 Kết nối TMĐT · M14 EDI/API mở
- M15 Phân tích, báo cáo · M16 Mobile
Extension: mở rộng không đổi lõi
- E1 Gói ngành: mẫu dữ liệu, quy trình, nhóm chat theo ngành (mỹ phẩm, thực phẩm, gia dụng…)
- E2 Trường tuỳ biến trên SKU, chứng từ, đối tác
- E3 Webhook ra hệ thống khác
- E4 Cổng đối tác: NCC, nhà xe tham gia như khách mời
Nếu chat là module, sẽ có khách không bật nó, và sản phẩm thành một WMS nữa giữa nhiều WMS. Đặt C6, C7 trong Core buộc mọi module phải "nói được" trong chat: mỗi module khai báo các thẻ (mục 8) và ý định của trợ lý (mục 9) mà nó cung cấp. Đó là hợp đồng bắt buộc khi viết một module mới Đề xuất.
5.2 Đồ thị phụ thuộc
Bật một module tự bật những gì nó cần; tắt một module bị chặn nếu module khác đang dựa vào nó (màn hình cấu hình ở mục 12 hiện cảnh báo này). Mọi module đều cần C1–C7, không ghi lại cho gọn.
5.3 Mô hình cấu hình: profile phân khúc
Profile là một tệp cấu hình có phiên bản, áp vào tenant lúc đăng ký và có thể chỉnh sau. Nó gồm năm phần Đề xuất:
| Phần | Nội dung | Ví dụ: profile S2 Bán lẻ đa kênh |
|---|---|---|
| Module | Danh sách module bật, theo gói | Gói Retail Multi-channel: Core, M01–M05, M07, M08, M13, M15, M16 |
| Cài đặt | Giá trị mặc định cho từng module | Xuất theo FIFO; cho phép tồn âm ở cửa hàng: không; giữ tồn đệm cho sàn: 5%; giờ chốt đơn sàn 15:00 |
| Nhóm chat mặc định | Nhóm tạo sẵn khi mời người, phạm vi dữ liệu và thành viên theo vai trò (mục 8) | #kho-<điểm> mỗi kho, #cua-hang-<điểm> mỗi cửa hàng, #dieu-phoi, #nhan-hang, #ke-hoach, #ngoai-le |
| Quy trình mặc định | Chuỗi thẻ và việc trợ lý chạy theo lịch hoặc sự kiện (mục 9, 10) | 07:30 kế hoạch soạn hàng từ đơn sàn; 17:00 tóm tắt ngày mỗi nhóm; cảnh báo tồn dưới mức đặt lại; đối soát hàng hoàn sàn hằng tuần |
| Mẫu dữ liệu | Mẫu Excel nhập dữ liệu gốc, trường tuỳ biến của gói ngành | SKU có biến thể màu/kích cỡ; mã SKU sàn ánh xạ sang SKU nội bộ |
5.4 Quy tắc: một codebase, cờ tính năng theo tenant, không fork
- Không có bản riêng cho khách nào. Một yêu cầu riêng chỉ được làm nếu nó trở thành cài đặt, trường tuỳ biến (E2), webhook (E3) hoặc tính năng cho mọi tenant cùng phân khúc. Đây là điểm khác có chủ đích với mô hình "thêm tính năng 3–5 ngày" của TKELog42.
- Cờ tính năng ở mức module và cài đặt, đọc từ profile của tenant; không có
if tenant == Xtrong code. - Dữ liệu không đổi hình theo module. Bảng tồn, chứng từ, lô luôn tồn tại; module chỉ bật màn hình, thẻ, quy tắc. Bật M06 sau sáu tháng không cần chuyển đổi dữ liệu, chỉ bắt đầu ghi lô.
- Mọi module khai báo: phụ thuộc, quyền mới, thẻ chat, ý định của trợ lý, sự kiện phát ra, báo cáo. Bộ khai báo này sinh ra màn hình cấu hình và tài liệu.
5.5 Cái giá của modular sai, và cách giới hạn
16 module bật tắt độc lập cho ra 216 = 65.536 tổ hợp về lý thuyết. Không đội nào kiểm hết được; lỗi sẽ nằm ở những tổ hợp mà chỉ một khách dùng, và khách đó sẽ là người phát hiện.
Cách giới hạn Đề xuất:
- Chỉ bán tổ hợp đã kiểm. Ba gói cộng một danh sách add-on có giới hạn (mục 7). Ma trận kiểm thử = 3 gói × các add-on được phép, ước khoảng 20–30 cấu hình, chạy tự động mỗi lần phát hành.
- Phụ thuộc là đồ thị, không phải gợi ý. Hệ thống chặn tổ hợp vi phạm, nên không tồn tại tenant "M10 mà không có M09".
- Hợp đồng sự kiện giữa module. Module giao tiếp qua sự kiện của sổ cái và chứng từ, không gọi thẳng vào nhau; kiểm thử hợp đồng cho từng sự kiện.
- Telemetry tổ hợp. Đếm tenant thật theo tổ hợp module; tổ hợp nào có tenant thì vào ma trận kiểm thử hồi quy.
- Gỡ module là việc có quy trình: tắt module giữ nguyên dữ liệu, chỉ ẩn màn hình và chặn ghi mới; bật lại không mất gì.
7Đóng gói và cấu trúc định giá
Ba gói thương mại, mỗi gói khớp với cụm Must của một nhóm phân khúc ở mục 6, cộng add-on có giới hạn và dịch vụ triển khai trọn gói. Không có con số giá trong tài liệu này: giá chốt sau 3–5 khách thiết kế. Phần dưới là cấu trúc và mô hình tính giá được đề xuất Đề xuất.
7.1 Ba gói
| Module | Retail Core | Retail Multi-channel | Producer |
|---|---|---|---|
| Phân khúc mặc định | |||
| Dành cho | S1 Bán lẻ D2C/TMĐT một kho | S2 Bán lẻ đa kênh; S3 khi thêm add-on Phân phối | S4 Sản xuất, lắp ráp nhỏ; S5 Thực phẩm, đồ uống, mỹ phẩm |
| Core (mọi gói) | |||
| C1–C7: dữ liệu gốc, sổ cái tồn, chứng từ, người dùng, kiểm toán, chat, trợ lý AI | Có | Có | Có |
| Module | |||
| M01 Nhập hàng, M03 Xuất hàng, M04 Barcode, M07 Hàng trả, M08 Kiểm kê, M16 Mobile | Có | Có | Có |
| M02 Cất hàng | Cơ bản (vị trí cố định) | Cơ bản | Đủ (gợi ý vị trí, khu cách ly) |
| M05 Đa kho, đa điểm | Không (1 kho) | Có | Có |
| M06 Lô, serial, hạn dùng | Add-on | Add-on | Có |
| M11 Sản xuất nhẹ (BOM, lệnh sản xuất) | Không | Không | Có (từ v1.5, xem câu hỏi 4) |
| M13 Kết nối TMĐT | Tối đa 2 kênh | Đủ kênh | Add-on |
| M15 Phân tích, báo cáo | Cơ bản | Đủ | Đủ |
| M14 API REST cơ bản | Có | Có | Có |
| Nhóm chat và quy trình mặc định | |||
| Nhóm tạo sẵn | #kho, #dieu-phoi, #ngoai-le | #kho-<điểm>, #cua-hang-<điểm>, #dieu-phoi, #nhan-hang, #ke-hoach, #ngoai-le | #kho-<điểm>, #san-xuat, #nhan-hang, #ke-hoach, #ngoai-le, #qa (S5) |
| Quy trình trợ lý chạy sẵn | Kế hoạch soạn hàng buổi sáng, tóm tắt ngày, cảnh báo tồn thấp | Như Retail Core, cộng đồng bộ tồn theo kênh, đối soát hàng hoàn sàn, chuyển hàng giữa điểm | Cảnh báo cận date, nhắc PO trễ, kế hoạch sản xuất tuần, truy xuất lô |
7.2 Add-on và thứ không bán
| Add-on | Cho ai | Ghi chú |
|---|---|---|
| Phân phối: M09 Giao tuyến + POD, M10 Van sales | S3; S2 có đội xe riêng | Mở từ v2 cho van sales; M09 bản POD đơn giản có thể sớm hơn (mục 14) |
| M06 Lô, serial, hạn dùng | S1, S2 bán mỹ phẩm, thực phẩm, điện tử có serial | Bật được bất cứ lúc nào, không chuyển đổi dữ liệu (mục 5.4) |
| M13 cho gói Producer | S4, S5 có bán thẳng trên sàn | |
| M14 EDI | Khách giao hàng cho chuỗi siêu thị lớn yêu cầu EDI | v2 |
| E1 Gói ngành, E2 Trường tuỳ biến, E3 Webhook, E4 Cổng đối tác | Theo nhu cầu | E4 khách mời trong nhóm chat không tính phí (mục 7.4) |
| M12 3PL đa chủ hàng + tính phí | S6 | Không bán ở v1. Lý do ở mục 3: S6 là sân của TKELog, Smartlog42,52,53 và cần độ sâu cấu hình mà SME không cần. |
7.3 Dịch vụ triển khai
Mặc định là tự triển khai theo luồng onboarding ở mục 11. Thêm một dịch vụ "triển khai cùng" trọn gói, giá cố định, không tính theo giờ Đề xuất: làm sạch dữ liệu Excel, cấu hình profile, dựng nhóm chat, đào tạo 1 buổi trong nhóm chat, theo kèm 2 tuần đầu. Mục tiêu là doanh thu dịch vụ không vượt doanh thu thuê bao năm đầu, để sản phẩm không trượt thành công ty dự án.
7.4 Mô hình tính giá: ba lựa chọn
Đối thủ: Smartlog mô tả tính theo quy mô kho, số người dùng, mô-đun cho SWM3, theo số đơn và số kênh cho SOM5, theo phương tiện hoặc đơn cho STM4; con số cụ thể không công khai21. TKELog: "liên hệ"43.
| Mô hình | Ưu | Nhược | Đánh giá |
|---|---|---|---|
| Theo kho + dải người dùng | Dễ hiểu; giống cách SME mua phần mềm khác | Phạt đúng thứ sản phẩm cần: mỗi tài xế, nhân viên cửa hàng, NCC kéo vào nhóm chat là thêm tiền, nên khách sẽ giữ người ngoài chat và quay lại Zalo | Không chọn |
| Theo đơn/tháng | Tăng theo giá trị khách nhận được; khách nhỏ trả ít | Mùa cao điểm (11/11, Tết) hoá đơn nhảy; khó dự đoán; với S4, S5 số đơn không phản ánh độ phức tạp | Dùng làm một trục |
| Theo điểm hoạt động + dải đơn/tháng, thành viên chat không giới hạn | Khớp chi phí thật (mỗi kho, cửa hàng cần cấu hình, hỗ trợ); khuyến khích kéo mọi người vào nhóm; dải đơn rộng nên không nhảy giá mỗi tháng | Phải định nghĩa "điểm" (xe van có là điểm không); khách một kho nhiều đơn trả nhiều hơn khách ba kho ít đơn | Khuyến nghị Đề xuất |
- Giá gói = phí theo điểm hoạt động (kho, cửa hàng) × dải đơn/tháng. Dải rộng, xét lại theo trung bình 3 tháng, không theo tháng cao điểm.
- Thành viên chat không giới hạn; khách mời NCC, nhà xe miễn phí; tài khoản quản trị không tính riêng.
- Hạn mức hành động AI tính trong gói theo dải đơn; vượt thì giảm tốc chứ không cắt (mục 9, chi phí mỗi hành động AI).
- Giá công khai trên website, có máy tính chi phí. Đây là một điểm khác biệt về cách bán so với "liên hệ" của cả hai đối thủ21,43.
- Con số: chốt sau 3–5 khách thiết kế, đo mức họ đang trả cho POS/OMS/kế toán và giá trị họ thấy được (câu hỏi mở 5).
11Triển khai dễ và onboarding
Dễ triển khai là tiêu chí cạnh tranh ngang với dễ dùng. Đối thủ đo bằng tuần: SWM 6–10 tuần cho một kho mới3, SOM 3–6 tuần5; TKELog quảng cáo 10 ngày nhưng với đội triển khai của họ đi cùng61. Ta đo bằng ngày, và khách tự làm được.
11.1 Lời hứa và điều kiện để giữ lời
Mục tiêu Đề xuất
- S1, S2: go-live trong 5 ngày làm việc kể từ khi đăng ký, khách tự làm, có hỗ trợ trong chat.
- S5: 10 ngày làm việc (thêm lô, hạn dùng, tồn đầu kỳ theo lô).
- S4: 10–15 ngày khi có M11 (thêm BOM).
- "Go-live" = phiếu nhập và phiếu xuất thật đầu tiên đi qua hệ thống, tồn khớp kiểm đếm ở 20 SKU bán chạy nhất.
Phải đúng thì mới đạt
- Khách có danh sách SKU trong Excel hoặc trong sàn/POS; dưới 3.000 SKU đang bán.
- 1–3 kho; vị trí trong kho có thể đặt tên theo kệ, không cần sơ đồ bin chi tiết ngày đầu.
- Có một người chịu trách nhiệm phía khách, 1–2 giờ mỗi ngày trong tuần đầu.
- Kiểm đếm tồn đầu kỳ được làm theo khu, không cần kiểm toàn kho trong một ngày (mục 11.3).
- Không cần tích hợp ERP ngày đầu; kế toán nhận file xuất cho tới khi kết nối xong.
11.2 Tám bước onboarding
- Đăng kýEmail hoặc số điện thoại, tên công ty. Không thẻ thanh toán. Ngay sau đăng ký, người đăng ký vào nhóm #bat-dau với Trợ lý và nhân viên hỗ trợ của ta.
- Chọn profile phân khúcNăm câu hỏi (bán ở đâu, bao nhiêu kho, có sản xuất không, có hạn dùng không, đang dùng gì) đề xuất S1–S5; người dùng xem trước module, nhóm chat và quy trình sẽ được tạo (màn hình mục 12c) rồi xác nhận.
- Nhập dữ liệu gốc từ ExcelTải mẫu theo profile hoặc thả file đang có; Trợ lý ánh xạ cột, phát hiện lỗi (mục 11.3) và đưa danh sách sửa vào nhóm #bat-dau dưới dạng thẻ việc.
- Đặt kho, điểm, vị tríTên kho, cửa hàng; vị trí đặt theo kệ hoặc khu; in tem vị trí và tem SKU thiếu mã vạch từ trình duyệt.
- Mời người, tự tạo nhóm chatMời bằng số điện thoại và vai trò; hệ thống tạo nhóm mặc định của profile và xếp người theo vai trò, phạm vi dữ liệu theo điểm.
- Kết nối kênhSàn, website, POS theo gói (M13). Tồn chưa đẩy lên sàn cho tới bước 8; chỉ kéo đơn về để xem trước.
- Chạy thử trong sandboxMột bản sao tenant, dữ liệu thật, giao dịch không tính: một phiếu nhập, một đơn xuất, một hàng trả, đi trọn trong nhóm chat. Trợ lý chấm từng bước và chỉ chỗ sai.
- Go liveKiểm đếm tồn đầu kỳ theo khu, ghi số dư đầu; bật đẩy tồn lên kênh; Trợ lý đăng thẻ "ngày đầu tiên" với danh sách việc trong 7 ngày đầu.
11.3 Chuyển dữ liệu từ Excel, kể cả chỗ lộn xộn
| Vấn đề thường gặp Suy luận | Hệ thống phát hiện thế nào | Xử lý đề xuất Đề xuất |
|---|---|---|
| SKU trùng: cùng hàng, hai mã (một mã cửa hàng, một mã sàn) | Trùng tên gần giống sau khi bỏ dấu, trùng mã vạch, trùng giá và nhóm | Thẻ "có thể trùng" theo cặp, người dùng chọn gộp hoặc giữ; mã cũ lưu làm mã phụ để đơn sàn vẫn khớp |
| Thiếu mã vạch | Cột trống hoặc mã không hợp lệ (sai số kiểm tra) | Sinh mã nội bộ, in tem; cho phép đi tiếp, không chặn go-live |
| Đơn vị tính hỗn loạn: thùng, lốc, cái, hộp lẫn lộn | Cùng SKU có số lượng cả lẻ và chẵn, tên có "thùng 24", "lốc 6" | Một đơn vị cơ sở mỗi SKU + bảng quy đổi; Trợ lý đề xuất quy đổi từ tên, người dùng xác nhận theo lô 20 dòng |
| Biến thể viết thành dòng riêng không liên kết | Tên giống nhau khác hậu tố màu, cỡ | Gợi ý gom thành sản phẩm cha có biến thể; không bắt buộc |
| Tồn đầu kỳ không tin được | Tồn âm, tồn lẻ ở hàng chỉ bán theo thùng | Không nhập tồn từ Excel làm số chính thức; dùng làm số "dự kiến" và kiểm đếm theo khu trong tuần đầu, chênh lệch thành phiếu điều chỉnh có lý do |
| Lô, hạn dùng nằm trong ghi chú | Chuỗi ngày tháng trong cột ghi chú (S5) | Trợ lý tách ngày, đề xuất số lô; người dùng xác nhận |
11.4 Trợ lý cài đặt và mẫu theo phân khúc
- Trợ lý cài đặt chính là Trợ lý trong chat, ở nhóm #bat-dau. Nó giữ một danh sách việc onboarding (thẻ việc), nhắc việc còn dở mỗi sáng, và trả lời "bước tiếp theo là gì".
- Mẫu theo phân khúc gồm: mẫu Excel, nhóm chat, quy trình mặc định, báo cáo mặc định, và một bộ dữ liệu mẫu hư cấu để sandbox có cái chạy trước khi dữ liệu thật vào.
- Gói ngành (E1) thêm trường và quy tắc: mỹ phẩm (số công bố, hạn dùng sau mở nắp), thực phẩm (FEFO, khu lạnh), gia dụng (biến thể, hàng dễ vỡ).
11.5 Mô hình hỗ trợ: chat trong chính sản phẩm
Hỗ trợ diễn ra trong nhóm #ho-tro của tenant, nơi nhân viên hỗ trợ của ta là khách mời có quyền hạn chế (không xem giá vốn, không ghi dữ liệu, chỉ xem cấu hình và nhật ký khi khách cấp quyền theo phiên). Hai lợi ích: khách không phải học một kênh hỗ trợ khác, và mỗi lần hỗ trợ là một lần khách thấy sản phẩm làm việc bằng chat như thế nào Đề xuất.
- Trợ lý trả lời trước câu hỏi "làm thế nào"; câu nào nó không chắc thì chuyển người thật, có ghi lý do.
- Cam kết phản hồi trong giờ làm việc Đề xuất; con số cụ thể chốt khi có đội hỗ trợ.
- Mỗi yêu cầu hỗ trợ có thẻ việc với trạng thái; khách không phải hỏi lại "xong chưa".
14MVP và lộ trình, rủi ro, câu hỏi mở, phụ lục nguồn
MVP phải chứng minh một điều trước mọi thứ khác: một cửa hàng bán lẻ đa kênh chạy kho cả tuần bằng nhóm chat, và tồn cuối tuần khớp kiểm đếm. Mọi thứ không phục vụ điều đó lùi sang v1.5 hoặc v2.
14.1 MVP và lộ trình Đề xuất
| Phiên bản | Phân khúc | Phạm vi | Vì sao ở đây |
|---|---|---|---|
| v1 (MVP) | S2 beachhead, S1 cùng gói Retail Core; 3–5 khách thiết kế | Core C1–C7 đủ: nhóm chat theo phạm vi dữ liệu, bảy loại thẻ, máy trạng thái thẻ nhập liệu, Trợ lý với các ý định đọc và soạn nháp (A0, A1). M01, M02 cơ bản, M03, M04, M05, M07, M08, M13 (2 sàn + website), M15 cơ bản, M16, API REST cơ bản. Tích hợp đơn vị vận chuyển phổ biến để in vận đơn. | Đây là tập Must của S1, S2 ở mục 6. Không có lô, BOM, tuyến: mỗi thứ thêm vào nhân ma trận kiểm thử (mục 5.5) trước khi chứng minh được giả thuyết chat. |
| v1.5 | Thêm S5, rồi S4 | M06 lô, hạn dùng, FEFO, truy xuất; gói Producer với M11 sản xuất nhẹ; E4 khách mời NCC, nhà xe trong nhóm; Trợ lý đọc ảnh tem để tạo SKU, đối chiếu phiếu giao của NCC với PO; kết nối phần mềm kế toán phổ biến; cầu nối thông báo sang Zalo (câu hỏi 2); M09 POD đơn giản. | S5 có nỗi đau lô, hạn dùng rõ và chi trả cao (mục 3–4); cần nền v1 ổn định trước. BOM lùi để v1 không gánh hai thế giới vận hành cùng lúc (câu hỏi 4). |
| v2 | S3; mở rộng S2 lớn hơn | M09 lập tuyến đủ, M10 van sales, M14 EDI, thêm gói ngành E1; cho phép quy trình lên mức tự chủ A2 khi đạt điều kiện ở mục 9; đánh giá lại M12 3PL. | S3 cần tuyến, xe, COD theo xe: phần TMS mà Smartlog, TKELog đều mạnh4,43. Vào sau khi lợi thế chat đã có bằng chứng. |
- 3 khách thiết kế chạy 4 tuần liên tiếp, không quay lại Excel làm sổ tồn chính.
- Ít nhất 70% thay đổi tồn đi vào qua nhóm chat (tin nhắn hoặc thẻ), phần còn lại qua màn quét.
- Chênh lệch kiểm đếm cuối tuần ở 20 SKU bán chạy dưới 1%.
- Không có lần ghi sai nào của Trợ lý đi qua mà không có người xác nhận.
- Thời gian onboarding thực tế được đo, so với mục tiêu ở mục 11.
14.2 Rủi ro và cách giảm
| Rủi ro | Vì sao đáng lo | Giảm thiểu | Tín hiệu sớm |
|---|---|---|---|
| Trợ lý ghi sai dữ liệu | Một lần ghi sai tồn làm mất niềm tin vào cả sản phẩm, và sai ở sổ cái lan sang sàn, kế toán. | Mọi ghi làm thay đổi tồn qua thẻ xác nhận (A1); cửa sổ hoàn tác 15 phút; ghi là bút toán đảo, không sửa đè; bộ đánh giá chạy trước mỗi lần đổi model (mục 9). | Tỉ lệ thẻ bị sửa trước khi xác nhận; số lần hoàn tác/tuần |
| Hoài nghi "chat làm cơ sở dữ liệu" | Kế toán, chủ doanh nghiệp quen màn hình và báo cáo; chat bị xem là tán gẫu. | Nói rõ: tin nhắn là nhật ký, chứng từ mới là sổ (mục 8); mọi thẻ mở ra chứng từ đầy đủ; báo cáo, màn hình vẫn có. Demo bằng đối soát tồn khớp. | Khách thiết kế hỏi "xuất Excel" trong tuần đầu nhiều hơn hỏi về chat |
| API sàn TMĐT thay đổi, giới hạn | Kết nối sàn là parity bắt buộc với S1, S2; khi hỏng thì oversell, khách đổ lỗi cho ta Suy luận. | Lớp kết nối tách riêng, có hàng đợi và thử lại; khi mất kết nối thì đăng thẻ ngoại lệ, giữ tồn đệm cho sàn; theo dõi thay đổi API như một việc thường xuyên. | Số lần đồng bộ thất bại/ngày theo sàn |
| Chi phí onboarding mỗi khách cao | Nếu mỗi khách cần người của ta ngồi cùng nhiều ngày, đơn vị kinh tế của SaaS SME vỡ. | Luồng 8 bước tự làm; Trợ lý cài đặt; mẫu theo phân khúc; dịch vụ triển khai giá cố định (mục 7.3). Đo giờ công hỗ trợ mỗi khách từ khách đầu tiên. | Giờ hỗ trợ/khách trong 30 ngày đầu |
| Đối thủ phản ứng về giá | Smartlog đã có gói SME (SSM)2,12; có thể hạ giá hoặc công khai giá. | Không cạnh tranh bằng giá thấp nhất; cạnh tranh bằng cách làm việc (chat), thời gian go-live và giá công khai. Giữ cấu trúc giá không tính theo đầu người. | Đối thủ công khai bảng giá hoặc gói dùng thử |
| Phụ thuộc Zalo | Nếu sản phẩm sống trên Zalo, ta phụ thuộc vào chính sách và API của một nền tảng không kiểm soát được; nếu không, ta phải kéo người dùng khỏi app họ dùng cả ngày. | App riêng là nơi làm việc; Zalo chỉ là kênh thông báo, khách mời (câu hỏi 2). Không đặt dữ liệu, xác nhận, kiểm toán trên Zalo. | Tỉ lệ người dùng tuần đầu mở app riêng so với chỉ đọc thông báo |
| Rò rỉ dữ liệu giữa tenant hoặc giữa nhóm | Trợ lý AI tăng bề mặt rò rỉ: một câu trả lời có thể lấy dữ liệu nhóm khác. | Lọc dữ liệu theo tenant và phạm vi nhóm trước khi tới model; kiểm thử cô lập tenant tự động; NFR cô lập ở mục 13; kiểm thử xâm nhập trước khi bán rộng. | Bất kỳ trường hợp nào trong bộ kiểm thử rò phạm vi; báo cáo của khách |
14.3 Năm câu hỏi mở cho anh Hà
Mỗi câu có một khuyến nghị để làm tiếp ngay, và ghi rõ cái gì thay đổi nếu anh chọn khác.
Khuyến nghị: S2 bán lẻ đa kênh trước, S1 bán cùng gói Retail Core; S5 là làn sóng thứ hai. Lý do ở mục 3: S2 có nhiều người ở nhiều điểm đang phối hợp bằng nhóm Zalo nên khác biệt chat thể hiện rõ nhất; không cần BOM; nỗi đau (bán quá tồn, lệch tồn giữa cửa hàng và sàn) xảy ra hằng ngày và đo được.
Nếu anh chọn sản xuất trước (S5 hoặc S4): v1 phải có M06 lô, hạn dùng và M11 BOM; M13 kết nối sàn lùi xuống; MVP dài hơn vì lô và BOM nhân ma trận kiểm thử; đổi lại, giá trị mỗi khách cao hơn và ít cạnh tranh từ công cụ POS/OMS phổ thông Suy luận.
Khuyến nghị: app riêng là nơi làm việc (thẻ, xác nhận, phạm vi dữ liệu, kiểm toán đều ở đây); Zalo chỉ là cầu thông báo một chiều và lối vào cho khách mời từ v1.5.
Cái giá thật: người dùng phải cài thêm một app; ta phải làm chat đủ tốt để họ chịu mở (đẩy thông báo, tải nhanh, chạy khi sóng yếu). Kênh doanh nghiệp chính thức mà Zalo mở là Official Account và tin thông báo theo mẫu; nhóm chat cá nhân không phải nơi một bot bên thứ ba tham gia như thành viên có quyền ghi dữ liệu Suy luận (cần xác minh với tài liệu Zalo for Developers trước khi chốt). Vì vậy "chạy hoàn toàn trên Zalo" có thể không làm được đúng thiết kế ở mục 8.
Nếu anh chọn bắc cầu Zalo làm chính: thẻ có nút, máy trạng thái, phạm vi dữ liệu theo nhóm và guardrail khách mời phải thiết kế lại theo những gì Zalo cho phép; phụ thuộc chính sách nền tảng; đổi lại, rào cản cài đặt gần như bằng không.
Khuyến nghị: không, ở v1. Mọi ghi làm thay đổi tồn là A1: Trợ lý soạn thẻ, người bấm xác nhận. Tenant chỉ được nâng một quy trình lên A2 sau 30 ngày và khi đủ mọi điều kiện ở mục 9 (không phải điều chỉnh tồn, tối đa 50 đơn vị mỗi dòng và dưới 10.000.000 đ mỗi thẻ, người gửi thuộc nhóm của điểm đó, độ tin cậy từ 0,9, độ chính xác trên bộ đánh giá của tenant từ 99%). A3 không bao giờ áp dụng cho ghi tồn.
Nếu anh cho phép tự ghi sớm hơn: nhanh hơn một chạm mỗi cập nhật, nhưng một lỗi ghi sai lan sang sàn và kế toán trước khi ai thấy; cần thêm đối soát tự động cuối ngày và chấp nhận rủi ro uy tín trong giai đoạn khách thiết kế.
Khuyến nghị: v1.5, cùng gói Producer. v1 đi với beachhead bán lẻ không cần BOM; làm BOM nửa vời sẽ bị S4 so với phần mềm sản xuất chuyên và thua.
Nếu đưa vào v1: thêm M11 và gần như kéo theo M06 (thành phẩm theo lô với S5); thêm nhóm #san-xuat, thẻ lệnh sản xuất, ý định "xuất nguyên liệu theo lệnh"; MVP dài hơn và khách thiết kế phải có ít nhất một nhà sản xuất.
Khuyến nghị: chốt cấu trúc bây giờ (theo điểm hoạt động + dải đơn/tháng, thành viên chat không giới hạn, mục 7.4), để con số tới sau 3–5 khách thiết kế. Khách thiết kế dùng miễn phí hoặc giá tượng trưng đổi lấy phỏng vấn hằng tuần và quyền dùng tên làm case.
Nếu chốt con số ngay: có giá công khai sớm để bán, nhưng đoán mò trần chi trả của SME (tài liệu không có số liệu nào về mức họ đang trả); hạ giá sau dễ hơn tăng giá, nên nếu phải chốt sớm thì chốt cao và giảm bằng ưu đãi.
14.4 Phụ lục nguồn
Mã nguồn giữ nguyên từ tài liệu deep-dive Smartlog và TKELog (s1–s33 Smartlog, s40–s62 TKELog), chỉ liệt kê những nguồn tài liệu này trích. Ngày truy cập 13/11/2026. Không có nguồn mới nào được thêm: mọi điều về sản phẩm của ta là Đề xuất hoặc Suy luận.
- s1gosmartlog.com: trang chủ, số liệu, khách hàng
- s2gosmartlog.com/gioi-thieu: lịch sử (SSM cho SME, 2023)
- s3gosmartlog.com/swm: SWM, FAQ giá và thời gian triển khai
- s4gosmartlog.com/stm: STM, FAQ giá và triển khai
- s5gosmartlog.com/som: SOM, kênh bán, FAQ
- s8gosmartlog.com/sct: control tower SCT, trợ lý AI, kênh cảnh báo
- s9gosmartlog.com/scp: hoạch định SCP, chatbot phân tích Excel
- s10gosmartlog.com/customers: khách hàng
- s12support-smartlog.gitbook.io/bo-huong-dan-su-dung-ssm: bộ hướng dẫn SSM
- s13Hướng dẫn STM: các đối tượng sử dụng
- s14Hướng dẫn SWM: phân quyền
- s18Hướng dẫn SWM: chiến thuật cất hàng
- s20Hướng dẫn SOM: lịch sử truy cập Public API (trang trống)
- s21Hướng dẫn Workspace: hệ thống vận hành và tính năng (giá sau đăng nhập)
- s23Case doanh nghiệp dầu nhớt đa quốc gia (17/10/2026)
- s30Google Play: SWM Pro SME
- s31App Store: SSM SWM
- s40tkelog.com: trang chủ, số liệu
- s41tkelog.com/gioi-thieu: giới thiệu, 100+ khách hàng
- s42tkelog.com/tkelog-wms: TKELog WMS, bảng hỗ trợ
- s43tkelog.com/tkelog-tms: TKELog TMS, bảng hỗ trợ
- s48TKELog_WMS_Presentation_V2.pdf trên tks.com.vn (nay 404; chỉ còn đoạn trích tìm kiếm): http://www.tks.com.vn/FileManagement/EditorDocument/TKELog_WMS_Presentation_V2.pdf
- s49TKELog_WMS_Presentation.pdf, bản 2021 (nay 404; đoạn trích tìm kiếm): http://tks.com.vn/FileManagement/EditorDocument/TKELog_WMS_Presentation.pdf
- s52Bài: hỗ trợ tính phí dịch vụ kho 3PL
- s53Bài: tăng tỷ lệ hài lòng khách thuê kho 3PL (cổng chủ hàng)
- s57Bài: quản lý hàng hoá theo shelf-life
- s59Bài: tuyển dụng thực tập sinh 2022 (Blazor, .NET 6, Xamarin)
- s61tkelog.com/tin-tuc: chuỗi "Hành trình 300 bước chân", thời gian go-live, AI Report 2026
