FULL-SYSTEM BLUEPRINT · GROK BOT × HUMAN-IN-THE-LOOP · DUAL-FUNNEL STRATEGY
Trang này mô tả cách Smart Tech CTC phối hợp bot và 6 vai trò người. Bot chỉ nghiên cứu và soạn nháp; người đi qua cổng duyệt, tự gửi từng lần chạm, xác nhận nhu cầu, chạy gói thử 5 ngày và bàn giao cho Đội kỹ sư chuyên trách (Pod).
01 · Sơ Đồ Hệ Thống End-to-End (8 Công Đoạn × 6 Lane)
Lane trên cùng là đội bot; mọi node gắn 👤 là chốt human-in-the-loop. Mũi tên đứt = vòng lặp phản hồi (re-signal của CTC Scout đánh thức lead nguội; referral của CSKH quay về đầu phễu).
| Mức | Hoạt động | Enforcement (nằm ở đâu) |
|---|---|---|
| 🤖 BOT TỰ ĐỘNG chỉ khi enforce được ở tầng CODE | Cào tín hiệu account trang công khai (logged-out) · enrich & dedup qua ledger · HubSpot UPDATE-only — do KEEPER (code VPS) thực thi SAU khi người bấm ✅, không phải bot · báo cáo ERP + Telegram · re-signal lead nguội | ✅ Đã hiện thực hoá bằng Grok Bot Gateway (grokgw.smarttechctc.io, PM2 grokbot-gateway): evidence_url bắt buộc (thiếu → 400), idempotency chống ghi trùng, auth timing-safe, log vào grok_runs/grok_audit, /health cho dead-man switch. CREATE HubSpot chặn tầng code (trần 1.000). Không giao cho browser-agent — chi tiết Tab 11 mục 04.5 |
| 🤝 BOT SOẠN — NGƯỜI DUYỆT | Draft bài LinkedIn/Substack · nháp InMail/email 5 chạm · comment Reddit · pre-call brief · SOW nháp · ĐỌC-only Sales Nav (search/xem/lưu list, chép dossier — KHÔNG nút tương tác) | ✅ Hàng đợi Telegram đóng mạch v2: POST /grok/draft → nút ✅/✏️/❌/⭐ → callback ghi grok_approvals, TTL expired thật — 1 chạm [✅/✏️/❌] (KHÔNG dùng Approvals của platform thay thế: approval-fatigue → Always-allow = mất kiểm soát); SLA 12h/4h, quá hạn = expired (fail-closed); Sales Nav chạy giờ hành chính, trần ~50–80 profile/ngày như người thật |
| 👤 NGƯỜI 100% — BOT CẤM ngoài quyền bot ngay từ prompt | Bấm gửi InMail/email/connect/comment/like · đăng nhập LinkedIn & HubSpot (Human Takeover: mật khẩu/OTP người tự gõ) · trả lời khách · Discovery Call & BANT · Fit Check Path A/B · Bootcamp · báo giá ngoài dải · ký SOW | ✅ Enforce vật lý: gateway KHÔNG có endpoint nào gửi/đăng — bot không thể gửi kể cả khi bị prompt-injection. Lý do: LinkedIn 2026 suspend NGAY lần đầu với browser-automation trên datacenter IP → mất account người đứng tên + Sales Nav đã trả tiền + cả phễu úp ngược. 1 câu sai DPA giết deal $16k/tháng |
⚠️ Nguyên tắc enforcement (BMAD Party Review 01/09): trên nền tảng Grok Bot, phần lớn guardrail của v1 (fail-closed, chặn CREATE, cấm gửi) vốn là enforcement tầng code — khi chạy trong browser-agent chúng tụt xuống chỉ còn lời dặn trong prompt. Vì vậy: mọi việc đụng credential/API (HubSpot, gửi outbound) ở lại tầng code/Terminal; browser-agent CHỈ làm việc đọc trang công khai + soạn draft. Đội bot thật (4 bot Airtable 03/09) + đặc tả I/O từng bot: Tab 12. Setup kỹ thuật (format 6 trường), Gateway đã chạy (6 endpoint), bản đồ webhook mở rộng và hệ UTM 2 pha: Tab 11.
Cả 5 cổng đều mang tên Minh OK vì anh Minh (CSMO) là người duyệt mặc định, KHÔNG phải vì chỉ mình anh Minh được duyệt. Hệ thống đã có dead-man switch cho bot chết; khối này là dead-man switch cho người duyệt vắng. Tên cổng giữ nguyên trong grok_approvals; trường approver ghi ai thực sự bấm nút để đối soát sau.
| Cổng | Uỷ quyền được? | Người duyệt dự bị | Luật cứng |
|---|---|---|---|
Minh OK Scout | CÓ | SDR (chủ trì Wave-1) | Chỉ duyệt hồ sơ có đủ evidence_url. Nghi ngờ ICP → ❌ về nurture, KHÔNG tự nới tiêu chí. |
Minh OK Route | KHÔNG | — | Phân tuyến A/B đổi cả cách chào giá → chỉ hoãn, không uỷ quyền. Hết TTL thì draft expired và account nằm chờ, không tự chảy tiếp. |
Minh OK Asset | CÓ | Presales/SA | Được duyệt kịch bản Loom + factsheet đúng bản mẫu đã chốt. Mọi câu chạm vào cam kết kỹ thuật/DPA → giữ lại chờ anh Minh. |
Minh OK Touch | CÓ (có trần) | SDR | Tối đa 10 chạm/ngày duyệt thay, chỉ với chạm 1–3 theo mẫu. Chạm 4–5 (chào giá, đặt lịch call) → anh Minh duyệt. |
Minh OK Pivot | KHÔNG | — | Hạ phễu Pod → Bootcamp là quyết định thương mại (đổi dải giá) → chỉ anh Minh. Bận thì lead ở nguyên trạng thái, không tự hạ. |
Kích hoạt dự bị (không cần hỏi lại): hàng đợi Telegram có ≥1 draft quá 2/3 TTL (8h với SLA 12h · 2h40 với SLA 4h) mà chưa có nút nào được bấm → CTC Master bắn 1 tin vào group chat gắn tên người dự bị của đúng cổng đó. Người dự bị bấm nút bằng chính tài khoản Telegram của mình; server ghi approver = <tên>, không mượn token.
Draft expired đi về đâu (trước đây bỏ trống): ① sweeper đánh expired → nội dung không mất, nằm lại grok_approvals với decision=expired; ② brief 08:00 hôm sau liệt kê danh sách expired kèm lý do "hết TTL" ở dòng đầu; ③ bot tự soạn lại tối đa 1 lần cho cùng account/chạm đó (idempotency key mới), sau đó dừng hẳn — không soạn lại vòng 3 để tránh đốt quota Telegram 40 tin/ngày; ④ quá 2 lần expired liên tiếp trên cùng account → account bị gắn HOLD_APPROVER và rút khỏi cadence 5 chạm, chờ người xử lý tay (không được để nửa chuỗi chạm dở dang gửi ra khách).
Anh Minh vắng dài (≥3 ngày làm việc — công tác/ốm): thông báo trước trong group chat, kèm 3 việc bắt buộc: ① nâng TTL 2 cổng uỷ quyền được lên 36h (giảm expired rác); ② đóng băng cổng Minh OK Route và Minh OK Pivot — bot ngừng sinh draft cho 2 cổng này, không xếp hàng đợi để khỏi expired hàng loạt; ③ hạ trần outreach xuống ≤5 chạm/ngày do người dự bị duyệt. Vắng không báo trước và hàng đợi im >24h → dead-man cron 15 phút réo MingBot sang anh Nam (SysAdmin) để xác nhận là "người bận" chứ không phải "Telegram/gateway chết".
02 · Bóc Tách Nhiệm Vụ Từng Công Đoạn (Cào Dữ Liệu → Close)
| Công đoạn | 🤖 Grok Bot làm | 👤 Human-in-the-loop | Data vào → ra | KPI đếm được |
|---|---|---|---|---|
| 1. Cào dữ liệu & Enrich CTC Scout · 02:00 daily | Quét GitHub/blog/press/job posting của 94 account; trả sự kiện thô + quote ≤25 từ + URL; chấm fit 0–1; enrich email/LinkedIn (Serper) | Rà mọi tên/chức danh <2 nguồn độc lập (needs_human); duyệt lead mới trước khi vào wave | HubSpot + web → ledger.db (dedup email PK) → HubSpot UPDATE 2 field LinkedIn | Số email never→accepted/ngày (query ledger độc lập — không tin log bot) |
| 2. Verify & Phân tầng CTC Scout + SDR · 08:30 | Gắn cờ trigger event (funding/hiring 3+/replatform); đề xuất tier + entry path | SDR chốt tier cuối; gán Wave; quyết Path A (Direct-to-Pod) / B (Bootcamp-First) | ledger → leads_data (wave, entry_path) → Tab 02 | Số account đủ 2–3 contact verified (đếm tay từ ledger) |
| 3. Marketing Content CTC Social · 06:00 T2/4/6 | Draft bài LinkedIn theo lịch IMC Tab 07; essay Substack (xuất Markdown); jitter giờ ±47 phút chống dấu vân tay máy | Duyệt Telegram 1 chạm; NGƯỜI đăng LinkedIn (copy 1 chạm — ToS cấm bot); ≤30% nội dung tuần do máy; mỗi bài thêm 1 chi tiết chỉ người trong cuộc biết | Lịch IMC + dossier → hàng đợi posts → permalink + link landing có UTM mã trung tính (#sol-health deep-link theo ngành) | Số draft ĐƯỢC DUYỆT (đếm từ grok_approvals); bài có URL public (đếm tay) |
| 4. Outbound 5 Chạm CTC Social + SDR · cả ngày | Nháp InMail/email cá nhân hoá TỪNG lead từ dossier (chạm 1→5 + chạm 4.5 mời Bootcamp) | NGƯỜI BẤM GỬI 100% — mục tiêu <60 giây/lead từ nháp đến gửi; xử lý reply ≤15m; battlecard khi bị từ chối | dossier → nháp (UTM bot tự sinh, validator regex chặn sai) → ledger log (timestamp) → HubSpot engagement | Touch thật/ngày (người ghi qua /sent → grok_runs); reply thật (đếm tay ERP /crm) |
| 5. Remarketing / Nurture CTC Social + CTC Scout + MKT · 2 tuần/lần | Chuỗi warm email T2; theo dõi engager bài viết → list nóng; re-signal khi account có trigger event mới (funding, tuyển dụng) | MKT chọn content nuôi; SDR quyết thời điểm đánh thức; CSKH gửi tài liệu nghiên cứu cho warm lead | post_metrics + trigger events + click landing (utm_hits/ghi tay Pha 1) → lọc DNC (dnc IS NOT TRUE) → nurture queue → CRM 7 tầng | Lead nguội đánh thức có phản hồi (đếm tay ERP /crm) |
| 6. Presales: Discovery + BANT Presales/AE · ca tối | Pre-call brief tự động ≥6h trước call (dossier + 3 câu hỏi cắt scope + 1 rủi ro data dự đoán) | Presales chủ trì call 30m, SỞ HỮU điểm BANT, chạy Cổng 5 Fit Check, gác cổng FDE (chỉ kéo vào khi BANT ≥75đ Hot SQL), SOW ≤48h | brief → BANT score → SOW (ERP /pricing) → CRM | Call diễn ra (đếm tay ERP /crm); latency/expired duyệt (GET /grok/hitl) |
| 7. Sales: Bootcamp / Pilot → Close FDE + AE · D1–D5 | Accelerator/starter-kit gợi ý sẵn cho use-case; README nháp | FDE cắm chốt 5 ngày (thu phí trước, gate D3/D5); AE demo 30m ngày 5 + đề xuất Pod; ký Retainer khấu trừ 50% | data khách (sau NDA/DPA) → prototype + Báo cáo ROI 3 chỉ số → hợp đồng | Deal trả phí ký; Bootcamp đúng 5 ngày (đếm tay ERP /pricing) |
| 8. Expand & Vòng lặp CSKH + CTC Master · W8+ | CTC Master brief 08:00/18:00 (dẫn đầu bằng con số TRƯỢT) — báo cáo qua POST /grok/report; CTC Scout quét network khách đã chốt → account mới về đầu phễu | CSKH xin referral khi NPS ≥9; MKT sản xuất case study thật thay khung Palantir | ROI report → case study → referral list → phễu úp ngược vòng 2 | Số cuộc gọi đặt được — đếm tay Cal.com/ERP (chỉ số xếp TRÊN mọi thứ); referral thật |
03 · Chiến Lược Phễu #1 — Phễu Thuận (Volume-First)
Phễu thuận dành cho Tier B/C và kho HubSpot: bot chuẩn bị dữ liệu và nháp, người duyệt rồi gửi. Lead chưa sẵn sàng được đưa vào luồng chăm sóc; người yêu cầu dừng liên hệ phải được loại khỏi mọi lịch gửi.
KPI 12 tuần: ≥17 phản hồi · ≥4 call · ≥1 deal · ≥1 Pod. Sản lượng lần chạm theo giai đoạn đang được mở.
dnc=true + dnc_reason + dnc_at, gỡ khỏi mọi lịch trong 24h.KPI: số lead nguội đánh thức có phản hồi / tháng (đếm tuyệt đối)
Mốc 100 lần chạm/ngày chỉ áp dụng ở giai đoạn mở rộng; số gửi thật do người ghi nhận.
04 · Chiến Lược Phễu #2 — Phễu Úp Ngược (Account-Based · Land & Expand)
Phễu account dành cho Wave-1 gồm 17 account ACTIVE và 1 HOLD. Mỗi account được nghiên cứu và tiếp cận 1:1. Nếu nhu cầu phù hợp, lộ trình là gói thử 5 ngày có thu phí → đo kết quả → đề xuất Đội kỹ sư chuyên trách (Pod). Account HOLD và FLAG DỪNG không được gửi.
KPI 12 tuần: 17/17 account ACTIVE đủ 5 chạm · ≥4 call · 1–2 Bootcamp · ≥1 Pod (tổng 2 phễu = ≥8 call · ≥3 deal · ≥2 Pod)
Mỗi account 1 owner duy nhất (Presales) — không chuyền tay
Mô hình tham chiếu: Palantir×Airbus — 1 nhà máy → nền tảng 100+ hãng bay
05 · So Sánh & Quy Tắc Điều Phối Giữa 2 Phễu
| Tiêu chí | Phễu Thuận (Volume) | Phễu Úp Ngược (Account-Based) |
|---|---|---|
| 🗄️ NGUỒN DATA (chiến lược) | HUBSPOT — API token, pull 10.085 contact, enrich UPDATE-only, webhook contact mới | LINKEDIN PREMIUM + SALES NAVIGATOR — browser session người đứng tên, đọc-only, filter hiring/posted-30d/changed-90d |
| Đối tượng | Tier B/C · kho HubSpot 10.085 SAU KHI trừ suppression list 22 account ABM · lead mới cào (ghi ledger source=grok, chưa vào HubSpot được do trần 1.000) | Wave-1 = 18 account Tier A (17 ACTIVE + 1 HOLD, lọc từ shortlist 22) · account referral · lead phễu thuận đạt cổng thăng hạng |
| Triết lý | Nhiều → lọc dần → nuôi phần rơi | Ít → đào sâu → nở giá trị (Land & Expand) |
| Vai Grok Bot | Gánh khối lượng: enrich hàng loạt, nháp template, nurture tự động | Tình báo: dossier sâu, trigger event, pre-call brief — không chạm khách |
| Vai Người | Duyệt nhanh + bấm gửi + qualify | Toàn bộ mặt tiền: Loom mặt thật, call, Bootcamp, quan hệ |
| Cửa vào deal | Theo entry_path của TỪNG lead (Tab 02 đã gán): Path A → Pilot $2k–$5k · Path B → Bootcamp $1.5k–$3k. Wave-1 có cả A lẫn B — không suy từ phễu | |
| Đo lường | Touch/reply/call — số lớn, % có nghĩa | Đếm tuyệt đối theo account — CẤM dùng % (mẫu chỉ 17 account ACTIVE — sai 1 account là lệch gần 6 điểm %) |
| 🔗 UTM / attribution | Campaign cX-wNN theo ngành; Pha 2 bật utm_hits khi ≥300 click/tháng | Pha 1: đối soát TAY theo tên khách — 18 account Wave-1 thì tên chính xác hơn mọi hệ tracking; link vẫn gắn UTM để nối Cal.com |
| Chi phí/lead | Thấp (~phút bot + giây người) | Cao (giờ người thật) — hoàn vốn ở LTV |
| Rủi ro | Spam, đốt domain, ảo giác số lượng | Bỏ trứng vào ít giỏ — 1 account rớt = mất 5,9% pipeline (1/17 ACTIVE) |
Vào Phễu Úp Ngược khi: (a) nằm trong Wave-1 = 18 account (17 ACTIVE + 1 HOLD, lọc từ shortlist 22 Tier A) chọn tay, HOẶC (b) lead phễu thuận đạt cổng thăng hạng (mở email >3 lần · click link báo cáo · BANT ≥60đ · có tin tuyển dụng mới từ ATS). Điểm ICP 0–100 dùng để XẾP ƯU TIÊN, không làm ngưỡng vào phễu. Phân tuyến A/B bên trong quyết theo tín hiệu ATS (nhiều req SWE mở → PATH_A Pod · ít/không có req nhưng có sản phẩm số → PATH_B Bootcamp), không theo điểm. Gán 1 lần tại bước Phân tầng (công đoạn 2), ghi vào field wave/entry_path.
Phân biệt 2 thang điểm (đừng lẫn): Điểm ICP 0–100 chấm ACCOUNT (ngành · quy mô · stack · tín hiệu tuyển) — chỉ dùng để XẾP ƯU TIÊN danh sách, không bao giờ là ngưỡng vào phễu. Điểm BANT 0–100 chấm CƠ HỘI sau khi đã nói chuyện (Budget · Authority · Need · Timeline · Fit) — đây mới là thang có ngưỡng: ≥60đ = cổng thăng hạng lên Phễu Úp Ngược · ≥75đ = Hot SQL, gate kéo FDE vào.
Lead phễu thuận có phản hồi phù hợp + BANT ≥60đ và đạt Cổng 5 Fit Check → rút khỏi luồng số lượng, giao một Presales phụ trách và chuyển sang chăm sóc 1:1. Tối đa 5 suất thăng hạng/tháng; công suất thực hiện luôn theo trần ≤2 Bootcamp song song · ≤8 FDE-ngày/tháng.
Account ABM im lặng (không phản hồi) sau đủ 5 chạm + 1 breakup note → KHÔNG vứt: chuyển về nurture của phễu thuận, CTC Scout canh trigger event để tái kích hoạt có lý do mới. Ghi rõ lý do giáng hạng vào CRM. Phân biệt rạch ròi: im lặng ≠ từ chối. Account trả lời để từ chối tiếp xúc đi thẳng ra DO-NOT-CONTACT (bước dưới), không qua nurture.
Trước MỖI lô bơm danh sách volume, KEEPER chạy bước suppression bắt buộc: đối chiếu toàn bộ contact sắp nhận volume-email/nurture-email với danh sách domain + email của 22 account shortlist (18 Wave-1 = 17 ACTIVE + 1 HOLD Securonix). Trùng domain công ty — không chỉ trùng email — thì gắn cờ abm_suppressed=true trong ledger.db và loại khỏi lô gửi. Lý do: 2 phễu ăn 2 nguồn data độc lập (Thuận = HubSpot API · Úp Ngược = Sales Navigator), nên một CEO Tier A hoàn toàn có thể vừa nằm trong kho 10.085 vừa nằm trong Wave-1. Người đó nhận InMail 1:1 nghiên cứu sâu + Loom mặt thật, cùng tuần nhận thêm email template hàng loạt = lộ ngay là máy chạy, đốt đúng account đắt nhất.
3 trường hợp BẮT BUỘC suppress: (1) 17 account ACTIVE — đang chạy 5 chạm ABM, chỉ được nhận abm-inmail/abm-loom; (2) 1 account HOLD (Securonix · LD011) — lệnh "cấm gửi" áp cho MỌI kênh kể cả volume-email, cho tới khi anh Minh duyệt; (3) lead vừa thăng hạng Thuận → Úp Ngược — huỷ ghi danh sequence HubSpot ngay trong ngày, không đợi chu kỳ sau.
Gỡ suppress chỉ ở 2 thời điểm: account bị giáng hạng (đủ 5 chạm + breakup note) → mở lại nurture-email sau cooldown 14 ngày; hoặc account bị gắn FLAG DỪNG (4 hồ sơ: PubNub · Rakuna · Regie.ai · Shield) → hạ Tier C, chuyển hẳn sang phễu thuận. 🤖 CTC Master kiểm tra chéo lúc 18:00 cùng nhịp đối soát ERP ↔ ledger: contact nào nhận cả abm-* lẫn volume-* trong 30 ngày → báo đỏ Telegram, dừng lô gửi kế tiếp cho tới khi người xử lý.
Kích hoạt khi có bất kỳ tín hiệu nào sau đây, bằng bất kỳ kênh nào (email · InMail · comment · điện thoại · qua đồng nghiệp): (a) câu từ chối rõ ràng — "stop", "remove me", "do not contact", "đừng liên hệ nữa"; (b) bấm unsubscribe; (c) nhắc tới GDPR / quyền phản đối / CCPA / CAN-SPAM; (d) báo spam. Không cần suy diễn ý định — nghi ngờ thì coi là DNC.
Hành động trong 24h (SDR làm tay, bot không được tự quyết): ① đặt dnc=true · dnc_reason (trích nguyên văn câu khách nói) · dnc_at · dnc_channel ở ERP CRM và ledger.db — DNC là trạng thái ngang hàng 7 tầng, không phải một tầng, ghi đè mọi tầng đang có; ② gỡ khỏi nurture queue, danh sách tái chạm 3 tháng và mọi lịch đã đặt; ③ trả 1 email xác nhận DUY NHẤT, không chào bán ("Đã gỡ khỏi mọi danh sách, xin lỗi vì làm phiền"); ④ báo anh Minh trong daily nếu là account Wave-1.
Ràng buộc cứng: DNC một chiều, vĩnh viễn — không có trigger event nào (gọi vốn, tuyển kỹ sư, đổi CTO) được phép đánh thức lại; CTC Scout phải lọc bỏ dnc=true trước khi đề xuất tái kích hoạt. Chỉ chính người đó chủ động liên hệ lại mới gỡ được cờ, và phải do anh Minh duyệt tay. DNC gắn ở cả cấp contact lẫn cấp domain khi câu từ chối nói thay công ty ("we are not interested, do not contact anyone here"). Mọi export danh sách gửi đều phải qua bộ lọc WHERE dnc IS NOT TRUE; thiếu bộ lọc = FAIL ngày.
Bối cảnh: 4 hồ sơ FLAG DỪNG (PubNub · LD018 · Rakuna · LD015 · Regie.ai · LD019 · Shield · LD022) bị lọc ATS loại khỏi Wave-1, hạ Tier A→C, dời sang wave 3; 1 hồ sơ HOLD (Securonix · LD011) chờ anh Minh duyệt, cấm gửi mọi kênh. Cả 5 KHÔNG sản xuất Loom, KHÔNG gửi outreach. Trước đây vòng re-signal chỉ định nghĩa cho lead nurture của phễu thuận — 5 hồ sơ này rơi vào khoảng trống: có tín hiệu mới cũng không ai biết phải xử lý thế nào.
Ai xét lại & theo tiêu chí gì: 🤖 CTC Scout vẫn canh tín hiệu như mọi account khác nhưng chỉ được đẩy vào hàng đợi đề xuất, tuyệt đối không tự mở lại. 👤 SDR rà hàng đợi này 1 lần/tuần (không rà hằng ngày — tránh mở lại vội). Chỉ đủ điều kiện đề xuất khi có ≥2 tín hiệu ATS mới kèm URL trong 30 ngày: (a) mở req SWE/AI mới · (b) gọi vốn vòng mới · (c) đổi CTO/VP Eng · (d) thông báo replatform. Tín hiệu marketing đơn thuần (đăng bài, like, follow) không tính.
Có cần cổng "Minh OK" không — CÓ: đề xuất mở lại đi qua Minh OK Scout (đúng cổng duyệt hồ sơ vào wave), SLA 12h, bắt buộc kèm: lý do loại ban đầu + 2 evidence_url mới + tuyến A/B đề xuất. ✅ duyệt → account vào wave 3 ở Tier C, chạy phễu thuận trước (nurture-email, gỡ abm_suppressed), chỉ được nâng lên ABM khi đạt cổng thăng hạng BANT ≥60đ như mọi lead thường. ❌ → khoá thêm 90 ngày, không đề xuất lại. Riêng Securonix (HOLD) KHÔNG đi đường này: chỉ chính anh Minh gỡ HOLD, không tín hiệu nào tự động gỡ được, và vẫn nằm trong suppression list cho tới lúc đó.
Trạng thái phễu của mọi lead nằm ở ERP CRM 7 tầng + ledger.db (không phải localStorage). 🤖 CTC Master đối soát 2 nguồn mỗi 18:00, lệch = báo đỏ Telegram. Người xem tổng quan tại Tab 08; bot nhận việc qua ERP task [GROK].
grokbot-plan-v1.md. Đây là thế hệ tool thứ 4 khi số email đã gửi vẫn = 0 — tự động hoá quy trình chưa chạy tay là tự động hoá một giả thuyết.