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

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

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

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

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

郵件必須轉成工單嗎？

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

Inbound：實際建立工單的部分

本文中的每個選項都會透過 IMAP（internet message access protocol）或 POP3（post office protocol），從你已擁有的信箱讀取郵件。服務台會像一般郵件用戶端一樣登入，並依排程定期輪詢。郵件不會主動推送至服務台，因此輪詢停止後，工單也會停止建立，而客戶完全不會看到錯誤訊息。

osTicket 會明確呈現這個機制。你可以在管理面板中為每個郵件帳戶設定擷取頻率，但單獨啟用擷取功能並不足夠。輪詢程式位於 api/cron.php，官方文件建議加入執行該程式的 crontab 項目，通常每五分鐘執行一次。內建替代方案 auto-cron 只有在已登入的 agent 使用 Web 介面時才會執行，因此安靜的週末可能要等到有人登入後，系統才會擷取郵件。

GLPI 將相同工作拆成兩部分。receiver 是 GLPI 對郵件收集器的稱呼，負責保存信箱認證資訊；mailgate automatic action 則決定收集工作的執行頻率。工單停止出現時，先檢查 automatic action，再處理信箱設定。Zammad 會依頻道設定透過 IMAP 或 POP3 擷取郵件；在自架伺服器上，也可以透過 fetchmail 或 sendmail pipe 將郵件傳入。

接下來的陷阱是 threading。客戶回覆時，郵件必須加入現有工單，而不是建立第二張工單。郵件執行緒依賴 Message-ID、In-Reply-To 和 References 標頭，服務台也會將工單參照加入主旨列作為備援，因此支援郵件的主旨中會出現類似 [#123456] 的內容。若從寄出範本中移除該 token 以讓郵件更整潔，每封回覆都會重新建立為新工單。

最後是自動回覆。你的服務台會對每封新郵件傳送確認訊息。如果回覆的地址本身也是 autoresponder，兩者可能持續互相回覆，直到有人停止其中一方。RFC 3834 定義了 Auto-Submitted: auto-replied 標頭，讓自動回應系統能夠彼此辨識並保持沉默；符合規範的系統會設定該標頭。在將服務台指向會轉寄至 mailing list 的別名之前，先使用實際信箱進行測試。

Outbound：決定回覆是否能送達的部分

Inbound 問題容易察覺，因為工單不會出現。Outbound 問題則不明顯：回覆已送出，agent 也關閉了工單，但客戶始終收不到。你的工單系統會以你的網域寄信，因此該網域必須授權這些寄信來源。

網域需要 SPF（sender policy framework）記錄，列出所有會寄送郵件的來源。也需要 DKIM（domainkeys identified mail）簽署，以及 DMARC（domain-based message authentication, reporting and conformance）記錄，其政策必須與兩者一致。在安裝任何系統前，先確認目前已發布的設定：

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 位址沒有寄信信譽，許多主機商也會預設封鎖 outbound port 25，直到你提出開通要求。改用 mail provider 進行 relay；這和伺服器上其他服務面臨的是同一個決定：讓自架應用程式寄出郵件而不被歸入垃圾郵件 說明了如何為所有服務一次完成設定。如果你也想自行管理信箱，在 VPS 上部署 Mailcow mail server 能提供服務台用來輪詢的收件匣，但這項工作比部署服務台本身更大型。

客戶支援，還是內部 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：具備服務台功能的共用收件匣

採用 AGPL-3.0 授權，以 Laravel framework 上的 PHP 撰寫，並持續發布版本：1.8.236 於 2026 年 8 月 24 日發布。其文件指出，沒有最低 CPU 或 RAM 要求，也能在 shared hosting 上執行。核心功能免費，代理人與工單數量不限；知識庫、工作流程、即時聊天、標籤等大量額外功能，則以單一執行個體的一次性永久授權形式，透過付費模組提供。當電子郵件是主要管道且團隊規模較小時，可選擇它。

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

採用 GPL-2.0，支援 PHP 8.2 至 8.4 與 MySQL。版本 1.18.4 於 2026 年 6 月發布，因此維護節奏緩慢但穩定。它提供部門、求助主題、自訂表單、預設回覆與 SLA 方案。介面風格較為老舊。當客戶透過表單建立工單、你需要傳統佇列，而且伺服器成本必須低廉時，可選擇它。

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

採用 AGPL-3.0 授權，以 Ruby on Rails 開發，2026 年 8 月目前為 7.1 系列。自架軟體可免費執行。Zammad 定價頁面的訂閱方案屬於支援合約；截至 2026 年 8 月，Business 方案每年起價為 2,999 歐元。Zammad 自身的硬體頁面要求 2 個 CPU 核心與 6 GB RAM；若 Elasticsearch 在同一台伺服器上執行，還需額外 4 GB。Elasticsearch 並非必要元件，但能加快跨多年舊工單的搜尋速度。當工單量實際較大、使用多個管道，且伺服器能負擔其需求時，可選擇 Zammad。

GLPI：附帶資產清冊的 IT 服務台

採用 GPL-3.0，支援 PHP 8.2 或更新版本、MySQL 8.0 或 MariaDB 10.6 以上版本，2026 年 6 月發布 11.0.8。郵件會透過 receiver 與 mailgate automatic action 轉成工單；路由規則可將郵件送入不同 entity，GLPI 便是以此在單一安裝中區分不同站點或客戶組織。當內部 IT 的資產清單與工單佇列同樣重要時，可選擇它。

iTop：以工單功能為基礎的 CMDB

採用 AGPL-3.0，目前版本為 2026 年 8 月發布的 3.2.3-2。其硬體規模建議指出，若每月工單少於 200 張、console 使用者少於 20 人，RAM 起始需求為 4 GB；每月工單量達 5,000 張時，需求提高至 8 GB。當你需要建立服務、合約與影響關係的模型，而工單只是整體資訊中最小的一部分時，可選擇它。

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

兩者都源自 OTRS Community Edition；該版本已於 2020 年 12 月底停止生命週期。Znuny 採用 GPL-3.0，延續 6.0.30 codebase，目前為 7.3 系列。OTOBO 採用 GPL-3.0，於 2019 年分支而出，目前為 11.0 系列。兩者都以 Perl 撰寫，也都依循 ITIL 實務設計，且資源需求較高：OTOBO 文件要求 production machine 配備 8 GB RAM 與 40 GB storage，建議使用 16 GB。當你需要流程自動化、符合服務組織需求的工單模型，且團隊中有人熟悉 Perl 時，可選擇其中一套。

另外兩個值得了解的選項

Request Tracker 採用 GPL-2.0、以 Perl 撰寫，於 2026 年 5 月發布 6.0.3。電子郵件是其原生介面，而非附加功能，因此仍適合以郵件驅動的工單佇列。Frappe Helpdesk 採用 AGPL-3.0，於 2026 年 8 月發布 1.29.0，擁有此處最現代化的介面，並提供 SLA 與知識庫；但你必須一併採用完整的 Frappe stack，也就是讓 Redis 與 background workers 和資料庫同時執行。

小型 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.2",
    "min_ram_gb": 4,
    "notes": "under 200 tickets a month, fewer than 20 console users"
  }
]

