AO2 FIELD GUIDE · N061 · WordPress 與轉換體驗
B2B 服務頁應回答適合誰、需要什麼資料及交付到哪裡。附內容結構與範圍核對表，安排證據、限制、合作流程與合理的下一步。
- 我是否在適用範圍內？
- 服務會做什麼、交付什麼？
- 需要我配合哪些資料與責任？
- 現在能確認什麼，哪些要進一步評估？
B2B 服務頁：先寫客戶問題，再寫服務名稱
「企業 AI 解決方案」或「數位轉型整合」可以涵蓋很多工作，也容易讓不同客戶產生不同期待。把第一屏改成具體問題，會更容易建立共同理解。例如：「產品資料散在 PM、型錄與網站裡，團隊每次寫內容都要重新確認。」再說明服務如何從來源、版本與責任開始整理。
這種寫法不是要把服務縮成單一功能，而是先提供讀者能辨認的入口。需要企業知識庫的人，可能尚未知道自己要不要 AI 問答；需要內容整理的人，也未必準備好改版網站。服務頁應讓人看懂起點與延伸條件。
一個可用的頁面順序：從適合性走到合作
| 區塊 | 要幫讀者回答什麼 | 應提供的資訊 |
|---|---|---|
| 問題與適用對象 | 這跟我的工作有關嗎？ | 角色、常見現象、適用情境 |
| 服務範圍 | 你們實際處理哪一段？ | 工作項目、起點與終點 |
| 交付內容 | 完成後我拿到什麼？ | 文件、頁面、規則或系統成果 |
| 合作流程 | 我需要配合什麼？ | 必要資料、核准角色、檢查節點 |
| 證據與限制 | 如何確認這些說法？ | 可公開示例、方法與適用邊界 |
| 下一步 | 現在怎麼開始？ | 需求準備清單與清楚的聯絡入口 |
這是可調整的閱讀順序，不是每頁必須有同樣六大段。如果服務需要先篩選適用條件，可以提早提供核對表；如果客戶通常先需要看交付示例，也可以把成果樣本往前放。順序要依讀者任務驗證。
把「做什麼」與「交付什麼」分開
例如「進行訪談、分析需求、規劃架構」描述工作；「來源盤點表、核准知識欄位、主題分工圖、更新規則」才是可交付成果。兩者都應說明，否則客戶可能以為一次訪談就包含完整資料庫上線，或把策略文件當成已完成的系統功能。
每個交付項目還要說明用途與驗收方式。來源盤點表是否包含原檔連結與責任？內容架構是否已對應現有文章？網站頁面是否已完成手機與表單檢查？明確到這個程度，才方便客戶比較方案，也能降低合作時的範圍誤解。
路燈與 IoT 情境：別把設備、平台與服務混成一個承諾
以下為服務頁規劃示例。某團隊提供聯網照明內容與網站規劃，可以協助整理設備、控制、通訊與平台資訊，但不因此代表承接所有現場施工或系統維運。服務頁應指出需要哪些資料，以及哪些問題要交給產品、工程或平台責任人確認。
可以把頁面中的服務範圍寫成三欄：目前可處理、取得資料後可評估、需由其他責任單位確認。例如可處理核准資料的結構化表達；需要原始文件後才能判斷規格缺口；現場工程配置由專責角色評估。這樣比一句「全方位整合」更能支援採購判斷。
沒有成熟客戶案例時，怎麼讓服務仍然具體？
可以提供匿名化且已獲准的成果節錄，或明確標示的示範工作單、流程圖與驗收情境。示例應展示方法：資料如何進來、如何核對、如何產出、哪些地方仍需專家判斷。不要把想像情境包裝成已完成專案，也不要放上沒有範圍說明的成效數字。
作者已公開的工作觀點可以補充方法背景，例如 Johnny Wu 將 Content、CRM、Data 與 Sales Enablement 視為彼此連接的工作系統；但這不能代替某項服務的實際交付證據。服務頁應分開呈現作者觀點、方法示例與真實案例。[1]
價格與時程：交代影響因素，比先填固定數字有用
若服務需要評估資料量、產品版本、語言、審核角色與技術範圍，可先說明影響估算的條件。初次詢問需要哪些資料、什麼時候才能確認範圍、報價會列出哪些交付與排除項目，都可以寫清楚。
可以提供有實際依據的方案區間或標準項目，但不能在沒有核准資料時編造起價、交期或保證。也不要要求第一次接觸的客戶填寫他不可能知道的完整技術規格；允許「尚不確定」，再說明後續如何一起確認。
驗收頁面：請讀者完成一個小任務
- 說出這項服務最適合解決的問題。
- 找出至少一項明確交付，以及如何確認完成。
- 指出一項不包含或仍待評估的範圍。
- 依頁面整理一份初步需求，不由業務在旁解釋。
- 在手機上找到服務資料、相關指南與詢問入口。
若測試者找不到交付範圍，優先補頁面內容；若知道要詢問卻不知道該準備什麼，補資料說明；若按鈕與錯誤訊息不好用，則改善介面。不要把所有問題都歸成設計不夠吸引人。
服務頁內容卡：讓需求討論有可帶走的起點
| 頁面資訊 | 知識整理服務的示意寫法 |
|---|---|
| 適用問題 | 產品資料多版本，行銷與業務每次都要重新找人確認 |
| 首輪範圍 | 先選一條產品線與明確使用任務 |
| 交付 | 來源盤點、資料缺口、責任與核准規則、可用知識示例 |
| 客戶配合 | 可使用文件、產品窗口、核准角色與既有問題 |
| 待評估 | 歷史資料量、多語版本、系統串接與額外開發 |
| 驗收 | 依共同任務回查來源、版本、限制與下一個確認角色 |
這是頁面規劃示例，並非 AO2 已核准的固定報價或交付承諾。實際上線前，應讓服務負責人核對每一列。若目前只能提供盤點與規劃，就不要在標題暗示已包含完整系統導入；若能提供延伸服務，也說清楚何時評估與如何界定。
請一位沒有參與製作的人，用這張頁面內容卡寫一封初次詢問。看他能否說出自己的問題、提供現有資料、列出未知，並理解下一步。如果他只寫「想了解報價」，卻不知需要補什麼，頁面可能仍缺少具體的需求入口。
常見問題
服務頁越長越有說服力嗎？
長度應由讀者需要的判斷決定。先讓人找到適用對象、要解決的問題、交付、必要資料、合作邊界與下一步，再用證據支持重要主張。較深的方法可連到指南，不需每段重述專業與效率。可請未參與製作的人看完後說出是否適合、還缺什麼資料以及如何開始；若仍只能回答「服務很多」，應補具體範圍，而不只是增加字數。
每個產業都需要一張服務頁嗎？
只有實質差異才值得拆。先比對各產業的問題、輸入資料、交付、審查角色與可公開證據；若這些都一樣，先以共用服務頁搭配情境說明即可。半導體和生技製藥不能只換名詞便宣稱具備相同專案能力；缺少真實材料時標示方法示例。拆頁後每頁應有獨立判斷價值與維護責任，避免大量近似內容增加更新負擔。
要不要把所有技術限制都放在第一屏？
第一屏先放會影響是否適合的關鍵條件，細節按任務逐層展開。例如導入需先有可使用資料或特定接口，就不應等到表單後才告知。較長的技術限制可放在相應方案、比較表或 FAQ，但保持容易找到。驗收時模擬不符合條件的需求，確認讀者能及早辨認並知道替代下一步；資訊層次可以精簡，不能把重要邊界變成難找的小字。
相關閱讀與下一步
了解對應 AO2 服務，或帶著目前的資料與工作問題，先確認適合開始的範圍。
參考資料與查核範圍
資料查核日期：2026 年 10 月 21 日。官方文件支援文中對應的平台規則；工作表、決策流程與虛構示例為本文整理。Johnny Wu 的公開分享作為作者工作觀點來源，未以此推定客戶成果或產品資格。
