Khách hỏi 'sao không dùng Copilot?', đừng mang model ra so

Thử hình dung buổi demo thứ hai. Agent của bạn vừa chạy trơn tru, và một người phía khách lên tiếng: công ty đã trả tiền Copilot cho toàn bộ nhân viên rồi, cái này khác gì?

Nếu bạn trả lời bằng chuyện model nào thông minh hơn, gần như chắc bạn thua. Người đặt câu hỏi đã bỏ phiếu cho một khoản mua lớn, và chẳng ai muốn nghe rằng mình mua nhầm. Câu hỏi ấy cũng không thù địch. Đó là câu hợp lý nhất mà một người giữ ngân sách có thể đặt ra.

Vì thế đừng tìm cách thắng một cuộc tranh luận. Việc của bạn là chỉ ra chính xác phần việc nào công cụ có sẵn đã lo được, phần nào chưa, và phần của bạn gắn vào đâu.

Vấn đề không nằm ở model

Nghiên cứu GenAI Divide của MIT, được Fortune đưa tin, cho rằng các pilot AI trong doanh nghiệp thất bại chủ yếu vì “khoảng trống học hỏi” của cả công cụ lẫn tổ chức, chứ không phải vì chất lượng model. Công cụ đa năng chững lại vì chúng không học từ quy trình và không thích nghi với quy trình.

Đó chính là chỗ của FDE. OpenAI mô tả FDE của họ là người ngồi cùng khách để xây, triển khai và lặp lại giải pháp AI, theo bản tóm tắt của ZenML về bài nói của Colin Jarvis. Thứ bạn mang tới không phải một model tốt hơn, mà là sự hiểu biết về một quy trình cụ thể, được biến thành phần mềm.

Tensoria, một công ty làm giải pháp AI riêng, nhận xét rằng Copilot rất giỏi tóm tắt, soạn thảo và viết lại. Họ khuyên chia đôi: Copilot lo các bộ phận hỗ trợ, còn giải pháp riêng lo quy trình lõi. Đây là ý kiến của một bên có lợi ích thương mại, nhưng cách chia đủ rõ để bạn đem ra kiểm chứng ngay tại chỗ khách.

Ba câu hỏi trước khi mở miệng

Microsoft có sẵn một khung để bạn dùng lại. Vòng đời làm plugin Copilot của họ bắt đầu bằng bước xác định việc cần làm, người sẽ dùng và nơi họ dùng plugin. Ba câu đó cũng là ba câu bạn hỏi khi khách thắc mắc “sao không dùng cái có sẵn”.

Hỏi việc gì để tách việc văn bản chung chung khỏi việc nghiệp vụ. Hỏi ai làm để biết người dùng thật là nhân viên văn phòng hay một đội vận hành có quy trình riêng. Còn câu làm ở đâu hay bị bỏ qua nhất, dù chính nó quyết định hình thức giải pháp của bạn.

Sau đó bạn kiểm tra dữ liệu. Credal, một công ty cũng có lợi ích thương mại, cho rằng Copilot chỉ tích hợp với dữ liệu nằm trong phạm vi Microsoft 365. Đừng lặp lại câu đó như sự thật, mà coi nó là giả thuyết cần thử trên tenant của khách: dữ liệu quy trình nằm trong SharePoint, Outlook, hay trong một hệ thống khác hẳn?

Thêm một phép thử nữa là chủ quyền dữ liệu. Theo Tensoria, trường hợp đầu tiên mà giải pháp riêng hơn hẳn công cụ SaaS là khi khách đòi chủ quyền dữ liệu và không chịu nhân nhượng. Nếu khách quy định dữ liệu không được rời khỏi một hạ tầng nhất định, cuộc trò chuyện chuyển hướng hẳn.

Một ví dụ đi đến cùng

Thử hình dung một công ty bảo hiểm. Toàn công ty đã có Copilot. Bạn được gọi vào để giúp đội xử lý hồ sơ bồi thường, nơi mỗi hồ sơ phải đối chiếu hợp đồng, ảnh hiện trường và lịch sử khách hàng trước khi duyệt.

Áp ba câu hỏi. Việc gì: quyết định một hồ sơ được duyệt, bị từ chối hay cần bổ sung, theo đúng điều khoản của từng loại hợp đồng. Ai làm: chuyên viên bồi thường, chứ không phải nhân viên văn phòng nói chung.

Làm ở đâu: họ trao đổi qua Teams và Outlook, nhưng hợp đồng và lịch sử bồi thường nằm trong hệ thống quản lý hợp đồng riêng của công ty.

Kết quả tự hiện ra. Soạn email báo khách bổ sung giấy tờ là việc Copilot làm tốt, và bạn nên nói thẳng như vậy. Phần đối chiếu điều khoản với dữ liệu nằm ngoài Microsoft 365 mới là phần cần bạn.