請將這 3 個數字視為底線，而不是目標，因為每個數字都假設工單量不高。RAM 也只是其中一半。這裡的每個選項都需要資料庫，而資料庫也需要獨立的記憶體預算。因此，執行 Zammad 的 4 GB 主機，實際上是同時執行 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 上執行自架 helpdesk 嗎？

可以，但應選擇 PHP 應用程式。FreeScout 文件指出沒有最低 CPU 或 RAM 要求，osTicket 也未公布相關要求，因此最低需求取決於 PHP 和 MySQL 在伺服器上的需求。Zammad 和 OTOBO 則相反：兩者的文件分別要求 6 GB 和 8 GB RAM，這還未計入 Elasticsearch。這兩個系統應各自使用獨立伺服器。

我需要自建 mail server，才能將電子郵件轉成 tickets 嗎？

不需要。這裡的每個選項都會透過 IMAP 或 POP3 登入你現有的 mailbox，並透過 SMTP 寄出回覆。使用目前服務商提供的 mailbox 就足夠。你需要的是寄件地址的授權設定：SPF 記錄必須涵蓋郵件所使用的 relay，並啟用 DKIM 簽署，以及建立與兩者一致的 DMARC 記錄。缺少這些設定時，回覆會被歸入 spam，而在你的畫面上看起來 ticket 已經回覆，收件者卻未必收到。

我應該使用 Chatwoot，還是 ticket system？

如果工作內容是對話，例如網站 live chat、社群頻道，或需要在幾分鐘內回覆的 shared inbox，請使用 Chatwoot。如果工作需要狀態、負責人和到期時間，且會持續到發起對話之後，請使用 ticket system。Escalation、核准流程和 SLA 計時都適合放在 tickets 中。如果兩者都適用，先選擇最符合大部分 incoming volume 的系統，再透過電子郵件將另一個頻道導入其中。

如何確認 helpdesk 專案仍在維護？

開啟 repository，查看最新 release 的日期，然後確認 repository 未被封存。Peppermint 已由其擁有者在 July 2026 封存，最後一次 release 可追溯至 November 2024；封存後的 repository 為唯讀，因此不會再取得 security fix。接著應讀取 repository 中的 licence file，而不是網站宣稱的 licence，因為這裡有些專案使用你可能尚未審閱過的條款，例如 UVdesk 的 OSL-3.0。

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

如果使用電子郵件作為頻道，且 agents 少於 five 人，請先選擇 FreeScout，因為它資源需求低、release 頻繁，也符合小型團隊現有的工作方式。如果客戶應透過表單開啟 tickets，而你希望在不需要大量 RAM 的情況下使用 departments 和 SLA plans，請先選擇 osTicket。如果 tickets 與公司硬體有關，請選擇 GLPI，讓 asset inventory 和 queue 集中在同一個系統中。