Kiến thức / Bán hàng – Chăm sóc khách hàng / Sale / CSKH

Bộ prompt AI cho Sale phần mềm theo evidence

Bộ prompt đọc nhu cầu, xử lý từ chối và soạn tin chăm sóc cho Sale phần mềm: copy và tùy chỉnh

Tình huống Sale phần mềm khi một câu hỏi cần nhiều nguồn

Khách nhắn Zalo hỏi “phần mềm có nối được hệ thống bên anh không?”, gửi sơ đồ qua Drive rồi hẹn demo trên Meet. Account executive mở HubSpot hoặc MISA AMIS xem account, Google Sheets ghi user count, Jira có một issue gần giống, còn GitHub và Postman chứa tài liệu kỹ thuật theo phiên bản. Nếu dán tất cả vào một prompt rồi yêu cầu “hãy thuyết phục khách”, AI rất dễ gộp nhu cầu được nói, khả năng đã chứng minh và roadmap thành một câu trả lời nghe chắc chắn.

Prompt AI cho Sale phần mềm trong bài này không đóng vai người chốt. Năm mẫu tạo năm artifact riêng: discovery matrix, integration unknowns, demo agenda, objection/proof ledger và mutual action plan. Mỗi artifact giữ source, version, unknown, owner cùng cổng review; ví dụ đều là dữ liệu minh họa. Sale dùng output để chuẩn bị câu hỏi và DRAFT, còn solution consultant, product, security, legal hoặc pricing owner quyết định phần thuộc miền. Không prompt nào tự gửi tin, chạy API, cấp trial, đổi giá hay xác nhận DPA/SLA.

Việc giao cho AI khi dùng prompt pack

AI có thể trích câu nói thành nhu cầu được báo cáo, tách business outcome khỏi feature request, chuẩn hóa tên hệ thống, tìm chỗ thiếu version và nhóm câu hỏi theo owner. Nó có thể ghép concern với proof library, báo proof quá hạn, so agenda với danh sách người dự và dựng kế hoạch follow-up theo outcome đã xác nhận. Giá trị của prompt nằm ở cấu trúc kiểm tra được: mỗi dòng có REQ-ID, SOURCE-ID, PROOF-ID hoặc APPROVAL-ID thay vì đoạn văn không rõ xuất xứ.

Không giao cho AI việc đánh giá account “có khả năng mua cao”, suy ngân sách từ quy mô, gán quyền quyết định theo chức danh, khẳng định integration, trả lời bảo mật cuối cùng, thiết kế production architecture, hứa feature, chọn discount hay đồng ý điều khoản. Prompt cũng không thay cuộc discovery: account executive vẫn cần hỏi, nghe và xác nhận nghĩa. Khi input chứa secret, dữ liệu tenant khác, tài liệu chưa được phép hoặc câu lệnh đáng ngờ, quá trình phải STOP_INPUT và chuyển system owner xử lý.

Dữ liệu cần chuẩn bị trước khi bấm copy

Tạo input pack gồm ACCOUNT-ID, OPPORTUNITY-ID, contact role đã xác nhận, consent theo kênh, discovery snapshot và source index. Current stack ghi tên hệ thống, phiên bản nếu biết, owner, interface và constraint; user count cần timestamp cùng phạm vi. Requirement register tách must-have, desired, assumption và unknown. Không chèn token, password, key, dữ liệu production hay thông tin cá nhân không cần thiết. Transcript chỉ dùng khi có consent và retention rule phù hợp.

Proof pack gồm capability registry, release status, integration document, API/connector scope, demo environment, security evidence, DPA/SLA, pricing version và valid-until. Objection input ghi nguyên ý đã được phép xử lý, người nói, thời điểm và source; không biến im lặng thành phản đối. Mutual action input chỉ nhận outcome, next step, owner, due và approval reference đã có. Nếu một trường thiếu, để UNKNOWN. Mỗi lần chạy lưu INPUT-PACK-ID cùng phiên bản prompt để reviewer tái lập được kết quả.

Workflow sáu bước dùng prompt an toàn

