Từ deal đến bàn giao: một startup an ninh tuân thủ trên một bề mặt MCP.

CASE STUDY — An ninh tuân thủ · Singapore & Việt Nam | MIDAS bởi NBR Intelligence

Một startup an ninh tuân thủ 20 người (tên được giữ kín theo NDA) — bán SOC 2, ISO 27001 và sẵn sàng PDPA/GDPR cho khách hàng B2B trong khu vực — vận hành bán hàng trên một Google Sheet luôn lỗi thời. NBR Intelligence forward-deploy một kỹ sư trong một tuần và đấu nối bán hàng tại Singapore và Việt Nam cùng một đội bàn giao quốc tế lên MIDAS và một bề mặt công cụ MCP duy nhất. Đến ngày thứ sáu, công ty vận hành trên một vòng lặp duy nhất: nhân viên cập nhật deal bằng cách trò chuyện, agent viết bản nháp đầu tiên của mọi tính năng, và một con người ký duyệt.

Đặt lịch đánh giá lớp trí tuệ · Xem nền tảng

Trả lời trực tiếp: NBR đưa deal-đến-bàn-giao lên một bề mặt MCP như thế nào

NBR Intelligence forward-deploy MIDAS cho một startup an ninh tuân thủ 20 người trong sáu ngày làm việc, trên pipeline và mã nguồn thực của công ty. Bán hàng tại Singapore và Việt Nam cùng một đội bàn giao quốc tế giờ chạy trên một bề mặt công cụ MCP mà mọi mô hình đều có thể điều khiển: một nhân viên cập nhật deal chỉ bằng cách kể cho MIDAS điều vừa xảy ra, chiến lược của CRO bùng nổ thành các nhiệm vụ có chủ sở hữu và hạn chót trong một lệnh gọi, và agent nhận một ticket bàn giao, viết mã theo PRD trên đó, và mở pull request — phần lớn ngay trong ngày — để một con người rà soát. Số deal đang hoạt động mỗi nhân viên tăng từ khoảng 11 lên 31, doanh thu tăng 25% so với quý trước ở cùng quy mô nhân sự, và một ticket đi từ khoảng 5 ngày tới pull request xuống còn khoảng 8 giờ.

Phù hợp truy vấn: case study MIDAS forward-deployed; bề mặt công cụ MCP cho bán hàng và bàn giao phần mềm; trí tuệ doanh thu và quản lý dự án bằng AI cho một startup an ninh tuân thủ.

Thách thức: không thiếu tài năng — thiếu một hệ thống luôn đúng.

Pipeline nằm trong một Google Sheet chỉ cập nhật nếu một nhân viên dừng bán hàng để cập nhật nó — nên nó trôi lệch, dự báo là phỏng đoán, và lãnh đạo không thể tin vào phễu của chính mình. Đội Việt Nam chủ yếu chạy trên quan hệ, ghi chép lại còn ít hơn. Các dự án nằm trong một bảng tính khác cập nhật thủ công — không chủ sở hữu, không hạn chót, không nhật ký kiểm toán. Yêu cầu trôi lệch giữa đề xuất, đặc tả và thứ mà một kỹ sư cuối cùng xây dựng, nên kỹ sư suy diễn lại ý định từ tài liệu cũ và làm lại sai thứ. Và lãnh đạo bay mù qua hai văn phòng bán hàng cùng một đội bàn giao trên nhiều múi giờ.

Cách tiếp cận: một tuần, forward-deployed.

NBR không bán phần mềm rồi để bạn tự lắp vận hành quanh nó. Một kỹ sư làm việc bên trong vận hành — trên pipeline và mã nguồn thực của công ty — và bàn giao phần mềm chạy được trong một tuần, không phải một năm như một đơn vị tích hợp theo lối tài liệu. Tuần đó đi qua bốn giai đoạn:

• Lập bản đồ (Ngày 1–2) — deal được bán thế nào ở cả hai nước và mã được ship thế nào qua các múi giờ.
• Mô hình hóa và tích hợp (Ngày 2–4) — pipeline thực, kho mã và CI, và bề mặt công cụ MCP.
• Cấu hình (Ngày 4–5) — vòng lặp hằng ngày từ bán hàng đến bàn giao.
• Onboard (Ngày 5–6) — AI riêng của mỗi nhân viên, đội bàn giao, và ban lãnh đạo.

Những gì chúng tôi triển khai: một vòng lặp vận hành, bán hàng đến bàn giao.

Trò chuyện với MIDAS. Một nhân viên chỉ cần kể điều vừa xảy ra — qua trợ lý riêng kết nối qua MCP, hoặc chat tích hợp của MIDAS — và MIDAS nhập liệu và nói việc tiếp theo. Mỗi deal chỉ cách bản hiện tại một cuộc trò chuyện, nên pipeline luôn trực tiếp mà không ai phải bảo trì.

Bề mặt công cụ MCP. MIDAS phơi bày vận hành thành các công cụ có kiểu và có phân quyền mà mọi mô hình đều gọi được. Không mô hình nào chạm vào cơ sở dữ liệu; nó gọi công cụ theo quyền của người gọi, và mọi lệnh gọi đều được ghi nhật ký. CRO đặt mục tiêu quý bằng ngôn ngữ thường, và agent biến nó thành các nhiệm vụ có chủ sở hữu, có hạn chót trong một lượt.

