搜尋來的詢問，如何帶著需求進入接待流程？

問題發生在網站與接待之間

讀者可能看完一篇服務介紹才來詢問，接待者卻只收到一句『想了解』。若重新從所有服務逐項問起，讀者會感覺先前閱讀沒有被承接；若直接推定需求，又可能把瀏覽興趣誤認為已決定接受服務。本篇設計的是資訊交接方式，不代表任何特定機構已採用。起點是釐清哪些資料可直接由讀者提供、哪些需要接待補問，以及哪些事項只能交給適任專業人員判斷。

先整理入口，再設計最少必要欄位

V 負責讓服務頁說明適用情境、接洽方式與下一步，並給每一個聯絡入口清楚的來源識別。O 則把來源頁、讀者主動提出的問題、聯絡方式與可聯繫時段整理成接待摘要。入口只收完成接洽所需的資訊，不要求讀者在公開表單敘述敏感細節，也不把瀏覽紀錄自動解讀為個人狀況。來源無法取得時保留未知，不能根據關鍵字猜出對方想接受哪項服務。

讓摘要成為接手線索，而非自動結論

候選流程可依序進行欄位檢查、一般行政問題分類、缺漏提醒與人工分流。接待者看見的摘要須區分『讀者原話』『網站來源』『待確認事項』。若只是詢問時間與地點，可以依核准資料回答；若涉及個人適用性、風險或專業處置，就轉交指定人員，不由分類結果直接推薦。讀者更正需求後，以更正內容為準，原始摘要保留版本脈絡，避免錯誤被後續人員持續引用。

來源不明或頁面變更時，如何繼續接待

讀者可能從舊文章、不同服務頁或轉傳連結進來，接待時先確認對方看到哪項資訊、目前想進一步了解什麼。來源頁提供上下文，實際接洽需求仍以對方確認為準。若來源頁已下架、服務內容有更新，接待畫面應提示需重新核對版本。當系統無法產生摘要時，仍保留原始詢問與人工接手清單。先做人工輔助比較容易調整；串接既有系統則能減少搬運，但必須先確認權限與資料介面。

把來源頁脈絡轉成接待可用的線索

聯絡事件保留來源網址、頁面主題、進入時間與讀者自行填寫的需求，不從瀏覽行為推定個人適用服務。摘要分成頁面已公開的共同資訊、使用者原話、尚待確認條件及建議接待路徑。若來源頁已更新或網址參數遺失，顯示來源未知或版本差異，不套用目前頁面內容假裝當時讀者看過。接待者仍需核對需求，不能把搜尋字詞或點擊位置當成顧客已同意的結論。

交付內容

驗收交接品質，並準備下一步

驗收可使用完整、缺欄、重複及來源未知等代表情境，檢查必要資訊是否保留、敏感問題是否正確轉交，以及接待者能否找到原始問題。比較補問次數時，要區分因表單缺漏而補問，與本來就需要專業確認的合理補問；後者不應被當成流程失敗。企業可以先準備現有聯絡入口、接待欄位與轉交角色，再評估 V 的頁面承接及 O 的流程診斷。若前線仍需要額外資訊，先判斷是否屬於必要接洽條件，再調整來源頁與摘要欄位。

驗收從送出到正確窗口真正接手

測試搜尋進入、直接網址、來源遺失、頁面更新與跨頁閱讀等情境，確認摘要不會誤寫來源或省略使用者原話。接待者依摘要完成分流後，由下一窗口確認收到並記錄退回原因。回看分列重複補問、來源未知、錯誤分流、接手等待與內容回寫完成時間；來源資料只用來改善交接與頁面，不作完整行銷歸因。若摘要無法降低補查，就縮減推論欄位並保留更多可追溯原文。

衡量與回看

• 必要欄位完整度：在授權收集範圍內檢查，不以多收資料提高分數
• 補問原因分布：區分缺漏、資料更正及必要專業確認
• 轉交完整度：以接手者是否取得原始問題與責任資訊判斷

行政補問與專業問題各有停止邊界

表單只蒐集分流所需資料，例如聯絡方式、想了解的主題與方便回覆時段；涉及個別情況時，告知將由適當人員後續確認。行政人員可以補問目標與資料缺口，不能依來源頁直接推薦個人服務。若訊息含多項需求，拆成可並行待辦；若頁面內容與現行服務範圍不同，先標記內容異常並以有效資料回覆，再把問題回寫內容負責人，避免每位接待者自行補丁。

適用範圍與限制

• 不自動判斷個人適用服務、不提供診斷或療效建議；來源識別並非完整行銷歸因。