Intake

Intake bắt đầu từ một việc Thành phải làm gần như mỗi ngày

ZiniSoft vừa phát triển sản phẩm vừa triển khai dự án với một đội ngũ nhỏ. Yêu cầu có thể đến từ tin nhắn, email, cuộc họp hoặc báo cáo ngày. Trước khi đội ngũ bắt đầu làm, Thành thường phải đọc lại nhiều nguồn, ráp bối cảnh và hỏi thêm để hiểu vấn đề thực sự là gì.

Một yêu cầu được ghi lại chưa có nghĩa mọi người đã hiểu giống nhau. Nó có thể thiếu người chịu trách nhiệm, tiêu chí nghiệm thu hoặc lý do vì sao cần làm lúc này. Nếu đưa thẳng vào hàng đợi triển khai, phần chưa rõ không biến mất. Nó chỉ xuất hiện muộn hơn dưới dạng làm lại, chờ quyết định hoặc một kết quả không ai chắc đã đúng.

Trước giai đoạn thử nghiệm, Thành ước tính riêng việc tổng hợp yêu cầu và báo cáo ngày cần khoảng 4,5 giờ tập trung của CTO trong một ngày làm việc. Đây là ước lượng cá nhân dùng làm mốc ban đầu, không phải số liệu được hệ thống đo tự động.

AI có thể đọc nhanh, nhưng không được tự biến một đề xuất thành cam kết

Intake được Thành đề xuất và cùng đội ngũ ZiniSoft xây dựng như một sản phẩm vận hành nội bộ. Mục tiêu không phải tạo thêm một công cụ quản lý task. Mục tiêu là giữ được hành trình từ nội dung nguồn, đề xuất do AI tạo, con người rà soát, lập kế hoạch, theo dõi triển khai đến lúc nghiệm thu.

AI có thể tóm tắt vấn đề, đề xuất tiêu chí nghiệm thu, mức ưu tiên và tuyến xử lý. Nhưng một cấu trúc trông hợp lý vẫn có thể sai bối cảnh. Vì vậy, AI phải dừng trước quyền phê duyệt. Người chịu trách nhiệm quyết định việc nào cần làm rõ, việc nào được đưa vào kế hoạch và kết quả nào đủ bằng chứng để chấp nhận.

Từ yêu cầu rời rạc đến một vòng vận hành có thể kiểm tra

Trước khi có Intake

Cùng một yêu cầu có thể được diễn giải lại khi chuyển từ người tiếp nhận sang người lập kế hoạch rồi sang đội triển khai. Báo cáo tiến độ lại cần thu thập từ từng người và đối chiếu với công cụ theo dõi. Khi một đầu việc dừng, Thành phải tìm lại bối cảnh để biết đang thiếu thông tin, thiếu người quyết định hay thiếu bằng chứng hoàn tất.

Điều Intake thay đổi

Intake giữ nội dung nguồn cùng đề xuất của AI để người duyệt có thể so sánh, sửa hoặc từ chối. Chỉ sau khi được duyệt, yêu cầu mới đi vào kế hoạch và kết nối với công việc triển khai. Cập nhật tiến độ, điểm nghẽn và bằng chứng sau đó quay lại cùng một hành trình để người chịu trách nhiệm nghiệm thu.

Báo cáo ngày không còn chỉ là một đoạn văn để đọc rồi quên. Nó trở thành tín hiệu có thể liên kết với yêu cầu, kế hoạch hoặc vấn đề đang chờ xử lý. Tác tử AI cũng chỉ là một giao diện được kiểm soát để làm việc với cùng nguồn dữ liệu, không phải một chủ thể có quyền tự quyết định.

Trạng thái hiện tại

Intake đang ở trạng thái In development và được vận hành trong controlled pilot trên hai đội sản phẩm nội bộ. Giai đoạn thử nghiệm bao phủ toàn bộ vòng vận hành: tiếp nhận, rà soát, lập kế hoạch, bàn giao để triển khai, thu thập bằng chứng tiến độ và nghiệm thu.

Bằng chứng có thể công bố

• Intake đang được thử nghiệm có kiểm soát trên hai đội sản phẩm nội bộ.
• Yêu cầu có thể đi từ nội dung nguồn đến đề xuất có cấu trúc, bước con người rà soát và kế hoạch có người chịu trách nhiệm.
• Báo cáo ngày, trạng thái triển khai và bằng chứng nghiệm thu được xem trong cùng một hành trình vận hành.
• Con người phải phê duyệt trước khi đề xuất trở thành công việc trong kế hoạch hoặc được ghi sang hệ thống theo dõi bên ngoài.

Trong cửa sổ đo 7 ngày được rà soát ngày 22/10/2026, hoạt động điều hành có dấu vết trong ứng dụng đạt trung bình 43 phút mỗi ngày. Số liệu này không bao gồm thời gian đọc và không đại diện cho toàn bộ thời gian làm việc.

Khối lượng yêu cầu được duyệt là 39 trong tuần bắt đầu ngày 5/10 và 53 trong tuần bắt đầu ngày 12/10. Tuần hiện tại chưa hoàn tất đã đạt 97 yêu cầu tại thời điểm thu thập bằng chứng. Những con số này cho thấy Intake đang được sử dụng trong controlled pilot; chúng không phải tỷ lệ hoàn thành hoặc mức cải thiện năng suất.

