Câu hỏi giờ đây không còn là "có nên dùng AI hay không", mà là "nên cho AI xử lý phần việc nào và bằng cách nào?".
1/ Mọi công việc AI của nhóm marketing đều đến từ một trong ba nguồn
Toàn bộ phần việc mà nhóm marketing đang làm với AI thực chất chỉ đến từ ba nguồn:
Phần mềm hoặc công cụ AI mua từ nhà cung cấp.
Chuyên môn tùy chỉnh và triển khai từ một chuyên gia tư vấn đã từng làm việc này rồi.
Thời gian của chính đội ngũ để tự xây công cụ AI nội bộ ngay từ đầu.
Làm việc với nhiều kiểu khách hàng hoàn toàn khác nhau, nhưng tôi cùng nhận ra một kiểu lặp lại giống hệt: các đội ngũ không hề phân loại công việc AI của mình một cách có chủ đích. Thay vào đó, họ đi thẳng vào việc cố tự động hóa càng nhiều càng tốt trong nội bộ.
Tự động hóa trong nội bộ không sai. Cái sai là bỏ qua bước phân loại, một bước chỉ mất chưa đến 30 phút, nhưng lại là một sai lầm rất tốn kém. May mắn là cách sửa lại khá đơn giản.
2/ Khi nào nên mua công cụ thay vì tự xây?
Nên mua công cụ khi vấn đề không phải của riêng bạn. Theo dõi thứ hạng, giám sát citation, theo dõi mention thương hiệu, chẩn đoán crawl, chấm điểm nội dung, đây đều là những bài toán mà hàng ngàn công ty khác cũng đang gặp, không riêng gì đội của bạn.
Bất chấp khoản đầu tư 30 đến 40 tỷ USD của khối doanh nghiệp vào GenAI, báo cáo rà soát các dự án AI doanh nghiệp của MIT cho thấy 95% tổ chức đang không nhận được bất kỳ lợi nhuận nào từ khoản đầu tư đó [1]. Báo cáo chỉ ra rằng các mối hợp tác chiến lược (với nhà cung cấp bên ngoài) đạt tỷ lệ triển khai thành công cao hơn hẳn so với các nỗ lực tự phát triển nội bộ. Dù số lượng dự án tự xây (BUILD) trong mẫu nghiên cứu nhiều hơn hẳn số dự án mua ngoài (BUY), và rất nhiều tổ chức vẫn đang thử tự phát triển, tỷ lệ thành công lại nghiêng hẳn về phía hợp tác bên ngoài.
Nguồn: The GenAI Divide STATE OF AI IN BUSINESS [1]
Dù chưa có dữ liệu chính xác về tổng khối lượng của từng loại, mô hình này cho thấy các nỗ lực tự phát triển nội bộ có tỷ lệ thành công thấp hơn đáng kể, dù đây lại là hướng được thử nhiều nhất. (Phần 1% còn thiếu trong biểu đồ của MIT là mô hình lai build-buy, nơi đội nội bộ cùng phát triển với nhà cung cấp, nhưng dữ liệu về mô hình này còn quá ít để định lượng.)
Nguyên nhân chính khiến các dự án thất bại, theo báo cáo, là công cụ không học hỏi hay không khớp được với cách con người vốn đang làm việc. Việc làm cho một công cụ thực sự khớp với quy trình là một trong những phần tốn kém nhất. Và nếu có một loại phần mềm trong ngành đã có hàng nghìn khách hàng sử dụng thì theo tôi bạn không cần phải thực hiện công việc tự xây lại phần mềm nữa.
Khi quyết định nên tự xây hay đi mua, bạn thực chất đang so sánh chi phí license của phần mềm với chi phí thật của một giờ làm việc của đội mình, nhân với số giờ cần để xây và duy trì phiên bản nội bộ. Cộng thêm cả những giờ ẩn mà không ai đếm: brainstorm, họp, thử nghiệm, làm lại, thử nghiệm lại.
Mua công cụ khi vấn đề là vấn đề phổ biến. Khi làm vậy, đội ngũ còn nhận được thêm hai thứ không thể tự xây được: nhà cung cấp chịu trách nhiệm bảo trì phần mềm, và có người ở đầu bên kia sửa nó khi nó gặp lỗi.
3/ Khi nào nên mua thay vì tự xây?
Nên mua khi quy trình đó là của riêng bạn. Một số quy trình thực sự đặc thù, như ai là người ký duyệt trước khi nội dung được xuất bản, dữ liệu của bạn được cấu trúc ra sao, báo cáo được gửi khi nào, cách thu thập ý kiến chuyên gia nội bộ cho nội dung, hay cách chèn CTA thương hiệu từ một kho câu chữ đã được duyệt sẵn.
Đây chính là nơi đội ngũ dễ đốt nhiều giờ nhất một cách vô tình, vì suy nghĩ "chỉ chúng ta có quy trình như vậy" thường bị hiểu nhầm thành "nên chúng ta tự xây nó".
Quy trình đó đúng là của riêng bạn, nhưng một người đã từng xây 65 quy trình tương tự cho 20 đội ngũ khác nhau thì đã biết rõ bước nào thường gãy, bước nào cần ý kiến từ chính nhân viên thực thi, bước nào đáng để tự động hóa, và bước nào trông có vẻ tự động hóa được nhưng thực ra không. Đội ngũ của bạn thì đang phải tự khám phá tất cả những điều đó lần đầu tiên, trong khi đồng hồ công việc vẫn đang chạy.
Đây là phép thử đơn giản: “nếu số giờ sắp bỏ ra chỉ để tạo ra một kiến thức mà bạn sẽ không cần dùng lại hàng tuần, hãy thuê ngoài phần kiến thức đó thay vì tự học lại từ đầu”.
Mua kiến thức có thể là một template đã được người khác kiểm chứng, một hợp đồng tư vấn ngắn hạn vài tuần, một buổi trao đổi với người đã từng làm chính việc đó, hoặc một thư viện tài liệu do những người đã từng mắc lỗi trước bạn biên soạn lại. Điều nó giúp tránh được là việc đội ngũ phải tự phát hiện từng kiểu thất bại một, theo đúng nghĩa đen, trên giờ làm việc thật.
4/ Sử dụng AI mà bạn không đủ chuyên môn để kiểm tra, nó sẽ đưa ra câu trả lời sai một cách rất tự tin
Chỉ 13% marketer hoàn toàn tin tưởng đầu ra của AI mà không cần con người đọc lại [2].
Con số này thường bị coi là vấn đề về độ chín của mô hình hay rào cản trong việc áp dụng AI, nhưng thực chất đây là một yêu cầu về chuyên môn nhân sự.
Ngày nay, tình huống như vậy không thiếu mỗi ngày khi bạn làm việc cùng khách hàng của bạn. Họ thường gửi cho tôi những yêu cầu được đề xuất từ AI - nhưng nó “không thực tế” một chút nào cả.
Báo cáo State of CRM Data Report 2026 cho thấy một con số đáng chú ý: gần 78% lãnh đạo cấp C-suite và 92% cấp SVP/VP thừa nhận đã từng hành động theo một khuyến nghị của AI mà sau đó họ nghi ngờ là sai vì dữ liệu đầu vào có vấn đề, so với chỉ 41% ở cấp nhân viên thực thi [3].
Nếu phần lớn đầu vào lẫn đầu ra đều cần được rà soát, thậm chí cần can thiệp trước khi một kết quả nào đó đến được hộp thư của CMO, thì phải có người đủ am hiểu chuyên môn để làm việc rà soát đó, nghĩa là công cụ AI chưa hề loại bỏ được kỹ năng cần thiết để làm công việc này. Việc đánh giá đúng sai của kết quả mới là phần khó hơn, và khó tái tạo hơn nhiều so với việc tạo ra kết quả đó.
Quy tắc rút ra từ cả hai trải nghiệm này: đừng bao giờ mua hay tự xây một công cụ cho một công việc mà không ai trong nhóm có thể tự tay xác minh độ chính xác. Vì khi đó, bạn sẽ không thể nhận ra lúc nó gãy, và nó sẽ luôn gãy một cách rất tự tin.
5/ Vì sao nên đổi từng bước nhỏ, thay vì đổi nguyên một khâu công việc?
Trong nội dung trước, tôi đã viết về “nghịch lý năng suất của AI” và kết luận “Giờ tiết kiệm được của người này lại là giờ mất đi của người khác”. Đó là lý do chúng ta nên cân nhắc tự động hóa từng bước nhỏ thay vì cả một quy trình.
Chỗ dễ vấp ngã nhất ngay từ đầu: nhóm của bạn nêu vấn đề rằng “một quy trình đang chậm”, và thế là quyết định để AI đảm nhận toàn bộ, rồi bắt tay xây một thứ xử lý cả 15 bước cùng lúc trong quy trình đó. Một tháng sau, nhóm bạn có một phần mềm nội bộ không có testing, không có document, và chỉ đúng một người hiểu cách bảo trì nó, cùng lắm là hai ba người biết cách vận hành.
Một công việc (job) là một ràng buộc nhiều bước, với sự cân nhắc rải rác trên khắp các bước đó. Một bước (step) chỉ có một đầu vào - một đầu ra, và một khâu kiểm tra chỉ mất vài giây.
Một bước trong công việc mà bạn muốn thay thế chỉ cần một đầu vào để xác thực, một đầu ra để kiểm tra bằng mắt thường và một việc cần sửa khi phiên bản mô hình thay đổi, trong khi quy trình 15 bước của bạn có đến 15 điểm có thể xảy ra lỗi và không có cách nào nhanh chóng để tìm ra lỗi ở đâu.
Trong nội dung trước, tôi đã nêu vấn đề rằng “mỗi workflow tự xây đều trở thành một công việc thường trực cần bảo trì”. Điều đó vẫn đúng. Nhưng đó là lý do để chia nhỏ công việc, chứ không lối tắt để nhảy cóc qua các công đoạn. .
6/ Làm sao tìm ra bước đáng để tự động hóa?
Hãy lấy đúng quy trình mà đội ngũ muốn tự động hóa, viết ra chính xác những gì đang thực sự diễn ra theo đúng thứ tự, rồi đánh dấu mỗi bước theo ba tiêu chí:
Đầu vào: là cái gì, và nó đến từ đâu? Nếu đầu vào của một bước là “mơ hồ, không cụ thể hóa”, thì đó chưa phải một bước đủ rõ ràng để tự động hóa.
Đầu ra: bạn muốn nhận lại gì, ở định dạng nào? Nếu câu trả lời vẫn không “cụ thể hóa”, hãy tìm tiếp bước khác.
Khâu kiểm tra: một người xác nhận đầu ra đúng bằng cách nào, và mất bao lâu? Khâu xác minh này là công việc thật, tốn thời gian thật, nên cần được tính vào kế hoạch từ đầu.
Bước đáng để tự động hóa là bước chậm, lặp lại, được định nghĩa rõ ràng, và có thể kiểm tra đúng sai chỉ bằng một cái liếc mắt.
Một ví dụ thực tế:
Đầu vào: Thông tin khách hàng gửi để làm hợp đồng trước khi 2 bên ký kết
Đầu ra: Một file word được tạo bằng tự động hóa dựa trên thông tin đầu vào
Khâu kiểm tra: pháp chế vẫn phải bắt buộc kiểm tra lại những phần nội dung quan trọng trong hợp đồng
Thông thường, một bước đáng tự động hóa nên là một việc làm tay click-copy-paste: dữ liệu thô thành bảng đã định dạng, gắn nhãn, internal link xuyên suốt các cụm nội dung...
7/ Điều gì khiến một bước không nên được tự động hóa?
Công việc mà mọi người hay tìm cách tự động hóa thành ba loại:
báo cáo (dễ tự động hóa),
tổng hợp (khó tự động hóa),
và ra quyết định (khó ở mức vừa phải).
Bất cứ việc gì đòi hỏi gu thẩm mỹ tinh tế, hoặc bất kỳ tác vụ tự động nào mà sai sót có thể gây ra hậu quả thì thường là dấu hiệu cho thấy cần phải cân nhắc kỹ lưỡng.
Nên loại một bước khỏi danh sách tự động hóa muốn xây trong nội bộ nếu:
Không ai trong đội có thể tự tay làm việc đó, nên cũng không ai có thể chấm điểm hay xác minh đầu ra.
Khâu kiểm tra mất thời gian còn lâu hơn cả việc tự làm (trừ khi đó là bản nháp dài, vốn tự nhiên cần thời gian để đọc lại).
Đầu vào thay đổi thường xuyên, khiến workflow khó lòng duy trì được.
Nó chạm vào một hệ thống bạn không kiểm soát được, nơi một bản cập nhật vào thứ Ba có thể làm gãy toàn bộ workflow vào thứ Tư.
Thử nghiệm luôn xứng đáng được thực hiện. Nhưng những vấn đề phổ biến nên được giao cho nhà cung cấp, họ tồn tại chính là vì lý do đó. Những vấn đề thực sự là của riêng bạn, mà đội ngũ đã hiểu rất sâu, có thể giao cho một người đã từng xây một thứ tương tự trước đây.
Và phần còn lại, sau khi đã loại bỏ hết những trường hợp trên, mới thực sự là phần thử nghiệm workflow AI đáng để làm trong nội bộ. Hãy gán cho nó một người chịu trách nhiệm, một ngày kết thúc rõ ràng (kill date), và một câu mô tả cụ thể thế nào là thành công. Còn lại tất cả những gì khác, đó chính là phát triển phần mềm, và nói thật, bạn đâu có tuyển nhóm marketing của mình về để viết phần mềm.
Nguồn trích dẫn:
[1] https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
[2] https://technologychecker.io/blog/ai-in-marketing-statistics-use-cases
[3] https://www.validity.com/resource-center/state-of-crm-data-report-2026/
