一句話摘要
從一份業務回饋表出發，重新整理展間接待、客戶問卷、CRM、報價工具與客戶概覽頁之間的資料流。目標是讓原本停留在口頭同步裡的第一線觀察，變成可以被記錄、累積與追蹤的資料。
專案背景
展間一直是我們理解客戶的重要現場。
客戶來到現場後，常常會透露很多比問卷更真實的資訊：他們為什麼想做智慧家庭、看過哪些競品、對價格或施工有什麼疑慮、哪些地方讓他們猶豫，最後為什麼成交或沒有成交。
但這些資訊過去大多停留在對話裡。
行銷想知道第一線發生什麼，就要一直和業務同步；管理端想理解客戶在想什麼，也要再請業務回想、補充、整理。久了之後，我開始覺得這件事有點消耗。
業務其實有觀察到很多事，只是他們的工作節奏本來就不是坐下來寫一份完整紀錄。很多有價值的片段，通常要經過追問才會被說出來。
所以我一開始想做的事情很單純：把這些問題整理成更容易回答的題型，讓業務在接待後用勾選或簡短補充的方式留下紀錄。
這個專案最早不是 CRM 專案。
我原本只是想做一份業務回饋表，讓業務在接待完客戶後，可以快速記錄幾件事：
- 客戶的主要需求
- 看過哪些競品
- 目前卡在哪裡
- 有沒有值得行銷或管理端注意的反應
剛好管理部也有類似需求。他們也想知道第一線到底發生了什麼，例如客戶最在意哪些問題、案子為什麼沒有成交、現場是否有一些可以改善的地方。
既然大家都需要這些資訊，與其一直分頭問業務，不如把它整理成一份可以累積、可以統計的資料。
我的角色
這個專案從我對展間流程的日常觀察開始，不是正式被指派的任務。
我的角色主要包含：
- 觀察並釐清資訊斷裂的位置，包括業務回饋、客戶問卷、CRM 與報價工具之間的落差
- 重新設計資料流動邏輯，決定哪些資料由誰填、在哪裡填、哪些資料應該自動帶入
- 設計業務使用的 Sales Tool 介面與回饋欄位
- 調整客戶滿意度問卷，減少重複填寫與資料對應負擔
- 與 AI 協作（Gemini 與 Claude）完成主要開發流程
- 協調業務與管理端的不同需求，找到可以同時服務兩邊的設計方式
問題觀察
真正開始整理之後，我才發現，問題比我一開始想的更大。
我們原本就有客戶填寫的 Google 表單，也有滿意度調查，業務有時候也會在 Google Sheet 裡補充回饋。資料看起來都有地方放，但它們其實是分散的。
1. 客戶資料重複填寫
客戶預約時已經填過聯絡資料，到了現場或填滿意度問卷時，卻常常還要再填一次，只是為了讓我們回頭對應是哪一筆資料。
更麻煩的是，同一個案子不一定會留下同一支電話。可能是先生預約時留了一支電話，太太到展間現場又填了另一支，最後 CRM 裡看起來像兩位不同客戶。資料一旦對不起來，後續的接待紀錄、問卷回覆與報價資訊也很難串在一起。
2. 業務回饋沒有回到 CRM
業務接待後的觀察，不一定會自然回到 CRM 裡。這些資訊如果沒有一個固定位置，很快就消失在對話裡。
3. 報價資料是獨立的流程
報價工具產生的金額與客戶資料，和 CRM 之間還是分開的，需要人工對應。
4. 新表單會變成新的資料孤島
如果直接新增一張回饋表，卻沒有解決資料散落的問題，新的表單只會成為另一個新的資料來源，讓情況更複雜。
解決方向
我把問題拆成幾個比較實際的判斷：
- 客戶已經在預約時填過的資料，能不能不要再填一次？
- 業務接待後觀察到的資訊，能不能用更輕量的方式留下來？
- 客戶滿意度問卷裡，哪些資訊其實可以由既有資料帶入，不需要請客戶再填一次？
- 報價工具產生的金額，能不能回到 CRM 裡？
- 如果同一個客戶在不同地方留下不同資訊，系統應該怎麼判斷？
這些問題想清楚後，我把原本單純的回饋表，重新整理成業務使用的 Sales Tool，並以此為核心，重新規劃整個 CRM 資料流。
一開始我也想過讓客戶自己填表來補充接待資訊，但現場體驗時間有限，太多填寫動作容易打斷節奏。所以我把兩邊分開處理：業務端設計成 Sales Tool，由業務輸入最少資訊，系統自動帶入 Google 日曆與 CRM 既有預約資料；客戶端保留滿意度問卷，但把預約時已填過的聯絡資料改由後台自動對應，讓客戶只需要回答真正屬於他們的問題：體驗感受與滿意度。
主要設計
1. 業務 Sales Tool
業務可以輸入客戶電話，系統會去比對 CRM 和 Google Calendar 的預約資料，帶出既有資訊，減少重複填寫。
如果客戶當天有預約，工具也可以協助確認報到狀態。接待結束後，業務可以快速勾選客戶需求、競品經驗、成交阻礙和補充觀察。
設計的核心原則是：讓業務在現場可以用最少操作留下最有用的資訊，而不是填一份完整的報告。
在來源與介紹人欄位，我也加入關鍵字搜尋與模糊比對。業務不用在很長的選單裡慢慢找，只要輸入設計師名字、活動名稱或來源關鍵字，就能快速找到接近的選項。這可以減少手動輸入造成的標籤混亂，也讓後續行銷統計比較容易使用。
2. CRM 資料比對與預填
預約時填過的基本資料，在業務使用 Sales Tool 時會自動帶入，不需要重複輸入。這減少了業務的操作步驟，也讓 CRM 裡的客戶資料更容易保持一致。
3. 客戶滿意度問卷調整
原有的滿意度問卷需要客戶再次填寫聯絡資料，方便我們回頭對應 CRM 紀錄；但對客戶來說，這些資訊其實在預約時已經填過一次。
因此這次調整的重點，是讓 CRM 與預約資料先處理身分對應，減少客戶重複填寫的負擔。客戶問卷則保留在體驗感受、滿意度與較適合由本人回答的問題上。
4. 報價工具串接
原本的 PWA 報價工具也已經和客戶概覽頁串接。業務在報價工具中按下「預覽列印」後，系統會把報價金額、報價日期、主要報價類別與品項摘要帶回對應的客戶 profile。這讓後續追蹤時，不需要另外打開報價檔或回頭找試算資料，就能在同一個地方看到客戶目前的報價狀態。
隨著報價工具持續更新，報價資料也開始回到 CRM 流程中。報價金額、日期、品項與版本紀錄不再只是單次文件，而是可以被客戶概覽頁與業務後續追蹤使用的資料。這讓 CRM 從單純記錄客戶資訊，逐步延伸成業務日常工作中可以回頭確認進度的入口。
5. 客戶概覽頁
除了資料蒐集與同步，我也另外設計了一個客戶概覽頁，讓業務可以用電話搜尋客戶，快速查看同一個案子的完整狀態。
這個頁面會整理客戶姓名、電話、縣市、房屋坪數、角色、案件溫度、是否已報價、是否加入 LINE，以及首次接洽、最後互動、預計追蹤時間、接待業務等資訊。下方則分成報價資訊、業務評估、行銷洞察與備註，讓業務不用在 Google Sheet、CRM、問卷與報價資料之間來回切換。
客戶概覽頁也不是單純的資料查看頁，而是業務接待後續工作的入口。業務可以在客戶 profile 裡直接點選「編輯業務評估」，進入對應的評估表單，補上案件溫度、推薦方案、主要猶豫因素與下一步行動。資料查看與後續更新接在同一個流程裡，不需要另外找表單或重新輸入客戶資料。
6. 滿意度問卷連結與回饋回寫
滿意度問卷也已經串進客戶概覽頁。業務可以在特定客戶的 profile 裡直接開啟已帶入客戶 ID（電話）的問卷連結；如果客戶現場急著離開、沒有時間填寫，業務也可以把這個連結傳給客戶，讓對方事後補填。問卷回覆後，滿意度資料會回到同一個客戶 profile，讓後續回訪時能一起看到接待紀錄、報價狀態與客戶回饋。
7. Design System 與介面規則
在正式實作前，我先用 AI 協作建立了一份簡單的 design system，確認色彩、字級、按鈕、表單、狀態標籤與客戶卡片的視覺規則，再把它套用到實際頁面。這讓後續開發不只可以運作，也比較容易維持一致的介面品質。
AI 在這個專案中的角色
這次開發主要是透過 AI 協作完成。
我先用 Gemini 建立主要架構，再用 Claude 處理 debug、code review、CSS 細節，以及一些 Gemini 解不出來的錯誤。
這個流程比我原本想像得有效率。Gemini 適合先把大架構搭出來，Claude 比較適合檢查細節、修 bug、協助我把介面調得更好看。
但我覺得這次真正有價值的地方，是我可以把自己對現場流程的理解，轉成具體的開發任務。
例如哪些資料應該由業務填、哪些資料應該由客戶填、哪些資料應該從既有 CRM 自動帶入，還有當不同資料來源互相衝突時，系統應該相信誰。
不同資料來源也需要判斷優先順序。像是業務現場觀察到的成交阻礙，會比客戶事後問卷更適合由業務補充；但滿意度評分則應該以客戶本人回覆為準。多選欄位則可以合併去重，避免同一個競品或需求被重複記錄。這些規則讓 CRM 最後留下來的資料，不只是某一張表單的結果，而是整個接待流程中比較完整的一筆紀錄。
這些判斷如果沒有先想清楚，AI 很容易做出一個看起來能用，但現場不一定會用的工具。
目前狀態
目前主要 flow、介面與幾個關鍵串接已經大致完成，仍在使用 CRM 副本測試，尚未直接串到正式資料，避免影響既有紀錄。
已完成的部分包含：
- 業務 Sales Tool：客戶資料查詢、CRM 比對、預約狀態確認、接待後回饋欄位
- CRM 資料比對邏輯：以電話號碼為主要識別依據，比對預約與既有客戶資料
- Google Calendar 預約整合：接待當天滿意度填寫可以直接抓 Google Calendar 的資訊，預先填入客戶資訊
- 業務回饋欄位：需求勾選、競品、阻礙與補充觀察
- 客戶概覽頁：用電話搜尋客戶，查看基本資料、案件時程、報價資訊、業務評估、行銷洞察與備註
- 報價工具串接：業務在報價工具按下「預覽列印」後，報價金額、報價日期、主要報價類別與品項摘要會帶回客戶 profile
- 滿意度問卷串接：可從特定客戶 profile 產生已帶入客戶 ID（電話）的問卷連結，問卷回覆後也會回到同一個客戶 profile
- Design System：先整理色彩、字級、按鈕、表單、狀態標籤與客戶卡片規則，再套用到實際頁面
接下來會先把完整流程測完，再評估切到正式 CRM 的時機與資料保護方式。
資料不要再只停在對話裡
我喜歡這個專案的地方，是它從一份回饋表開始，慢慢變成一個資料流程的整理。
很多公司內部的問題，看起來像是缺工具，但實際上常常是資訊沒有被好好留下來。
展間裡其實一直都有很多重要資訊，只是它們過去常常停留在對話裡、會議裡，或某個人腦中的印象裡。久了之後，行銷要知道第一線發生什麼，就只能一直問；管理端想理解客戶卡在哪裡，也要再請業務回想一次。
我後來比較想處理的是這件事：能不能讓這些資訊在接待當下就比較自然地被留下來，後面的人也比較容易接著使用。
這也是我喜歡做內部工具的原因。它的價值在於讓一件原本反覆消耗人力的事，變得更穩定、更可追蹤，也更能累積成組織的判斷。