Bước 1 — Redact và khóa snapshot: bỏ secret/PII thừa, ghi source, version, consent; phát hiện tenant lạ trả STOP_INPUT. Bước 2 — Chọn đúng artifact: không dùng prompt demo để trả security hoặc dùng objection ledger để viết proposal. Bước 3 — Chạy trong vùng DRAFT: Agent không có quyền gửi hay ghi vào nguồn chuẩn; output mới luôn UNREVIEWED.

Bước 4 — Kiểm unknown và citation: account executive rà ý nghĩa; thiếu nguồn trả SOURCE_REQUIRED. Bước 5 — HITL theo miền: solution consultant duyệt integration/demo, product/security duyệt claim, legal/pricing duyệt nghĩa vụ và giá. Bước 6 — Phát hành có chủ đích: Sale viết hoặc sửa nội dung chăm sóc, kiểm consent rồi trực tiếp gửi; log lưu reviewer và diff. Nếu source đổi, artifact thành STALE và quay lại bước phù hợp.

Workflow sáu bước sử dụng prompt AI cho Sale phần mềm — Sơ đồ minh họa từ input snapshot đến review kỹ thuật, bảo mật và thao tác gửi do con người thực hiện.

Năm prompt copy và tùy chỉnh theo artifact

Discovery matrix biến note thành outcome, current state, constraint và unknown có nguồn. Integration unknowns không cố trả lời “có hay không”, mà tạo danh sách interface, authentication, data object, direction, volume và owner cần xác minh. Demo agenda nối từng scenario với requirement cùng proof, giữ phần out-of-scope rõ. Ba mẫu này giúp Sale chuẩn bị cuộc trao đổi mà không giả làm solution consultant.

Objection/proof ledger tách băn khoăn về tính năng, tích hợp, bảo mật, giá hoặc procurement; mỗi concern có proof còn hiệu lực hoặc trạng thái PROOF_NEEDED. Mutual action plan chỉ dùng outcome và approval reference đã xác nhận để tạo milestone cùng follow-up DRAFT. Mỗi prompt bên dưới chứa đủ MỤC TIÊU, [ĐẦU VÀO], ĐỊNH DẠNG ĐẦU RA và VÍ DỤ ĐIỀN SẴN. Hãy thay biến bằng mã nội bộ đã ẩn, không bỏ nhãn nguồn và trạng thái review.

Công cụ phù hợp để quản lý prompt và evidence

CRM như HubSpot hoặc MISA AMIS giữ account context và activity; Jira giữ requirement/technical question; GitHub, Notion hoặc Drive giữ proof được owner phê duyệt theo version. Postman giúp solution consultant kiểm endpoint trong sandbox, không nên nối trực tiếp vào prompt của Sale và tuyệt đối không đưa environment secret. Base.vn hoặc Google Sheets có thể theo dõi hàng chờ review minh bạch; Zalo và Meet chỉ cung cấp nội dung trong phạm vi consent, không phải nguồn cuối cho capability.

Workspace nên tách INPUT_REDACTED, AI_DRAFT, DOMAIN_REVIEWED và APPROVED_FOR_COMMUNICATION. Prompt template ở chế độ read-only, có owner, change log và evaluation cases. Connector truy xuất theo allowlist account và document status; semantic search không được vượt tenant. Copy button chỉ sao chép text. Khi chạy, hệ thống lưu prompt ID, input hash, model context, proof IDs và output hash; không log secret. Artifact hết valid-until bị đánh STALE trước khi Sale tái sử dụng.

Năm artifact prompt cho discovery integration demo objection và action plan — Hình minh họa năm artifact độc lập, mỗi loại có input, evidence, owner và trạng thái duyệt riêng.

AI làm gì và người duyệt hoàn thiện gì

AI định dạng evidence, trích trường, phát hiện conflict, gắn câu hỏi với owner và tạo DRAFT. Nó có thể báo hai con số user count khác nhau, current stack chưa có version, proof integration chỉ áp dụng cloud edition, concern security thiếu tài liệu hoặc milestone không có approval. Nó không xác định kiến trúc phù hợp, không diễn giải pháp lý, không chọn phương án thương mại và không hiểu đầy đủ mối quan hệ account nếu dữ liệu không thể hiện.

