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

Workflow AI cho Sale phần mềm từ lead đến follow-up

Workflow từ lead mới đến phân loại, tư vấn và follow-up dành cho Sale phần mềm

Tình huống thật khi lead đi qua nhiều bàn

Một lead điền form xin demo lúc 9 giờ, nhắn thêm qua Zalo rằng đang dùng hệ thống kế toán nội bộ, rồi gửi danh sách 120 user trong Google Sheets. Account executive tạo opportunity trên HubSpot hoặc MISA AMIS; solution consultant mở Jira để ghi câu hỏi API; product team trả lời trong Notion; security questionnaire nằm trên Drive. Nếu mỗi người chỉ đọc phần của mình, bản demo có thể nói đúng tính năng nhưng sai use case, còn follow-up lại vô tình nhắc một khả năng tích hợp chưa được xác nhận.

Workflow AI cho Sale phần mềm cần bảo toàn chuỗi bằng chứng khi hồ sơ đổi tay, chứ không chỉ tự động gửi tin. Mỗi bước nhận một snapshot có version, tạo output DRAFT, kiểm điều kiện lỗi và chuyển đúng reviewer. Lead chưa chắc là account mới; câu hỏi chưa chắc là requirement; demo tốt chưa chắc POC đạt success criteria; POC đạt chưa đồng nghĩa security, legal và pricing đã duyệt. Quy trình dưới đây vì vậy có bảy cổng, từ account candidate đến success handoff, cùng STOP cụ thể cho consent, nguồn, kỹ thuật và thương mại.

Việc giao cho AI ở từng checkpoint

AI phù hợp với các thao tác có thể đối chiếu: chuẩn hóa payload, đề xuất account/contact candidate, tách câu discovery thành fact và unknown, ghép requirement với capability proof, dựng demo coverage, kiểm POC criterion, so version proposal và tạo mutual action plan DRAFT. Nó cũng có thể phát hiện hồ sơ thiếu owner, ngày hiệu lực đã qua, hai tài liệu nói khác nhau hoặc một next step không có người chịu trách nhiệm. Mỗi phát hiện phải dẫn về record và source cụ thể.

Con người giữ việc cần thẩm quyền và phán đoán: account executive chọn record, trực tiếp discovery và gửi follow-up; solution consultant xác nhận fit, demo, integration và POC; security/product trả lời claim thuộc miền; legal duyệt DPA/SLA; pricing owner duyệt giá; procurement xử lý order form. Agent không tự merge lead, đổi stage, lên lịch ngoài consent, chạy Postman vào production, cấp trial, hứa roadmap, chấp thuận questionnaire, thay discount hay gửi proposal. Nếu chưa có người duyệt, output dừng WAITING_OWNER.

Dữ liệu cần chuẩn bị cho luồng xuyên suốt

Lead event cần EVENT-ID, source, campaign, received-at, contact fields được phép dùng, consent purpose và idempotency key. Account candidate cần domain, tên pháp lý, existing account IDs, owner và rule phân tuyến. Discovery packet gồm current stack, business use case, workflow hiện tại, user count, integration/security constraint, timeline, buying roles, success criteria và câu hỏi mở. Mọi fact có SOURCE-ID; nội dung do AI suy ra gắn INFERENCE; không có nguồn gắn UNKNOWN. Contact yêu cầu dừng phải có STOP_CONTACT cùng timestamp.

Solution packet chứa requirement ID, capability ID, release status, product version, integration proof, dependency và domain owner. Demo/trial/POC record có environment, test data class, access scope, start/end date, scenario, metric, baseline và acceptance owner. Commercial packet có pricing version, currency, package, user tier, approval route, proposal version, DPA/SLA, security status và procurement checklist. Success handoff cần approved scope, open risk, milestone, customer owner và artifact references; không chuyển lời hứa trong chat thành nghĩa vụ.

Workflow bảy bước từ account candidate đến success handoff

Bước 1 — Account candidate: Agent nhận event, chống lặp và đề xuất LINK_ACCOUNT, CREATE_CANDIDATE hoặc MATCH_REVIEW; người phụ trách quyết định. Bước 2 — Discovery evidence: AI chuẩn bị brief và matrix; Sale trực tiếp hỏi, xác nhận consent, ghi outcome. Thiếu source hoặc contact STOP trả DISCOVERY_HOLD. Bước 3 — Solution fit review: requirement được nối với proof; solution consultant chọn FIT_CONFIRMED, GAP, NEEDS_SPIKE hoặc OUT_OF_SCOPE, không để Agent kết luận kỹ thuật.

