一句話摘要
將原本以紙本與 Excel 為主的報價單，重新設計為適合業務展間接待、即時報價、數位簽署、PDF 留存與後續工程交接的線上工具，並讓報價結果可以回到客戶概覽頁，成為後續追蹤與流程自動化的基礎。
工具上線並進入業務現場使用後，我也持續根據實際操作回饋調整設備選項、付款條件、報價單版面與資料串接方式，讓它從第一版工具逐步變成更貼近現場流程的業務系統。
專案背景
有一天，業務同仁拿了兩份報價單給我。
那是兩份紙本資料，上面分別列出兩種不同情境的預估價格：一種是局部安裝，另一種是全屋安裝。這樣的設計原本是為了讓業務在展間接待客戶時，可以更快提供價格感，協助客戶理解方案差異，也提高提前成交的可能性。
乍看之下，這份報價單沒有什麼大問題。它很穩重、很踏實，也符合公司過去長期使用的工作習慣。
但我看著它時，腦中浮現的第一個問題是：
如果我是業務，我真的會想用這樣的方式報價嗎？
報價會隨著設備數量、安裝範圍、應用情境與折扣條件改變。當這些變數仍然仰賴手動輸入、紙本確認、Excel 修改與後續人工交接，整個流程其實就會留下很多容易出錯、重複作業與資訊斷裂的空間。
而且更現實的是，業務同仁在展間接待客戶時，通常不是坐在辦公桌前慢慢開 Excel，而是拿著平板、一邊 demo 產品功能，一邊跟客戶討論需求與預算。
所以我開始想：如果這份報價單不是一份「文件」，而是一個可以直接支援現場成交的工具，它應該長什麼樣子？
這個任務一開始服務的是業務端需求：讓業務可以在展間接待或客戶溝通後，更快產出一份格式一致、內容完整，也比較正式的報價單。
但工具進入實際使用後，我才更清楚看見，報價單其實不只是業務對外溝通的文件。它同時牽動財務核帳、設備成本、安裝成本、佣金計算、ERP 料號、追加減版本，以及後續 CRM 資料追蹤。原本看起來像是「報價單格式」的問題，實際上是一個跨部門工作流程問題。
這也改變了我對這個專案的理解。這個工具除了處理業務對外專業度，也讓原本依賴 Excel、口頭同步與人工記憶的報價流程，逐步變成可以被追蹤、交接與維護的工作系統。
我的角色
這個專案一開始不是正式被指派的任務，而是從一個日常觀察開始。
我的角色主要包含：
- 重新理解業務報價的實際使用情境
- 將原本 Excel 報價單轉換成線上工具邏輯
- 與 AI 協作建立網頁版報價單雛形
- 根據業務、客戶、工程師與財務需求補上流程細節
- 依照品牌 guideline 重新設計報價單視覺與資訊版面
- 根據業務現場回饋持續調整設備選項、付款條件與列印版面
- 串接客戶概覽頁，讓報價金額與品項摘要可以回到客戶 profile
- 協助團隊從單一報價工具，延伸思考後續流程自動化的可能性
問題觀察
原本的報價流程有幾個明顯問題。
一、報價仍然偏向人工操作。 價格、設備數量、折扣、備註等資訊需要手動輸入與調整，不只耗時，也容易出現版本不一致或計算錯誤。
二、報價單不完全符合展間接待的真實情境。 業務在展間與客戶互動時，通常會使用平板 demo 產品情境。如果報價工具不能順著這個情境設計，就會讓業務在「展示產品」與「處理報價」之間來回切換。
三、報價單不只是給客戶看的文件，也會影響後續內部交接。 成交後還有場勘、設備規劃、工程安裝、發票與付款確認。如果報價單沒有承載足夠的結構化資訊，後續就需要靠業務額外補充或口頭交接。
四、原本的文件視覺與資訊排版已經偏舊。 報價單是一個重要的品牌接觸點。客戶看到的不只是價格表，而是公司是否專業、是否值得信任的第一印象。
五、報價結果過去不容易回到客戶追蹤流程。 業務完成報價後，報價金額、主要品項與後續付款條件如果沒有被整理回客戶資料中，後續追蹤時仍然需要重新開檔案或回頭找試算資料。
解決方向
我一開始就不想只做一個「網頁版 Excel」。 原本的公式和價格邏輯可以沿用，但工具一旦變成線上版本，就應該更貼近實際接待現場。 所以我把重點放在業務怎麼操作、客戶怎麼看、報價怎麼被確認，以及後續資訊怎麼交接。
今年年初，我上了台大資工開設的 Python 課程，對 coding 有了基礎理解。雖然還不能完全獨立從零寫出完整系統，但我已經能理解程式邏輯、資料如何被處理，以及如何把需求拆成 AI 可以協作的任務。
因此，我透過 Claude 協作，把原本的 Excel 報價單轉換成線上版報價單雛形。原始公式與價格邏輯已經存在於 Excel 中，所以第一步並不是最難的部分。真正重要的是：當它變成線上工具後，應該加入哪些原本 Excel 做不到的使用體驗？
主要設計
1. 平板優先的現場報價體驗
我預設業務在展間使用平板接待客戶，因此整個報價單要適合在平板上操作。按鈕、欄位、資訊密度、報價結果呈現方式，都要考慮現場情境。客戶可能會同步看著螢幕，業務也需要快速切換不同設備數量、方案與折扣。
所以設計時，我一直把現場操作放在前面：業務能不能快速調整數量、切換方案，並在客戶還坐在面前時，就把價格與文件確認下來。
2. 即時計算價格與折扣
線上版報價單本身就是一個計算機。業務可以直接輸入或調整設備數量，並套用可操作的折扣空間，底部總價會即時更新。這讓業務可以在現場快速提供不同組合的價格感，而不是事後再回去整理報價。
後續也依照業務情境加入不同優惠名稱、整數化折扣設定與實收金額千位捨去，讓報價結果更符合現場溝通與正式文件呈現。
3. 數位簽署與 PDF 儲存
既然報價單已經數位化，我認為簽署也不應該再回到紙本。工具加入了線上簽署欄位，讓客戶可以直接簽署，並將簽署後的文件儲存為 PDF。現場確認、現場簽署、現場留存。
4. 業務名稱、簽名檔與草稿管理
同一份工具會由不同業務使用，因此加入了業務名稱管理與草稿儲存的設計。業務可以選擇自己的名稱，系統帶入對應資訊與簽名檔。報價單也具備自動儲存功能，不需要一次完成，之後可以繼續修改。
5. 報價有效期限改為日期選擇
報價有效期限改為由業務直接選擇日期，系統自動換算有效天數並顯示在報價單上。這個操作方式比手動輸入天數更直覺，也能減少現場心算與日期不一致的問題。
6. 工程交接資訊整合
報價單不只給客戶看，也會提供給後續場勘與安裝的工程師參考。因此加入了設備備註欄位，讓業務可以選填房間位置、應用設備與相關細節，這些資訊可以直接出現在報價單上，減少後續人工交接。
這讓報價單從一份「成交前文件」，變成一份可以往後承接流程的工作資料。
7. 視覺與資訊重新設計
依照品牌 guideline 重新設計版面，並調整文字資訊的排列方式。目標不是把資訊刪到很少，而是在必要資訊完整的前提下，讓報價單更短、更清楚，也更像一份專業品牌會提供給客戶的文件。
後續我也調整了設備清單的輸出排版。原本品項編號放在類別左側，閱讀上容易讓人誤會編號是整個類別的一部分。後來我把結構改成先顯示設備類別，再在同一個類別底下依序列出 1、2、3 等品項。這樣客戶看到報價單時，可以更快理解每一項設備屬於哪個分類，也讓文件看起來更接近正式的報價格式。
8. 付款條件與優惠方案連動
付款階段也配合優惠方案做了調整。當業務選擇「一次付清優惠」時，下方付款階段會自動改成 100% 一次付款，避免報價總計已經套用一次付清折扣，但付款階段仍顯示成分期付款，造成客戶理解上的落差。
這個調整讓金額、折扣與付款條件能保持一致，也減少業務在現場需要額外解釋的機會。
9. 報價結果回寫客戶概覽頁
報價工具目前也已經可以和客戶概覽頁串接。業務在報價工具中按下「預覽列印」後，系統會把報價金額、報價日期、主要報價類別與品項摘要帶回對應的客戶 profile。
這讓後續追蹤時，業務不用另外打開報價檔或回頭找試算資料，就能在同一個客戶頁面看到目前的報價狀態。報價單因此不只是一次性的輸出文件，也開始成為客戶追蹤流程中的一筆可用資料。
後續延伸：讓同一份資料服務不同角色
工具後續延伸出一份內部專案成本核算表，提供業務與財務使用。這份文件不直接給客戶，而是整理專案成本、設備成本、安裝成本、佣金、其他費用與利潤率。
整理這份文件時，我發現同一批報價資料面對不同使用者時，重點順序也要重新設計。客戶需要先理解方案與價格，財務則會先看成本、佣金與利潤。因此內部文件把財務資訊放在品項表格上方，讓使用者一打開文件就能先看到最重要的數字。
這次也加入追加減版本管理。業務直接在原本的報價工具中調整品項，按下追加減後，系統會自動比對最新版本，顯示差異預覽，確認後再儲存。這樣不需要另外建立一套編輯介面，也更貼近業務原本的工作方式。
這個調整讓我重新理解「報價」這個節點。它不只是客戶文件的輸出點，也是業務、財務與 CRM 資料之間的交會點。當資料開始被結構化，後續能改善的就不只是報價效率，也包含跨部門之間如何對齊資訊、追蹤版本與減少重複確認。
AI 在這個專案中的角色
這個專案很大一部分是透過 AI 協作完成的，但我不會把它理解成「AI 幫我做了一個工具」。
AI 最大的幫助，是讓我能更快把想法變成可以測試的雛形。 不過，工具能不能真的派上用場，仍然取決於前面的需求判斷。 我需要先理解誰會使用它、在哪裡使用、原本卡在哪裡、哪些資訊不能漏掉，以及這個工具要怎麼接進公司原本的工作方式。
對我來說，這是一個很典型的現場問題解法：先看懂流程，再用合適的工具把它整理成更好操作的形式。
意外延伸：成為流程自動化的起點
第一版完成後，我向業務說明這個工具。沒過多久，財務也加入了討論。
原來財務本來就有計畫修改相關流程——目前一旦業務成交，後續還需要手動寫一封信給相關人員，讓財務確認發票與付款事宜。
我做的這份線上報價單，剛好可以成為後續流程自動化的開頭。當報價單本身已經變成結構化資料，就代表未來有機會進一步串接成交回報、財務通知與發票資訊確認。
後來報價工具進一步與客戶概覽頁串接，也讓這個方向變得更具體。報價不只停留在 PDF 文件裡，而是可以回到客戶 profile，成為後續業務追蹤與內部交接時能直接使用的資訊。
有時候數位化不是從一個宏大的系統規劃開始，而是從一個看起來很小、但剛好卡在流程關鍵位置的工具開始。
目前狀態
工具已進入業務現場使用，並在實際報價情境中持續累積回饋。第一版完成後，這個工具開始承接更多後續流程：品項資料維護、ERP 料號對應、內部成本核算、追加減版本管理，以及業務與財務之間的交接需求。
近期我依據新版報價單範本，重新對照並更新 60 多個品項的售價、成本、品名與功能描述，同時為每個品項建立 ERP 料號欄位。這讓報價資料可以銜接業務 key 單與財務核帳，也讓報價工具更接近實際營運流程。
這次更新也讓我發現，品項維護不是單純改價格。有些產品結構已經改變，例如原本合併在同一個名稱下的控制器，實際上已經拆成不同用途的新品項。如果沒有仔細比對 Excel 範本與現有工具邏輯，這類變化很容易被漏掉。
後續也新增了內部專案成本核算表與追加減版本管理。前者整理設備成本、安裝成本、佣金、其他費用與利潤率，讓財務可以更快掌握專案成本；後者讓業務直接在原本的報價工具中調整品項，再由系統自動比對最新版本並顯示差異。
這次更新也讓我更清楚看見，報價工具真正重要的價值，不只在於計算價格，而是把原本分散在業務經驗、Excel 表格、財務需求與客戶文件裡的資訊，整理成一套可以持續維護的工作邏輯。
我學到的事
一開始，這個專案看起來只是一份報價單。但整理到後來，我才發現它其實連著很多後續流程：業務怎麼接待客戶、客戶怎麼理解價格、工程師怎麼接手資訊，財務又怎麼確認成交與付款。
這個專案也讓我更清楚感受到，AI 協作要真的發揮作用，前面需要有人先把資料整理方式、輸入與輸出邏輯、現場操作情境想清楚。
因為之前上過程式語言課，我知道只要邏輯能被清楚拆解，就有機會透過程式實作出來。像是業務選擇特定設備時，系統可以自動帶入必要配件並一起計算，這其實是把原本靠人記憶的報價規則，轉成工具可以處理的邏輯。
工具進入實際使用後，業務回饋也讓我看見很多自己原本不會知道的細節。例如有些客戶報價時還沒交屋，開關面板顏色無法馬上決定；業務因此建議加入「顏色待定」選項，並在報價單上列出可選顏色。我再把這個回饋轉成工具裡的選項與列印顯示規則，讓客戶後續可以直接透過報價單了解有哪些選擇。
整個專案都在現有的報價單邏輯之下，先數位化，再透過業務實際回饋持續調整。我不斷檢查哪些設計可以讓報價單更嚴謹、更順手，也讓後續資料更容易被追蹤與使用。
最近除了密切合作的業務，其他業務夥伴也開始主動詢問這個報價工具是怎麼做出來的，並給了很多正面回饋。對我來說，這是很大的成就感，代表它已經從一個自己主動做出的工具，逐步進入團隊實際使用的工作流程。
這次持續更新也讓我更明確感受到，工具設計的價值不只在於把一件事做得更快。當一個工具真的進入工作現場，它會暴露出更多原本被人工經驗掩蓋的流程問題：哪些資料其實需要被追蹤、哪些角色會使用同一份資料、哪些資訊需要被分開呈現，哪些變更需要留下紀錄。
對我來說，這個專案後來最有價值的地方，是它讓原本土法煉鋼的跨部門溝通變得更清楚。業務可以用它產出客戶文件，財務可以用它核對成本與利潤，後續 CRM 也可以承接報價紀錄。它也從一次性的報價單改善，逐步變成整理營運流程的起點。