🥇Service Desk 如何拯救一家服務公司，或者如果您的業務正在成長該怎麼辦？

我叫 Daria，是一名產品分析師。我公司的主要產品是服務台，一個自動化業務流程的雲端平台：例如，維修工作、各種物件的維護。我的任務之一是參與將我們的平台引入客戶業務的過程，同時我需要盡可能深入地了解特定公司的具體情況。

我想告訴您我們的客戶之一，布蘭特服務公司，如何設法實現勞動密集型業務流程的自動化。當客戶數量以及相應的服務請求開始快速成長時，該公司轉向我們的平台。業務正在積極發展，很棒，有什麼問題嗎？事實是，類似例行流程的數量正在急劇增長，這種危險不容小覷。此外，很明顯，您無法使用應用程式較少時有效的相同工具。

聽起來有點熟？

所以，救贖的故事。

是的 服務公司 盡可能充分地使用我們平台的功能，因為他們需要多方之間的及時溝通。這些側面是什麼？

提供的服務：設備維修及保固服務、建築安裝工程；打掃;
超過1000個服務設施分佈在莫斯科及莫斯科地區；
員工中有 60 多名服務專家。
該公司每月處理超過 4500 份申請。
在本文中，我們使用假名來識別布蘭特的客戶。它們是：一家聯邦雜貨連鎖店－我們稱之為「Polyanka」；兩家連鎖藥局－「Doctor A」和「Doctor B」；電信業者「Op Mobile」的服務中心；以及多個生產設施；

每個主要連鎖店都堅持所有應用程式支援工作都在其會計程序中完成。互動自動化對於客戶和服務公司來說都是有效的，並且在綜合服務領域是合理的。然而，當有兩個以上的客戶時，服務公司同時處理多個程序的工作就會產生困難。

Polyanka網路採用1C：MRO方案；「A醫生」－透過Intraservice系統提交申請； “Doctor B”和“Op Mobile” - 透過他們自己的服務台。線下客戶透過電子郵件、電話甚至 WhatsApp 和 Viber 提交請求。

所有收到的申請均收集在 Excel 文件中。一次的申請數量可能超過 4 個——而且這些只是活躍的申請，但也有必要儲存已完成申請的歷史記錄。

摘要文件隨時都有死亡的危險，我們必須不斷地進行複製，以免丟失應用程式資料庫。從所有來源收集申請並將其傳輸到 Excel 文件花費的時間長得令人無法接受。然後還需要透過簡訊、電子郵件、Viber 和 WhatsApp 手動向表演者發送申請。

在這種情況下，發送給服務專家的請求必須包含其實施所需的最大資訊。完成申請後，需要收集實施情況和照片報告的資訊。還有其他地方可以存放它。

可想而知，這樣多管道的接收、錄製和分發應用程式是多麼困難。鑑於該公司正在吸引新客戶並僱用更多專家，因此該流程迫切需要自動化和提高透明度。但是，不可能拒絕以對客戶方便的方式使用應用程序，因為這是合約條款規定的。

這意味著需要一個單獨的系統來允許：

同時，對於表演者（僅隨身攜帶電話作為通訊手段的現場員工）來說，它應該很方便。

在研究了軟體產品市場後，Brant 選擇了我們的系統－HubEx 平台。

步驟 1：使用 Excel 匯入，將所有服務物件的資料傳輸到平台（啟動時有超過 900 個物件） - 現在每個物件的所有必要資訊都儲存在物件的 Web 護照中：地址、地圖上的地理位置、技術文件、聯絡人、服務歷史記錄。及時完成申請可能需要的一切。

步驟 2： - 將應用程式載入到通用系統中很快就完成了。只需點擊兩次即可匯入 HubEx 系統，現在每個物件的所有請求都收集在一個位置。從客戶系統收集申請的另一種方法是建立一種透過電子郵件直接接收申請的機制。平台中也提供此選項。

結果：Brant 調度員在一個程式中查看所有請求並將其分發給現場員工。

每個員工口袋裡都有一部手機，裡面有一個行動應用程序，可以通知新分配的請求。在應用程式本身中，專家可以看到其應用程式的當前清單：

重要的一點：現在有關應用程式的所有通訊都不是透過電話交談或即時通訊工具進行的，而是嚴格地在應用程式本身中進行。

這使您可以儲存請求的歷史記錄，清楚地分段每個請求的通信，並確保不會遺失任何重要資訊。承包商可以要求有關工作的更多資訊、報告遲到或邀請必要的參與者參與討論 - 例如另一位以前曾服務過該對象的專家。

現在，當申請轉移給另一位專家時，新員工可以獲得有關先前操作的所有必要資訊。

因此，服務台的引入使 Brant 能夠將其所有項目合併到一個系統中。此外，威脅淹沒公司的常規流程也顯著減少：儘管服務對象數量增加了，但沒有必要僅為了彌補類似任務數量的增加而增加新員工。

Service Desk 如何拯救服務公司，或者如果您的業務正在成長該怎麼辦？