前導問卷 7 份回填 × 實體需求訪談準備盤點 — 供兩位顧問訪談前對齊使用
鈦坦技術是一家室內裝修／工程公司，組織圖列有 7 個部門。7 份前導問卷由 3 位填寫人代填，且填寫人未必是部門主管本人——真實的部門負責人與人數，需在訪談時當面確認。真正關鍵的是：7 份回填的痛點高度一致——資訊散落 LINE／口頭／Excel／雲端／紙本、跨部門交接斷點、靠記憶追進度。解法方向因此非常明確。
建立一套以「案件」為中心的中台，把宣傳→銷售→設計→工程→財務這條協作鏈的資訊接在同一個系統。
① 先用提問釐清現況，別一開場就 show 優化方案。② AI 需求先收斂到第二階段，第一階段先把資訊結構化。
| 部門 | 填寫人 | 職稱 | 人數 | Notion 熟悉度 |
|---|---|---|---|---|
| 企業主 | 謝晉程 | 總經理 | 1 | 偶爾用 |
| 管理處｜人事部 | 林佳璇 | 人資主管 | 1-2 | 日常會用 |
| 管理處｜財務部 | 林佳璇 | 財務主管 | 1-2 | 日常會用 |
| 業務處｜宣傳部 | 林佳璇 | 宣傳部主管 | 1-2 | 日常會用 |
| 業務處｜銷售部 | 謝晉程 | 總經理兼業務開發 | 1-2 | 偶爾用 |
| 技術處｜設計部 | 顏漢忠 | 設計經理 | 2 | 沒用過 |
| 技術處｜工程部 | 顏漢忠 | 技術處主管 | 2-3 | 沒用過 |
7 份問卷的填寫人僅 3 位（謝晉程、林佳璇、顏漢忠），且填寫人不必然是該部門主管本人——可能是某人代多個部門蒐集、轉述後填寫。因此不能直接用「填寫人」推論組織規模或部門負責人。
→ 訪談第一件事：當面確認每個部門的真實負責人、實際人數與分工。財務部 After 設計的「主管／企業主分層簽核」也須確認真實簽核角色有幾人，避免設計出空的關卡。7 份回填的痛點驚人地一致：資訊分散在 LINE／口頭／Excel／雲端／紙本、版本不一致、跨部門交接「講過了但沒留痕」、靠記憶與聊天紀錄追進度、缺乏以案件為核心的全貌視圖。
企業主畫出核心接力鏈：宣傳 → 銷售 → 設計 → 工程 → 財務，企業主辦公室統管。這條鏈即系統設計的主軸——以案件為單位，沿這條鏈流動。
銷售／宣傳／企業主都提到想要 AI：自動摘要、生成腳本、爬社群話題、問答式查歷史案件（如「鳴森苑的立柱包板何時改第三版」）。
→ 呼應頁面「杜的小筆記」：先以「系統能解決」做盤點，不要掉進發散的 AI 需求。AI 列第二階段，第一階段先把資訊結構化。訪談時溫和地幫客戶收斂期待。技術處兩位（設計／工程）「聽說過沒用過」需從零教學；企業主與銷售「偶爾用」；林佳璇負責的三部門「日常會用」，可當內部 power user／種子使用者。全公司現況工具：Excel ＋ Google 雲端 ＋ Line ＋ 紙本，無人使用真正的專案管理工具。
依「每部門 4 張」結構（現況釐清 → 問題詢問 → 優化後流程 → 優化後成效）製作，依兩場實體訪談拆成兩份獨立網頁簡報。流程圖採橫式（左→右）排版，現場投影清晰。
共 19 張。財務／人事流程圖採顧問已備版本；銷售／宣傳由本報告依問卷起草。
製作原則：每部門皆採四段結構；問題詢問頁皆嵌入「現場待確認」提問，引導客戶自述；標「草稿待確認」者為依問卷起草、待顧問檢視；未使用任何產學工作區或其他客戶畫面。
⚠️ 下列「問卷填寫」為實際填表者，未必是該部門主管本人；「記錄職稱」為問卷上所填的職稱。真實的部門負責人與人數，請於訪談現場確認。
最花時間／易出錯：從請款條件確認 → 收款 → 入帳 → 對帳 → 報表更新的整段流程。
最花時間／易出錯：從「用人需求提出」到「新人正式上線」的整段流程。
最花時間／易出錯：案源取得 → 需求確認 → 內部評估提案 → 報價追蹤 → 成交交接。
最花時間／易出錯：整理素材 → 轉譯成對外內容 → 製作 → 發布 → 收集回饋。
最關注：整家公司從案源、設計、施工到收款的資訊整合、流程透明與決策即時性。
※ 技術處（設計部／工程部）已填問卷，但本次訪談範圍為管理處＋業務處，技術處資料留待後續階段參考。