需求文件(RFP)怎麼寫?讓報價精準的十個問題

需求文件(RFP)寫得好不好,直接決定你收到的報價準不準。我們收過一句話的需求——「想做一個像蝦皮的網站」——也收過三十頁但關鍵資訊全缺的簡報。這篇從報價方的視角,講一份好 RFP 該回答的十個問題。不用寫成論文,一到三頁、把這十題答清楚就夠。

第一部分:商業脈絡(最重要,最常缺)

1. 你是誰,靠什麼賺錢?公司簡介兩三句,加上這個專案跟營收的關係。我們報價前一定會問這題,因為「幫你賺錢的功能」和「老闆想要的功能」優先序完全不同。
2. 這個專案要解決什麼問題?「訂單都用 LINE 接,每月漏單十幾筆」比「想要一個訂單系統」有用一百倍。講問題,不要講你想像的解法。
3. 成功長什麼樣子?上線半年後,你希望哪個數字變了?詢問數、訂單數、省下的人力時數,挑一個。

第二部分:範疇(報價準度的關鍵)

1. 核心流程有哪些?用「使用者做什麼 → 系統做什麼」的句型列出來。例:「客人選時段付訂金 → 系統發簡訊提醒 → 到期前一天再提醒」。
2. 誰會用後台?做什麼?角色與權限是報價的隱藏變數。一個角色和五個角色,是不同量級的工程。
3. 要跟哪些既有系統或服務串接?金流、發票、POS、LINE、內部 ERP——每一條串接都是工時,先列出來。
4. 內容誰提供?文案、商品資料、照片是你給還是廠商做?這塊沒講清楚,是時程延誤的第一名原因。

第三部分:限制條件

1. 預算區間是多少?很多人怕講了預算會被報好報滿。實情相反:不講預算,廠商只能亂猜範疇,報價反而失準。講一個區間,讓廠商告訴你「這個預算能做到哪裡」。
2. 時間底線在哪?為什麼?「雙十一前要上線」是有意義的底線;「越快越好」不是。
3. 有沒有不可妥協的事?資料要留在台灣、要能匯出、原始碼要交付——先講,免得簽約後才發現。

RFP 的目的不是把廠商考倒,是讓每一家廠商報的是同一個專案。

常見的反效果寫法

• 直接指定技術方案:除非你真的懂,否則寫問題就好,解法留給專業。
• 功能清單複製競品全站:你會為用不到的功能付錢。先砍到「不能沒有」的最小集合。
• 「細節見面再談」:見面前對不齊範疇,見面後也對不齊。

RFP 過了報價關之後,下一份文件是規格書,那是另一門功夫,可參考規格書怎麼寫。如果你正要發需求、不確定寫得夠不夠,歡迎預約免費 30 分鐘諮詢,把草稿帶來,我們用報價方的眼睛幫你檢查一遍。