Đến đây là bước quan trọng nhất: bạn không xây một ứng dụng mới bắt chuyên viên mở thêm một tab. Microsoft định nghĩa plugin Copilot là một gói cài đặt gom các khả năng cho một việc cụ thể. Gói đó có thể chứa một declarative agent, các skill, connector và thông tin kết nối tới một MCP server, trong khi server ấy chạy riêng bên ngoài.

Vậy là bạn viết một MCP server đọc hệ thống hợp đồng, đặt nó ở hạ tầng mà khách cho phép, rồi đóng gói agent bồi thường thành plugin. Chuyên viên vẫn hỏi trong Copilot như mọi ngày. Ramp gọi tinh thần này là đến với khách ngay trong công cụ họ đang dùng, thay vì ép họ theo một quy trình hoàn toàn mới.

Kịch bản trả lời ở buổi demo có thể như sau:

Khách: Công ty đã có Copilot. Cái này khác gì?

FDE: Copilot vẫn là nơi đội anh làm việc, và nó đang soạn email bồi thường rất tốt. Thứ nó chưa làm được là đối chiếu hồ sơ với điều khoản trong hệ thống hợp đồng, vì dữ liệu đó không nằm trong Microsoft 365.

Phần giải pháp này sẽ chạy bên trong Copilot dưới dạng plugin, nên chuyên viên không cần học công cụ mới.

Khách: Sao không để đội IT tự làm?

FDE: Hoàn toàn được, và đội IT sẽ nhận bàn giao để làm tiếp. Câu hỏi là ai đo được agent này có học đúng quy trình bồi thường hay không trong ba tháng đầu.

Câu trả lời cuối đáng để ý. Theo nghiên cứu của MIT, mua công cụ từ nhà cung cấp chuyên biệt và xây quan hệ đối tác thành công khoảng 67% trường hợp, thường xuyên hơn nhiều so với tự xây nội bộ. Nhưng con số đó cũng nhắc bạn đừng hứa xây mọi thứ từ đầu.

Năm bước, tóm vào một bảng

Bước	Câu hỏi	Kết quả cần có
Xác định việc	Việc gì, ai làm, làm ở đâu?	Một trang mô tả quy trình bằng lời của người dùng
Lập bản đồ dữ liệu	Dữ liệu nằm trong hay ngoài Microsoft 365?	Danh sách nguồn dữ liệu, đánh dấu nguồn ngoài
Kiểm tra ràng buộc	Có yêu cầu chủ quyền dữ liệu không?	Quyết định nơi đặt server
Chia phần	Việc văn bản chung hay quy trình lõi?	Phần giao cho Copilot, phần giải pháp riêng lo
Chọn hình thức	Người dùng đang làm việc ở đâu?	Plugin trong Copilot hoặc lý do rõ ràng để đứng ngoài

Những lỗi khiến bạn mất khách

Lỗi phổ biến nhất là chê Copilot. Bạn có thể đúng về kỹ thuật nhưng vẫn làm người đã ký hợp đồng mất mặt, và họ sẽ bảo vệ quyết định của mình bằng cách loại bạn.

Kế đến là đem benchmark model ra so. Nếu khoảng trống thật nằm ở việc học quy trình, thắng một bài benchmark chẳng trả lời được câu hỏi nào của khách.

Nguy hiểm không kém là trích nhận định của các nhà cung cấp như thể đó là sự thật. Cả Credal lẫn Tensoria đều bán giải pháp cạnh tranh, nên hãy dùng ý của họ làm danh sách điều cần kiểm tra, rồi kiểm tra trên môi trường thật của khách.

Cuối cùng là bắt người dùng sang một giao diện mới khi họ vốn đã sống trong Teams và Outlook. Một agent chính xác hơn mà không ai mở thì vẫn là một pilot thất bại.

Kỹ năng này đáng ghi vào CV

Khi đọc tin tuyển dụng FDE, hãy để ý các cụm như Microsoft 365 extensibility, MCP hay integration với hệ thống có sẵn của khách. Đó là dấu hiệu công ty cần người biết đặt giải pháp vào hệ sinh thái khách đã mua.

Trong CV, đừng chỉ ghi “xây agent cho khách”. Hãy viết rằng bạn đã xác định phần việc công cụ có sẵn chưa làm được, rồi tích hợp giải pháp vào chính công cụ đó. Câu này cho nhà tuyển dụng thấy bạn hiểu cả kỹ thuật lẫn chính trị nội bộ của khách.

Bài tập tuần này: chọn một quy trình của khách bạn đang làm, viết kịch bản trả lời câu “sao không dùng cái có sẵn” dài đúng năm câu, và đọc to cho một đồng nghiệp đóng vai CIO khó tính. Nếu câu nào trong đó nhắc tới model, viết lại câu đó.