自架服務台與工單系統怎麼選？

選擇自架服務台的 4 個問題

自架服務台容易安裝，卻很難選擇，因為這類產品的需求通常非常具體。回答 4 個問題，就能把約 20 個專案縮小到 1 或 2 個。在開啟任何功能頁面前，先決定以下事項。

• 電子郵件是否必須轉換成工單，還是使用者會透過網頁表單並登入系統？
• 這是面向客戶的支援服務，還是內部 IT 服務台，讓工單對應到筆記型電腦或伺服器？
• 最多會有多少服務代理人登入？2 個人使用的產品，與 20 個人使用的產品不同。
• 是否需要服務水準協議（SLA）計時器、資產記錄、公開知識庫或核准流程？

以下各節會依照上述順序說明。產品清單放在最後，因為產品本身是這裡最不重要的決策。

郵件是否必須轉成工單？

如果答案是肯定的，無論安裝哪個系統，電子郵件都是主要整合方式，而且分成兩個會以不同方式失效的部分。

入站：實際建立工單的機制

這篇文章中的幾乎所有選項，都會透過 IMAP（網際網路訊息存取協定）或 POP3（郵局協定），從你已擁有的信箱讀取郵件。服務台會像一般郵件用戶端一樣登入，並依計時器定期輪詢。郵件不會主動推送到服務台，因此計時器停止時，工單也會停止建立，而客戶完全不會看到錯誤。Request Tracker 是例外：其安裝指南只說明在你自己的郵件伺服器上設定別名，將每封郵件透過管線傳入 rt-mailgate。因此，若要從供應商的信箱讀取郵件，就必須在前面執行 fetchmail 等擷取器，而需要監控的計時器就會變成該擷取器。

osTicket 會讓這套機制更明確。你可以在管理面板中，為每個郵件帳號設定擷取頻率，但僅啟用擷取功能還不夠。輪詢程式位於 api/cron.php，文件建議以 crontab 項目執行，通常每 5 分鐘執行一次。內建的替代方案 auto-cron 只有在已登入的代理人使用 Web 介面時才會執行，因此安靜的週末可能完全不會擷取郵件，直到有人登入為止。

GLPI 將相同工作拆成兩部分。receiver 是 GLPI 對郵件收集器的稱呼，負責保存信箱憑證；mailgate 自動動作則決定收集的執行頻率。工單停止出現時，先檢查該自動動作，再處理信箱設定。Zammad 會依頻道設定，透過 IMAP 或 POP3 擷取郵件。在自架伺服器上，也可以透過 fetchmail 饋送郵件；fetchmail 會將每封郵件透過管線傳入 Zammad 自己的郵件驅動程式。其 Sendmail 選項僅供寄出郵件使用，因此文件沒有記載用於入站郵件的郵件伺服器管線。

