現場服務請求及調度 SOP
Insatech的現場服務請求及調度SOP：服務台接收及分流、遙距或現場的決策、指派技術員、準備設備、客戶探訪，以及為每宗個案結案的服務報告。
甚麼是現場服務請求及調度 SOP流程
客戶聯絡Insatech服務業務的每一次接觸，不論渠道，都會落在同一個地方：服務台。這是刻意的設計。一位流量讀數正在漂移的客戶、一位發送器已經停止回應的客戶，以及一位查問下次校正日期的客戶，從客戶的角度而言，都只是「致電Insatech反映儀器問題」，他們毋須預先知道哪一種是五分鐘可以解決的電話個案，哪一種需要技術員親身站在設備前面。這個判斷屬於服務台，在接收階段一次過作出，透過「按徵狀及服務紀錄作技術分流」以及隨後的「遙距支援已足夠，還是需要現場探訪？」決策完成。本SOP涵蓋的一切，都是為了將這一個判斷做好：不為求快而快，也不為求謹慎而謹慎。
這個決策才是本SOP的真正內容，而它兩面都要顧及。為一件電話已可解決的事情調派技術員，會耗用一輛服務車、一整天的車程，以及客戶其實毋須支付的技術員工時，而這正是服務台最有條件在早期截住的失敗模式，因為徵狀通常在分流完成時已經記在工單上。相反的失敗更嚴重：因為沒有人想安排探訪，就電話指導客戶處理懷疑感應器故障、實時的安全隱患，或者任何需要親身接觸受分區、ATEX認證設備的情況。「遙距支援已足夠，還是需要現場探訪？」被寫成一個真正的分支，有兩個真正的出口——一邊是「透過電話或平台與客戶遙距解決」，另一邊是「指派技術員」——正是為了確保這個決定要根據工單上的徵狀明確作出，而不是由接聽電話的人隨口定下來。
這兩條分支不會永遠分開，而任何一條都不保證直達結案。遙距解決會完全跳過「確認所需備件有庫存，並為工作揀選」、「準備測試設備並裝上服務車」，以及探訪本身，直接由「透過電話或平台與客戶遙距解決」跳到「服務台結案，並確認解決方案已記錄」。現場探訪則會經過「現場撰寫服務報告並取得客戶簽署」，進入第二個決策「問題在探訪期間已完全解決？」，因為不是每一單工作都在一次探訪內完成：一個待訂的零件、一個客戶製程當日無法批出的隔離，或者一個需要第二位專家的故障，都會在此標記為「需要跟進」，而不是靜靜重開一張工單，並轉去「記錄未完成工作，並排期跟進探訪」，再循環返回「指派技術員」，而不是開展一宗互不相關的第二個案。兩種最終結果——電話解決及完全解決的探訪——都會匯聚到同一行「服務台結案，並確認解決方案已記錄」。這個匯聚，正是防止一次電話解決淪為一項未經記錄的人情：它與調派探訪一樣，透過同一張服務台紀錄、同一張工單、同一個負責人結案。People與Workload在兩條分支及跟進循環的每一步都有設定，讓workload BI面板可以在電話繁忙的一星期，顯示出繁忙究竟是反映在方瑞秋的服務台工時上，還是賴德文的現場工時上，還是兩者皆是。
本流程圖涵蓋的內容
本範本包含
- 接收及分流：由「客戶聯絡服務台（電話、電郵或客戶平台）」，經「記錄工單，捕捉徵狀、儀器及製程背景」，到「按徵狀及服務紀錄作技術分流」
- 遙距對現場的關卡本身：「遙距支援已足夠，還是需要現場探訪？」，可以在「透過電話或平台與客戶遙距解決」直接解決個案，或者轉去調度
- 橫跨服務台、現場服務及物流三條泳道的調度準備：「指派技術員」、「確認所需備件有庫存，並為工作揀選」、「準備測試設備並裝上服務車」，以及「與客戶確認預約時段、現場出入及個人防護裝備要求」，全部都在有人出發前完成
- 探訪、其紀錄，以及跟進關卡：「客戶探訪：現場評估並解決問題」、「現場撰寫服務報告並取得客戶簽署」，以及「問題在探訪期間已完全解決？」，可以令個案通過結案，或者轉去「記錄未完成工作，並排期跟進探訪」，再循環返回「指派技術員」，而不是開一張互不相關的第二張工單
- 兩條分支共用的結案：「服務台結案，並確認解決方案已記錄」，不論是遙距解決還是完全解決的現場探訪，都用同一張工單結案
- 每一行都透過People與Workload欄位附有具名負責人與工時，讓workload BI面板顯示方瑞秋的服務台工時貫穿整張圖，而賴德文的現場工時則集中在調度準備及現場探訪
何時使用本範本
- 你們想將Insatech服務台決定遙距支援還是技術員探訪的方式標準化，希望這個判斷固定在一張圖上，而不是交由當值接聽電話的人自行決定
- 有客戶質疑一次派車是否真的有必要，你們想要一個有紀錄的分流步驟，展示這個決策的依據
- 你們要培訓新入職的服務台協調員或調度員，需要一份參考，準確說明分流在遙距／現場決策之前涵蓋甚麼，以及技術員出發前必須完成甚麼
- 你們要檢查同一位技術員是否在同一星期被排定到兩宗調度探訪
- 一次現場探訪結案時，沒有已簽署的服務報告存檔，你們想在工單結案之前，有一個位置可以攔截這種情況
運作方式
將泳道換成你們實際的服務崗位
這張圖使用服務台、現場服務及物流。如果Insatech將調度協調從服務台分流中拆分出來，或者有獨立的倉存職能負責備件，就將該角色設為獨立泳道，不要併入服務台——交接位通常正是一個步驟被默默假定已經有人完成、而實際上是雙方互相假設對方已經處理的地方。
在決策上訂立你們自己的遙距／現場準則
「遙距支援已足夠，還是需要現場探訪？」需要一份明確寫明的清單，列出哪些情況會偏向哪一邊，而不只是「憑判斷」三個字。將實際準則——徵狀模式、涉及ATEX或受分區區域、安全指標——寫入該行的備註欄，令分流不會因為當值協調員不同而有差異。
在依賴BI面板之前，先在每一行設定People與Workload
Workload面板只可以合計有填寫工時的行。在你們改編這張圖的時候，為每一步填上People與Workload，使用實際的有效工時而不是經過時間，讓有多宗調度的一星期，真正顯示出是正確的人特別忙碌。
決定備件檢查對你們的產品線代表甚麼
「確認所需備件有庫存，並為工作揀選」只有在按工單上已記錄的儀器類型及故障模式核對時才有效。如果Insatech的倉存是按產品線或按客戶合約分類，就在該行寫明，而不要留作一個通用的存貨檢查。
指明誰可以在沒有已簽署報告的情況下結案
「服務台結案，並確認解決方案已記錄」是兩條分支匯聚的一點。決定並寫下，結案是否容許在「現場撰寫服務報告並取得客戶簽署」存檔之前發生，讓這成為圖上的一項政策，而不是有人在壓力下作出的例外。
常見問題
甚麼決定一宗個案是遙距處理，還是調派技術員？
由「遙距支援已足夠，還是需要現場探訪？」這個決策決定，作出於「按徵狀及服務紀錄作技術分流」完成之後。它會衡量徵狀及儀器的服務紀錄：設定問題，或者活動讀數上可見的接線故障，通常電話已可解決；懷疑感應器故障、安全隱患，或者任何需要親身接觸ATEX認證設備的情況，則要改為現場處理。
服務台決定需要探訪之後，接下來會發生甚麼？
個案會進入調度準備階段：「指派技術員」、「確認所需備件有庫存，並為工作揀選」、「準備測試設備並裝上服務車」，以及「與客戶確認預約時段、現場出入及個人防護裝備要求」，全部都在技術員出發前往探訪之前完成。
遙距解決的個案會跳過服務報告嗎？
會。「透過電話或平台與客戶遙距解決」會直接前往「服務台結案，並確認解決方案已記錄」，不會經過調度準備或現場報告，因為沒有派出技術員，現場也沒有東西需要簽署。遙距解決本身，就是被記錄下來的內容。
誰負責結案，服務台還是技術員？
兩條分支都由服務台結案。「服務台結案，並確認解決方案已記錄」是電話解決及完全解決的現場探訪都會經過的同一行，令每一宗個案，不論由哪一條分支處理，最終都落在同一份紀錄上。
如果技術員未能在一次探訪內完全解決問題，會怎樣？
「問題在探訪期間已完全解決？」會在報告撰寫完成後，即場在現場截住這個情況。答案為「需要跟進」會轉去「記錄未完成工作，並排期跟進探訪」，再循環返回「指派技術員」，而不是結案，讓一單需要待訂零件或第二次探訪的工作留在同一宗個案上，而不是日後變成一次無人追蹤的重開。
這個與緊急儀器故障排除 SOP有甚麼分別？
本SOP假設客戶已經將問題描述得足夠清楚，讓分流可以冷靜衡量遙距與現場。緊急儀器故障排除 SOP處理的是相反的情況：一個此刻正在惡化的製程，甚至連哪一個儀器出錯都仍未確定，緊急程度評估必須在任何遙距／調度決定之前先進行，而不是作為一個例行的分流步驟。
這個SOP可否用於一個只有電話支援合約、沒有現場成分的客戶？
可以。每一宗個案仍然會經過「遙距支援已足夠，還是需要現場探訪？」以作記錄，但對這位客戶而言，現場分支永遠不會被採用。將這個決策保留在圖上，而不是移除，正是向審計員展示個案曾被評估過，而不是被想當然的地方。