首頁 / 資源 / 預算與報價怎麼算

Pricing 預算與報價怎麼算 報價單上的每一項,
都寫清楚怎麼驗收。

客製化系統的預算,取決於做什麼、接什麼、給誰用,以及上線後誰負責。JoinX 的報價單會把系統拆成區塊、模組與一項一項的功能,每一項都寫清楚規格描述、驗收方式和預估天數,也寫明這次不做的事。天數是估算依據,你驗收的是規格裡寫的成果。

01報價單長什麼樣子

不是一個總價, 是一份可以逐項核對的清單。

以一份投信網站的無障礙專區報價為例(內容已改寫、金額省略)。把滑鼠移到(或點選)說明,看它對應報價單的哪個部分。

示意・內容已改寫,非實際報價
報價單|無障礙服務專區(示意)客戶:○○投信
專案窗口・業務窗口・報價日期
區塊模組項目與規格描述天數
1 前台資料查詢查詢表單與結果表格
  • 沿用既有資料來源與查詢邏輯,只調整呈現方式
  • 日期格式錯誤時,於欄位旁顯示錯誤並把焦點帶回該欄位
  • 查無資料時顯示明確訊息,不呈現空白表格
  • 查詢失敗時保留原查詢條件,讓使用者重新送出
3
2 前台文件下載文件分類與下載
  • 連結文字標示檔案格式,不只寫「下載」
  • 另開新視窗時事先標示,目前頁面狀態不受影響
3
3 共同專案管理
  • 需求訪談與系統功能規劃
  • 流程圖與線框圖等規劃文件
  • 開發進度追蹤與定期回報
  • 需求變更的影響評估
4
共同功能測試
  • 依規格逐項驗證功能與操作流程
  • 問題回報、修正追蹤與複測
  • 驗收前的整體回歸測試
3
4範圍外只處理專區既有頁面,不新增頁面或資料功能;若需擴大範圍,另行估價。
5驗收與保固交付後依規格逐項驗收;保固期內,可界定為程式錯誤者於約定時間內修正。
6交付物原始碼、企劃線框圖、規格文件、設計檔、檢查清單。版權屬於客戶。
環境與責任測試環境由 JoinX 提供;正式環境由客戶提供,協助安裝。不含硬體、主機與 CDN。
  1. 1
    每一項都有規格描述

    不是只寫「查詢功能」四個字,而是寫清楚正常、錯誤、查無資料、失敗時各要怎麼表現。這些就是驗收時逐條核對的標準。

  2. 2
    依區塊與模組分組

    前台、後台、APP、API 分開列,再細分到模組。你可以一眼看出錢花在哪裡,也方便決定哪些先做、哪些延後。

  3. 3
    看不見的工作也列出來

    需求訪談、流程與線框圖、進度回報、測試與複測都單獨列項。報價差很多時,通常就差在這些有沒有算進去。

  4. 4
    不做的事寫清楚

    範圍外的事直接寫在報價單上。之後要加,就另外估價,不會在驗收時才發現彼此認知不同。

  5. 5
    驗收與保固有規則

    交付後怎麼驗收、多久內修正、保固涵蓋什麼,都在簽約前講好。

  6. 6
    你拿到的東西

    原始碼、規格文件、設計檔全部交付,版權屬於你;哪些環境由誰提供,也事先寫明。

02影響預算的事

預算的差距, 通常來自這 6 件事。

01

要串接幾個既有系統

ERP、POS、金流、物流、會員系統……每多一個串接,就多一份對接規格、測試與例外處理。

預算增加對方沒有現成 API、文件不完整,或資料格式要轉換
02

有幾種使用者與權限

前台會員、第一線員工、主管、總部管理員,角色越多,畫面、流程和權限設定就越多。

預算增加需要依部門、分店或資料範圍細分權限
03

有沒有舊資料要搬

從 Excel 或舊系統搬資料,要先清理、對照欄位、轉換格式,再驗證搬過來的資料對不對。

