Đề Xuất Upsale Khách Hàng

Một đề xuất upsale được xây dựng trên bằng chứng codebase chốt nhanh hơn đề xuất được xây dựng trên ý kiến chủ quan. Với Sun Agent Kit, bạn chạy một cuộc kiểm tra có cấu trúc trên dự án hiện có, ánh xạ các phát hiện thành kết quả kinh doanh, xác nhận các tuyên bố với các benchmark ngành, và tạo ra một tài liệu chuyên nghiệp dành cho khách hàng — tất cả mà không cần viết một dòng code nào. Điều mà trước đây phải mất một senior engineer và một account manager gần cả tuần giờ có thể hoàn thành vào chiều thứ Tư.

Tổng Quan

Mục tiêu: Tạo đề xuất upsale có cấu trúc được hỗ trợ bởi bằng chứng codebase, không phải ý kiến chủ quan
Thời gian: 1–2 giờ (so với 4–6 giờ phân tích + viết thủ công)
Agents sử dụng: scout, researcher, doc-writer
Commands: /sk:scout, /sk:brainstorm, /sk:research, /sk:plan, /sk:docs

Lưu ý: Không có code nào được viết trong workflow này. Mọi lệnh đều tạo ra phân tích, nghiên cứu hoặc tài liệu — codebase chỉ được đọc xuyên suốt.

Yêu Cầu Trước Khi Bắt Đầu

• Sun Agent Kit đã cài đặt (hướng dẫn cài đặt)
• Truy cập vào codebase của khách hàng (clone local hoặc quyền đọc là đủ)
• Một trigger rõ ràng cho upsale — một yêu cầu mới từ khách hàng, một sự cố hỗ trợ, một lần gia hạn sắp tới
• Ngữ cảnh từ account manager: khách hàng quan tâm nhất đến kết quả nào? (hiệu suất, mobile, scale)

Quy Trình Từng Bước

Bước 1: Kiểm Tra Codebase Để Tìm Bằng Chứng

/sk:scout "audit this Laravel codebase for technical debt, missing test coverage, architectural bottlenecks, security gaps, and scalability risks — generate a structured findings report for a client proposal"

Điều gì xảy ra: Agent sẽ:

1. Duyệt qua repository và lập chỉ mục source files, cấu hình và dependency manifests
2. Đo test coverage, xác định các test suite còn thiếu và đánh dấu các critical path chưa được kiểm tra
3. Phát hiện các architectural pattern — hoặc sự vắng mặt của chúng — bao gồm thiếu service layers, tight coupling và direct database calls trong controllers
4. Quét các vấn đề bảo mật đã biết: thông tin xác thực bị lộ, packages lỗi thời, thiếu input validation
5. Lưu báo cáo phát hiện có cấu trúc vào plans/reports/scout-report.md với xếp hạng mức độ nghiêm trọng và tham chiếu bằng chứng

Bước 2: Ánh Xạ Phát Hiện Thành Giá Trị Kinh Doanh

/sk:brainstorm "based on the scout findings: no tests, monolithic architecture, no API layer, and the client wants a mobile app — what are the 3-5 most compelling upsell scopes? Map each to both technical risk reduction and business value"

Điều gì xảy ra: Agent sẽ:

1. Đọc báo cáo scout và trích xuất các phát hiện có mức độ nghiêm trọng cao nhất
2. Dịch từng phát hiện kỹ thuật thành một tuyên bố rủi ro kinh doanh (ví dụ: “không có test coverage → rủi ro regression cao trong quá trình trích xuất mobile API”)
3. Nhóm các phát hiện thành các phạm vi engagement nhất quán, mỗi phạm vi có đề xuất giá trị rõ ràng
4. Xếp hạng các phạm vi theo tác động đến khách hàng và tính khả thi của việc giao hàng
5. Tạo ra danh sách ưu tiên các góc độ upsale với cả lý giải kỹ thuật và khung kinh doanh

Bước 3: Xác Nhận Tuyên Bố Với Dữ Liệu Ngành

/sk:research "ROI benchmarks: cost of adding test coverage to a 50k LOC Laravel project, typical timeline for API extraction from a PHP monolith, mobile app backend requirements for REST vs GraphQL"

Điều gì xảy ra: Agent sẽ:

1. Tìm kiếm các benchmark ngành, case studies và dữ liệu cộng đồng liên quan đến các phạm vi đề xuất
2. Tìm ước tính effort và các khoảng thời gian cho các engagement tương đương
3. Xác định dữ liệu ROI cho việc đầu tư vào test infrastructure trong các dự án PHP/Laravel
4. Biên soạn một tóm tắt nghiên cứu kèm tham chiếu nguồn để hỗ trợ các tuyên bố trong đề xuất
5. Đánh dấu các lĩnh vực mà benchmark còn thưa thớt hoặc ước tính có phương sai cao

