建立診斷背景
只保留判斷必要資料，避免把現場變成填表。每個欄位都要能支援後續分析或提案範圍。
資料少一點，判斷要準一點
事件今天發生什麼
模式是否反覆重演
結構流程如何造成它
選出最有感的痛點
先選一個主觀最痛的構面，再勾選實際症狀。系統會把症狀映射到營運結構，而不是只統計表面現象。
痛點 → 結構 → 需求
判斷方式：勾選症狀後，系統會判斷它比較像「存量失衡、流量卡住、延遲未被看見、回饋太慢、例外沒有回流」哪一類，再轉成後續服務需求。
用六題補足分析依據
問題設計來自系統思考與學習型組織：不是問感覺，而是確認資料連結、延遲、回饋、槓桿點與組織學習。
回答越高，代表越需要優先處理
診斷分析與依據
結果會同時給出主要卡點、判斷依據、風險原因與第一階段建議，避免只得到一個漂亮但不能行動的分數。
每個結論都要可追溯
Primary Bottleneck
待補問
請先完成痛點與快問，系統會整理主要卡點與建議方向。
把痛點轉成服務需求
服務不是硬推，而是依診斷結果對應：先做哪個小型改善，才能最快驗證價值、降低導入阻力。
範圍要小，價值要清楚
紀錄預覽與匯出
紀錄會包含：診斷依據、痛點分類、快問回答、需求服務、建議下一步。可作為後續提案與內部討論的基礎。
可複製、可下載、可追溯
如果要給客戶正式版，下一步可以把這份紀錄轉成提案摘要：現況、根因、第一階段範圍、預期改善指標。