Đây là bản đọc của giáo trình Tự dựng hệ thống sale page nhận đơn tự động.
Bản đầy đủ viết cho hai đối tượng cùng lúc: bạn, và trợ lý AI trên máy bạn. Nên nó trộn lẫn hai thứ — chỗ giải thích hệ thống, và chỗ hướng dẫn thao tác từng dòng lệnh. Đọc liền mạch thì rối, vì quá nửa số chữ là thứ bạn sẽ không tự gõ.
Bản này bóc riêng vế của bạn: hiểu hệ thống, và biết cách kiểm. Phần kỹ thuật vẫn còn, nhưng chỉ còn mục đích — làm để được cái gì, và làm sao biết đã xong.
Cả hai bản đều dùng chung quy ước này, và nó là thứ đáng tin nhất trong tài liệu:
🔵 ĐÃ CHẠY THẬT — tôi tự tay làm, có ngày tháng, có lần hỏng và cách chữa. Phần lớn tài liệu nằm ở mức này.
🟡 CHƯA THỬ — tôi chưa gặp tình huống này bao giờ. Nội dung tra từ tài liệu chính thức. Đừng coi đó là kinh nghiệm của tôi.
Không dán nhãn thì mặc định là 🔵.
Tôi tách ra vậy vì tài liệu kỹ thuật mà nói như đúng rồi ở đúng chỗ tác giả chưa từng làm thì khó chịu lắm — bạn làm theo, hỏng, mà chả hiểu hỏng vì đâu. Chỗ nào tôi không biết thì tôi nói là không biết. Đổi lại, chỗ nào tôi bảo đã chạy thật thì bạn tin được.
| Bạn đang muốn | Đọc |
|---|---|
| Hiểu hệ thống chạy ra sao trước khi quyết định làm hay không | Bản này |
| Biết mình sẽ phải tự làm những gì, chuẩn bị trước cho khỏi tắc | Bản này |
| Đang ngồi dựng, cần lệnh cụ thể / cấu trúc bảng dữ liệu | Bản đầy đủ bo-cai/GIAO-TRINH.md |
| Muốn trợ lý dẫn bạn làm từng bước | Bộ skill trong bo-cai/.claude/ — không phải đọc |
Số mục ở hai bản khớp nhau. Đọc tới mục 1.5 ở đây mà muốn xem chi tiết kỹ thuật thì mở mục 1.5 bản đầy đủ.
Bạn bán một sản phẩm. Khách thấy quảng cáo, bấm vào trang, điền đơn. Xong xuôi rồi thì bình thường nó diễn ra thế này:
Cái hệ này tôi làm ra để bỏ hết đoạn chép tay đó đi. Khách bấm một phát là:
Khách bấm ĐẶT HÀNG
│
├─► Lưu vào cơ sở dữ liệu của bạn, sinh MÃ ĐƠN duy nhất (vd CMC7)
├─► Ghi một dòng vào Google Sheet ──► người đóng gói mở Sheet là gói được ngay
├─► Gửi email cho khách (kèm mã QR chuyển khoản ĐÚNG SỐ TIỀN, ĐÚNG MÃ ĐƠN)
└─► Đẩy khách sang trang cảm ơn
Không ai phải gõ lại gì hết.
Chỗ tiết kiệm lớn nhất không phải khâu nhận đơn, mà là khâu đối soát tiền. Nhận đơn thì chép tay cũng xong. Còn ngồi dò từng dòng sao kê xem đơn nào đã trả, đó mới là việc ăn thời gian và dễ sai nhất — và đó là việc mã đơn duy nhất giải quyết. Xem mục 2.2 và 3B.2.
Tôi trả lời thẳng, vì cái này với bạn quan trọng hơn một cái bảng so sánh cho oai.
Lý do duy nhất: tôi có trợ lý AI dựng hộ.
Không có Claude Code thì tôi xài nền tảng đóng gói từ lâu rồi, chả đắn đo một giây. Tôi không phải dân lập trình, không kiến thức, không kinh nghiệm, và cái máy chủ nhỏ trong tài liệu này bảo tôi tự ngồi viết thì chịu chết.
Mà tôi cũng không định đi học. Tôi làm những việc có lợi cho chuyện chia sẻ giá trị của mình, còn có trợ lý AI rồi thì học lập trình nó tụt xuống hàng thứ yếu, không còn là cái cửa bắt buộc phải qua nữa.
Cái này tôi tin chắc, và nó định hình luôn cách tôi viết cả tài liệu này — kể cả bản rút gọn bạn đang đọc.
Muốn xài trợ lý AI ra kết quả, bạn buộc phải có hai thứ:
- Biết mình muốn gì, chi tiết vào. Không phải kiểu "làm cho tôi cái trang bán hàng", mà là biết cái trang đó phải gỡ nỗi lăn tăn nào của khách, ở chỗ nào, bằng câu gì.
- Kiểm được trợ lý — nhìn vào thứ vừa làm ra là biết đúng ý mình hay chưa.
Thiếu thứ nhất, bạn nhận về một cái trang chung chung, đúng kỹ thuật mà chả bán được hàng. Thiếu thứ hai còn nguy hơn: trợ lý làm sai mà bạn không biết, cứ tưởng xong rồi.
Hai thứ này không ai làm hộ bạn được, kể cả AI. Nhưng nó cũng chả bắt bạn phải biết code: thứ nhất ra từ chuyện bạn bán hàng thật nên hiểu khách vướng ở đâu, thứ hai chỉ cần bạn chịu mở ra xem thay vì tin lời.
⭐ Đây chính là lý do tồn tại của bản rút gọn này. Trong hai thứ trên, phần kỹ thuật của tài liệu gốc không giúp bạn được cái nào cả — nó chỉ dạy trợ lý cách gõ. Bản này giữ lại đúng phần dựng nên khả năng biết mình muốn gì và kiểm được trợ lý.
Và đó cũng là lý do bộ này không bán cho bạn một cuốn PDF, mà bán một bộ hướng dẫn để trợ lý trên máy bạn dẫn bạn làm. Chứ nếu bạn phải tự gõ từng dòng thì tôi cũng chả phải người giúp được bạn — tôi có gõ được dòng nào đâu.
🟡 CHƯA THỬ. Tôi chưa từng xài Ladipage, Sapo, Haravan hay bất kỳ nền tảng nào, nên tôi không so sánh được, và cũng chả định giả vờ so sánh. Ai bảo bạn nền tảng X không làm được việc Y mà chưa mở ra xem thử thì cứ nghi ngờ đi, kể cả người đó là tôi.
Tôi chỉ nói được về hệ của mình. Mấy thứ dưới đây là cái tôi tự kiểm được, không phải chê ai:
| Thứ | 🔵 Hệ này |
|---|---|
| Chi phí hạ tầng | 0đ, kể cả khi có nhiều trang. Chỉ tốn tiền tên miền |
| Mã QR | mang mã đơn riêng + số tiền, số tiền lấy từ máy chủ nên khách không sửa được |
| Sửa nội dung | sửa file rồi đẩy lên, cỡ 20 giây |
| Dữ liệu đơn | nằm trong cơ sở dữ liệu của bạn, muốn làm gì thì làm |
Còn nền tảng đóng gói có làm được từng ấy không, giá bao nhiêu, thì bạn tự tra. Tra xong thấy nó đủ dùng cho bạn thì cứ dùng nó, đừng vì trót mua tài liệu này mà cố. Tôi thà bạn chọn đúng còn hơn bạn xài đồ của tôi rồi thấy phí thời gian.
Nói trước cho đỡ mất thời gian của nhau:
Cả tài liệu chỉ có bốn thứ. Mọi mục sau này đều là chi tiết của một trong bốn:
┌──────────────────────────────────────────────────────────────────┐
│ [1] TRANG │
│ trang bán hàng (có form đặt đơn) │
│ trang cảm ơn cho đơn COD │
│ trang cảm ơn cho đơn chuyển khoản │
└────────────────────────────┬─────────────────────────────────────┘
│ khách bấm gửi
┌────────────────────────────▼─────────────────────────────────────┐
│ [2] MÁY CHỦ NHỎ — người gác cổng │
│ • kiểm tra dữ liệu khách điền │
│ • cấp số đơn, sinh mã chuyển khoản (vd CMC7) │
│ • ghi vào [3], rồi bắn sang [4] │
│ • tự phục vụ ảnh mã QR │
└──────┬────────────────────────────────────┬──────────────────────┘
│ │
┌──────▼───────────────────┐ ┌────────────▼─────────────────────┐
│ [3] CƠ SỞ DỮ LIỆU │ │ [4] TỰ ĐỘNG HOÁ (Make.com) │
│ sổ đơn của bạn │ │ • ghi Google Sheet │
│ 3 bảng, xem 2.4 │ │ • email "đã nhận đơn" │
│ │ │ • email "mời chuyển khoản" │
└──────────────────────────┘ └──────────────────────────────────┘
Thuật ngữ, giải thích một lần rồi thôi:
Vì sao đáng nhớ bốn khối này dù bạn không tự dựng: lúc có gì đó hỏng, câu hỏi đầu tiên luôn là hỏng ở khối nào. Khách không nhận được email — là khối [4] hay khối [2]? Đơn không vào Sheet nhưng email vẫn tới — chắc chắn là [4]. Không định vị được khối thì bạn chỉ biết nói "hệ thống hỏng", và trợ lý cũng phải mò từ đầu.
Luật 1: Mọi sale page dùng CHUNG một luồng tự động hoá + một Google Sheet. Trang thứ hai, thứ mười cũng bắn vào đúng một chỗ, vì chúng đều là đơn hàng: cùng loại dữ liệu, cùng đích đến. Tách ra là bạn ngồi bảo trì 10 bản sao của cùng một luồng.
Luật 2: Việc KHÁC LOẠI thì phải có luồng riêng. Trang tặng quà miễn phí (lead page) không phải đơn hàng → luồng riêng.
⚠️ Tôi từng nhét một sự kiện lạ vào luồng đơn hàng (18/07/2026). Dữ liệu không khớp nhánh nào → Make báo lỗi xác thực → Make tự tắt luồng → đơn hàng ngừng chảy. Một lỗi bên luồng quà tặng mà làm chết luồng tiền thì không chấp nhận được.
Ranh giới nằm ở loại việc, chứ không phải cứ thấy sự kiện mới là tách.
Cả phần này là việc của bạn, không giao cho ai được. Mất khoảng 60–90 phút nếu chưa có gì.
Trong đó có ba việc phải làm với người ngoài nên hãy khởi động sớm, đừng để tới lúc ngồi dựng mới làm: mua tên miền và đổi nameserver (1.4), kiểm ngân hàng có tạo được mã QR không (1.5), và mở tài khoản nếu ngân hàng hiện tại không hỗ trợ.
| Dịch vụ | Dùng làm gì | Bản miễn phí đủ tới đâu |
|---|---|---|
| Cloudflare | chứa trang + máy chủ nhỏ + cơ sở dữ liệu | 100.000 lượt gọi/ngày — thừa sức cho vài nghìn đơn/tháng |
| Make.com | nối dữ liệu → Sheet → email | 1.000 thao tác/tháng. Mỗi đơn tốn ~3 thao tác ⇒ khoảng 330 đơn/tháng |
| Google (Gmail + Sheets) | gửi email cho khách + bảng đơn | miễn phí |
| Tên miền | địa chỉ trang | ⚠️ thứ duy nhất tốn tiền — xem 1.4 |
| Meta Business (tuỳ chọn) | Pixel để chạy quảng cáo sau này | miễn phí |
| Google Analytics 4 (tuỳ chọn) | đo lưu lượng | miễn phí |
⭐ Trần thật của hệ này là Make, không phải chỗ nào khác. 330 đơn/tháng là con số bạn nên nhớ. Chạm trần thì nâng gói Make — đừng đi tìm nguyên nhân ở Cloudflare hay Gmail, hai chỗ đó còn rất xa mới tới hạn. Xem thêm phép tính ở 1.6.
⚠️ Mua tên miền rồi trỏ nameserver về Cloudflare. Không làm bước này thì phần gắn tên miền sẽ vướng. Mua ở đâu cũng được, miễn đổi được nameserver.
Phần này bản đầy đủ ghi từng lệnh cài. Ở đây chỉ cần biết cần những gì và vì sao.
Mục đích: máy bạn phải có sẵn bốn thứ để trợ lý làm việc được — môi trường chạy mã (Node.js), công cụ đẩy trang lên Cloudflare (Wrangler), Python cho vài script tiện ích (làm favicon, ảnh chia sẻ), và một lần đăng nhập Cloudflare.
Bạn phải làm gì: gần như không. Trợ lý tự kiểm và cài hộ. Riêng bước đăng nhập Cloudflare sẽ mở trình duyệt cho bạn bấm đồng ý — trợ lý không được phép đăng nhập thay bạn, và bạn cũng không nên muốn thế.
Dấu hiệu xong: trợ lý gõ được tên hai công cụ đó ở bất kỳ thư mục nào mà máy không báo "không tìm thấy".
⛔ Một cái bẫy đáng biết dù bạn không tự cài: nếu ai đó (hoặc trợ lý) cài Node bằng cách tải file nén rồi giải nén tay vào một thư mục, máy sẽ không nhớ đường tới nó. Hôm nay chạy ngon, buổi sau mở lại là "không tìm thấy node", và trợ lý phiên sau cũng mù luôn. Cài bằng bộ cài chính thống thì không bị. Thấy hiện tượng "hôm qua chạy được hôm nay không" thì đây là nghi phạm đầu tiên.
Đây là mục quan trọng nhất của Phần 1, vì nó quyết định bạn sẽ phải ngồi cạnh máy bao lâu.
Nhìn danh sách mười bước triển khai thì tưởng toàn dòng lệnh. Không phải. Hai bước khó nhất lại là thao tác chuột thuần, không có lệnh nào thay thế:
| Bước | Làm ở đâu | Có lệnh thay thế không |
|---|---|---|
| Bước 1 — dựng luồng tự động hoá | canvas Make.com | ❌ không |
| Bước 10 — gắn tên miền | dashboard Cloudflare, phần DNS | ❌ không |
| Sửa tiêu đề / định dạng Google Sheet | Google Sheets | ❌ không |
Nên nếu bạn làm cùng trợ lý AI, tiện ích trình duyệt Claude for Chrome là bắt buộc, không phải "nên có". Thiếu nó thì ở ba chỗ trên trợ lý mù hoàn toàn: không nhìn thấy màn hình, không biết bạn đang đứng ở đâu, chỉ đọc hướng dẫn chay cho bạn nghe. Mà đây đúng là ba chỗ người mới dễ lạc nhất.
Có nó thì trợ lý nhìn được màn hình, chỉ đúng nút, và tự kiểm lại kết quả — quan trọng nhất là cái cuối.
Bản đầy đủ còn cả một mục dài về bẫy thao tác trên canvas Make — mở module phải bấm đúp, đặt bộ lọc phải bấm chuột phải, chọn chữ hay lệch ký tự… Tôi mất gần trọn một ngày cho bộ đó. Bản này lược hết, vì đó là việc của trợ lý, không phải của bạn. Bạn chỉ cần biết một điều: nếu thấy trợ lý loay hoay lâu bất thường ở màn hình Make, đó là chuyện đã biết trước, không phải bạn làm sai gì.
Mở Chrome đúng tài khoản mà vẫn báo mất kết nối: thủ phạm hay gặp là tiện ích tự cập nhật ngay dưới chân ứng dụng đang chạy. Cách chữa: khởi động lại ứng dụng Claude — không phải khởi động lại Chrome. Nghe ngược đời nhưng đúng.
Trong tài liệu bạn sẽ thấy ví dụ dạng sanpham.tenban.com. Đó chỉ là ví dụ. Hệ thống này
không quan tâm đuôi tên miền là gì — .vn, .com, .net, .store, .shop đều chạy như
nhau.
Đây mới là thứ quyết định, không phải cái đuôi. Trang chỉ gắn được tên miền riêng khi nameserver — máy chủ tên miền, nơi quyết định "tên miền này trỏ đi đâu" — đã trỏ về Cloudflare.
Cách làm, một lần duy nhất cho cả tên miền:
⚠️ Kiểm được điều này TRƯỚC KHI MUA, đặc biệt với tên miền .vn: hỏi thẳng nơi bán —
"tôi có tự đổi nameserver sang Cloudflare được không?" Phần lớn nhà đăng ký cho phép, nhưng
đây là thứ phải hỏi trước thay vì mua xong mới phát hiện vướng. Chưa hỏi được thì đừng đoán,
cũng đừng tin tôi — hỏi nơi bán.
Tên miền phụ (subdomain) là phần đứng trước, ví dụ sanpham trong sanpham.tenban.com.
Vì sao: một tên miền đẻ ra bao nhiêu tên miền phụ cũng được, hoàn toàn miễn phí. Nghĩa là trang bán hàng thứ hai, thứ năm của bạn không tốn thêm đồng tên miền nào — chỉ cần thêm một bản ghi DNS.
⭐ Đây là chỗ tiết kiệm lớn mà nhiều người bỏ lỡ vì quen nghĩ "một trang một tên miền". Nếu bạn định bán nhiều món, khoản này cộng dồn lại không nhỏ — và nó cũng là lý do Phần 5 nói trang thứ hai gần như không tốn thêm chi phí nào.
Đặt tên miền phụ dễ nhớ, đọc lên là biết bán gì: chaico, kemtay, bbcream.
Muốn dùng thẳng tên miền gốc thì vẫn được — Cloudflare có cơ chế riêng xử lý, miễn là DNS đang ở Cloudflare. Dù vậy tôi vẫn khuyên để dành tên miền gốc cho một trang giới thiệu chung, đừng gán cho một sản phẩm cụ thể: gán rồi mà sau này ngừng bán món đó thì tên miền đẹp nhất của bạn trỏ vào chỗ chết. (Nói cho công bằng: tôi cũng chưa dựng trang giới thiệu chung đó. Đây là khuyên, không phải khoe.)
Giá chênh nhau rất nhiều theo đuôi: đuôi quốc tế thường rẻ hơn hẳn đuôi .vn. Và gần như
đuôi nào cũng có giá năm đầu rẻ, năm sau tăng — hãy xem giá gia hạn chứ đừng chỉ xem giá
lần mua đầu.
⚠️ Mọi con số giá trong tài liệu chỉ để bạn hình dung mức chi. Kiểm giá thật tại nơi bán vào đúng lúc bạn mua.
🟡 CHƯA THỬ. Tôi xài đúng một ngân hàng (Techcombank) cho cả 4 trang và nó chạy ngon. Chưa thử ngân hàng nào khác bao giờ. Phần dưới là tôi tra tài liệu, không phải kinh nghiệm.
Cả luồng chuyển khoản của hệ này dựa vào VietQR — chuẩn mã QR chuyển khoản của Napas. Ngân hàng không tham gia thì mã QR không tạo được, và bạn mất toàn bộ phần tự động của luồng chuyển khoản.
Mạng lưới này đã mở rộng tới khoảng 40 ngân hàng, gồm gần như mọi ngân hàng phổ thông ở Việt Nam. ⚠️ Danh sách thay đổi theo thời gian, nên đừng học thuộc — hãy tự kiểm.
Đây là phần đáng tin nhất trong mục này, vì bạn tự chứng minh chứ không tin lời ai:
vietqr.io, tạo thử một mã QR với ngân hàng + số tài khoản của bạn, số tiền để
2.000đ.⚠️ Quét bằng app ngân hàng, đừng quét bằng camera thường. Camera đọc ra một chuỗi ký tự loằng ngoằng và bạn không kết luận được gì.
Làm việc này TRƯỚC KHI mua tên miền hay mở tài khoản gì khác. Nếu ngân hàng của bạn không hỗ trợ thì cả luồng chuyển khoản phải tính lại, mà đó là thay đổi lớn — biết sớm hơn nhiều so với biết lúc đã dựng xong trang.
Hai đường, cả hai tôi đều chưa thử:
Tên chủ tài khoản trong cấu hình phải VIẾT HOA, KHÔNG DẤU. Có dấu là mã QR sinh ra sai và app ngân hàng đọc không đúng tên.
🟡 PHẦN HẠN MỨC: CHƯA THỬ. Lượng đơn của tôi chưa bao giờ chạm hạn mức nào. 🔵 PHẦN THƯ VÀO RÁC: đã thử, kể cả cách chống được khuyên nhiều nhất.
Theo tài liệu công bố, Gmail miễn phí gửi khoảng 500 thư/ngày.
⭐ Làm phép tính: bản Make miễn phí chịu được khoảng 330 đơn/tháng ≈ 11 đơn/ngày, mỗi đơn tối đa 2 thư ⇒ khoảng 22 thư/ngày. Còn xa mức 500. Trần thật của hệ này là Make — nếu phải nâng cấp thứ gì thì nâng Make trước.
⚠️ Có một con số dễ gây hiểu nhầm: tài liệu hay nhắc mức 100 thư/ngày cho trường hợp gửi qua SMTP. Make gửi qua kết nối Gmail chứ không phải SMTP thủ công, nên tôi nghĩ mức đó không áp — nhưng tôi không chắc. Nếu bạn định chạy trên 100 đơn/ngày thì đừng dựa vào phỏng đoán của tôi.
Đây là rủi ro thật hơn hạn mức, và nó im lặng: Make vẫn báo gửi thành công, Sheet vẫn đúng, chỉ là khách không thấy thư.
Lời khuyên bạn sẽ nghe ở khắp nơi: dùng email theo tên miền riêng và cấu hình SPF · DKIM · DMARC — ba bản ghi chứng minh với hộp thư nhận rằng thư đúng là do bạn gửi — thì thư sẽ vào hộp thư chính.
Tôi làm đúng như vậy rồi. Email theo tên miền riêng, xác thực đầy đủ. Gửi thử. Thư vẫn vào thư rác.
⇒ Kết luận của tôi, nói đúng mức thôi chứ không nói quá: xác thực có thể giảm rủi ro thật, nhưng chẳng đảm bảo được gì cả. Nó là điều kiện cần, không phải điều kiện đủ. Ai bảo bạn cứ cấu hình ba bản ghi đó vào là hết rơi vào rác thì người đó đang bán cho bạn thứ gì đó.
🟡 Một cách giải thích tôi thấy hợp lý nhưng chưa tự kiểm chứng được: tên miền mới gửi thư thì chưa có "lịch sử" nào để hộp thư nhận đánh giá, và cái lịch sử đó mới là thứ quyết định chính. Nếu đúng vậy thì nó sẽ tự tốt dần lên khi có người mở thư của bạn đều đặn. Tôi chưa chạy đủ lâu để nói chắc.
Vậy có nên làm không? Muốn nhìn chuyên nghiệp hơn thì cứ làm, không hại gì. Nhưng đừng làm với kỳ vọng nó giải quyết chuyện vào rác.
Vì không có nút nào bấm một cái là xong, tôi xử lý theo hướng khác — thiết kế để khách vẫn nhận được thư kể cả khi nó rơi vào rác:
Đây là chỗ nhiều người (và cả trợ lý AI) làm sai một cách rất tự nhiên: điền email của chính mình vào form, đơn chạy, thư về, mở ra thấy đẹp → kết luận "xong".
Thư tự gửi cho chính mình không chứng minh được hai thứ quan trọng nhất:
| Muốn kiểm | Tự gửi cho mình | Vì sao hỏng |
|---|---|---|
| Có vào thư rác không | ❌ vô nghĩa | Thư bạn gửi cho chính mình gần như không bao giờ bị ném vào rác. Bạn sẽ luôn thấy nó nằm ngoan trong hộp thư chính — và tưởng mọi khách cũng vậy |
| Tên người gửi hiện ra sao | ❌ vô nghĩa | Hộp thư hiển thị "tôi" thay vì tên bạn đã đặt. Đúng cái tên bạn cần kiểm thì nó lại giấu đi |
⇒ Test đủ phải hai lượt:
⚠️ Chọn email lượt 2 cho đúng: một hộp thư KHÔNG có bạn trong danh bạ. Hộp thư nhận thường
hiển thị tên trong danh bạ của nó, không phải tên thật trên thư — nên gửi sang địa chỉ phụ
mà bạn đã lưu nhau từ lâu thì lại thấy tên cũ, và bạn kết luận sai lần nữa. Nhờ một người bạn
nhận hộ là chắc nhất. Muốn chắc tuyệt đối thì mở thư → "Hiển thị bản gốc" → đọc dòng From:.
⚠️ Và làm lại lượt 2 sau mỗi lần đổi thứ gì đó dính tới email.
Tới đây bạn có đủ tài khoản, công cụ, tên miền. Toàn bộ phần còn lại là dạy bạn nhận đơn. Mà nhận đơn thì phải có người bấm nút đã.
Thứ quyết định người ta bấm hay không là: họ có tin bạn không.
Cái đó không nằm trong số tài khoản, không nằm trong tên miền, và tôi không dựng hộ bạn được. Nhưng tôi chỉ được cho bạn nó gồm những gì và moi ở đâu ra.
Dân làm nội dung gọi bộ này là E-E-A-T. Nghe hàn lâm nhưng bóc ra thì rất đời:
| Trụ | Tiếng người | Câu khách thầm hỏi |
|---|---|---|
| Experience — trải nghiệm thật | bạn đã tự dùng chưa | "Ông này có xài không hay chỉ đi bán?" |
| Expertise — chuyên môn | bạn biết gì mà nói | "Có biết gì không hay nghe hơi nồi chõ?" |
| Authoritativeness — có gì chứng minh | ai đã mua, ở đâu ra | "Có thật là bán được không?" |
| Trustworthiness — dám thừa nhận giới hạn | bạn giấu gì không | "Sao toàn lời khen thế?" |
⭐ Trụ thứ tư là trụ mạnh nhất, và cũng là trụ ai cũng bỏ. Trang bán hàng nào cũng khen sản phẩm từ đầu tới cuối, đọc riết thành nhàm và chả ai tin. Một câu kiểu "món này không làm được X đâu" hoặc "người đang bị Y thì đừng mua" làm mọi câu còn lại tự nhiên đáng tin hơn hẳn. Bạn mất một ít khách không hợp, đổi lại khách hợp thì tin bạn thật.
Cả tài liệu này cũng viết theo đúng nguyên tắc đó — đó là lý do có nhãn 🟡 rải khắp nơi. Bạn đang đọc một ví dụ chứ không chỉ một lời khuyên.
Trong bộ này có sẵn HO-SO-NGUOI-BAN.md. Điền một lần.
Vì sao phải là file:
Cái cuối quan trọng hơn nghe tưởng. Trợ lý AI rất sẵn lòng viết cho bạn "với hơn 10 năm kinh nghiệm trong ngành" dù bạn mới bán tháng đầu. Trợ lý không cố lừa ai, chỉ đang lấp chỗ trống bằng thứ nghe xuôi tai. Nhưng thứ đó in lên trang là bạn phải đỡ khi khách hỏi vặn.
⇒ Bộ này đã dặn trợ lý: ô nào trống thì hỏi bạn, không được tự điền. Bạn cứ để trống thoải mái, đừng bịa cho đầy. Một dòng thật đáng giá hơn mười dòng nghe kêu.
Vẫn có, chỉ là không nằm ở chỗ bạn tưởng. So hai câu:
❌ "Với nhiều năm kinh nghiệm, chúng tôi tự hào mang đến sản phẩm chất lượng..." ✅ "Tôi mới bán món này từ tháng 3. Nhưng tôi tự dùng nó một năm rồi, và lý do tôi nhập về bán là vì mẹ tôi dùng thấy đỡ."
Câu dưới thật hơn, cụ thể hơn, và bán tốt hơn — dù nghe "yếu" hơn. Câu trên thì ai cũng viết được, viết xong chẳng ai tin, mà lỡ có người hỏi "nhiều năm là mấy năm" thì bạn kẹt.
Nhóm hàng này ảnh hưởng trực tiếp tới sức khoẻ và tiền bạc người mua. Viết ẩu là hại người thật, chứ không phải chỉ mất uy tín. Google gọi nhóm này là YMYL (Your Money or Your Life) và soi rất kỹ, nhưng kể cả không có Google thì đây vẫn là chuyện nên làm cho đàng hoàng.
Luật tối thiểu:
⚠️ Rà mấy điểm này TRƯỚC khi viết, đừng viết xong mới rà. Mấy lỗi kiểu này nằm ngay trong cách dựng câu chứ không phải chỗ nào cắt phăng ra được — viết xong mới sửa là gần như phải viết lại.
Trợ lý cũng đã được dặn từ chối viết mấy câu hứa hẹn kiểu đó. Bạn vẫn ép được nếu muốn, nhưng trợ lý sẽ nói cho bạn biết vì sao không nên trước đã.
⭐ Đây KHÔNG phải bài tập về nhà. Trợ lý sẽ hỏi bạn từng dòng rồi tự ghi lại — bạn không cần chép ra hay điền vào đâu cả. Để đây là để bạn biết trước sẽ bị hỏi những gì, và thấy dòng nào cần đi làm thật thì chuẩn bị sớm cho khỏi chờ.
── Về sản phẩm ────────────────────────────────────────────────
□ Tên sản phẩm (đúng như muốn hiện trên đơn)
□ Bảng giá theo số lượng: 1 = ______đ 2 = ______đ 3 = ______đ
□ Ảnh sản phẩm (3–6 tấm, đã cắt gọn)
□ Nội dung bán hàng: câu chuyện, cam kết, hỏi–đáp
── Tiền nong ──────────────────────────────────────────────────
□ Mã ngân hàng theo chuẩn VietQR (vd TCB, VCB, MB)
□ Số tài khoản
□ Tên chủ tài khoản — VIẾT HOA KHÔNG DẤU
(⚠️ có dấu là mã QR sinh ra sai, ngân hàng không đọc được)
── Thương hiệu ────────────────────────────────────────────────
□ File logo gốc, nền trong suốt, tối thiểu 1000×1000
□ Tên miền đã mua (đuôi gì cũng được)
□ Tên miền phụ định dùng cho trang này
□ Nameserver đã trỏ về Cloudflare chưa? □ rồi □ chưa (xem 1.4)
□ Địa chỉ Zalo nhóm cộng đồng (nếu có, không thì để trống)
── Kỹ thuật (bạn chọn, trợ lý điền) ───────────────────────────
□ Tiền tố mã đơn — 2–4 chữ HOA không dấu ⚠️ xem cảnh báo dưới
□ Mã mở trang quản trị — chuỗi ngẫu nhiên dài
□ Địa chỉ Gmail dùng để gửi email cho khách
Trong bảng trên, ba dòng cần thời gian của người ngoài — logo, tên miền + nameserver, và số tài khoản ngân hàng đã kiểm QR. Bắt đầu ba dòng đó sớm nhất có thể.
Mỗi trang tự đếm đơn từ 1. Hai trang cùng tiền tố CMC là cùng đẻ ra mã CMC1 → lúc bạn
dán sao kê để đối soát, hệ thống lật nhầm đơn của trang kia. Không báo lỗi gì hết. Bạn chỉ
biết lúc khách gọi hỏi hàng đâu.
⇒ Giữ một cuốn sổ tiền tố. Mỗi lần dựng trang mới, tra sổ, chọn tiền tố chưa ai dùng, ghi lại ngay. Sổ của tôi:
| Tiền tố | Sản phẩm |
|---|---|
CMC |
Chải Mạch Cơ (trang gốc) |
CMB |
Chải Mạch Cơ (trang kể góc khác) |
KDT |
Kem dưỡng tay |
BBC |
BB Cream |
Chú ý
CMCvàCMBlà cùng một món hàng, chỉ khác trang và góc kể chuyện. Đó cũng là lý do phải phân biệt bằng tiền tố: muốn biết trang nào ra đơn tốt hơn thì đếm theo tiền tố.
Gmail có HAI cái tên tách rời nhau:
Đổi cái thứ nhất KHÔNG kéo theo cái thứ hai. Tệ hơn: nếu ô đó đang ở chế độ "lấy tên từ Tài khoản Google" thì màn hình cài đặt hiện tên mới ngay lập tức — nhìn tưởng xong — nhưng tên thật in trên thư gửi đi thì không đổi. Khách nhận được email đề tên cũ.
Cách duy nhất ăn chắc: bấm "chỉnh sửa thông tin" → chọn ô nhập tự do → GÕ TAY tên → Lưu.
⚠️ Và đừng tự kiểm bằng cách gửi thư cho chính mình — Gmail hiển thị tên trong danh bạ của bạn, không phải tên trên thư. Bạn sẽ thấy tên cũ dù thư đã đúng.
Phần này không có thao tác nào cả. Nhưng bỏ qua thì lúc hỏng bạn chả biết hỏng ở đâu.
Đây là phần đáng đọc kỹ nhất của bản này. Bốn mục dưới đây trả lời bốn câu "vì sao lại làm thế" — và mỗi câu đều là một quyết định thiết kế mà tôi đã trả giá để rút ra.
Đơn COD (thu tiền khi giao):
khách điền form
→ máy chủ nhỏ kiểm dữ liệu (tên, số điện thoại, email, địa chỉ)
→ cấp số thứ tự → sinh mã đơn "CMC" + số
→ ghi vào sổ đơn
→ bắn sang tự động hoá, gắn nhãn "đơn COD mới"
├─ nhánh Google Sheet: thêm một dòng
└─ nhánh email "đã nhận đơn": gửi khách
→ đẩy khách sang trang cảm ơn COD
Đơn chuyển khoản: giống hệt, chỉ khác nhãn, và:
⭐ Chỗ đáng nhớ: Google Sheet là bảng cho người đóng gói. Nên nó chỉ nhận đơn đã chắc chắn có tiền hoặc đơn COD. Đơn chuyển khoản chưa trả tiền mà đã nằm trên Sheet thì có ngày người ta gói hàng gửi đi cho một đơn không bao giờ trả.
Hệ thống rẽ nhánh dựa vào đúng ba cái nhãn đó. ⚠️ Sai một chữ là đơn rơi vào hư không, mà Make vẫn báo thành công — đây là kiểu lỗi im lặng, và nó xuất hiện nhiều lần trong tài liệu này.
Vì ai cũng bấm được mà chả cần chuyển đồng nào. Bạn đóng hàng gửi đi xong mới biết.
Ở hệ này, đơn chuyển khoản chỉ lật sang "đã thanh toán" khi bạn dán sao kê ngân hàng vào trang quản trị. Hệ thống dò mã đơn trong nội dung chuyển khoản, soi lại số tiền, khớp thì lật.
⚠️ Đơn lệch tiền thì nó KHÔNG tự lật, mà giữ lại cho bạn xem. Vì lật một đơn là kéo theo gửi email cho khách và ghi vào Sheet — lật nhầm rồi ngồi dọn còn mệt hơn bấm tay một nhát.
Đây là ví dụ rõ nhất của một nguyên tắc chạy suốt hệ thống: thà bắt người bấm thêm một nhát, còn hơn để máy tự làm sai rồi phải dọn. Bạn sẽ gặp lại nó ở 3B.3.
Cái này tôi trả giá hôm 16/07/2026: khách báo mã QR trong email hiện ngon trên máy tính, mà vỡ trên Gmail điện thoại.
Mò ra thì nơi tạo QR không chặn gì cả, nhưng ảnh trả về thiếu chỉ dẫn lưu tạm, và đường link nhồi đầy tham số → Gmail lọc HTML trên di động khác với trên web. Đây là chỗ kinh điển làm ảnh chết trên app mà vẫn sống ngon trên trình duyệt.
Cách bịt: cho máy chủ nhỏ tự phục vụ ảnh QR. Đường link sạch, không tham số, chả phụ thuộc ai.
⚠️ Số tiền lấy từ cơ sở dữ liệu theo mã đơn, tuyệt đối không cho truyền qua đường link. Cho truyền thì ai cũng dựng được mã QR mang tên bạn với số tiền tuỳ thích.
Bài học rộng hơn cái lỗi ảnh vỡ: thứ gì dính tới tiền thì phải lấy từ máy chủ của bạn, đừng để nó đi qua tay trình duyệt của khách. Người ta sửa được mọi thứ hiện trên máy họ.
| Bảng | Chứa gì | Vì sao tách |
|---|---|---|
| Đơn hàng | từng đơn | dữ liệu chính |
| Bộ đếm | mỗi sản phẩm một dòng | để mã đơn đếm riêng theo sản phẩm dù dùng chung kho. Không có nó thì trang thứ hai mở hàng từ số 57 vì trang khác đã ăn mất 56 đơn, nhìn rất kỳ |
| Danh mục sản phẩm | có những sản phẩm nào | để trang quản trị biết phải dò những tiền tố nào mà không phải gõ cứng |
Một nguyên tắc nhớ được thì đỡ khối lỗi về sau:
Thứ gì không đổi theo từng đơn thì đừng lưu theo từng đơn.
Ví dụ cái link nhóm Zalo: đó là cấu hình, không phải dữ liệu đơn. Nhét nó vào cơ sở dữ liệu thì hôm bạn đổi link, mọi đơn cũ vẫn ôm cái link chết.
Nguyên tắc này có một ngoại lệ quan trọng, và nó cũng nằm ở chỗ dính tiền: thông tin ngân hàng thì phải chụp lại theo từng đơn. Vì hôm bạn đổi số tài khoản, đơn cũ vẫn phải hiện đúng số tài khoản mà khách đã chuyển vào. Xem 3B.4.
Đây là phần bị rút gọn nhiều nhất so với bản đầy đủ, vì quá nửa là việc trợ lý làm. Với mỗi bước tôi ghi ba dòng:
Cần lệnh cụ thể thì mở bản đầy đủ, cùng số bước.
Mục đích: tạo cái "đường ống" nhận đơn từ trang rồi rẽ về ba chỗ: Google Sheet, email báo đã nhận đơn, email mời chuyển khoản. Làm trước tiên vì các bước sau cần đường link của nó.
Bạn phải làm gì: ⭐ Đây là một trong hai bước cần tay bạn nhiều nhất. Toàn thao tác chuột trên canvas Make. Trợ lý nhìn được màn hình và chỉ việc, nhưng nhiều ô sẽ phải bạn gõ. Riêng nội dung hai email nếu dài thì bạn dán tay.
Dấu hiệu xong: luồng ở trạng thái Active, và Google Sheet đã có hàng tiêu đề đủ 15 cột.
⚠️ Một tuỳ chọn nhỏ mà tôi trả giá 22/07/2026: trong module Google Sheets có ô "dùng tiêu đề cột làm mã cột". Mặc định là Không, nghĩa là hệ thống ghi theo vị trí cột. Hôm tôi sắp lại thứ tự cột cho dễ nhìn thì mọi đơn mới đổ vào sai cột — mà Make vẫn báo thành công, Sheet vẫn có dòng mới. Chỉ đọc kỹ mới thấy tên khách nằm ở ô trạng thái.
Bật Có rồi thì sắp lại cột thoải mái. Đổi lại: đừng sửa chữ ở hàng tiêu đề — từ đó trở đi, đổi tên tiêu đề mới là thứ làm gãy.
⚠️ Viết hai email hoàn toàn bằng biến, đừng gõ cứng tên sản phẩm. Trả giá 16/07/2026: khách đầu tiên của trang Kem tay nhận email ghi "Cảm ơn bạn đã đặt Combo Chải Mạch Cơ". "Dùng chung luồng" nghĩa là dùng chung cả lời văn — cái gì gõ cứng cho sản phẩm này sẽ đọc sai cho sản phẩm kia. Lỗi im lặng hoàn toàn: Make báo thành công, Sheet đúng, chỉ mỗi khách đọc email là thấy sai.
Mục đích: dựng đúng cấu trúc thư mục cho cả công việc bán hàng của bạn, không phải chỉ cho một trang.
Bạn phải làm gì: không có gì, nhưng ⭐ hiểu đúng một điều dưới đây thì tránh được lỗi nguy hiểm nhất cả hệ.
Bạn lập một thư mục dự án duy nhất. Mọi trang bán hàng sau này nằm bên trong nó:
sale-page-cua-toi/ ← MỘT thư mục cho cả công việc bán hàng
HO-SO-NGUOI-BAN.md ← dùng chung cho MỌI trang
TIEN-DO.md ← tiến độ + SỔ TIỀN TỐ, dùng chung
san-pham-1/
san-pham-2/
quan-tri/ ← trang đối soát, dựng MỘT lần dùng chung
Bốn thứ dùng chung, và đó là lý do phải gom một chỗ:
| Thứ | Vì sao chung |
|---|---|
| Hồ sơ người bán | vẫn là bạn bán, đâu đổi người |
| Sổ tiền tố | ⭐ xem cảnh báo ngay dưới |
| Cơ sở dữ liệu | dán sao kê một lần là đối soát được mọi sản phẩm |
| Trang quản trị | một cái ví, một chỗ xem |
⛔ Sai lầm phải tránh: mỗi trang bán hàng một thư mục dự án riêng. Lúc đó mỗi thư mục có sổ tiền tố riêng → sổ bị chia đôi → bạn đặt trùng tiền tố lúc nào không hay. Mà trùng tiền tố là lỗi im lặng nguy hiểm nhất cả hệ.
Trợ lý cũng mất luôn trí nhớ về mấy trang cũ, vì chỉ đọc được thư mục đang mở.
Dấu hiệu xong: mở thư mục dự án ra thấy đúng một hồ sơ người bán và đúng một sổ tiền tố, nằm ở ngoài cùng chứ không nằm trong thư mục của một trang nào.
Mục đích: dựng cái sổ đơn của bạn — ba bảng đã giải thích ở 2.4.
Bạn phải làm gì: không có gì. Trợ lý làm hết.
Dấu hiệu xong: trợ lý báo đã tạo và đọc lại được cấu trúc ba bảng. Bạn không cần đọc hiểu cấu trúc đó.
Nếu bạn đang dựng trang thứ hai trở đi: dùng lại đúng cơ sở dữ liệu cũ, đừng tạo mới. Đó là điều kiện để sau này dán sao kê một lần đối soát được mọi sản phẩm.
Mục đích: khai báo những thứ riêng của trang này — tên sản phẩm, bảng giá, tài khoản ngân hàng, tiền tố mã đơn, mã mở trang quản trị.
Bạn phải làm gì: cung cấp thông tin ở bảng 1.8. Trợ lý hỏi từng dòng.
Dấu hiệu xong: ⚠️ ba thứ này phải KHÁC hẳn mọi trang bạn đã có — tiền tố mã đơn, mã định danh sản phẩm, và mã mở trang quản trị. Trùng mã quản trị nghĩa là ai biết khoá trang này mở được trang kia.
Đây là chỗ đáng bạn tự kiểm bằng mắt, vì hậu quả im lặng và lâu dài.
Mục đích: phần khiến người ta bấm nút.
Bạn phải làm gì: ⭐ Đây là bước tốn nhiều thời gian của bạn nhất, và không có phần kỹ thuật nào trong đó. Chất liệu lấy từ hồ sơ người bán bạn đã điền ở 1.7. Cách dựng câu chuyện nằm ngoài phạm vi tài liệu này.
Dấu hiệu xong: đọc lại trang, tự trả lời được: người lạ đọc xong có biết món này không làm được gì không? Nếu cả trang toàn lời khen thì quay lại đọc 1.7, trụ thứ tư.
Mục đích: gắn Pixel và Google Analytics vào cả ba trang ngay từ lúc lên sóng.
Bạn phải làm gì: đưa mã Pixel và mã GA4 nếu có.
⭐ Vì sao không hoãn được: pixel không hồi tố. Tệp khách để nhắm lại quảng cáo chỉ tính từ ngày bạn gắn. Hoãn hai tháng là mất trắng hai tháng người đã vào trang — đúng nhóm rẻ nhất khi bật quảng cáo. Đây là quyết định tôi từng hoãn rồi phải đảo ngược.
Dấu hiệu xong: không phải "thấy có chữ pixel trong file", mà là trang thật sự bắn được sự kiện đi. Trợ lý kiểm được việc này và phải cho bạn xem kết quả.
⚠️ Một điều nên biết để khỏi hoảng khi xem số liệu: hệ thống ghi nhận "đã mua" lúc khách đặt, chưa phải lúc tiền về. Nên con số đó sẽ cao hơn doanh thu thật. Đó là lựa chọn có chủ ý — quan trọng là giữ nhất quán ở mọi trang thì số giữa các trang mới so sánh được.
Mục đích: để link dán ra Zalo/Messenger hiện ảnh và tiêu đề đàng hoàng, tab trình duyệt có biểu tượng. Thiếu là trông nghiệp dư ngay lập tức.
Bạn phải làm gì: đưa file logo gốc — nền trong suốt, càng lớn càng tốt.
⚠️ Đừng đưa ảnh poster rồi bảo cắt logo ra từ đó. Và biết trước một bẫy: logo nhiều thương hiệu là chữ trắng trên nền trong suốt — dán thẳng lên tab trình duyệt nền sáng là mất hút. Cách xử là đặt logo lên một đĩa màu đậm; trợ lý biết làm, nhưng bạn nên mở ảnh ra nhìn kết quả.
Dấu hiệu xong: dán thử link vào một tin nhắn Zalo cho chính mình, xem có hiện ảnh lớn không.
Mục đích: chạy thử toàn bộ luồng đơn mà không gửi email thật và không đổ rác vào Google Sheet.
Bạn phải làm gì: ⭐ bạn nên tự bấm thử, đừng chỉ nghe báo cáo. Bốn tình huống:
Dấu hiệu xong: cả bốn ô trên đều tự tay bạn thấy.
Mục đích: đẩy trang ra internet.
Bạn phải làm gì: không có gì.
Dấu hiệu xong: mở địa chỉ trang thấy trang hiện ra.
⚠️ Hai hiện tượng bình thường mà rất dễ tưởng hỏng:
- Ngay sau khi đẩy lên, phần nào đụng cơ sở dữ liệu sẽ báo lỗi vài chục giây rồi mới chạy. Trang tĩnh thì lên ngay. Chờ khoảng 20 giây rồi thử lại.
- Bản trên các địa chỉ khác nhau lệch nhau vài chục giây, và trình duyệt còn giữ bản cũ. Chưa thử tải lại kiểu bỏ qua bộ nhớ đệm thì đừng vội kết luận là hỏng.
Mục đích: đổi địa chỉ trang từ đường mặc định sang tên miền của bạn.
Bạn phải làm gì: ⭐ Đây là bước còn lại cần tay bạn. Trợ lý không có quyền đụng vào DNS, và ô địa chỉ đích hay bị chặn gõ. Thực tế chạy được: trợ lý set sẵn phần làm được, bạn gõ ô Target và bấm Save.
⚠️ Nhớ chọn loại bản ghi TRƯỚC rồi mới điền các ô còn lại — đổi loại sau làm ô địa chỉ đích bị nạp lại, mất chữ vừa gõ.
⚠️ Dashboard Cloudflare có bước kiểm tra bot khoảng 5 giây lúc vào, cứ chờ.
Dấu hiệu xong: mở tên miền của bạn ra trang, và có ổ khoá bảo mật. Chứng chỉ thường cấp trong khoảng một phút.
Phần 3 mới dựng chỗ nhận đơn. Nhưng đơn chuyển khoản nằm im ở trạng thái chờ tiền cho tới khi có người xác nhận tiền về. Nếu bước đó vẫn làm tay thì bạn chưa tiết kiệm được gì.
Trang quản trị là một project riêng, dùng chung cơ sở dữ liệu với mọi sale page. Dựng một lần, mọi trang sau hưởng.
Vì bạn sẽ có nhiều sale page, nhưng chỉ có một cái ví. Sao kê ngân hàng tải về là một file chung cho tất cả sản phẩm. Mỗi trang một trang quản trị riêng thì bạn phải dán cùng một đoạn sao kê vào 4 chỗ, mà mỗi chỗ lại chỉ nhặt ra mã của nó.
Gộp lại thì dán một lần, hệ thống tự tra tiền tố của mọi sản phẩm rồi lật hết.
Bạn tải sao kê từ app ngân hàng, bôi đen, dán vào một ô. Hệ thống:
cmc007
vẫn ra CMC7). Khách gõ nội dung chuyển khoản rất tuỳ hứng, phải chịu được.| Kết luận | Khi nào | Hệ thống làm gì |
|---|---|---|
| đã lật | mã đúng, số tiền khớp | lật sang đã thanh toán, ghi Sheet + gửi email |
| lệch tiền | mã đúng, dòng có số tiền nhưng không khớp | ⭐ GIỮ LẠI, không lật |
| đã rồi | đơn đã thanh toán từ trước | bỏ qua |
| không phải chuyển khoản | đơn này là COD | bỏ qua |
| không thấy | không có mã đó trong hệ thống | báo để bạn tự tra |
| không thấy | đơn đã bị huỷ | ⭐ bỏ qua — dán trúng mã cũng không lật lại |
⭐ Đọc bảng này một lượt là bạn hiểu vì sao có thể tin trang quản trị. Nó không im lặng quyết thay bạn ở bất kỳ ca nào không chắc chắn — mọi ca mập mờ đều rơi về phía "giữ lại, báo cho người xem".
Ba luật này không phải chuyện kỹ thuật. Chúng là cách nghĩ, và bạn dùng lại được ở chỗ khác.
Luật 1: Lệch tiền thì KHÔNG tự lật, giữ lại cho người xem.
Lật một đơn đâu phải chỉ đổi một chữ trong cơ sở dữ liệu. Nó gửi email cho khách và ghi một dòng vào Sheet cho người ta đóng gói. Lật nhầm rồi ngồi dọn còn mệt hơn bấm tay một nhát nhiều.
Có một chỗ tinh: hệ thống chỉ kêu lệch khi dòng đó có chứa một con số tiền nào đó mà không khớp. Còn đoạn bạn dán không có cột tiền thì nó vẫn lật theo mã, nhưng ghi rõ "đã lật theo mã, đoạn dán không có cột tiền để đối chiếu" — tức là nó khai luôn với bạn là nó đang tin vào cái gì.
Cái vế sau quan trọng hơn vế trước. Một hệ thống nói cho bạn biết mức độ chắc chắn của nó thì đáng tin hơn hẳn một hệ thống lúc nào cũng báo "xong".
Luật 2: Xoá đơn là xoá MỀM.
Đơn thì đã lỡ bắn đi và ghi vào Sheet rồi. Xoá trắng khỏi cơ sở dữ liệu là mất dấu đối soát, sau này lệch tiền không lần lại được. Nên "xoá" ở đây chỉ là đánh dấu đã huỷ: đơn biến khỏi bảng, khỏi thống kê, đối soát cũng bỏ qua, nhưng nó vẫn nằm đó.
Muốn xoá hẳn thì phải qua hai bước, huỷ trước rồi mới xoá, và chốt chặn nằm ở máy chủ. Không có đường nào xoá vĩnh viễn bằng một cú bấm nhầm.
⚠️ Huỷ đơn ở đây KHÔNG gỡ dòng đã ghi trên Google Sheet, cũng KHÔNG rút lại email đã gửi. Hai thứ đó phải dọn tay. Hệ thống không giấu bạn chuyện này, nhưng bạn phải nhớ.
Luật 3: Mã mở trang quản trị nằm trên thanh địa chỉ — hiểu đúng mức bảo vệ của nó.
Nó chống được người lạ mò trúng, không chống được người mà bạn đã đưa link. Cái link đó còn nằm trong lịch sử duyệt web nữa.
⇒ Đặt chuỗi dài vào, đừng dán vào nhóm chat, và đừng xài chung một mã cho mọi thứ.
Mục đích: dựng một trang giống sale page nhưng không có form đặt hàng, và trỏ vào cùng một cơ sở dữ liệu với các sale page.
Bạn phải làm gì: không có gì. Nhưng biết một điều để hiểu vì sao đối soát đáng tin:
⚠️ Khi lật đơn, thông tin ngân hàng được lấy từ bản đã chụp lại lúc khách đặt hàng, không phải từ cấu hình hiện tại. Vì sao: hôm bạn đổi số tài khoản, đơn cũ vẫn phải hiện đúng số tài khoản mà khách đã chuyển vào. Đây là ngoại lệ của nguyên tắc ở 2.4, và là ngoại lệ có lý do.
Dấu hiệu xong: dán một đoạn sao kê thật vào, đơn lật đúng.
Chưa làm hết danh sách này thì chưa được chạy quảng cáo.
Đây là phần cụ thể hoá cái trụ thứ hai ở mục 0.2 — kiểm được trợ lý. Trợ lý chạy hộ bạn được gần hết, nhưng mấy ô có dấu ⭐ dưới đây thì phải mắt bạn nhìn, vì chúng chỉ hiện đúng trên điện thoại thật, hộp thư thật, app ngân hàng thật.
□ Đặt một đơn COD thật bằng số điện thoại của bạn, điền EMAIL CỦA CHÍNH BẠN
□ sang đúng trang cảm ơn
□ Google Sheet có dòng mới, ĐÚNG CỘT (đọc kỹ, đừng chỉ đếm số dòng)
□ email tới hộp thư, ĐỌC TỪNG CHỮ: tên sản phẩm đúng, không sót ô trống nào
□ ⭐ ĐẶT THÊM MỘT ĐƠN NỮA, điền một EMAIL KHÁC — không có bạn trong danh bạ
(lượt tự gửi cho mình KHÔNG kết luận được 2 ô dưới đây, xem 1.6)
□ thư nằm ở hộp thư chính, hay rơi vào tab Quảng cáo / thư rác? ← kiểm TRÊN ĐIỆN THOẠI
□ tên người gửi hiện đúng chưa
□ Đặt một đơn CHUYỂN KHOẢN thật
□ email "mời chuyển khoản" tới
□ ⭐ MỞ EMAIL RA XEM ẢNH QR CÓ HIỆN KHÔNG — trên ĐIỆN THOẠI, không chỉ máy tính
□ ⭐ QUÉT THẬT mã QR bằng app ngân hàng: đúng ngân hàng, đúng số tài khoản,
đúng số tiền, đúng mã đơn trong nội dung
□ Dán sao kê thật vào trang quản trị → đơn lật đúng
□ Chỉ SAU KHI làm hết các bước trên: xoá đơn test và cho bộ đếm về 0
→ khách thật đầu tiên nhận mã số 1
Đây là bẫy tôi trả giá 20/07/2026 và nó phá đúng cái bước nghiệm thu quan trọng nhất.
Ảnh QR được dựng ra từ đơn trong cơ sở dữ liệu mỗi lần có người mở email. Xoá đơn đi là ảnh gãy — vì Gmail chỉ tải ảnh lúc người ta MỞ thư, không phải lúc gửi. Bạn dọn dữ liệu xong, mở thư ra thấy ảnh vỡ, tưởng sản phẩm mình hỏng.
⇒ Thứ tự đúng: đặt đơn test → MỞ EMAIL xem ảnh QR → rồi mới xoá đơn.
Bản đầy đủ còn một danh sách dài bẫy thao tác. Dưới đây chỉ giữ những cái rơi vào tay bạn.
0824352686 hiện thành 824352686. Gọi khách là sai số. Sau mỗi lần sắp
lại cột: bôi cột đó → Format → Number → Plain text.
⚠️ Đổi định dạng không tự khôi phục số 0 đã mất — phải gõ tay lại những ô đã lỡ.Trang đầu ngốn cỡ một ngày. Trang thứ hai chỉ còn một buổi, mà phần lớn thời gian là ngồi viết nội dung bán hàng chứ không phải kỹ thuật.
Những gì đổi và những gì không:
| Việc | Trang thứ hai |
|---|---|
| Luồng tự động hoá | không phải đụng gì ⭐ |
| Cơ sở dữ liệu | dùng lại cái cũ |
| Trang quản trị | dùng lại cái cũ |
| Hồ sơ người bán | dùng lại |
| Tên miền | thêm một tên miền phụ, miễn phí |
| Cấu hình riêng của trang | đổi — nhớ tra sổ tiền tố |
| Nội dung bán hàng | viết mới, đây là phần tốn thời gian |
| Nghiệm thu Phần 4 | chạy lại từ đầu, đủ cả |
Không phải đụng gì bên tự động hoá là điểm mạnh nhất của thiết kế này — và cũng là lý do Luật 1 ở mục 0.4 đáng giữ.
Ngoại lệ duy nhất: nếu trang mới gửi thêm một trường dữ liệu MỚI mà email cần dùng thì phải cho Make học cấu trúc mới một lần.
⚠️ Đừng bỏ qua nghiệm thu vì "trang này copy từ trang cũ". Đúng cái tính chất copy đó mới sinh ra lỗi im lặng: ảnh sản phẩm của trang cũ còn sót, tiền tố trùng, tên sản phẩm trong email vẫn của trang trước.
Bảng Google Sheet có số cột cố định. Đẻ thêm trường dữ liệu mới thì Sheet không có cột nhận → người đóng gói không biết gói cái gì, dù dữ liệu vẫn nằm trong cơ sở dữ liệu.
Cách rẻ nhất: nhét thuộc tính vào ngay tên sản phẩm đang chảy sẵn:
"Kem dưỡng tay Gongskin x3 (Wood x2, Blackberry x1)"
Đọc một cột là biết gói mấy cái, loại nào. Không phải sửa gì bên tự động hoá.
Nói rõ để bạn biết mình đang thiếu gì, và biết mở bản đầy đủ ở đâu khi cần:
| Đã lược | Nằm ở đâu trong bản đầy đủ |
|---|---|
| Lệnh cài Node, Wrangler, Python | 1.2 |
| Bẫy thao tác canvas Make, cách chọn chữ trong ô nội dung | 1.3, Phần 4 |
| Cấu trúc ba bảng dữ liệu, câu lệnh tạo bảng | Bước 3 |
| Nội dung khối cấu hình, tên từng biến | Bước 4 |
| Kỹ thuật CSS của nút bấm, bẫy sửa file tiếng Việt | Bước 5 |
| Đoạn mã kiểm tra Pixel bắn thật | Bước 6 |
| Danh sách file favicon cần xuất, các thẻ khai trong trang | Bước 7 |
| Lệnh chạy thử, lệnh đưa lên mạng | Bước 8, 9 |
| Bốn đường API của trang quản trị | 3B.4 |
| Cách sắp lại cột Google Sheet an toàn | Phần 4 |
Không lược gì ở Phần 0, Phần 2 và mục 1.4 → 1.8 — đó là phần viết cho bạn ngay từ đầu, và ở bản này còn được khai triển thêm.
Tài liệu này là hướng dẫn kỹ thuật, không phải nội dung sức khoẻ — nhưng nó dạy người khác dựng trang bán hàng, nên có ba điểm phải nói rõ:
Số liệu trong tài liệu (hạn mức miễn phí, giá tên miền) đúng tại 22/07/2026 — hãy kiểm lại trên trang chính thức trước khi dựa vào để ra quyết định.