接著要注意的是討論串處理。客戶的回覆必須落在現有工單，而不是建立第二張工單。郵件討論串會依據 Message-ID、In-Reply-To 與 References 標頭處理，服務台也會將工單參照加入主旨列作為後備機制，因此支援郵件的主旨中通常會出現類似 [#123456] 的內容。若從寄出範本中刪除該識別字串，讓郵件外觀更整潔，每封回覆都會被當成新工單。

最後是自動回覆。服務台會對每封新郵件傳送確認通知。如果回覆的地址本身也是自動回覆器，兩者可能持續循環，直到有人停止其中一方。RFC 3834 定義了 Auto-Submitted: auto-replied 標頭，讓自動回覆器能彼此識別並保持靜默；行為正常的系統都會設定該標頭。在將服務台指向會轉寄至郵件清單的別名前，先用實際信箱進行測試。

出站：決定回覆是否送達的部分

入站問題很明顯，因為不會出現工單。出站問題則不易察覺：回覆已送出，代理人也關閉了工單，但客戶始終看不到郵件。你的工單系統會以你的網域寄送郵件，因此該網域必須授權它寄送。

網域需要 SPF（寄件者政策框架）記錄，列出所有會寄送郵件的來源。也需要 DKIM（DomainKeys Identified Mail）簽署，以及 DMARC（網域型訊息驗證、回報與一致性）記錄；其政策必須與兩者一致。在安裝任何系統前，先檢查目前已發布的設定：

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

第一個命令應輸出以 v=spf1 開頭的行。第二個命令應輸出以 v=DMARC1 開頭的行。第三個命令只會查詢簽署者使用的 selector 名稱，因此若結果為空，通常表示查詢了錯誤的 selector，而不是 DKIM 遺失。

直接從 VPS 寄送郵件通常會在這裡出問題。新的 IP 位址沒有寄件信譽，而且許多主機商會先封鎖出站連接埠 25，直到你提出開通要求。請改用郵件供應商進行轉送。這和伺服器上其他服務面臨的是同一項決策：讓自架應用程式寄出郵件而不被判定為垃圾郵件 說明了如何一次為所有服務完成設定。如果你也想自行管理信箱，在 VPS 上架設 Mailcow 郵件伺服器 可提供服務台輪詢的收件匣，但這項工作比服務台本身更大型。

客戶支援，還是內部 IT 服務台？

這是兩種使用相似介面的不同資料模型，而這項差異會決定你的候選清單。

在客戶支援中，提出請求者是電子郵件地址。身分資訊不完整，請求量可能突然暴增，而成功的定義是讓回覆送達一位永遠不會登入你所執行之系統的人員。網頁表單、預設回覆及依部門劃分的佇列在此情境中很重要。資產則不重要。

在內部服務台中，提出請求者是員工，通常會透過 LDAP（輕量型目錄存取協定）從目錄擷取，而工單會指向某項資產：筆記型電腦、授權或虛擬機器。該資產會記錄在 CMDB（組態管理資料庫）或資產清冊中，而工具有一半的價值在於能知道哪張工單曾處理哪台機器。

GLPI 和 iTop 是為第二種模型打造。FreeScout 和 osTicket 則是為第一種模型打造。Zammad 很適合客戶支援，也能用於內部服務台，但不提供資產記錄。之後才跨越這條界線，是此類別中代價高昂的錯誤，因為必須遷移的是資料模型，而不是佈景主題。

未來會有多少 agent 登入？

本文列出的軟體都不會按 agent 數量收費，因此數量不會改變你的帳單。它會影響你在收到第一張 ticket 前，需要建立多少組織架構。

只有 2 名 agent 時，組織架構反而會增加問題，而不是解決問題。你需要共用單一信箱的檢視方式、顯示目前由誰處理哪些事項的方法，以及可供搜尋的歷史紀錄。FreeScout 正好符合這些需求。如果客戶是透過網站上的表單提交問題，osTicket 也很適合。

有 10 或 20 名 agent 時，你需要佇列或部門、指派規則、權限層級，以及能顯示工作卡在哪裡的報表。osTicket、Zammad 和 GLPI 都已提供這些功能。設定需要一天的工作時間；略過設定後，常見的結果是所有事項都進入同一個佇列，卻沒有人負責任何工作。

需要 SLA、資產、知識庫或核准流程嗎？

請逐項評估，因為每增加一項條件，候選清單就會縮短。

SLA 計時器會依目標值衡量回應與解決時間，因此需要營業時間、優先級制度及升級路徑。osTicket 隨附 SLA plans，Zammad 隨附 SLAs；GLPI 與 iTop 也都將服務等級管理視為模型中的一級功能。

資產追蹤功能應選擇 GLPI 或 iTop。GLPI 在服務台旁內建機器清冊。iTop 是以 CMDB 為核心、在其上建立工單功能的系統；如果重點在於服務與硬體之間的關聯，iTop 會更適合。Znuny 與 OTOBO 可透過其 ITSM 套件加入 CMDB 功能。

知識庫很常見，但並非所有產品都有。Zammad 內建知識庫，但預設停用，必須由管理員啟用。osTicket 提供 FAQs。GLPI 提供與服務台整合的知識庫。FreeScout 則將知識庫作為付費模組銷售。

核准步驟與變更管理的支援範圍較小，主要是 iTop 與 OTRS 的衍生產品。如果工作必須等到有人核准後才能開始，應優先查看這些產品，但也要接受因此增加的系統複雜度。

即時聊天與工單是不同的工作

如果您要的是搭配網站即時聊天功能的共用收件匣，請停止閱讀工單系統比較，直接參閱將 Chatwoot 作為支援服務台執行。

差異在於狀態機。Chatwoot 對話是附帶聯絡人的訊息串，適合跨多個頻道快速回覆。工單則是具有狀態、負責人、佇列、到期時間及可供報表分析之歷程的紀錄，適合處理超出單次對話範圍的工作。花四天追蹤硬體更換屬於工單工作。在 90 秒內回答「我的訂單在哪裡」則屬於聊天工作。

許多團隊兩者都需要。但同時執行兩者代表要管理兩個收件匣及兩套通知，因此請選擇最符合大部分進件量的方式，再讓另一個頻道透過電子郵件將訊息送入其中。

值得投入時間評估的選項

FreeScout：具備 helpdesk 行為的共用收件匣

採用 AGPL-3.0 授權，以 Laravel framework 上的 PHP 撰寫，並持續發布版本：1.8.247 於 10 October 2026 發布。其文件指出，沒有最低 CPU 或 RAM 要求，也能在 shared hosting 上執行。核心功能免費，agent 與 ticket 數量不限；knowledge base、workflow、live chat、tag 等大量額外功能，則以單一 instance 的一次性永久授權形式，作為付費模組提供。若團隊規模小，且主要以 email 作為溝通管道，可選擇它。

osTicket：經典的表單與佇列 ticket 系統

採用 GPL-2.0、PHP 8.2 至 8.4 與 MySQL。版本 1.18.4 於 June 2026 發布，因此維護節奏緩慢但穩定。它提供部門、help topic、自訂表單、預設回覆與 SLA 方案。介面保留較明顯的年代感。若客戶透過表單建立 ticket、需要傳統佇列，而且主機成本必須低廉，可選擇它。

Zammad：完整的服務台，但需要足夠 RAM

採用 AGPL-3.0 與 Ruby on Rails，7.2 系列自 23 September 2026 起為目前版本。自行託管的軟體可免費執行。Zammad 定價頁面的訂閱方案屬於支援合約；截至 October 2026，Business 層級每年起價為 2,999 euros。Zammad 的硬體需求頁面要求 2 個 CPU 核心與 6 GB RAM；若 Elasticsearch 與其部署在同一台伺服器，還需額外 4 GB。Elasticsearch 並非必要，但能加速跨多年舊 ticket 的搜尋。若 ticket 量大、使用多個管道，且伺服器具備足夠資源，可選擇 Zammad。

GLPI：整合資產清冊的 IT 服務台

採用 GPL-3.0。版本 12.0.0 於 7 October 2026 發布，要求 PHP 8.3 或更新版本。11.0 系列仍持續提供修補程式；11.0.11 於 1 October 2026 發布，並可搭配 PHP 8.2 或更新版本、MySQL 8.0 或 MariaDB 10.6 以上版本。透過 receiver 搭配 mailgate automatic action，可將 email 轉換為 ticket；routing rule 則能將訊息分派至不同 entity，這也是 GLPI 在單一安裝中區分不同站點或客戶組織的方式。若是內部 IT 環境，且資產清冊與 ticket 佇列同樣重要，可選擇它。

iTop：以 ticketing 為上層功能的 CMDB

採用 AGPL-3.0，目前版本為 3.3.0，於 15 September 2026 發布。其 sizing 指引指出，在每月少於 200 個 ticket 且 console 使用者少於 20 人的情況下，RAM 起始需求為 4 GB；若每月最多 5,000 個 ticket，則提高至 8 GB。若需要建立服務、合約與影響範圍的模型，而 ticket 只是整體架構中最小的一部分，可選擇它。

Znuny 與 OTOBO：仍在維護的 OTRS 系列

兩者都源自 OTRS Community Edition；該版本已於 December 2020 底終止生命週期。Znuny 採用 GPL-3.0，延續 6.0.30 codebase，目前為 7.3 系列。OTOBO 採用 GPL-3.0，於 2019 年 fork，目前為 11.0 系列。兩者都以 Perl 撰寫，也都遵循 ITIL 實務設計，且資源需求較高：OTOBO 文件要求 production machine 具備 8 GB RAM 與 40 GB 儲存空間，並建議使用 16 GB。若需要流程自動化與適合服務組織的 ticket 模型，且團隊中有人熟悉 Perl，可選擇其中一個。

另外兩個值得了解的選項

Request Tracker 採用 GPL-2.0、以 Perl 撰寫，於 May 2026 發布 6.0.3；email 是其原生介面，而非附加功能，因此仍適合以 email 驅動的佇列。Frappe Helpdesk 採用 AGPL-3.0，於 October 2026 發布 1.30.2，介面是這些選項中最現代化的一個，並提供 SLA 與 knowledge base；但必須一併採用完整的 Frappe stack，也就是讓 Redis 與 background worker 和資料庫一同執行。

小型 VPS 各自需要什麼

官方公布的最低需求是可靠的起點。這些數字來自各專案本身，不是我的測量結果。

[
  {
    "tool": "OTOBO 11",
    "min_ram_gb": 8,
    "notes": "production minimum, 16 GB recommended, 4 GB for a test box"
  },
  {
    "tool": "Zammad 7",
    "min_ram_gb": 6,
    "notes": "add 4 GB more to run Elasticsearch on the same server"
  },
  {
    "tool": "iTop 3.3",
    "min_ram_gb": 4,
    "notes": "under 200 tickets a month, fewer than 20 console users"
  }
]

將這 3 個數字視為最低門檻，而不是目標，因為每個數字都假設工單量不高。RAM 也只是其中一半。這裡的每個選項都需要資料庫，而資料庫也需要獨立的記憶體預算。因此，在 4 GB 主機上執行 Zammad，實際上是讓 Zammad、PostgreSQL 及其他安裝的元件共同使用這 4 GB 記憶體。

FreeScout 和 osTicket 完全沒有公布 RAM 最低需求。這不是行銷說法。它們只是透過 MySQL 運作的一般 PHP 應用程式，因此其最低需求取決於 PHP 與資料庫，而不是 helpdesk 本身；這個門檻也遠低於上方的數字。請改為檢查磁碟空間：附件成長速度通常會超出預期，因為客戶會傳送螢幕擷取畫面。

如何判斷專案仍在維護？

先檢查這一點，再查看功能清單。因為保存客戶資料的無人維護 helpdesk 發生問題時，無法靠設定修正。

• 閱讀 repository 中的 license，不要只看行銷頁面。UVdesk 的 community package 採用 OSL-3.0，這是多數團隊從未審閱過的 license；其最近一次 release 是 2025 年 9 月的 v1.1.8。
• 查看最新 release 的日期，不要只看最新 commit。commit 可能只是修正 README 中的錯字。
• 確認 repository 是否已封存。Peppermint 是許多清單中都會出現的 open source helpdesk，其擁有者已於 2026 年 7 月 17 日將 repository 封存，最近一次 release 則是 2024 年 11 月的 0.5.5。封存後的 repository 只能讀取，因此不會再有人為它發布 security fix。
• 如果專案是從已停止維護的專案 fork 出來，請確認該 fork 仍在維護。Znuny 和 OTOBO 都是如此，release 持續發布至 2026 年。

完全不應自行託管的情況

請如實評估團隊規模。每天只處理少量訊息的 2 人團隊不需要工單系統。他們需要共用信箱、標籤，以及誰負責回覆哪些內容的共識。Helpdesk 會增加需要備份的資料庫、可能無聲失效的郵件整合，以及必須持續修補的應用程式，但不會替你回覆任何工單。

有理由時再自行託管：資料必須留在你所控制的基礎架構上，或按代理人計價的費用已成為工具預算中最大的支出項目。市面上沒有任何工具支援的自訂需求，也算是理由。這些都是充分理由，而且上述工具確實都很優秀。

不要只為了節省成本，就在規模很小時自行託管。工單系統會儲存客戶姓名、地址、訂單詳細資料與客訴紀錄，因此修補不可省略，備份也至少必須成功還原過 1 次，才能算是真正可用。你不情願支付費用的託管方案，包含郵件送達能力、升級，以及由其他人負責的 on-call 輪值。使用 2 名代理人時，這通常是較佳的取捨；等佇列增加後，再重新評估也很容易。

安裝前需要規劃的工作

請在安裝前規劃備份。你需要備份資料庫與附件目錄，也需要在備用主機上完整還原一次，才能確認備份可正常使用。

使用 Compose 執行，這樣升級只需更新版本並重新啟動。如果你不熟悉 Compose，VPS 的 Docker Compose 基礎會說明檔案配置與應命名哪些 volume。請將資料庫放在 named volume，而不要放在容器內，否則升級時可能連同工單一併遺失。

請監控郵件擷取器，因為這是最容易靜默失敗的部分。未送達的工單不會觸發警示，而你最先注意到的可能是憤怒的客戶詢問為何沒有人回覆。每週透過支援地址傳送一封訊息，並確認訊息有出現。更好的做法是針對它設定警示：在擷取工作停止時傳送推播通知到自己的手機，比起沒有人開啟的儀表板更可靠。

最後，請查看工單的內容。當大多數工單都是不同人提出的相同問題時，自行託管的論壇可以公開回答一次。當大多數工單都與付款和日期有關時，更完善的紀錄可能比支援台更能解決問題，而自行託管的發票工具會是更合適的選擇。

FAQ

我可以在 2 GB 的 VPS 上執行自架服務台嗎？

可以，但請選擇 PHP 應用程式。FreeScout 的文件表示沒有最低 CPU 或 RAM 需求，osTicket 也沒有公布相關需求，因此最低配置取決於 PHP 與 MySQL 在你的主機上所需的資源。Zammad 與 OTOBO 則相反：兩者的文件分別要求至少 6 GB 與 8 GB 的 RAM，還未計入 Elasticsearch。請為這兩者各自準備一台伺服器。

我需要自行架設郵件伺服器，才能將電子郵件轉成工單嗎？

不需要。這裡幾乎所有選項都會透過 IMAP 或 POP3 登入你現有的信箱，並透過 SMTP 寄送回覆。Request Tracker 預期郵件會以管線方式輸入，因此需要在它與信箱之間加入 fetchmail 等擷取工具。使用目前郵件供應商提供的信箱即可。你需要的是寄件地址的授權設定：涵蓋郵件轉送伺服器的 SPF 記錄、DKIM 簽署，以及與兩者一致的 DMARC 記錄。缺少這些設定時，回覆會被歸入垃圾郵件，而在你的畫面上看起來就像工單已回覆，實際上客戶可能根本沒收到。

我應該使用 Chatwoot，還是工單系統？

當工作內容是對話時，請使用 Chatwoot，例如網站即時聊天、社群頻道，或需要在幾分鐘內回覆的共用收件匣。當工作具有狀態、負責人與到期時間，且生命週期超過最初展開對話的時間時，請使用工單系統。升級處理、核准流程與 SLA 計時都適合放在工單中。如果兩者都適用，請先選擇最符合大部分進件量的工具，再透過電子郵件將另一個頻道導入其中。

如何確認服務台專案仍在維護？

開啟儲存庫，查看最新版本的發布日期，然後確認儲存庫未被封存。Peppermint 的擁有者已在 2026 年 7 月將其封存，最後一個版本發布於 2024 年 11 月；封存後的儲存庫只能讀取，因此不會再有安全性修補。接著請直接閱讀儲存庫中的授權檔案，不要只看網站宣稱的授權，因為這裡有些專案使用你可能尚未審閱過的條款，例如 UVdesk 的 OSL-3.0。

小型團隊預設應該選哪一個？

如果主要使用電子郵件，且代理人少於 5 人，請先選擇 FreeScout，因為它輕量、發布頻繁，也符合小型團隊既有的工作方式。如果希望客戶透過表單建立工單，並在不使用大量 RAM 的情況下管理部門與 SLA 方案，請先選擇 osTicket。如果工單主要涉及公司硬體，請選擇 GLPI，讓資產清冊與工單佇列集中在同一個系統中。