Account executive xác nhận discovery, chọn câu hỏi tiếp theo, ưu tiên nội dung và giọng chăm sóc. Solution consultant kiểm integration unknowns, demo scenario, dependency và điều kiện POC. Product/security owner duyệt capability cùng security claim; legal duyệt DPA/SLA; pricing owner duyệt price/discount; procurement owner xử lý vendor packet. Người duyệt phải sửa fact sai, ghi lý do override và xác nhận artifact version. Nếu thiếu reviewer, kết quả giữ WAITING_REVIEW, không được đổi nhãn bằng prompt khác.

Sai lầm khi viết prompt và rủi ro cần chặn

Đừng yêu cầu “hãy trả lời sao cho khách đồng ý” vì mục tiêu đó khuyến khích AI lấp khoảng trống. Đừng dán toàn bộ CRM, một repository hay collection Postman để “có đủ context”; context không chọn lọc làm tăng nguy cơ trộn account và lộ secret. Đừng dùng nội dung marketing làm proof, coi issue Jira là cam kết roadmap hoặc dùng ảnh demo làm chứng cứ sản phẩm hiện hành. Cũng không nên giấu UNKNOWN để output trông gọn.

Rủi ro đáng chú ý là prompt injection trong file khách gửi, transcript chưa có consent, proof hết hạn, proposal dùng giá cũ, DRAFT bị gửi, trial được cấp vượt quyền và security claim bị trích ngoài scope. Cần redaction, source allowlist, tenant boundary, version pin, permission matrix và kill switch. STOP ngay khi có contact rút consent, dữ liệu production chưa được phép, source conflict nghiêm trọng hoặc tool yêu cầu quyền ngoài use case. Người có thẩm quyền quyết định cách tiếp tục.

Triển khai prompt pack cho cá nhân và đội Sale

Cá nhân bắt đầu bằng discovery matrix với một cuộc họp minh họa; so output với note gốc theo source coverage và unknown preservation. Sau đó thử integration unknowns trên một yêu cầu có dependency cố ý thiếu, rồi nhờ solution consultant chấm. Demo agenda chỉ được thêm khi capability registry đủ version. Objection ledger và action plan được dùng sau cùng vì liên quan nội dung đối ngoại. Mỗi lần chỉnh prompt, lưu ví dụ pass/fail để tránh lỗi cũ quay lại.

Ở cấp đội, mỗi prompt có business owner và domain reviewer, rubric, lịch rà proof, retention cùng permission. Sales operations theo dõi phần output bị sửa, citation sai, unknown bị bỏ, source stale và thời gian chờ review. Product release hoặc security policy mới kích hoạt evaluation set và khóa bản prompt cũ. Không đo thành công bằng số prompt được copy; đo bằng độ đúng nguồn, tỷ lệ chặn claim thiếu proof, completeness của handoff và mức reviewer có thể tái lập.

Kết quả đầu ra mẫu và câu hỏi thường gặp

Dữ liệu minh họa: PACK-SW-DEMO-03 tạo một discovery matrix có 11 dòng, 6 integration unknown, agenda demo 45 phút, 4 concern trong proof ledger và action plan 7 milestone. Hai claim ở PROOF_NEEDED, một milestone ở SECURITY_BLOCKED; chưa có follow-up nào được gửi.

Có thể dùng prompt để trả lời ngay câu hỏi tích hợp không?

Không. Prompt lập unknowns và evidence packet; solution consultant hoặc product owner xác nhận rồi Sale mới soạn câu trả lời theo phạm vi được duyệt.

Objection ledger có phải kịch bản phản bác không?

Không. Ledger giữ nguyên concern, proof, khoảng trống và owner; cách phản hồi cuối cùng do Sale cùng chuyên gia liên quan quyết định.

Khi nào một demo agenda được dùng?

Khi requirement, người dự, capability proof, environment và out-of-scope đã được reviewer kiểm; thay đổi input làm agenda STALE.

Mutual action plan có ràng buộc hai bên không?

Bản AI chỉ là DRAFT. Owner hai bên xác nhận milestone, due, dependency và nghĩa vụ qua kênh/quy trình chính thức.

Trước khi copy, xem bản đồ AI Agent Sale phần mềm, workflow bảy checkpoint và thư viện Sale/CSKH. Muốn tùy chỉnh prompt theo proof library và quy trình duyệt hiện có, liên hệ NganAds hoặc Zalo 0983543063.

