Bản xem thử: Trích nguyên văn từ bản bán. Không phải bản viết riêng để mời mua.
Agent Tự Bán Hàng

Bản xem thử miễn phí

Đọc trước khi trả tiền

Bốn phần dưới đây lấy nguyên văn từ bản đầy đủ: module mở đầu, module kiến trúc, module về dashboard bằng chứng, và case study đổi sản phẩm. Không cắt câu, không thêm lời mời.

4.192 từ khoảng 19 phút đọc trích từ 62 trang bản đầy đủ

Bản đầy đủ gồm 13 module và 2 case study. Bản trọn bộ thêm bộ mã webhook SePay mẫu và 5 file mẫu dùng ngay: luật agent, config, khung dashboard, test bằng chứng, checklist trước khi bán.

Module 1

Nói thật trước khi bán

Câu quan trọng nhất trong cả tài liệu này

Agent không tự kiếm ra tiền.

Tiền đến từ sản phẩm và từ khách hàng. Agent chỉ làm được ba việc: dựng trang bán, trả lời khách, và ghi chép trung thực. Nếu bạn mua tài liệu này với hy vọng cắm một con bot vào là có thu nhập thụ động, thì đây không phải sản phẩm dành cho bạn — và tôi nói câu đó ngay trang đầu, trước khi bạn trả tiền.

Tôi cũng không cam kết doanh thu. Không cam kết số đơn. Không cam kết sau bao lâu thì hoà vốn. Không ai cam kết được những thứ đó, kể cả người bán cho bạn một khoá học có ảnh chụp màn hình thu nhập.

Shop này vận hành thế nào — giải thích đơn giản

Phần này viết cho người chưa biết gì về kỹ thuật. Đọc xong bạn sẽ biết: tiền đi đường nào, ai làm việc gì, mỗi tháng tốn bao nhiêu, và tài liệu giúp bạn làm được gì.

Một câu để nhớ

Khách trả tiền vào tài khoản ngân hàng của bạn. Một trợ lý AI giúp bạn lo phần giấy tờ và ghi chép. Bạn giữ quyền quyết định mọi việc liên quan đến tiền và đến khách.

Không có cổng thanh toán trung gian giữ tiền của bạn. Không có "bot tự kiếm tiền". Có một cái shop nhỏ chạy gọn, và một trợ lý biết làm việc theo luật.

Mô hình này giải quyết vấn đề gì

Bạn có một sản phẩm số — một cuốn hướng dẫn, một bộ mẫu, một khoá học ghi sẵn. Bạn muốn bán nhưng:

Cách làm trong tài liệu này: một trang bán đơn giản, khách quét mã QR chuyển khoản thẳng vào tài khoản của bạn, tiền về thì khách nhận được file. Phần việc lặp đi lặp lại giao cho trợ lý AI, nhưng nó không được tự ý làm những việc nhạy cảm.

Hành trình của một đơn hàng

Giả sử khách tên An muốn mua gói 99.000đ.

1. An vào trang bán. Trang là một trang web bình thường. An đọc, xem bản xem thử miễn phí, rồi bấm "Mua".

2. An chọn gói và thấy mã QR. Trang hiện mã QR của ngân hàng, kèm đúng số tiền (99.000đ) và một mã đơn riêng, ví dụ TS-D5HPVF. Mã đơn là cách để bạn biết khoản tiền nào của ai.

3. An quét QR bằng app ngân hàng và chuyển khoản. Tiền đi thẳng vào tài khoản của bạn, như một lần chuyển khoản bình thường. Bạn không phải trả phí cổng thanh toán.

4. Bạn biết tiền đã về. Có hai cách, tuỳ giai đoạn:

5. An nhận file. Trong vòng 24 giờ ở chế độ thủ công, hoặc ngay lập tức ở chế độ tự động.