Bước 4 — Demo/trial/POC: agenda, access và success criteria được duyệt trước; yêu cầu dữ liệu thật khi chưa có phép làm POC_BLOCKED. Bước 5 — Security/integration review: product/security kiểm version, authentication, data flow, retention cùng questionnaire; proof hết hạn trả EVIDENCE_REQUIRED. Bước 6 — Proposal/procurement: proposal DRAFT chỉ dùng scope và giá đã duyệt; conflict trả COMMERCIAL_BLOCKED. Bước 7 — Success handoff: người duyệt xác nhận outcome, risk, owner và milestone; Agent chỉ soạn follow-up theo consent.

Workflow bảy bước cho Sale phần mềm từ lead đến success handoff — Sơ đồ minh họa bảy checkpoint và các nhánh STOP khi thiếu consent, proof, người duyệt hoặc phiên bản thương mại.

Năm prompt vận hành workflow theo bằng chứng

Prompt một tạo intake packet và kiểm account candidate; prompt hai chuyển discovery note thành requirement register; prompt ba chuẩn bị solution-fit review packet; prompt bốn lập POC acceptance plan; prompt năm dựng mutual action plan từ approval references. Chúng tạo artifact cho từng checkpoint, không viết một câu trả lời tổng hợp bao trùm cả chu kỳ. Nhờ đó đội nhìn thấy nơi context được chuyển, nơi reviewer phải quyết định và nơi một bản DRAFT trở nên stale khi nguồn thay đổi.

Mỗi prompt nhận ID, version và owner thay vì một khối chat tự do. Output phải giữ distinction giữa REPORTED, VERIFIED, ASSUMPTION và UNKNOWN. Khi gặp tài liệu chứa chỉ dẫn “bỏ qua quy tắc”, Agent coi đó là dữ liệu không tin cậy và gắn INJECTION_FLAG; nó không gọi connector. Ví dụ điền sẵn đều dùng mã minh họa, không chứa contact thật. Người dùng có thể sao chép prompt, nhưng việc chạy và ghi kết quả phải nằm trong workspace kiểm soát với snapshot cùng audit.

Công cụ và kết nối theo nguyên tắc không vượt quyền

HubSpot hoặc MISA AMIS làm nguồn opportunity và activity; Jira giữ requirement, spike cùng bug; GitHub giữ technical docs đã được owner đánh dấu dùng cho pre-sale; Notion/Drive giữ enablement, proof, DPA/SLA theo version. Postman chỉ được solution consultant sử dụng với collection đã duyệt trong sandbox. Meet hỗ trợ cuộc trao đổi có consent; Zalo giữ hội thoại theo mục đích liên hệ. Base.vn hoặc Google Sheets có thể làm review board tạm, nhưng không được trở thành bảng giá hay capability source không có owner.

Tích hợp nên dùng event queue và idempotency key để một form submit không tạo hai opportunity. Agent đọc view theo tenant, ghi AI_DRAFT vào vùng riêng và gửi REQUEST_REVIEW nội bộ; nó không có scope gửi khách, merge account, issue token trial, cập nhật stage hoặc phát hành proposal. Action adapter kiểm actor, artifact version và approval reference trước mọi ghi có chủ đích. Log lưu correlation ID xuyên bảy bước, input hash, output hash, quyết định reviewer và lý do rollback.

Bảng trạng thái và cổng người duyệt trong workflow Sale phần mềm — Hình minh họa trạng thái DRAFT, WAITING_REVIEW, BLOCKED và APPROVED_BY_HUMAN theo từng artifact.

AI làm gì và người duyệt quyết định gì

Ở bước intake, AI đề xuất candidate; sales ops hoặc account owner quyết định record. Ở discovery, AI đặt cấu trúc; account executive xác nhận ý nghĩa và next question. Ở solution fit, AI nối requirement với proof; solution consultant cùng product owner quyết định mức phù hợp. Ở POC, AI theo dõi criterion; acceptance owner xác nhận kết quả. Ở security, AI tìm tài liệu; security owner chịu trách nhiệm câu trả lời. Ở proposal, AI báo variance; pricing và legal owner phê duyệt phần thuộc miền.