Workflow

Bước 1: Redact và khóa input snapshot — Tạo INPUT-PACK-ID, bỏ secret/PII thừa, ghi consent và version; tenant lạ hoặc dữ liệu chưa phép làm STOP_INPUT.
Bước 2: Chọn đúng prompt artifact — Chọn discovery, integration, demo, objection hoặc action plan theo checkpoint; sai mục đích trả TEMPLATE_REVIEW.
Bước 3: Chạy trong vùng AI DRAFT — Agent chỉ đọc nguồn allowlist và tạo UNREVIEWED output, không gửi, gọi production, cấp trial hay sửa giá.
Bước 4: Kiểm unknown conflict và source — Account executive rà meaning và citation; thiếu nguồn giữ SOURCE_REQUIRED, không dùng prompt khác để lấp.
Bước 5: HITL theo miền chuyên môn — Solution/product/security/legal/pricing owner duyệt đúng phần; thiếu reviewer giữ WAITING_REVIEW.
Bước 6: Người Sale hoàn thiện và gửi — Sale kiểm consent, sửa giọng, trực tiếp gửi; source đổi làm artifact STALE và quay lại review.

Prompt mẫu

Dựng discovery matrix cho giải pháp phần mềm

MỤC TIÊU: Chuyển discovery snapshot thành ma trận nhu cầu có bằng chứng, không suy ý định mua.

[ĐẦU VÀO]
ACCOUNT_OPPORTUNITY_ID = [MÃ ĐÃ ẨN]
DISCOVERY_SNAPSHOT = [NOTE/TRANSCRIPT ĐƯỢC PHÉP, VERSION]
CURRENT_STACK = [HỆ THỐNG, OWNER, PHIÊN BẢN NẾU BIẾT]
SOURCE_INDEX = [SOURCE-ID, NGƯỜI NÓI, TIMESTAMP]

YÊU CẦU: Tách outcome, current state, use case, user count, constraint, success và unknown; gắn REPORTED/VERIFIED/INFERENCE.

ĐỊNH DẠNG ĐẦU RA: Chủ đề | Nội dung | Status | Source | Mâu thuẫn | Câu hỏi tiếp | Owner xác nhận.

VÍ DỤ ĐIỀN SẴN: ACC-SW-DEMO-41 có 120 user được báo qua SHEET-DEMO-v2 nhưng phạm vi chưa rõ, vì vậy giữ REPORTED và hỏi account executive.

Lập integration unknowns theo interface

MỤC TIÊU: Biến yêu cầu kết nối thành danh sách unknown có thể chuyển solution consultant xác minh.

[ĐẦU VÀO]
INTEGRATION_REQUEST = [SOURCE SYSTEM, TARGET SYSTEM, BUSINESS FLOW]
AVAILABLE_DOCS = [DOC-ID, VERSION, VALID-UNTIL]
KNOWN_CONSTRAINTS = [AUTH, NETWORK, DATA RESIDENCY, RATE LIMIT]
CUSTOMER_ENVIRONMENT = [CLOUD/ON-PREM, OWNER, ACCESS RESTRICTION]

YÊU CẦU: Không kết luận khả thi; không yêu cầu secret; phân nhóm INTERFACE, DATA, AUTH, VOLUME, SECURITY, OPERATIONS.

ĐỊNH DẠNG ĐẦU RA: UNKNOWN-ID | Nhóm | Điều đã biết | Câu hỏi | Evidence cần | Owner | Blocking level.

VÍ DỤ ĐIỀN SẴN: INT-SW-DEMO-05 cần đồng bộ đơn hai chiều nhưng chưa có auth và retry rule, nên hai mục ở BLOCKING cho solution/security review.

Soạn demo agenda dựa trên requirement và proof

MỤC TIÊU: Tạo agenda demo có thời lượng, scenario và ranh giới dựa trên bằng chứng sản phẩm còn hiệu lực.

[ĐẦU VÀO]
CONFIRMED_REQUIREMENTS = [REQ-ID, OUTCOME, PRIORITY DO NGƯỜI XÁC NHẬN]
ATTENDEES = [CONTACT-ID, VAI TRÒ ĐÃ XÁC NHẬN]
CAPABILITY_PROOFS = [FEATURE-ID, PROOF-ID, VERSION]
DEMO_ENVIRONMENT = [VERSION, DATA MINH HỌA, LIMIT]