6. Nếu An chuyển sai thì sao? Chuyển thiếu, thừa, sai mã, hoặc chuyển hai lần: shop không tự đoán. Giao dịch đó được để riêng chờ bạn xem. Bạn quyết định hoàn tiền hay xử lý. Tiền chưa khớp thì không được tính là doanh thu.

Ai làm việc gì

Ai Việc Quyền quyết định
Khách Đọc, quét QR, chuyển khoản, nhận file —
Ngân hàng Giữ tiền, báo biến động —
SePay (giai đoạn sau) Thấy tiền về thì báo cho shop Không giữ tiền, chỉ báo tin
Trợ lý AI Soạn nội dung, chạy kiểm tra, ghi nhật ký, báo cáo Không tự đăng bài, đổi giá, trả lời khách, chi tiền, hoàn tiền
Bạn Duyệt mọi việc ra ngoài, xác nhận tiền, xử lý khiếu nại Mọi quyết định cuối cùng

Điểm mấu chốt: trợ lý AI làm nhanh việc lặp lại, còn tiền và lời nói với khách luôn qua tay bạn.

"Cổng duyệt" nghĩa là gì

Nghe kỹ thuật nhưng ý rất đơn giản: trợ lý AI soạn nháp, bạn bấm đồng ý rồi việc đó mới xảy ra.

Ví dụ: AI viết sẵn một bài đăng Facebook. Bài nằm trong một file nháp. Nó không tự đăng. Bạn đọc, sửa, rồi tự đăng. Tương tự với tin nhắn cho khách, thay đổi giá, hoàn tiền.

Lý do: một lần AI đăng sai giá hay trả lời sai với khách là mất tiền thật và mất niềm tin, mà bạn không biết cho đến khi có người hỏi.

"Dashboard chỉ hiện số có bằng chứng" nghĩa là gì

Trang chủ của shop có một bảng số: doanh thu, số đơn, tiến độ. Quy tắc: con số nào khác 0 phải chỉ ra được file chứng minh nó. Chưa có đơn thì ghi 0. Chưa có hoá đơn chi phí thì để trống, không đoán.

Vì sao cần quy tắc này? Vì trợ lý AI rất dễ viết ra những con số nghe hợp lý nhưng không có thật. Chương 11 kể lại đúng lần chuyện này đã xảy ra khi dựng sản phẩm này và cách nó bị phát hiện.

Mỗi tháng tốn bao nhiêu

Ở giai đoạn đầu, gần như 0 đồng:

Khoản Chi phí
Đưa trang lên mạng (Vercel, GitHub Pages…) Miễn phí với nhu cầu nhỏ
QR chuyển khoản Miễn phí
SePay (nếu dùng) Gói miễn phí 50 giao dịch/tháng, kiểm lại trên trang SePay
Tên miền riêng Tuỳ chọn, thường vài trăm nghìn đồng mỗi năm
Trợ lý AI Tuỳ công cụ bạn dùng

Bạn nên tự kiểm lại giá và điều kiện trên trang của từng dịch vụ, vì họ có thể đổi.

Bạn cần gì để làm theo

Bạn nhận được gì khi mua

Cả hai đều được hoàn tiền 100% trong 7 ngày, không cần lý do.

Chuyện gì chưa có — nói thật

Mô hình này hợp với bạn nếu

Không hợp nếu

Vì sao phần "không bịa" lại là phần chính

Vì đó là chỗ hỏng thật.

Trong lúc dựng sản phẩm này, chính tôi đã viết một dashboard có những con số không tồn tại: một ngày mở kênh không có thật, một video chưa từng làm, "12 chủ đề" chưa chốt, hai bước được đánh dấu hoàn thành trong khi chưa có file nào. Trang vẫn chạy. Test vẫn xanh. Không có lỗi JavaScript nào. Nhìn vào thì hoàn toàn hợp lý.

Người phát hiện không phải tôi. Là người kiểm tra, grep toàn bộ workspace và thấy tiêu đề video đó chỉ tồn tại trong đúng cái file đang hiển thị nó.

