把「有查詢」拆成可核對嘅步驟
| 環節 | 先核對嘅證據 | 優先處理方向 |
|---|---|---|
| 訪客進入 | 來源、裝置及進入頁面。 | 廣告或搜尋訊息是否同服務吻合。 |
| 理解服務 | 服務頁閱讀路徑、訪客提問及測試觀察。 | 對象、範圍、條件與證據是否足夠。 |
| 開始查詢 | 按鈕或表單開始事件。 | 下一步是否清楚，入口是否可見及可用。 |
| 成功收到 | 接收系統紀錄，而非只看按鈕點擊。 | 表單接收、通知、重複提交及錯誤處理。 |
| 聯絡與篩選 | 可聯絡情況、需要及服務配合。 | 資料品質、分派、回覆及資格定義。 |
| 進入報價或成交 | CRM 階段與後續原因。 | 方案、預算、時程或銷售流程，唔只看網站。 |
先定義合資格查詢，先有得比較
可以由服務範圍、可服務地區、需要、聯絡資料及合作時間等條件開始。唔同行業嘅定義會不同，應由實際負責接單嘅人確認。只要填過表單就計成功，可能會忽略垃圾訊息、重複名單及不屬服務範圍嘅查詢。
若想比較版本，可以同時睇「成功收到數 ÷ 合理定義嘅訪客數」及「合資格查詢數 ÷ 成功收到數」。固定期間與定義，分開記錄來源或服務類別，避免把來源變化誤認為版面效果。
示範：由症狀決定工作，而非直接重建
假設一間虛構工程顧問公司收到唔少私人住宅零碎維修查詢，但實際只承接商業項目。優先工作可以係在服務頁及查詢入口講清楚項目類型與範圍，而唔係再增加「免費報價」按鈕。
另一種情況係表單顯示成功，但接收端冇紀錄。呢個時候要測試接收與通知，而唔應先加廣告預算。兩個例子都需要保留實測證據，不能只靠前台畫面推斷。
網站同跟進團隊要一齊交收
- 內容：服務範圍、合作條件與公開承諾有負責人確認。
- 接收：每條查詢去邊個系統、由誰負責、失敗時點樣發現。
- 分派：不同服務或地區交畀邊個人；人員休假或離職時點樣接手。
- 識別：用合適嘅內部識別資料連接紀錄，避免在分析網址或事件加入姓名、電話或電郵。
- 回覆：確認聯絡渠道與實際跟進安排，唔在頁面承諾未能履行嘅回覆時間。
- 檢討：統計不合適、無法聯絡及未進入報價嘅原因，回饋到內容或流程。
一輪優化可以點樣做？
- 先記錄現有版本、主要入口、指標定義及已知追蹤缺口。
- 整理一批近期查詢，分類是否重複、可聯絡、符合服務及能否安排下一步。
- 揀最明顯嘅阻礙修正，例如錯誤範圍描述或接收失敗；唔同時改晒所有因素。
- 由來源一路實測到接收及分派，保留測試識別、時間與結果。
- 在有足夠且可比較資料時再判斷方向；資料少時用具體使用問題與流程證據，唔把波動寫成成效保證。
常見問題
轉化率低，係咪一定要重建網站？
先檢查流量是否相關、服務條件是否清楚及查詢能否成功接收。若架構或技術限制持續阻礙修正，先評估重建範圍。
有 WhatsApp 點擊，點解冇對話？
點擊只代表打開相關入口，訪客可能冇送出訊息。應分開查看網站點擊及實際接收紀錄，並檢查連結、裝置與替代聯絡方式。
下一步與延伸閱讀
官方參考與更新說明
本文嘅規劃表、測試步驟及示範情境由 ITOB Group 編輯團隊整理；示例並非客戶成效紀錄。最後實質更新：2026 年 10 月 25 日。