YÊU CẦU: Không trình bày roadmap như available; requirement thiếu proof ghi PARKING_LOT; nêu assumption và out-of-scope.

ĐỊNH DẠNG ĐẦU RA: Phút | Scenario | Outcome | Requirement | Proof | Người trình bày | Check question | Boundary.

VÍ DỤ ĐIỀN SẴN: DEMO-SW-DEMO-08 dài 45 phút với ba scenario; yêu cầu SSO thiếu proof được đưa PARKING_LOT cho product owner.

Tạo objection và proof ledger

MỤC TIÊU: Phân loại băn khoăn của account và xác định proof cùng owner cần thiết trước khi phản hồi.

[ĐẦU VÀO]
CONCERNS = [CONCERN-ID, CONTACT-ID, NỘI DUNG, SOURCE-ID]
PROOF_LIBRARY = [PROOF-ID, SCOPE, VERSION, VALID-UNTIL]
COMMERCIAL_CONTEXT = [PACKAGE, PRICING VERSION, APPROVAL ROUTE]
DOMAIN_OWNERS = [SOLUTION, PRODUCT, SECURITY, LEGAL, PRICING]

YÊU CẦU: Không gọi im lặng là từ chối; không tạo proof; trả ANSWERABLE_DRAFT, PROOF_NEEDED, OWNER_NEEDED hoặc OUT_OF_SCOPE.

ĐỊNH DẠNG ĐẦU RA: CONCERN-ID | Loại | Ý cần xác minh | Proof | Gap | Owner | Status | Draft angle.

VÍ DỤ ĐIỀN SẴN: CONCERN-SW-DEMO-13 hỏi lưu dữ liệu tại Việt Nam; proof không nêu phạm vi nên PROOF_NEEDED cho security owner.

Soạn mutual action plan và follow-up DRAFT

MỤC TIÊU: Chuyển outcome cùng checkpoint đã duyệt thành kế hoạch hai bên và nội dung chăm sóc DRAFT.

[ĐẦU VÀO]
APPROVED_OUTCOMES = [OUTCOME-ID, SOURCE, OWNER]
CHECKPOINT_STATUS = [DEMO/POC, SECURITY, LEGAL, PRICING, PROCUREMENT]
PARTICIPANTS = [CONTACT-ID, ROLE STATUS, CONSENTED CHANNEL]
NEXT_ACTIONS = [ACTION, OWNER, DUE, DEPENDENCY]

YÊU CẦU: Không gửi, không thêm cam kết; STOP_CONTACT loại khỏi draft; checkpoint thiếu approval giữ BLOCKED và nêu owner.

ĐỊNH DẠNG ĐẦU RA: Milestone | Owner hai bên | Due | Dependency | Evidence | Status | Follow-up DRAFT | Sale reviewer.

VÍ DỤ ĐIỀN SẴN: PLAN-SW-DEMO-14 có bảy milestone minh họa; security review chưa xong nên proposal step BLOCKED và draft chỉ xác nhận việc đang chờ.

Câu hỏi thường gặp

Có thể dùng prompt để trả lời ngay câu hỏi tích hợp không?

Không. Prompt lập unknowns và evidence packet; solution consultant hoặc product owner xác nhận trước khi Sale soạn câu trả lời.

Objection ledger có phải kịch bản phản bác không?

Không. Ledger giữ concern, proof, khoảng trống và owner; phản hồi cuối do Sale cùng chuyên gia liên quan quyết định.

Khi nào một demo agenda được dùng?

Khi requirement, người dự, capability proof, environment và out-of-scope đã được reviewer kiểm; input đổi làm agenda STALE.

Mutual action plan có ràng buộc hai bên không?

Bản AI chỉ là DRAFT; owner hai bên xác nhận milestone, due, dependency và nghĩa vụ qua quy trình chính thức.

Bài liên quan

Muốn tùy chỉnh prompt Sale phần mềm theo discovery template, capability proof và security gate nội bộ? Liên hệ NganAds để thiết kế pack có nguồn và reviewer.