Bước 4: Cấu Trúc Tài Liệu Đề Xuất

/sk:plan "structure a 3-month upsell proposal: Section 1 current state findings with evidence, Section 2 three engagement scopes with effort estimates, Section 3 risk-if-no-action analysis, Section 4 pricing tiers (essential/recommended/comprehensive)"

Điều gì xảy ra: Agent sẽ:

1. Đọc báo cáo scout, kết quả brainstorm và tóm tắt nghiên cứu làm đầu vào
2. Thiết kế cấu trúc đề xuất bắt đầu bằng bằng chứng và dẫn đến yêu cầu
3. Xác định những gì thuộc về mỗi phần — phát hiện nào, phạm vi nào, benchmark nào
4. Chỉ định mô hình pricing tier: những gì được bao gồm trong mỗi tier và cách phân biệt chúng
5. Lưu kế hoạch tài liệu vào plans/proposal-structure.md để doc-writer thực thi

Bước 5: Viết Tài Liệu Đề Xuất Dành Cho Khách Hàng

/sk:docs "write the upsell proposal document per the plan — formal client-facing tone, reference scout findings as supporting evidence, include executive summary at the top"

Điều gì xảy ra: Agent sẽ:

1. Đọc kế hoạch cấu trúc đề xuất và tất cả kết quả từ các agent trước đó làm tài liệu nguồn
2. Viết từng phần bằng ngôn ngữ trang trọng dành cho khách hàng, hướng đến đối tượng executive không có chuyên môn kỹ thuật
3. Nhúng các phát hiện scout cụ thể làm bằng chứng hỗ trợ — thống kê codebase, không phải các tuyên bố trừu tượng
4. Xây dựng ba tùy chọn engagement theo tier với phạm vi, timeline và hướng dẫn pricing tương đối
5. Tạo tài liệu đề xuất cuối cùng và lưu vào docs/client-proposal.md

Ví Dụ Hoàn Chỉnh: Biến Yêu Cầu Mobile App Thành Engagement 3 Tháng

Tình huống: Bạn đang duy trì một Laravel monolith 2 năm tuổi cho khách hàng. Codebase đã phát triển đến ~50k dòng không có test suite, không có service layer, và toàn bộ business logic nằm trong Blade controllers. Trong một cuộc gọi thứ Hai, khách hàng đề cập rằng họ muốn có một mobile app vào Q3. Account manager của bạn yêu cầu một đề xuất vào cuối tuần.

Bạn chạy:

# 1. Kiểm tra codebase — bằng chứng thực tế nói gì?
/sk:scout "audit this Laravel codebase for technical debt, missing test coverage, architectural bottlenecks, security gaps, and scalability risks — generate a structured findings report for a client proposal"

# 2. Ánh xạ các phát hiện thành các góc độ upsale mà account manager có thể pitch
/sk:brainstorm "based on the scout findings: no tests, monolithic architecture, no API layer, and the client wants a mobile app — what are the 3-5 most compelling upsell scopes? Map each to both technical risk reduction and business value"

# 3. Xác nhận ước tính effort và tuyên bố ROI trước khi đưa ra trước khách hàng
/sk:research "ROI benchmarks: cost of adding test coverage to a 50k LOC Laravel project, typical timeline for API extraction from a PHP monolith, mobile app backend requirements for REST vs GraphQL"

# 4. Thiết kế cấu trúc đề xuất trước khi viết bất kỳ đoạn văn nào
/sk:plan "structure a 3-month upsell proposal: Section 1 current state findings with evidence, Section 2 three engagement scopes with effort estimates, Section 3 risk-if-no-action analysis, Section 4 pricing tiers (essential/recommended/comprehensive)"

# 5. Viết tài liệu cuối cùng dành cho khách hàng
/sk:docs "write the upsell proposal document per the plan — formal client-facing tone, reference scout findings as supporting evidence, include executive summary at the top"

Kết quả: Đến chiều thứ Tư, bạn có một đề xuất 10 trang với bằng chứng codebase, ba tùy chọn engagement theo tier — test infrastructure, trích xuất API layer và phát triển mobile app — và các dự báo ROI được đặt nền tảng trên nghiên cứu. Account manager bước vào buổi gặp khách hàng thứ Sáu với một thứ đáng tin cậy, không phải một báo giá được xây dựng dựa trên cảm tính.

So Sánh Thời Gian

Các Phương Pháp Tốt Nhất

1. Đặt nền tảng mọi tuyên bố đề xuất trên phát hiện scout ✅

