Alakris — Sales Playbook 2026
| Phiên bản | v1.0 |
| Ngày | 2026-07-12 |
| Trạng thái | APPROVED — đã xuất bản 2026-07-12 |
| Hợp đồng | MKT-030-4 (PARENT: MKT-030) |
| Thay thế/mở rộng | sales_playbook_pricing_and_qualification_2026.md (SUPERSEDED đối với self-service segment — xem banner trong file đó) |
| Tham chiếu đến | Pricing Book (pricing-book-2026.md, MKT-030-3), Demo Playbook (MKT-030-5), Qualification Guide (MKT-030-6), Objection Handling (MKT-030-7) |
0. Tại sao tài liệu này thay thế playbook cũ
sales_playbook_pricing_and_qualification_2026.md (Status: Active) chỉ nhắm đến duy nhất high-ticket ICP: revenue ≥$1M, paid traffic đang hoạt động, đã có CRM, marketing budget ≥$10K/tháng — đây là cùng phân khúc với Alakris_Price_List_2026.pdf cũ (Growth/Scale/Performance). Vào thời điểm viết playbook cũ, các tier self-service (Lite $30 / Self-Service $129 / Managed $349) chưa tồn tại.
Tài liệu này bao phủ toàn bộ phổ — Lite → Enterprise. Playbook cũ không bị xóa, được đánh dấu SUPERSEDED và tiếp tục là tài liệu tham khảo hợp lệ cho Enterprise segment (các mục 5–14 của tài liệu cũ — ROI framing, deal qualification matrix, founder call rule — vẫn còn phù hợp cho các discovery-call Growth/Scale/Performance, xem mục 6 bên dưới).
1. Các giai đoạn bán hàng (tổng quan)
Tiếp xúc đầu tiên → Discovery-call → Qualification → Demo → Đề xuất gói
→ Xử lý phản đối → Thương lượng điều khoản → Đóng giao dịch → Onboarding| Giai đoạn | Tài liệu của epic | Owner | Thời hạn |
|---|---|---|---|
| Discovery-call | tài liệu này, mục 2 | Sales-manager | Lần đầu tiếp xúc, tối đa 30 phút |
| Qualification | Qualification Guide (MKT-030-6) | Sales-manager | Trong/ngay sau discovery |
| Demo | Demo Playbook (MKT-030-5) | Sales-manager | Trong vòng 3 ngày làm việc sau discovery |
| Đề xuất gói | Pricing Book (MKT-030-3) + cây gói (mục 3 bên dưới) | Sales-manager | Ngay sau demo |
| Xử lý phản đối | Objection Handling Guide (MKT-030-7) | Sales-manager | Trong suốt cuộc trò chuyện |
| Thương lượng điều khoản | Enterprise Pricing Policy (Pricing Book, mục "Enterprise") — chỉ cho giao dịch Enterprise | Sales-manager → Owner (approval matrix) | Tối đa 5 ngày làm việc |
| Đóng giao dịch | tài liệu này, mục 7 | Sales-manager | — |
| Onboarding | Customer Journey (MKT-030-10) | Onboarding-specialist | Từ lúc thanh toán |
Quy tắc next steps: sau MỖI giai đoạn phải ghi nhận hành động cụ thể với owner và thời hạn trong CRM (Марина, AI-sales-manager — lead card). Cách diễn đạt "thảo luận sau" bị cấm — hoặc là ngày gọi lại, hoặc là trạng thái rõ ràng "tạm dừng, lý do X, follow-up ngày Y".
2. Discovery-call — cấu trúc cuộc họp đầu tiên
Checklist tuyến tính thống nhất (không làm quá tải phương pháp): ACE mở đầu → SPICED-câu hỏi → next steps. Xương sống của qualification là MEDDPICC-lite (mục 2.2), nhưng người phỏng vấn đặt câu hỏi theo logic SPICED, không đọc MEDDPICC như bảng câu hỏi.
2.1. Thời gian cuộc gọi (30 phút)
| Khối | Thời gian | Mục tiêu |
|---|---|---|
| ACE mở đầu | 3 phút | Agenda, Context, Expectations — chúng ta thảo luận gì, tại sao khách hàng ở đây, họ nhận được gì sau cuộc gọi |
| Situation | 5 phút | Tình hình hiện tại: kênh bán hàng, khối lượng traffic/lead, có CRM không, hiện ai đang trả lời khách hàng |
| Pain | 10 phút | Đâu là nơi mất tiền/thời gian: đơn hàng ban đêm không được trả lời, qualification chậm, support quá tải, không có SEO traffic |
| Impact | 5 phút | Chuyển pain thành tiền/giờ: "mỗi tháng mất bao nhiêu đơn hàng ban đêm?", "mỗi tuần mất bao nhiêu giờ để qualification lead thủ công?" |
| Decision | 4 phút | Ai ra quyết định, có ngân sách không, thời hạn nào |
| Next steps | 3 phút | Hành động tiếp theo cụ thể + ngày |
2.2. MEDDPICC-lite (những gì cần được làm rõ trước khi kết thúc discovery)
| Chữ cái | Câu hỏi | Ghi nhận ở đâu |
|---|---|---|
| Metrics | Khách hàng muốn cải thiện chỉ số nào và bao nhiêu (bằng số, không phải "sẽ tốt hơn") | CRM, trường Impact |
| Economic Buyer | Ai thực sự ký hóa đơn — không phải lúc nào cũng là người đang họp | CRM, nếu khác — xem mục 2.4 |
| Decision Criteria | Theo tiêu chí nào khách hàng sẽ so sánh các phương án (giá / tốc độ triển khai / tích hợp) | CRM |
| Decision Process | Cần bao nhiêu bước để ký, còn ai tham gia | CRM |
| Identify Pain | Cụ thể pain từ mục Pain bên trên | CRM |
| Champion | Ai bên phía khách hàng sẽ thúc đẩy giao dịch nội bộ | CRM |
| Competition | Khách hàng có xem xét lựa chọn khác không (không nhất thiết hỏi trực tiếp — nếu lộ ra thì ghi nhận) | CRM, tùy chọn |
2.3. 6–8 câu hỏi mở (mẫu, nghiêng về Pain/Impact)
- Hiện tại các yêu cầu/liên hệ của khách hàng ngoài giờ làm việc được xử lý như thế nào?
- Khoảng bao nhiêu liên hệ mỗi tháng đến qua website/messenger?
- Nếu sales-manager không kịp trả lời nhanh, yêu cầu sẽ ra sao?
- Hiện tại pipeline của bạn trông như thế nào — bạn dùng gì để quản lý lead (CRM, bảng tính, không có gì)?
- Nếu các đơn hàng ban đêm và "chậm" không bị mất — thì mỗi tháng sẽ mang lại bao nhiêu tiền? (câu hỏi Impact định lượng)
- Team dành bao nhiêu thời gian để qualification lead đến thủ công?
- Trong công ty bạn ai là người quyết định về các công cụ như vậy và ngân sách đã được dự trù là bao nhiêu?
- Thời hạn nào — khi nào bạn muốn thấy kết quả?
2.4. Edge case — không có Economic Buyer trong cuộc họp
Nếu trên discovery-call chỉ có Champion (marketer, manager, nhưng không phải người ký hóa đơn):
- Không chuyển sang thảo luận giá cho đến khi Economic Buyer xuất hiện trong cuộc trò chuyện (miệng hoặc cuộc gọi tiếp theo).
- Hỏi rõ Champion: "Trong công ty ai là người phê duyệt cuối cùng các chi phí như vậy?" — ghi tên/vai trò vào CRM.
- Thỏa thuận cuộc gọi chung với Economic Buyer TRƯỚC khi gửi đề xuất thương mại — không gửi giá "vào khoảng không" cho người không có quyền quyết định.
- Champion trong trường hợp này nhận vai trò "người bán hàng nội bộ" — cung cấp tài liệu (Pricing Book, case) để họ trình bày nội bộ với sếp, nếu không thể sắp xếp cuộc gọi chung ngay.
3. Cây quyết định — nhu cầu khách hàng → gói
Script nội bộ của manager (dùng như checklist trên cuộc gọi, không phải quiz công khai trên web). Value driver của các nhánh — số lượng quy trình kinh doanh có thể tự động hóa / AI-nhân viên (xem ai-employee-catalog-2026.md), không phải số người dùng là người.
| Câu hỏi | Trả lời | → Gói đề xuất |
|---|---|---|
| Q1. Cần những kênh nào? | Chỉ chat trên website | Lite / Self-Service |
| Website + chat + e-commerce (CRM, messenger) | Self-Service / Managed | |
| Q2. Bao nhiêu quy trình kinh doanh sẽ tự động hóa? | 1 quy trình | Self-Service |
| 2–4 quy trình | Managed | |
| Q3. Chuỗi/nhượng quyền/multitenant/tích hợp phức tạp? | Có | Enterprise (ghi đè Q1/Q2 — xem quy tắc ưu tiên bên dưới) |
3.1. Cách sử dụng cây trên cuộc gọi
- Đặt Q1 → Q2 → Q3 đúng thứ tự này.
- Nếu trả lời Q3 là "có" (chuỗi, nhượng quyền, multitenant, tích hợp custom phức tạp) — điều này ghi đè lên câu trả lời Q1/Q2, ngay cả khi theo khối lượng kênh/quy trình khách hàng trông giống Self-Service. Độ phức tạp của tích hợp quan trọng hơn số lượng quy trình.
- Đề xuất gói cuối cùng được nói với khách hàng kèm theo điều kiện rõ ràng: "Đây là định hướng dựa trên những gì bạn vừa chia sẻ — giới hạn và giá chính xác chúng ta cùng xem trong Pricing Book" (không đưa đề xuất như giá cuối cùng trước mục 4).
- Các trường hợp biên (ví dụ, đúng ranh giới Managed/Enterprise) — xem Edge case "giữa Managed và Enterprise" trong Pricing Book (MKT-030-3, mục Enterprise Pricing Policy).
3.2. Edge case — khách hàng không khớp rõ ràng với kịch bản nào
Ví dụ: khách hàng chỉ muốn chat (Q1 → Lite/Self-Service), nhưng có chuỗi chi nhánh (Q3 → Enterprise). Quy tắc ưu tiên: Q3 luôn thắng — độ phức tạp tích hợp/multitenant quan trọng hơn số lượng quy trình hoặc kênh. Ngay cả yêu cầu chức năng tối thiểu từ chuỗi/nhượng quyền cũng được định tuyến vào Enterprise-discovery, không phải tier self-service — vì kiến trúc multitenant, billing theo chi nhánh và phân quyền truy cập đều cần cấu hình riêng, bất kể chi nhánh muốn tự động hóa gì vào lúc này.
4. Chuyển sang gói và giá
Sau cây quyết định (mục 3) — chuyển đến tier cụ thể theo Pricing Book (MKT-030-3):
- Tier và giá chỉ được nêu SAU KHI Impact (mục 2.1) đã được chuyển thành tiền — không sớm hơn. Quy tắc từ playbook cũ vẫn hiệu lực: "No pricing discussion without qualification."
- Nếu tier đề xuất là Enterprise, chuyển vào discovery-process của Enterprise Pricing Policy (mục tương ứng trong Pricing Book): discovery-câu hỏi → custom quote → SLA → triển khai. Giá KHÔNG được nêu như một con số cố định ở giai đoạn này — chỉ phạm vi sub-tier (Growth/Scale/Performance) và giải thích rằng giá chính xác là kết quả của discovery riêng.
- Neo vào ROI với mọi mức giá (xem mục 6 — ROI framing model, giữ nguyên từ playbook cũ như một kỹ thuật hiệu quả).
5. Positioning (điều chúng ta nói và không nói)
Giữ nguyên từ thực tiễn hiện có (SALES-RUNBOOK-2026.md, đã cập nhật theo tier):
Khi được hỏi "bạn làm gì?":
Chúng tôi giúp doanh nghiệp không bị mất lead và tăng conversion bằng cách sử dụng AI-nhân viên hoạt động 24/7 — từ AI-tư vấn trên website đến đội nhóm nhân viên số đầy đủ (bán hàng, marketing, phân tích, SEO).
Không nói:
- "Chúng tôi làm chatbot"
- "Chúng tôi bán AI-agent"
- "Chúng tôi tự động hóa tin nhắn"
Luôn:
- Bán AI-nhân viên với chức danh và phạm vi trách nhiệm (xem
ai-employee-catalog-2026.md), không phải "tính năng" trừu tượng - Gắn cuộc trò chuyện vào kết quả (lead bị mất, giờ làm thủ công, conversion), không phải chi tiết kỹ thuật
- Với tier self-service (Lite/Self-Service) — nhấn mạnh tốc độ triển khai ("từ đăng ký đến widget hoạt động trong một phiên"), không phải ROI-calculation từ mục 6 (cái đó dành cho Managed+/Enterprise discovery, nơi check lớn hơn và quyết định được cân nhắc kỹ hơn)
6. ROI Framing Model (cho giao dịch Managed/Enterprise)
Giữ nguyên từ sales_playbook_pricing_and_qualification_2026.md (mục 6) — kỹ thuật hiệu quả cho các giao dịch có check đủ lớn để cuộc trò chuyện ROI phù hợp (Managed $349+ trở lên, đặc biệt là Enterprise):
Ví dụ: doanh thu khách hàng $1M/năm ≈ $83K/tháng.
"Nếu chúng tôi tăng conversion của bạn 5% — điều đó có nghĩa là bao nhiêu tiền?"
Đưa khách hàng đến mức tự nêu con số (5% uplift ≈ +$4K/tháng trong ví dụ này), sau đó:
"Hệ thống của chúng tôi thường rẻ hơn doanh thu bổ sung mà nó tạo ra."
Không bao giờ tranh cãi trực tiếp về giá — đưa cuộc trò chuyện trở lại ROI. Với tier self-service, kỹ thuật này là thừa (xem mục 5) — ở đó khách hàng tự quyết định trong vài phút, không cần lập luận tài chính phức tạp.
7. Đóng giao dịch
| Loại giao dịch | Cách đóng |
|---|---|
| Lite / Self-Service | Khách hàng tự thanh toán qua conversational-onboarding — sales-manager không tham gia vào việc lập hóa đơn, chỉ hướng dẫn khách hàng và loại bỏ phản đối (Objection Handling, MKT-030-7). |
| Managed | Demo (MKT-030-5) → đề xuất → thống nhất chi tiết (chuyên viên phụ trách, tích hợp) → thanh toán bằng thẻ, như self-serve. |
| Enterprise | Discovery → custom quote (approval matrix, Pricing Book) → SLA → ký hợp đồng riêng → onboarding-specialist chuyển khách hàng tiếp theo Customer Journey (MKT-030-10). |
Next step sau khi đóng bất kỳ giao dịch nào: chuyển khách hàng sang onboarding với owner đã xác định (onboarding-specialist cho Managed/Enterprise, flow tự động cho Lite/Self-Service) — xem Customer Journey (MKT-030-10).
8. Disqualification lead (giữ từ playbook cũ, đã cập nhật)
Không lên lịch gọi với founder/senior sales nếu:
- Rõ ràng hoàn toàn không có ngân sách (không nhầm với "ngân sách thấp hơn Managed" — đây KHÔNG phải lý do từ chối, vì có Lite/Self-Service)
- "Chỉ muốn chatbot rẻ" mà không sẵn sàng tìm hiểu tự động hóa quy trình kinh doanh
- Không có mục tiêu kinh doanh rõ ràng ngay cả sau các câu hỏi Pain/Impact ở mục 2
Điểm khác biệt quan trọng so với playbook cũ: ngưỡng revenue ≥$1M không còn là tiêu chí disqualification chung — điều đó chỉ đúng với mô hình high-ticket-only cũ. Các tier self-service (Lite/Self-Service/Managed) được thiết kế đặc biệt cho khách hàng dưới ngưỡng này. Ngưỡng revenue ≥$1M vẫn còn phù hợp CHỈ như định hướng phân khúc Enterprise (sub-tier Growth bắt đầu từ $1M, xem Pricing Book).
Tài liệu được quản lý bởi task riêng MKT-030-4. Thay đổi cây gói — chỉ theo sau cập nhật Pricing Book (MKT-030-3), không độc lập.