預算增加資料量大、格式不一致,或新舊系統要並行一段時間
04

要做哪些平台

只做網頁,或同時要 iOS、Android APP 和管理後台,每個平台都有各自的設計、開發與上架工作。

預算增加需要離線使用、推播、藍牙或硬體裝置串接
05

上線後要什麼等級的支援

從 5×8 到 7×12 的支援時段、主機與系統管理、監控與備份,維運範圍決定上線後每個月的投入。

預算增加需要更長的支援時段,或由我們代管主機
06

資安與法規要求

金融、醫療、公部門或無障礙標章等要求,會增加檢核項目、文件與稽核配合的工作。

預算增加需要通過第三方檢測或主管機關稽核
03分階段報價

需求還不清楚時, 先別急著要總價。

需求越模糊,總價就越不準:不是報得太高,就是之後一直追加。所以我們通常分階段報價,每一階段結束時,你都可以決定要不要繼續。

PHASE 1

釐清需求

走進你的現場、一起畫出流程、做出可操作的原型。範圍、優先順序和例外情況都在這個階段講清楚。

你會拿到:流程與需求整理、原型、開發報價
PHASE 2

開發與上線

依 Phase 1 確認的規格逐項開發,定期 demo;交付後依規格逐項驗收,再正式上線。

你會拿到:可驗收的系統、原始碼與文件
PHASE 3

維運與持續開發

主機、維護、資安和支援依維運合約進行;新需求另外估價,同一個團隊接著做。

你會拿到:穩定運作的系統,以及下一個版本
04合作方式與預算特性

三種計價方式, 適合不同的狀況。

方式適合什麼狀況預算怎麼變動
固定範圍需求明確、變動少,例如已經有流程與原型的系統總價清楚;範圍外的需求另外估價
分階段迭代需求要邊做邊驗證,例如新產品或第一次數位化的流程每一階段各自報價,依結果決定下一步
PoC/MVP先驗證技術可行性或市場反應,例如 AI 應用或新服務刻意縮小範圍,用較少的預算先學到答案;核心的安全與品質要求不變
05常見時程

時程可以先有個底。

以下是常見情境的參考時程,確切時程會在提案時寫清楚。

4–6 週企業官網品牌與服務介紹、內容管理
3–6 月中型平台或 APP會員、金流與管理後台
6–8 週MVP先上線核心功能,再逐步擴充
6–12 月大型企業系統分階段上線,不等到最後一天
FAQ關於預算與報價

簽約之前, 先把這些問清楚。

逐項比較報價的正確方式

「為什麼每家的報價差這麼多?」

通常不是同一件事的價格不同,而是範圍不同。請把各家報價單並排,逐項比較:有沒有列出需求訪談、設計、測試與複測?規格描述寫到多細?範圍外寫了什麼?會不會再轉包?上線後誰負責?只比總價,最便宜的那一份往往是寫得最少的那一份。

天數估算依據,不是驗收標準

「報價單上的天數是什麼意思?」

天數是我們估算每一項工作量的依據,讓你看得出哪些項目比較重。驗收時看的是規格描述有沒有做到,不是實際花了幾天。

變更先評估影響,再決定

「做到一半想加功能,怎麼辦?」

可以加。我們會先評估這項變更對時程和費用的影響,跟你確認後再排進開發;範圍外的需求另外估價,不會在驗收時才算總帳。這也是為什麼報價單要把範圍外寫清楚。

MVP縮小範圍,不降低品質

「先做 MVP,是不是就做得比較差?」

不是。MVP 縮小的是這次要驗證的問題範圍,不是品質標準。核心流程一樣要符合資安、測試與可維護性的要求,之後才能在同一套系統上繼續長大。

想知道你的系統大概要多少?

不用先準備規格書,帶著你想解決的問題來就好。我們會先幫你判斷範圍,告訴你哪些事最容易讓預算失控。