AO2 FIELD GUIDE · N027 · 內容策略與專業表達
業務對話選題先去識別並定義問題單位，再分開記錄出現次數、影響與缺少資料。附問題分類表及選題評估表，避免把同一案件重問當成市場需求。
業務常說「客戶一直問」，但這句話可能代表很多客戶都有疑問，也可能只是一個案件尚未解決。把對話整理成可追查的問題與決策任務，才能判斷應補文章、修正產品頁，還是先處理內部資料缺口。
業務對話選題：先定義一個問題如何計算
先約定觀察期間與來源，例如核准使用的詢問摘要、展會問答及客服工單。每筆記錄保留案件代碼、角色、產品與待完成的決定，不把完整信件與客戶身分直接搬進選題表。同一案件反覆追問，應能回到同一識別碼；不同客戶問相似問題，則保留各自來源，避免合併後失去脈絡。
次數可以反映某批紀錄中出現的情形，但不能直接稱為搜尋量或市場占比。若只抽到某位業務的資料，也不能代表全公司客群。記錄缺漏來源、樣本選法與尚未納入的通路，讓選題會議知道這張表能支持什麼決策，以及哪些推論還需要外部或其他團隊資料。
| 欄位 | 紀錄方式 | 要避免的錯誤 |
|---|---|---|
| 來源單位 | 案件代碼、期間與通路 | 同一案件重問重複計算 |
| 角色與任務 | 採購、工程或維護要做的決定 | 只保留熱門詞 |
| 必要條件 | 產品、版本及現場限制 | 去識別時刪掉判讀條件 |
| 答案狀態 | 已核准、待確認或衝突 | 將暫時回覆當成定案 |
| 缺口類別 | 內容、資料或流程 | 所有問題都新寫文章 |
保留原話線索，再將問題改寫成讀者任務
客戶問「能不能跟舊設備連」，背後可能是介面相容、現場停機或採購責任。不要立即把它改成泛泛的「IoT 整合優勢」。先問業務：客戶當時要決定什麼，已有什麼條件，哪一項資訊讓討論停住。對話摘錄保留必要語境，對外題目則去除身分與不可公開資訊。
假想半導體設備零件情境：兩個案件都問交期，一個需要確認標準品供貨，另一個涉及客製測試與核准。表面詞彙相同，內容任務卻不同。前者可能需要產品頁的詢問欄位，後者需要解釋評估流程；若只做一篇「快速交貨」，可能形成沒有依據的承諾，也無法解決真正的資料缺口。
將缺口分成內容、資料與流程
如果答案已經核准，只是客戶找不到，先改善入口、用語與內部連結。若規格尚未確定，先交給產品團隊，不以文章補出答案。若客戶不知道找誰確認，問題可能在分派與回覆流程。每個題目都應寫出要修正哪一種缺口，避免把所有業務摩擦都交給行銷加寫長文。
| 問題特徵 | 可採工作 | 發布前證據 |
|---|---|---|
| 答案已有但難找 | 改善入口與 FAQ | 來源一致且可找到 |
| 需要理解評估流程 | 製作步驟型指南 | 流程責任與適用條件 |
| 缺少產品規格 | 先整理資料主檔 | 產品負責人核准 |
| 對外主張仍有限制 | 寫方法或確認清單 | 明示示例與待確認處 |
| 已寫過相同任務 | 更新既有文章 | 保留變更與連結紀錄 |
對生技製藥合作相關問題，也要分辨是一般流程說明，還是涉及特定產品用途或專業認定。選題表可以標記需由合作方或適當審核角色確認，不能把對話中的暫時意見寫成官方結論。沒有可公開證據時，改成方法示例或列出確認步驟，並清楚說明示例性質。
排序時同看重複程度、決策影響與可完成性
先選能幫助讀者完成重要判斷，且資料與責任可確認的題目。高頻但沒有核准來源的問題，可以先安排資料整理；低頻但每次都阻礙技術評估的題目，也可能值得處理。不要將出現次數、潛在商業價值與製作成本塞成看似精準卻無法解釋的總分。
需要評分時，先公開每個等級的定義，再讓不同角色各自試判一組題目。分歧大的項目保留討論理由，而不是取平均就結束。Google 的 實用內容指引提醒內容應服務既定讀者。它沒有要求每個問題都另開一頁；本文的選題方法仍需依企業資料與客戶任務調整。
文章交付要回到原本的對話現場
給業務一段可使用的說明、適用時機、不可延伸的主張與正式連結。請他用去識別的代表問題試回覆，確認文章是否真的少了一輪追問，或至少讓缺少的條件更明確。若仍需要另外貼三份互相矛盾的文件，問題可能尚未解決，不應只用「已發布」作為完成標準。
後續將新出現的疑問連回原選題，區分新需求、內容沒說清楚與來源已變更。固定檢查少量代表性案件，比累積大量無人維護的問句更有用。沒有基線時，不宣稱文章已減少多少工時；先建立可比的紀錄，再評估實際使用和下一次修訂。
常見問題
最常被問的問題一定先寫嗎？
先區分內容缺口與流程缺陷。若多位客戶不知道文件在哪裡，可能應先修下載入口；若反覆問相同選型取捨，才值得寫解釋文章。整理問題時記錄任務、出現情境、現有答案與影響決策，再評估答案是否有可靠來源。優先處理高影響且能被內容改善的疑問，不僅按次數排序；上線後回查問題是否減少，或對話是否更容易進入下一步。
一句客戶原話可以直接當標題嗎？
可以作為語言線索，但不宜直接照貼。先移除姓名、公司、專案參數等可識別或受限制資訊，再將個別描述整理成其他讀者也能理解的任務。保留原話與整理題目的內部對照，避免把客戶的假設寫成產品事實。例如「你們一定支援某接口吧」應先核對產品，再改成適用性問題。案例若仍能被反推出客戶，需另確認公開範圍。
有詢問次數就能推估搜尋需求嗎？
不能直接換算。業務詢問來自既有客群、通路與活動，搜尋需求則是另一個觀察範圍。先記錄詢問數的期間、去重方式與來源，再用實際查詢、搜尋結果和 Search Console 等可取得資料交叉理解。沒有搜尋量資料時可標示未知，先製作能解決真實問題的內容；不要把某月幾次詢問乘上一個比例，就宣稱有多少市場需求或潛在營收。
來源與方法範圍
查核日期：2026 年 10 月 22 日。官方資料僅支持文中對應的平台或方法說明；工作表、決策步驟與核對方式為 AO2 編輯整理。產業情境依文中標示作假想示例，不作客戶實績、產品資格或效果背書。