Khách hàng tin vào bằng chứng hơn ý kiến. Khi đề xuất nói “codebase của bạn có zero test coverage trên 47 controller classes,” điều đó có tác động khác với “chúng tôi nghĩ bạn cần tests.” Các phát hiện scout là độ tin cậy của bạn.

2. Đưa ra các phạm vi theo tier ✅

Essential / Recommended / Comprehensive mang lại cho khách hàng các lựa chọn thay vì một mức giá “chấp nhận hoặc không”. Khách hàng sẽ từ chối một phạm vi lớn duy nhất thường sẽ chọn tier trung bình khi được đưa ra một dải tùy chọn.

3. Nêu rõ đối tượng và tone trong prompt docs ✅

"formal client-facing tone" không được ngầm hiểu — hãy nêu rõ trong mỗi lần gọi /sk:docs. Doc-writer mặc định theo register kỹ thuật nếu bạn không chỉ định khác.

4. Bao gồm phần “rủi ro nếu không hành động” ✅

Định lượng chi phí của việc không làm gì thuyết phục hơn việc mô tả lợi ích của hành động. “Trích xuất API layer bây giờ tốn X; làm sau khi ra mắt mobile app tốn 3X và cần viết lại” là lý do cụ thể để quyết định.

5. Đề xuất công việc không có cơ sở trong phát hiện scout ❌

Nếu đề xuất khuyến nghị migration Kubernetes nhưng báo cáo scout không đề cập đến vấn đề mở rộng quy mô infrastructure, phạm vi đó không có bằng chứng đằng sau. Khách hàng và cố vấn kỹ thuật của họ sẽ nhận ra, và điều đó làm suy yếu độ tin cậy của toàn bộ tài liệu.

6. Bỏ qua nghiên cứu ❌

Các tuyên bố ROI chưa được xác minh còn tệ hơn không có tuyên bố nào. Nếu bạn không thể hỗ trợ một ước tính effort với một benchmark hoặc một case study tương đương, hãy xóa nó đi hoặc đánh dấu rõ ràng là ước tính nội bộ.

Xử Lý Sự Cố

Vấn đề: Scout tìm thấy quá nhiều vấn đề — đề xuất đọc như một bug report

Giải pháp: Dùng brainstorm để ưu tiên trước khi viết. Thêm ràng buộc vào prompt brainstorm: "pick the 3 most business-critical findings — ignore anything that is cosmetic or low risk". Một đề xuất cố gắng sửa tất cả mọi thứ sẽ không được phê duyệt bất cứ điều gì.

Vấn đề: Kết quả docs quá kỹ thuật cho một CTO không có chuyên môn kỹ thuật

Giải pháp: Chạy lại /sk:docs với hướng dẫn đối tượng rõ ràng: "write for a non-technical CTO who understands business risk but not PHP internals — no code snippets, no framework-specific terminology".

Vấn đề: Plan tạo ra quá nhiều phần đề xuất

Giải pháp: Ràng buộc cấu trúc ngay từ đầu: "maximum 4 sections, executive summary under 200 words, no appendices". Nhiều phần hơn không làm cho đề xuất mạnh hơn — chúng làm cho việc phê duyệt khó hơn.

Vấn đề: Nghiên cứu không trả về benchmark phù hợp cho stack của bạn

Giải pháp: Thu hẹp phạm vi tìm kiếm: "Laravel-specific test coverage ROI case studies from teams between 5 and 20 engineers". Benchmark phần mềm chung ít đáng tin cậy hơn dữ liệu theo stack cụ thể; nếu không có, research agent sẽ nói rõ điều đó.

Bước Tiếp Theo

• Tạo Prototype Nhanh — nếu đề xuất được chấp nhận, prototype các tính năng mới trước khi cam kết xây dựng đầy đủ
• Di Chuyển Dự Án — nếu đề xuất bao gồm migration tech stack, dùng workflow này để lên kế hoạch và thực thi
• Tạo Tài Liệu — tạo tài liệu bàn giao cho engagement mở rộng khi nó bắt đầu
• Kiểm Tra & Quét Bảo Mật — khi đề xuất bao gồm phạm vi bảo mật, chạy quét bảo mật chuyên dụng làm deliverable đầu tiên

Điểm chính: Đề xuất upsale được hỗ trợ bởi kiểm tra codebase chốt nhanh hơn đề xuất dựa trên ý kiến — /sk:scout cung cấp bằng chứng, /sk:brainstorm ánh xạ nó thành giá trị kinh doanh, và /sk:docs biến nó thành một deliverable sẵn sàng cho khách hàng. Không viết code, không lãng phí thời gian kỹ thuật cho một đề xuất có thể không thành công.