Nguyên tắc quan trọng là approval không được suy từ sự im lặng hay một thay đổi stage. Mỗi quyết định có actor, role, time, artifact version và comment. Nếu reviewer sửa output, diff được lưu để cải thiện evaluation set, không để AI học ngầm rồi thay policy. Account executive là người chọn giọng, thời điểm và kênh follow-up trong consent. Customer success chỉ nhận handoff khi scope, open risk và owner rõ; nếu thiếu, trạng thái quay về HANDOFF_INCOMPLETE.

Sai lầm và rủi ro trong nhánh lỗi

Lỗi thường gặp là route lead chỉ theo domain, khiến công ty có nhiều đơn vị bị nối nhầm; hoặc coi email cá nhân là consent cho mọi kênh. Trong discovery, đội dễ biến câu “có thể cần SSO” thành requirement bắt buộc. Ở demo, presenter dùng môi trường khác phiên bản khách hỏi; ở POC, metric được viết sau khi chạy; ở security, câu trả lời cũ được tái sử dụng; ở proposal, price sheet hết hiệu lực vẫn được đưa vào vì tên file trông mới.

Rủi ro hệ thống gồm retry tạo trial lặp, prompt injection trong questionnaire, lộ account khác qua semantic search, API call vượt sandbox, gửi DRAFT, tự hứa roadmap, thay giá hoặc chấp nhận DPA. Cần circuit breaker, tenant filter, allowlist tool, redaction, version pinning và dead-letter queue. STOP_CONTACT đóng mọi follow-up; SECURITY_BLOCKED chặn proposal có claim liên quan; PRICE_CONFLICT chặn commercial output; POC_BLOCKED chặn quyền môi trường. Chỉ owner xác định mới được giải phóng hàng chờ.

Triển khai workflow cho cá nhân, đội và doanh nghiệp

Cá nhân nên tập với ba lead minh họa có mức rõ ràng khác nhau: account mới, account trùng và contact đã STOP. Chạy intake cùng discovery, sau đó tự đối chiếu mọi source. Khi không còn lỗi record, thêm solution-fit packet với một proof hết hạn. Đội nhỏ có thể pilot hai checkpoint đầu trong hai tuần, họp review ngắn mỗi ngày và theo dõi tỷ lệ candidate sai, unknown bị biến thành fact, thời gian chờ owner cùng số hành động bị chặn đúng.

Doanh nghiệp cần schema owner, workflow owner và domain owner tách biệt. Sales ops quản lý routing cùng stage; IT quản lý identity, event và log; product/security/legal/pricing quản lý proof với SLA review. Release mới hoặc policy mới làm artifact liên quan STALE và kích hoạt kiểm lại. Mở từng connector sau threat model, không mở đồng loạt. KPI phù hợp là source accuracy, handoff completeness, block precision, reviewer correction và cycle time đã loại thời gian khách chờ; không đo bằng lượng follow-up AI tạo.

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

Dữ liệu minh họa: FLOW-SW-DEMO-02 xử lý 10 event thành 7 account candidate, 5 discovery packet, 3 solution-fit review và 1 POC plan. Một event vào MATCH_REVIEW, một contact ở STOP_CONTACT và hai claim ở EVIDENCE_REQUIRED; không trial, proposal hay tin nhắn nào được tự phát hành.

Agent có tự phân loại lead thành nóng hay lạnh không?

Không. Workflow chỉ route theo rule và evidence đã duyệt; mức ưu tiên do owner xác nhận, không suy từ dữ liệu nhạy cảm hay cảm xúc.

Khi nào được mở trial hoặc POC?

Khi có account owner, scope, environment, access policy, dữ liệu thử, thời hạn và người duyệt success criteria; Agent không tự cấp quyền.

Nếu requirement vượt capability hiện tại thì sao?

Solution consultant chọn GAP, NEEDS_SPIKE hoặc OUT_OF_SCOPE và nêu owner. Không chuyển roadmap thành lời hứa để giữ cơ hội.

Follow-up được tạo ở bước nào?