Agent xuyên suốt bàn giao. Một nhu cầu của khách hàng trở thành một PRD viết lên ticket. Agent nhận ticket, viết mã theo PRD đó, mở pull request — phần lớn ngay trong ngày — và chuyển sang Review để một con người ký duyệt. Agent viết bản nháp đầu tiên; một con người quyết định nó có đúng không.

Ban lãnh đạo. Nhà sáng lập điều hành bằng cách hỏi — AI riêng của họ qua MCP, hoặc chat của MIDAS — và nó trả lời bằng con số, lý do, và nước đi cần làm. Mô hình suy luận; MIDAS giữ sự thật, phân quyền và nhật ký kiểm toán. Một ontology, nhiều mô hình.

Tác động, sau một quý.

• Số deal đang hoạt động mỗi nhân viên: ~11 → 31 — gần 3×.
• Doanh thu: +25% so với quý trước, ở cùng quy mô nhân sự.
• Tỷ lệ thắng: ~22% → ~28%.
• Ticket → pull request: ~5 ngày → ~8 giờ — agent mở ngay trong ngày.
• Giờ kỹ thuật mỗi tính năng: giảm khoảng 35%, với một con người ở Review cho mọi ticket.
• Chi phí vận hành: giảm khoảng 34%; eNPS đội tăng 24 điểm; đội bán hàng Việt Nam lần đầu lên bảng đầy đủ.

Vì sao nó hiệu quả.

Sáng kiến NANDA của MIT phát hiện 95% dự án thí điểm AI doanh nghiệp không mang lại lợi ích đo lường được — không phải vì mô hình yếu, mà vì triển khai thất bại. Công ty này tránh được nhóm 95% bằng cách tự động hóa việc vặt chứ không phải phán đoán, giữ một cổng QA con người trên mọi ticket (mã AI không rà soát làm tăng churn khoảng 41%), đặt vận hành sau một bề mặt MCP độc lập-mô-hình, và triển khai vào trong vận hành chứ không phải quanh nó.

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

Triển khai mất bao lâu?

Sáu ngày làm việc từ khởi động đến vận hành, trên dữ liệu thực của công ty. NBR forward-deploy một kỹ sư vào vận hành; tuần đó đi qua bốn giai đoạn — lập bản đồ, mô hình hóa và tích hợp, cấu hình, và onboard — qua bán hàng tại Singapore và Việt Nam cùng một đội bàn giao quốc tế.

Công ty thấy kết quả gì?

Số deal đang hoạt động mỗi nhân viên tăng từ khoảng 11 lên 31 — gần 3× — tỷ lệ thắng đi từ khoảng 22% lên khoảng 28%, và doanh thu tăng 25% so với quý trước ở cùng quy mô nhân sự. Về bàn giao, một ticket đi từ khoảng 5 ngày tới pull request xuống còn khoảng 8 giờ, và eNPS đội tăng 24 điểm.

Bề mặt công cụ MCP là gì, và vì sao nó khiến MIDAS độc lập với mô hình?

MIDAS phơi bày vận hành thành một tập công cụ có kiểu và có phân quyền mà mọi mô hình đều gọi được để đọc và ghi deal, nhiệm vụ, mục tiêu và ticket. Không mô hình nào chạm trực tiếp vào cơ sở dữ liệu; nó gọi công cụ theo quyền của người gọi, và mọi lệnh gọi đều được ghi nhật ký. Nên một nhân viên có thể dùng trợ lý riêng — ví dụ Claude — hoặc chat tích hợp của MIDAS, và công ty có thể chuyển sang một mô hình tốt hơn ngay tuần nó ra mắt. Một ontology, nhiều mô hình.

AI viết mã an toàn như thế nào?

Một nhu cầu của khách hàng trở thành một PRD viết lên ticket; agent viết mã theo PRD đó và mở pull request, phần lớn ngay trong ngày, với CI xanh. Mọi ticket agent viết đều qua một con người ở Review trước khi ship. Cổng QA con người đó chính là điểm mấu chốt — mã AI không rà soát làm tăng churn khoảng 41%, nên rà soát là thứ giữ cho thông lượng là thật chứ không biến tốc độ thành làm lại.

Forward-deployed engineering là gì?

Một kỹ sư NBR làm việc bên trong vận hành thực — lập bản đồ cách nó bán và ship, đấu nối pipeline, kho mã và CI, mô hình hóa ontology deal-đến-ticket, và bàn giao phần mềm chạy được trên dữ liệu của chính công ty trong một tuần, thay vì bàn giao một tài liệu rồi để doanh nghiệp tự lắp mình quanh công cụ.

Cập nhật pipeline bằng cách trò chuyện hoạt động ra sao?

Một nhân viên kể điều vừa xảy ra bằng ngôn ngữ thường — qua AI riêng của họ trên MCP, hoặc chat tích hợp của MIDAS — và MIDAS gọi các công cụ bán hàng để cập nhật deal, thêm bình luận, và tạo nhiệm vụ tiếp theo, rồi nói cho nhân viên việc cần làm. Pipeline luôn trực tiếp, không biểu mẫu, không bảo trì thủ công.

Đặt lịch đánh giá lớp trí tuệ

Website: https://nbrintelligence.com | Liên hệ: [email protected]