Mốc ước lượng 4,5 giờ và số liệu 43 phút được thu thập bằng hai phương pháp khác nhau, nên không thể dùng làm phép so sánh trực tiếp trước và sau. Thành không dùng chúng để tuyên bố phần trăm thời gian đã giảm.

Một yêu cầu đi qua Intake

1. Giữ lại nguồn: yêu cầu, báo cáo hoặc kết quả cuộc họp đi vào hệ thống cùng thông tin về nơi nó xuất phát.
2. AI tạo đề xuất: nội dung được cấu trúc và phần thông tin còn thiếu được chỉ ra, nhưng chưa tạo thành cam kết.
3. Con người rà soát: người phụ trách sửa, yêu cầu làm rõ, từ chối hoặc phê duyệt đề xuất.
4. Đưa vào kế hoạch: công việc đã duyệt có vị trí, người chịu trách nhiệm và kết nối với hệ thống triển khai khi cần.
5. Trả lại bằng chứng: tiến độ, điểm nghẽn và kết quả quay lại Intake để con người nghiệm thu hoặc yêu cầu làm tiếp.

Đây là mô hình công khai được tái dựng để giải thích trách nhiệm. Nó không mô tả kiến trúc nội bộ của Intake.

Vai trò của Thành và đội ngũ

Thành tham gia Intake với vai trò product builder, chịu trách nhiệm về định hướng sản phẩm, kiến trúc giải pháp và vận hành sản phẩm. Thành xác định ranh giới nào AI được đề xuất, quyết định nào cần người duyệt và bằng chứng nào phải có trước khi công việc được xem là hoàn tất.

Đội ngũ ZiniSoft thiết kế, xây dựng, kiểm thử và tiếp tục phát triển sản phẩm. Người phụ trách dự án và CTO vẫn chịu trách nhiệm phê duyệt, ưu tiên, lập kế hoạch và nghiệm thu. AI giúp cấu trúc thông tin và chuẩn bị bước tiếp theo; nó không sở hữu quyết định cuối cùng.

Ba quyết định định hình sản phẩm

Một hành trình chung cho nhiều nguồn đầu vào

Tin nhắn, email, cuộc họp, báo cáo ngày và tác tử AI có cách biểu đạt khác nhau, nhưng đều có thể chứa cùng một loại tín hiệu vận hành. Intake đưa chúng vào một hành trình chung để cùng một tiêu chuẩn rà soát được áp dụng. Đánh đổi là hệ thống phải giữ được nguồn gốc và không làm mất sắc thái của nội dung ban đầu khi chuẩn hóa.

AI đề xuất trước khi con người cam kết

Cho AI tự tạo task có thể làm hàng đợi tăng rất nhanh, nhưng tốc độ đó không đảm bảo công việc đúng hoặc đáng làm. Intake giữ một điểm duyệt có chủ đích trước khi đề xuất trở thành cam kết. Đội ngũ chấp nhận thêm một bước để người chịu trách nhiệm biết mình đang duyệt điều gì và hành động nào sẽ xảy ra sau đó.

Không xem task được tạo là kết quả cuối cùng

Intake giữ bối cảnh tiếp nhận, lịch sử rà soát, kế hoạch và quyết định nghiệm thu. Công cụ triển khai vẫn giữ phần thực thi kỹ thuật. Khi hai bên được kết nối nhưng không nhập nhằng trách nhiệm, một task chỉ được xem là hoàn tất khi kết quả quay lại cùng bằng chứng để người phụ trách kiểm tra.

Điều Intake đã thay đổi trong cách Thành giao việc cho AI

Trước Intake, Thành thường đánh giá một công cụ AI qua chất lượng câu trả lời hoặc tốc độ tạo nội dung. Khi đưa AI vào công việc của đội ngũ, hai tiêu chí đó chưa đủ. Một đề xuất chỉ có giá trị khi biết nó đến từ đâu, ai được quyền duyệt, hành động tiếp theo là gì và kết quả sẽ được kiểm tra bằng bằng chứng nào.

Intake cũng giúp Thành nhìn rõ hơn một nguyên tắc đang áp dụng ở các sản phẩm khác: đừng tự động hóa một quy trình vẫn chưa thống nhất. AI có thể làm phần mơ hồ chạy nhanh hơn, nhưng không tự biến nó thành một cách làm có trách nhiệm.

Phạm vi công bố

Case này trình bày mô hình vận hành, số liệu controlled pilot đã được phê duyệt và các giao diện được tái dựng. Nội dung không công bố tên khách hàng, dữ liệu nguồn riêng tư, đường dẫn dự án nội bộ, thông tin xác thực, địa chỉ dịch vụ, cấu trúc hạ tầng hoặc kiến trúc nội bộ.

Các hình sử dụng dữ liệu hư cấu. Số lượng theo tuần là khối lượng vận hành tổng hợp. Mức giảm thời gian xử lý, mức giảm thao tác thủ công và mức tăng tỷ lệ hoàn thành chỉ được công bố khi có cùng ranh giới quy trình, kỳ đo và nguồn dữ liệu được định nghĩa rõ.