Đó là lý do tài liệu này có một module riêng về sự cố đó, và lý do bộ file mẫu đi kèm có một test chuyên đi tìm những con số không có bằng chứng. Không phải để khoe. Để bạn không phải tự phát minh lại cái bẫy đó.

Bạn không cần gì

Không cần VPS trả tiền ngay. Trang tĩnh chạy được trên GitHub Pages, Cloudflare Pages, Vercel, hoặc bất kỳ host tĩnh miễn phí nào. Một file status.json sửa tay rồi push cũng là dashboard hợp lệ.

Không cần cổng thanh toán. VietQR chuyển khoản là đủ cho giai đoạn đầu, và nó miễn phí.

Không cần đăng ký doanh nghiệp để bắt đầu thử. Nhưng khi doanh thu thành thật, chuyện thuế và pháp lý là việc bạn phải tự xử lý — tài liệu có nêu ở module cuối, và tôi không tư vấn thay cơ quan thuế.

Cách đọc

Đừng đọc hết rồi mới làm. Đọc module 1 và 2, dựng được trang trắng, rồi đọc tiếp.

Thứ tự gợi ý:

  1. Module 1 — hiểu năm khối và chỗ nào hỏng trước.
  2. Module 5 và 6 — dựng được trang bán có QR chạy được.
  3. Module 7 — dựng dashboard, kèm test bằng chứng.
  4. Module 3, 4, 9 — đặt luật cho agent và cổng duyệt.
  5. Module 10 — chỉ làm khi đã có đơn thật.
  6. Module 11 và 12 — đọc lúc rảnh, để biết sẽ hỏng ở đâu.

Một quy ước về số

Trong toàn bộ tài liệu này, mọi con số về dung lượng, số trang, số test đều lấy từ lần build thật và ghi kèm đường dẫn file. Nếu bạn thấy một con số không có đường dẫn, hãy coi đó là lỗi của tài liệu và báo lại. Quy ước đó áp dụng cho cả những gì bạn viết sau khi đọc xong.

Module 2

Kiến trúc: năm khối

Nguyên tắc chọn kiến trúc

Một hệ thống bán hàng nhỏ có thể chia làm hai kiểu:

Kiểu nặng: web app có backend, database, session, admin panel, cổng thanh toán, webhook, job queue. Mạnh, nhưng cần bảo trì, cần backup, cần vá bảo mật, và mọi thứ đều có thể sập lúc 2 giờ sáng.

Kiểu tĩnh: HTML + JS + một file JSON. Không có gì để sập. Không có gì để hack ngoài việc sửa file — mà sửa file thì bạn biết ngay.

Giai đoạn đầu, kiểu tĩnh thắng gần như tuyệt đối. Bạn chưa có traffic để cần scale. Bạn chưa có đơn để cần tự động. Thứ bạn cần là sửa được nhanh và không nói dối khách.

Kiến trúc dưới đây là kiểu tĩnh, với đúng một chỗ động: cái QR.

Năm khối

   ┌──────────────┐
   │  1. AGENT    │  giữ luật, viết nội dung, chạy test, báo cáo
   └──────┬───────┘
          │ đọc/ghi file
   ┌──────▼───────┐
   │  2. TRANG    │  HTML tĩnh + config.js + status.json
   │     BÁN      │  không backend, không database
   └──────┬───────┘
          │ khách bấm mua
   ┌──────▼───────┐
   │  3. VIETQR   │  sinh payload EMVCo ngay trên máy khách
   └──────┬───────┘
          │ khách chuyển khoản
   ┌──────▼───────┐
   │  4. SỔ ĐƠN   │  đối soát tay (hoặc SePay tự động)
   └──────┬───────┘
          │ bạn xác nhận tiền vào
   ┌──────▼───────┐
   │  5. DASHBOARD│  status.json + evidence + test
   └──────────────┘

Khối 1 — Agent

Agent không phải "người bán". Agent là người vận hành có ghi chép. Việc của nó:

