企業 AI 導入 RFP 與需求盤點範本:排程、文件、客服三類 use-case 怎麼寫規格

上季有家製造業客戶把 RFP 寄給我們,標題寫得很認真:「導入 AI 提升營運效率」。內文十二頁,列了三十七項「期望功能」,從自動排程、報表分析到智慧客服全包。我讀完只有一個問題想問:你們現在最痛的那件事,一天發生幾次?對方愣了幾秒,回:「這個要問各部門。」

這就是問題。一份問不出使用頻率的 RFP,廠商只能報一個「看起來都能做」的價格,然後上線後大家一起後悔。

一份能用的「AI 導入 RFP 範本」,重點從來不是把功能列滿,而是把三件事寫死:誰在什麼情境下、用多少次、成功長什麼樣子。這篇給你可以直接複製貼上的需求盤點清單與規格骨架,涵蓋企業最常導入的三類 use-case:排程、文件、客服。

先做需求盤點,再談 RFP

在寫任何規格之前,先花兩天把下面這張清單填完。填不出來的欄位,就是你還沒準備好發 RFP 的訊號。

• 觸發情境:這個需求一天/一週被觸發幾次?尖峰在什麼時段?我們看過一個「急需 AI」的需求,實際一週只跑四次,根本不該優先做。
• 現況基準線:現在是誰在做、平均花多久、錯誤率多少?沒有 before,就沒辦法證明 after。
• 資料現況:資料在哪個系統、什麼格式、乾不乾淨、誰有權限?RAG 系統八成的坑都埋在這裡。
• 成功門檻:上線後要達到什麼數字才算驗收通過?寫「提升效率」等於沒寫,要寫「客服首次回覆時間從 8 分鐘降到 2 分鐘內」。
• 採用責任人:上線後誰負責讓同事真的用?沒有這個人,使用率通常卡在個位數。

這五欄填完,你的 RFP 就已經贏過市面上八成的版本。

三類 use-case 的規格怎麼寫

不同 use-case,規格的重心完全不同。用同一套模板套三種需求,是我們最常看到的踩雷。下面這張表把每類要在 RFP 裡寫清楚的欄位攤開:

排程類要特別寫清楚「硬約束」。AI 可以優化,但不能違反法規工時或產線物理限制,這些要當成不可跨越的紅線寫進規格,而不是期待模型自己學會。

文件類最容易被 Demo 騙。Demo 那天問的都是漂亮問題,上線後同事問的是刁鑽的邊角案例。RFP 裡一定要要求廠商附上「引用來源可溯源」與「查無資料時誠實回答不知道」這兩條,不然你買到的是一台會自信亂編的機器。

客服類的關鍵不是答得多快,而是知道自己什麼時候該閉嘴。信心不足就轉真人,帳務、退款、法律相關的問題要能被明確排除在自動回覆之外。我們幫客戶寫這類規格時,「絕不自動回覆清單」通常比「能自動回覆清單」更重要。

把驗收寫進 RFP,而不是留到最後

大部分 RFP 的驗收條款只有一句「功能符合需求」。這句話讓所有人都能過關,也讓所有人都不滿意。

正確做法是在 RFP 階段就把測試集定義好:排程類用近三個月真實工單回放、文件類準備一百題人工標註的問答、客服類跑兩週影子模式跟真人並行對比。這些數字寫進合約,驗收那天就沒有「感覺還不錯」的模糊空間。

我們自己接案時,幾乎都是從幫客戶重寫這份需求盤點開始,因為工程師進場前如果規格是糊的,再強的模型也只是做出另一個 4% 使用率的漂亮 Demo。Demo 很美不算數,寫得清楚、上線有人用,才算。