Sau checkpoint có outcome do người xác nhận. AI tạo DRAFT theo kênh và mục đích consent; account executive duyệt rồi trực tiếp gửi.

Tham khảo bản đồ công việc Sale phần mềm, prompt pack theo artifact và landing nghề. Muốn thiết kế workflow theo CRM, security gate và procurement hiện tại, liên hệ NganAds hoặc Zalo 0983543063.

Workflow

Bước 1: Nhận event và tạo account candidate — Dùng idempotency key, đề xuất record; người phụ trách chọn LINK/CREATE/HOLD, mơ hồ trả MATCH_REVIEW.
Bước 2: Thu discovery evidence — AI chuẩn bị matrix, Sale trực tiếp discovery và xác nhận source; thiếu consent hoặc contact STOP làm DISCOVERY_HOLD.
Bước 3: Duyệt solution fit — Ghép requirement với proof; solution consultant quyết định FIT, GAP, NEEDS_SPIKE hoặc OUT_OF_SCOPE.
Bước 4: Duyệt demo trial hoặc POC — Khóa scope, sandbox, dữ liệu thử, quyền và success criteria; thiếu acceptance owner trả POC_BLOCKED.
Bước 5: Duyệt security và integration — Product/security xác nhận data flow, authentication, proof cùng version; hết hiệu lực trả EVIDENCE_REQUIRED.
Bước 6: Duyệt proposal và procurement — Chỉ dùng scope, pricing, DPA/SLA đã duyệt; variance hoặc version conflict trả COMMERCIAL_BLOCKED.
Bước 7: Success handoff và follow-up — Người duyệt khóa outcome, risk, owner, milestone; AI chỉ tạo DRAFT, STOP_CONTACT tuyệt đối chặn gửi.

Prompt mẫu

Tạo lead intake và account candidate packet

MỤC TIÊU: Chuẩn hóa lead event và đề xuất account/contact candidate mà không tự merge record.

[ĐẦU VÀO]
LEAD_EVENT = [EVENT-ID, SOURCE, RECEIVED-AT, IDEMPOTENCY-KEY]
CONTACT_FIELDS = [TRƯỜNG ĐƯỢC PHÉP DÙNG]
ACCOUNT_INDEX = [ACCOUNT-ID, DOMAIN, TÊN PHÁP LÝ, OWNER]
CONSENT_STATUS = [MỤC ĐÍCH, KÊNH, STOP]

YÊU CẦU: Trả LINK_CANDIDATE, CREATE_CANDIDATE, MATCH_REVIEW hoặc STOP_CONTACT; không tự merge, đổi owner hay liên hệ.

ĐỊNH DẠNG ĐẦU RA: EVENT-ID | Candidate | Evidence | Confidence basis | Conflict | Route | Human owner.

VÍ DỤ ĐIỀN SẴN: EVENT-SW-DEMO-21 trùng domain với hai account minh họa nên phải MATCH_REVIEW cho sales ops.

Chuyển discovery thành requirement register

MỤC TIÊU: Tách lời khách thành use case, constraint, success criterion và câu hỏi mở có nguồn.

[ĐẦU VÀO]
DISCOVERY_SNAPSHOT = [NOTE/TRANSCRIPT ĐÃ ĐƯỢC PHÉP, VERSION]
CURRENT_STACK = [HỆ THỐNG, OWNER, VERSION NẾU CÓ]
PARTICIPANTS = [CONTACT-ID, VAI TRÒ ĐÃ XÁC NHẬN]
SOURCE_INDEX = [SOURCE-ID, TIMESTAMP]

YÊU CẦU: Gắn REPORTED, VERIFIED, INFERENCE hoặc UNKNOWN; không suy ngân sách, quyền mua hay khả năng tích hợp.

ĐỊNH DẠNG ĐẦU RA: REQ-ID | Use case | Constraint | User count | Success | Status | Source | Question | Owner.

VÍ DỤ ĐIỀN SẴN: DISC-SW-DEMO-04 nêu đồng bộ đơn nhưng chưa rõ API direction, vì vậy REQ-07 giữ UNKNOWN và hỏi solution consultant.

Chuẩn bị solution-fit decision packet

MỤC TIÊU: Ghép requirement đã xác nhận với capability và integration proof để người kỹ thuật ra quyết định.