Nó không được tự đăng bài, tự gửi mail, tự đổi giá, tự trả lời khách. Xem module 9.

Khối 2 — Trang bán

Bốn file là đủ cho một shop: index.html, buy.html, config.js, data/status.json. Thêm CSS và một file JS đọc JSON. Không framework, không build step, không npm install.

Điểm quan trọng: chỉ một file chứa thông tin nhận tiền. Trong bộ mẫu là config.js. Mọi chỗ khác đọc từ đó. Nếu bạn để số tài khoản ở ba nơi, sớm muộn sẽ có hai nơi lệch nhau và khách chuyển tiền vào chỗ không ai đọc.

Khối 3 — VietQR

Payload QR được sinh bằng JavaScript ngay trên máy khách, từ thông tin trong config.js. Không gọi API nào. Không có gì để hết hạn, không có gì để chặn.

Đây là điểm mạnh nhất của kiến trúc: QR vẫn vẽ được khi mất mạng, khi API bên thứ ba sập, khi proxy công ty chặn. Module 6 giải thích định dạng và cách kiểm.

Khối 4 — Sổ đơn

Giai đoạn đầu: một file CSV. Mỗi dòng là một đơn, có cột loai để tách that và test. Tách bằng cột, không tách bằng file, vì tách file thì sẽ có ngày bạn cộng nhầm.

Giai đoạn sau: SePay hoặc tương đương đọc biến động số dư, khớp mã đơn, đánh dấu đã trả. Module 10.

Khối 5 — Dashboard

Đọc status.json, hiển thị số. Luật duy nhất: mỗi số khác 0 phải có trường evidence trỏ tới một file mở được. Không có file thì số là 0 và trạng thái là "chưa bắt đầu".

Luật này nghe đơn giản nhưng nó là thứ chặn được lỗi tệ nhất: dashboard trông rất chuyên nghiệp trong khi mọi con số đều là sản phẩm của trí tưởng tượng.

Module 8

Dashboard chỉ hiển thị số có bằng chứng

Vấn đề

Một dashboard trống trông như sản phẩm chưa làm xong. Một dashboard có số trông như sản phẩm đang chạy. Áp lực đó khiến người ta điền số.

Không ai quyết định "tôi sẽ bịa". Chuyện diễn ra thế này: bạn dựng khung, cần một bản mẫu để xem bố cục có đẹp không, bạn điền vài con số cho dễ hình dung. Rồi bản mẫu đó ở lại. Rồi nó được deploy. Rồi ba tuần sau có người hỏi "video V01 là video nào" và bạn không trả lời được.

Đây không phải giả thuyết. Đó là sự cố có thật trong quá trình dựng sản phẩm này, ghi chi tiết ở module 11.

Luật

Một câu, áp dụng cho mọi mục:

Mỗi số khác 0, mỗi trạng thái khác "chưa bắt đầu", bắt buộc có trường evidence trỏ tới một file mở được trong workspace. Không có file thì số là 0 và trạng thái là "chưa bắt đầu".

Ba hệ quả:

  1. evidence: null + số khác 0 = vi phạm.
  2. evidence: "duong/dan/file" + file không tồn tại = vi phạm.
  3. evidence: null + số 0 = hợp lệ.

Hình dạng dữ liệu

{
  "revenue": {
    "real": {
      "orders": 0,
      "net": 0,
      "note": "Doanh thu thật. Chỉ ghi đơn đã xác nhận tiền vào tài khoản.",
      "evidence": null
    },
    "test": {
      "orders": 0,
      "gross": 0,
      "note": "Giao dịch thử. Không bao giờ cộng vào số thật.",
      "evidence": null
    }
  }
}

Khi có đơn thật đầu tiên:

{
  "orders": 1,
  "net": 99000,
  "evidence": "orders.csv#dong-1"
}

evidence không cần là file riêng — có thể là một file kèm neo tới dòng cụ thể. Điều quan trọng là người đọc mở được và thấy đúng con số đó.

