2026 年我們從營運主管聽到最常見的一句話——比「我要做新網站」或「我要做 App」都還常見——大概是這個版本：「我們一半的公司都跑在一張 Google Sheet 上，那張表開始撐不住了。」團隊從 6、8 人成長到 15、20 人。試算表換過三任 owner。新人要花一週才搞清楚哪個分頁做什麼。上一季某個外包不小心改錯了一格，財務花兩天對帳。沒有人能輸出一份「誰在什麼時間改了什麼」的稽核記錄。然後公司還在繼續成長。
這正是內部工具要解決的問題。也是多數外包合約搞砸的地方——因為簽合約的人腦袋裡想的是「對外網站」與「App」，不是「跑公司內部營運那層、不華麗、但價值極高的軟體」。
下面是我們怎麼替一個成長中的中小企業 scope、建置、交接一套內部工具——後台、營運儀表板、廠商入口、內部資料登錄 App——時程 4–8 週。
一、這項服務到底是什麼
內部工具建置是設計與建造一個有權限、有角色概念的 web 應用，用它取代 Google Sheets、共用收件匣、Slack 對話串、與一次性 PHP/Python 腳本所組成的脆弱拼裝。系統只給你的團隊用——不對外——它的任務是讓日常營運更快、更安全、更可稽核。
我們會交付的典型組件：
- 角色式存取層：admin、manager、operator、view-only，每一個動作都做權限檢查。
- 資料輸入與驗證表面：型別化欄位、連到真實資料的下拉選單、防止 Sheet 那種誤改細胞意外的驗證規則。
- 列表-詳情導航 pattern：可搜尋、過濾、排序、批次動作的列表頁；有完整修改歷史與行內留言的詳情頁。
- 輕量工作流引擎：工單狀態流轉、簽核鏈、指派——那些目前活在「某個人腦袋裡」的「若 X 則 Y」邏輯。
- 稽核日誌：每一次變更、每一個使用者、每一個時戳，保留到你所在產業要求的留存期。
- 報表表面：給營運每天早上看的指標儀表板，可匯出 CSV 或接你既有 BI。
- 批次匯入／匯出：因為沒有這個的工具，中小企業換掉後活不過半年。
- 輕量 API：讓你的會計、CRM、排程系統可以讀寫同一份資料，不要靠人類中轉。
我們預設的技術堆疊是 Laravel + Filament + MySQL + Tailwind，部署在 NGINX 後面、單台低成本伺服器，整個系統掛在公司 SSO 後（Google Workspace、Microsoft 365、或你既有 IdP）。Filament 後台框架讓我們能用「幾週」交付「手刻要幾個月」的東西，而底層仍然 100% 是標準 Laravel——未來任何工程師都能接著擴充。
二、怎麼 scope——兩週 discovery
每個內部工具案都從 1–2 週付費 discovery 開始，因為「資料模型沒設好」的代價是「正確做 discovery」代價的數倍。
discovery 期間我們做四件事。兩天 shadow——看團隊實際怎麼用現有試算表（永遠跟他們自己描述的不一樣）。分別訪談每一個角色——老闆、操作員、資料登錄、查看者——找出每個角色擁有的工作流步驟與真正的摩擦點。和你一起畫資料模型——把既有 sheet 拉成正規化 schema，並用三個真實情境驗證該 schema。然後狠下心排優先序——團隊想要 30 件事，我們找出能交付 80% 價值的 7–10 件，剩下 20 件放進 Phase 2 backlog 並編列明確預算。
discovery 的交付物是一份 15–20 頁的文件：資料模型圖、角色矩陣、user flow、MVP 功能清單、Phase 2 backlog、build 階段的固定報價、交付時程表。如果你不喜歡我們的提案，可以把這份文件拿去找別家做。我們確實有兩個客戶這樣做了——這份文件的價值與「誰做」無關。
三、怎麼 build——4–6 週建置
建置切成兩週為一個 sprint，每個 sprint 結尾都有一個可運作的 demo。
Sprint 1 交付資料模型、認證、角色式存取、以及前兩個畫面——通常是「最高流量的列表頁」與「最高價值的詳情頁」。這是會告訴我們「discovery 的模型有沒有撐住現實」的 sprint。大約 30% 的案子會在這個 sprint 改掉一個主要欄位型別或關聯——這是正常的，預算裡有編。
Sprint 2 加入剩下的列表頁、工作流轉移、稽核日誌、批次匯入。Sprint 2 結束時，團隊就可以停止用試算表做主要輸入了——即使還有功能沒做完。
Sprint 3 加報表、匯出表面、上下游整合用的 API，以及打磨——錯誤狀態、空狀態、loading 指示、少數會在手機上用到的畫面的響應式版型。
build 期間，營運團隊從第一天就有 staging 權限。每週五我們在現場跑 30 分鐘 UAT。session 跑出的 bug 與功能請求，是整個案子訊號最強的東西；我們在會議結束前就把它們排進下一個 sprint backlog。
四、交接什麼——以及多數中小企業在這一步翻車的原因
工程結束時，你會收到：在你自己 GitHub 組織下的原始碼、部署用的 infrastructure-as-code、後續維運用的後台手冊、給團隊的 2 小時訓練、以及 90 天減價的 post-launch retainer，處理 bug 與「Phase 1.5」打磨需求。
中小企業翻車的時刻在交接之後。系統能跑、團隊滿意，然後六個月後有人說「可不可以加 X？」如果原本的工程工作室不在了，連簡單的修改都可能卡幾週。我們建議、也提供：輕量 retainer，第一年每月 4–8 小時。多數月份你會用零小時。一年有兩三個月會把累積的時數用掉，出貨一個有意義的改進。retainer 讓系統不會慢慢回到「試算表 workaround」的失敗模式——這個失敗模式是每一個內部工具最後都會遇到的。
五、我們看到的常見場景
最近做過的五個具體案例，去識別化：
一家 14 人的製造業供應商，取代一張追蹤 2,000+ 零件 SKU、供應商交期、PO 狀態的 Google Sheet。6 週、MySQL + Laravel + Filament。結果：第一季 PO 錯誤降到零；客戶端準時交貨率從 86% 升到 94%。
一家 25 人的 B2B 服務公司，取代一個用 Slack 對話串與共用收件匣處理客戶 onboarding 的流程。5 週、完整稽核軌跡、Phase 1.5 加上對客戶唯讀的入口。結果：onboarding 週期從 9 天降到 3 天；onboarding 的 NPS 從中性轉正。
一家有 11 家店的區域零售商，取代各店紙本盤點流程，做成共享、行動優先的盤點 App。4 週、可離線 PWA、每日同步。結果：庫存準確率從約 85% 升到約 98%，人力沒增加。
一個有 40+ 醫療人員的醫療院所集團，取代各家用 Excel + WhatsApp 協調排班的流程。8 週（因為要符合本地等同 HIPAA 的合規而多兩週），完整稽核日誌。結果：失約率下降 11 個百分點。
一家 50 位承包司機的物流公司，取代用電話 + Excel 派工的流程，改成派工員 web 工具 + 司機 App + 客戶簡訊通知。7 週。結果：準時派遣率從 78% 升到 91%；運量成長 30% 但派工員人力沒增加。
共通模式不華麗、事後看也很明顯。這些公司不是被對外形象卡住的。是被「跑營運的試算表+Slack 骨架」卡住的。把他們解開的那個建置，不是網站改版、也不是新 App，而是那個原本沒人編預算的內部工具。
六、價格與時程的指引
對於典型中小企業案——5–10 個角色、4–6 個主要資料實體、3–5 個工作流、8–12 個畫面——價格區間約等於一位中階工程師兩個月的薪資總額，discovery 階段另計，占整體 5–10%。時程端到端 6–10 週，每週五一個可運作 demo。我們不接「沒有兩週 discovery」的案子，我們學過跳過這一步的失敗模式。
post-launch retainer 以年約計價、按季結算，年費約 build 成本的 8–12%。多數客戶第一年用掉這個量的 30–50%，第二年要嘛續約減價、要嘛把維護收回自家。
如果團隊的日常營運活在一張「已經重要到不能壞」的 Google Sheet 裡，這就是這項服務。如果你想替團隊 scope 一個內部工具案——並且想在承諾建置前先看到 discovery 的交付物——我們從一通 90 分鐘的對話開始，沒承諾義務，走過你目前的試算表與它在上一季帶來的代價。