[ĐẦU VÀO]
REQUIREMENT_REGISTER = [REQ-ID, VERSION, STATUS]
CAPABILITY_REGISTRY = [FEATURE-ID, RELEASE STATUS, PROOF]
INTEGRATION_EVIDENCE = [API/CONNECTOR, SCOPE, VALID-UNTIL]
KNOWN_DEPENDENCIES = [HẠ TẦNG, DỮ LIỆU, BÊN THỨ BA]

YÊU CẦU: Không tự kết luận; đề xuất FIT_REVIEW, GAP, NEEDS_SPIKE hoặc OUT_OF_SCOPE; proof hết hạn trả EVIDENCE_REQUIRED.

ĐỊNH DẠNG ĐẦU RA: REQ-ID | Candidate capability | Proof | Dependency | Unknown | Proposed status | Reviewer.

VÍ DỤ ĐIỀN SẴN: REQ-SW-DEMO-11 cần SSO; proof v1 hết hạn nên packet chuyển security/product review thay vì ghi hỗ trợ.

Lập POC acceptance plan có cổng dữ liệu

MỤC TIÊU: Thiết kế POC minh họa với tiêu chí đo và quyền môi trường trước khi cấp access.

[ĐẦU VÀO]
APPROVED_SCOPE = [REQ-ID, CAPABILITY-ID, OUT-OF-SCOPE]
TEST_ENVIRONMENT = [SANDBOX, ACCESS ROLE, START/END]
TEST_DATA = [LOẠI DỮ LIỆU, REDACTION, OWNER]
SUCCESS_CRITERIA = [METRIC, BASELINE, THRESHOLD, ACCEPTANCE OWNER]

YÊU CẦU: Thiếu owner, dữ liệu chưa được phép hoặc metric viết mơ hồ phải POC_BLOCKED; không cấp token hay chạy production.

ĐỊNH DẠNG ĐẦU RA: Scenario | Input minh họa | Metric | Method | Evidence | Risk | Owner | Gate.

VÍ DỤ ĐIỀN SẴN: POC-SW-DEMO-06 dùng 500 record minh họa đã ẩn; thiếu acceptance owner nên ở POC_BLOCKED.

Dựng mutual action plan từ approval references

MỤC TIÊU: Tạo kế hoạch hai bên từ outcome, security, proposal và procurement đã có người xác nhận.

[ĐẦU VÀO]
CONFIRMED_OUTCOMES = [OUTCOME-ID, OWNER]
APPROVAL_REFERENCES = [SOLUTION, SECURITY, LEGAL, PRICING]
PROCUREMENT_CHECKLIST = [ITEM, STATUS, OWNER, DUE]
CONSENTED_CONTACTS = [CONTACT-ID, KÊNH, MỤC ĐÍCH]

YÊU CẦU: Không tạo cam kết mới, không gửi; item thiếu approval ghi BLOCKED; STOP_CONTACT bị loại khỏi follow-up.

ĐỊNH DẠNG ĐẦU RA: Milestone | Bên phụ trách | Due | Dependency | Approval | Status | Follow-up DRAFT owner.

VÍ DỤ ĐIỀN SẴN: MAP-SW-DEMO-09 có sáu milestone minh họa; DPA chưa duyệt nên proposal signing ở BLOCKED và chuyển legal owner.

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

Agent có tự phân loại lead thành nóng hay lạnh không?

Không. Workflow route theo rule và evidence đã duyệt; mức ưu tiên do owner xác nhận, không suy từ cảm xúc hay dữ liệu nhạy cảm.

Khi nào được mở trial hoặc POC?

Khi có account owner, scope, environment, access policy, dữ liệu thử, thời hạn và người duyệt success criteria.

Nếu requirement vượt capability hiện tại thì sao?

Solution consultant chọn GAP, NEEDS_SPIKE hoặc OUT_OF_SCOPE và nêu owner; roadmap không được biến thành lời hứa.

Follow-up được tạo ở bước nào?

Sau checkpoint có outcome do người xác nhận; AI tạo DRAFT theo consent và account executive trực tiếp duyệt, gửi.

Bài liên quan

Muốn thiết kế workflow Sale phần mềm có nhánh lỗi, cổng security và procurement theo stack thật? Liên hệ NganAds để dựng pilot có audit và HITL.