Bảy loại mục cần kiểm

Test tự động phải phủ hết bảy loại này. Thiếu một loại là có lỗ đi qua.

1. Ngày bắt đầu. startedAt khác null → phải có startedAtEvidence trỏ tới file có ngày đó (ảnh chụp, log, bài đăng đầu tiên).

2. Bước đang làm. state: "done" hoặc "active" → phải có evidence trỏ tới sản phẩm của bước đó. Bước "viết kịch bản" xong thì phải có file kịch bản.

3. Video hiện tại. currentVideo khác null → phải có trường evidence trỏ tới file của video đó, không chỉ tên.

4. Video đã đăng. Mỗi phần tử trong published[] phải có evidence là URL hoặc file chứng minh đã đăng.

5. Doanh thu. orders > 0 hoặc net > 0 → phải có evidence. Số test cũng cần, để chứng minh nó là test.

6. Chi phí. monthlyTotal khác null → phải có hoá đơn hoặc bảng tính. Chưa có thì null, không điền ước lượng.

7. Nhất quán nội bộ. currentStep phải khớp số bước done. publishedCount phải bằng published.length. Số đơn đã bán phải khớp sổ đơn.

Mục 7 là mục dễ bỏ qua nhất và cũng lộ liễu nhất: một dashboard nói "bước 3/7" trong khi cả 7 bước đều todo sẽ bị phát hiện trong ba giây.

Viết test

Test phải chạy được bằng một lệnh, không cần framework:

node site/tests/evidence.test.js

Kết quả phải có dạng đếm được:

checks: 48 | fail: 0
PASS — mọi số trên dashboard đều có evidence mở được.

Và khi sai:

checks: 53 | fail: 5
FAIL
  x startedAt khác null nhưng thiếu startedAtEvidence
  x bước 1 (done) thiếu evidence
  ...
EXIT=1

Nguyên tắc viết:

Chứng minh test có tác dụng

Một test luôn pass là test vô dụng. Phải chứng minh nó bắt được lỗi.

Cách làm: tiêm lại đúng dữ liệu sai rồi chạy test.

1. Sao lưu status.json
2. Điền lại các số bịa cũ (ngày, video, số chủ đề, bước done)
3. Chạy test → phải fail, đếm đúng số lỗi mong đợi
4. Phục hồi status.json
5. Chạy lại → phải pass

Trong lần kiểm thật của sản phẩm này: tiêm lại dữ liệu cũ → checks: 53 | fail: 5 | EXIT=1, bắt đúng 5/5 lỗi. Phục hồi → checks: 48 | fail: 0 | EXIT=0.

Không có bước này, bạn chỉ có một file test đẹp.

Case study 1

Đổi sản phẩm chính

Case study thật, viết từ log làm việc trong một ngày. Số liệu lấy từ file, đường dẫn đã làm sạch. Không có doanh thu trong case này vì chưa bán được đơn nào.

Bối cảnh

Mục tiêu ban đầu: bán một tài liệu hướng dẫn làm kênh video faceless. Sản phẩm đã có: 12 module, 8 template, 2 case study, PDF 50 trang, ZIP 300KB.

Trang bán dựng xong, test pass, QR chạy đúng. Mọi thứ sẵn sàng trừ một thứ: chưa có khách.

Vấn đề phát hiện

Trang chính từng có một khối dự kiến hiển thị tiến độ của một kênh faceless. Tuy nhiên, kênh và dữ liệu thật chưa tồn tại nên khối này không đủ điều kiện để được trình bày như bằng chứng.

Vấn đề: kênh đó chưa tồn tại. Dashboard hiển thị "bước 3/7", một video tên cụ thể, "12 chủ đề", "đang viết bản 3". Không có file nào cho bất kỳ mục nào.

Chi tiết sự cố ở module 11.

Quyết định

Hai lựa chọn:

A. Làm kênh faceless thật để dashboard có số thật. Cần 2–4 tuần, cần sản xuất video, cần đăng, cần đợi số liệu. Trong lúc đó trang vẫn không bán được gì.

B. Đổi sản phẩm chính sang thứ đang có sẵn bằng chứng: chính hệ thống đã kiểm thử đầu cuối nhưng chưa có giao dịch thật — agent + trang bán + VietQR + dashboard + cổng duyệt. Trang chính minh hoạ trực tiếp sản phẩm đó, vì nó là sản phẩm đó.

Chọn B. Lý do ghi trong file quyết định:

Trang chính minh hoạ trực tiếp chính sản phẩm. Kiến trúc đã kiểm thử đầu cuối nhưng chưa có giao dịch thật; thứ khách đang xem chính là thứ họ mua. Sản phẩm faceless giữ làm sản phẩm thứ hai.

Thay đổi cụ thể

Việc Trước Sau
Sản phẩm chính Kênh Faceless 7 Bước Hướng dẫn dựng agent tự bán hàng
Trang chính Trang bán tài liệu Dashboard + trang bán của chính shop
Bằng chứng Số liệu bịa Chỉ số có file, hiển thị đường dẫn
Sản phẩm phụ Không có Kênh Faceless 7 Bước, trang riêng
Giá 49k / 99k Ngày 26/10, theo quyết định của Sếp, đổi từ bảy mươi chín nghìn / một trăm bốn mươi chín nghìn về 49k / 99k

Cái đã học được

1. Sản phẩm tốt nhất là thứ bạn đang dùng. Không cần nghĩ ra sản phẩm mới. Nhìn vào việc mình vừa làm trong 8 tiếng, đó là sản phẩm.

2. Bằng chứng phải có trước lời bán. Nếu phải chọn giữa "nội dung hay hơn" và "có file chứng minh", chọn cái thứ hai.

3. Đổi sản phẩm rẻ hơn làm kênh thật. Làm kênh mất 2–4 tuần và không chắc thành công. Đổi sản phẩm mất một buổi và chắc chắn có bằng chứng.

4. Không xoá sản phẩm cũ. Tài liệu faceless đã làm xong, có bằng chứng, có giá trị riêng. Bỏ đi là lãng phí. Chuyển thành sản phẩm thứ hai, trang riêng, số liệu riêng.

Chi phí thật của việc này

Khoản Số
Thời gian viết nội dung mới ~5 giờ
Thời gian sửa trang ~2 giờ
Thời gian viết lại test ~1 giờ
Tiền mặt 0đ

Không có chi phí tiền mặt vì mọi thứ chạy trên hạ tầng đã có. Đây là lợi thế thật của sản phẩm số: chi phí biên gần bằng 0.

Cái chưa làm được

Trung thực, vì đây là case study chứ không phải quảng cáo:

Case này chứng minh quy trình dựng hoạt động. Nó không chứng minh bán được. Hai chuyện khác nhau, và trộn chúng lại là cách nhanh nhất để viết một case study vô giá trị.

Bài học chuyển được sang việc khác

Khi bí sản phẩm, đọc lại việc mình vừa làm. Không phải việc mình biết làm — việc mình vừa làm xong, có file, có lỗi đã sửa.

Khi phát hiện mình đang bịa, sửa cấu trúc chứ không sửa lời. Đổi "đang viết bản 3" thành "đang chuẩn bị" là che lỗi. Xoá hẳn và thêm test là sửa lỗi.

Khi đổi hướng, ghi lý do ngay. Ba tuần sau bạn sẽ không nhớ vì sao. Một đoạn 3 dòng đủ.

Bản đầy đủ: 13 module + 2 case study, 62 trang. Trọn bộ kèm 5 file mẫu và bộ mã webhook SePay mẫu.

Mua trọn bộ — 99.000đ Chỉ bản PDF — 49.000đ

Hoàn tiền 100% trong 7 ngày, không cần lý do. Giao trong 24 giờ sau khi xác nhận thanh toán.