onlyTG 多專案管理與權限隔離深度對比：TG-Staff 如何實現更靈活的 Bot 營運

營運多個 Telegram Bot 是許多團隊的常態——無論是電商品牌用不同 Bot 處理售前與售後、Web3 專案區分社群營運與交易通知，還是行銷團隊為不同渠道設置專屬入口。然而，當 Bot 數量從 1 個增長到 3 個、5 個甚至更多時，管理痛點就會浮現：客服帳號混用導致權限失控、對話分配缺乏規則、敏感資料（如用戶錢包地址）可能被誤發。本文將客觀對比 onlyTG 與 TG-Staff 在 onlyTG 多專案管理與權限隔離上的差異，幫助你找到適合團隊的方案。

為什麼需要多 Bot 專案管理與權限隔離？

先看一個典型場景：一家跨國電商公司營運著 3 個 Telegram Bot——一個面向歐美用戶的售前諮詢 Bot、一個處理售後與退換貨的 Bot、以及一個用於內部客服培訓的測試 Bot。團隊有 5 名客服，分別負責不同時區。

• 權限混亂：如果所有客服都能存取所有 Bot，可能出現測試 Bot 的對話誤發到正式渠道，或售後客服看到了售前的商業策略資訊。
• 資料洩露風險：Web3 專案尤其敏感——客服在對話中誤發加密錢包地址，可能導致資產損失或合規問題。
• 協作效率低下：沒有對話分流規則，多個客服同時搶同一個用戶，或者高峰時段無人承接。

多專案管理與權限隔離的核心需求正是：讓正確的人，在正確的 Bot 專案中，做正確的事，同時防止錯誤發生。

onlyTG 多專案功能概述

onlyTG 是一個輕量級的 Telegram Bot 管理工具，支援基礎的多 Bot 管理與訊息轉發。它的核心定位是幫助個人或小團隊將多個 Bot 的訊息集中到一個介面處理。

onlyTG 的專案切換與基礎權限

• 專案切換：用戶可以在控制台內新增多個 Bot Token，並透過下拉選單在不同專案間切換，查看每個 Bot 的訊息列表。
• 基礎權限：onlyTG 的權限控制主要基於「用戶角色」——例如管理員可以管理所有 Bot，普通成員只能查看被分配的專案。但這種角色劃分較粗，通常只區分「所有者」與「成員」兩級。

onlyTG 在多團隊協作上的局限

• 缺乏獨立客服概念：所有成員共用同一個控制台登入，無法為每個客服建立獨立的帳號和權限配置。這意味著客服甲和客服乙的操作記錄難以追溯，一旦出現問題，無法快速定位責任人。
• 無專案級精細化權限：只能按「專案」整體分配權限，無法在專案內部進一步限制某個客服只能查看特定類型對話（例如僅查看已標記的 VIP 用戶）。
• 缺少內控審計：onlyTG 不提供訊息內容監控、風險詞攔截或操作稽核日誌。如果客服誤發了敏感資訊（如收款地址），團隊無法事前阻止，事後也難以追蹤。

TG-Staff 多專案管理與權限隔離的差異化優勢

與 onlyTG 不同，TG-Staff 從設計之初就面向多客服協作場景，將權限隔離、對話分流與內控管理作為核心能力。

獨立客服帳號與專案級權限配置

TG-Staff 引入了 客服（Staff Seat） 機制：

• 每個客服擁有獨立的登入帳號和密碼，透過 Web 控制台或行動端接待 Telegram 用戶。
• 在專案設定中，管理員可以將客服範圍配置為「全部客服」或「指定客服」。例如：將 Bot A 的客服權限僅開放給客服甲和乙，客服丙則無法看到 Bot A 的任何對話。
• 客服之間互不可見對方的私人便箋（專業版功能），進一步保護內部溝通資訊。

這種設計意味著：一個客服只能存取他被授權的一個或多個 Bot 專案，且操作範圍受限於管理員配置。 對於有多個業務線或客戶分層的團隊來說，這是基礎但關鍵的權限隔離能力。

對話分流與分配策略保障協作效率

多 Bot 並發諮詢時，如何確保每個用戶都能被及時承接？TG-Staff 提供了兩種分流規則：

• 輪流分配（預設）：按順序將新對話輪詢分配給有權限的客服，適合客服數量穩定、工作負載均衡的場景。
• 線上優先：優先分配給當前線上且空閒的客服；如果所有客服都離線，則回退到輪流分配。適合客服排班不固定的團隊。

此外，分流連結（Diversion Link） 是一個獨特優勢：你可以為每個 Bot 生成一個官方域名短鏈（如 https://app.tg-staff.com/{code}），用戶點擊後跳轉到 Bot 對話前，系統會捕獲訪客的 IP、瀏覽器資訊及 URL 參數。這意味著：

• 廣告歸因：區分不同渠道（如 Facebook 廣告 vs 搜尋引擎）帶來的用戶。
• 多渠道引流：同一個 Bot 可以配合多個分流連結，追蹤各渠道轉換效果。
• 高峰承接：配合分流規則，確保諮詢高峰時用戶不會被遺漏。

對於 onlyTG 用戶來說，這些功能通常需要額外開發或接入第三方工具才能實現。

內容風控與內控審計：Beyond 基礎權限

TG-Staff 專業版提供的內控管理功能，是 onlyTG 完全不具備的能力：

• 風險詞監控：管理員可以在風險詞組中配置敏感關鍵詞（如特定 TRC20/ERC20/BTC 地址或地址片段）。當客服發送訊息時，系統會即時偵測：命中風險詞時，彈窗要求二次確認或直接阻止發送。
• 觸發記錄審計：所有風險詞觸發事件都會被記錄，包括觸發客服、所屬對話、觸發時間與具體風險詞。管理員可以隨時查看稽核日誌，快速定位問題。
• 錢包地址攔截：對於 Web3、交易所、NFT 專案團隊，這個功能尤為重要——可以防止客服在對話中誤發或違規發送收款地址，降低資產安全風險。

簡單說：onlyTG 只解決了「誰可以看哪些 Bot」的問題，而 TG-Staff 進一步解決了「客服在對話中不能說什麼」的問題。

核心功能對比表：onlyTG 與 TG-Staff

功能維度	onlyTG	TG-Staff
多專案管理	支援多 Bot 新增與切換	支援多專案，依方案 3/5/20 個客服
獨立客服帳號	不支援（共用帳號）	支援，每個客服獨立登入
專案級權限	粗粒度的角色分配	支援「全部客服」或「指定客服」精細配置
對話分流	無內建分流規則	輪流分配 / 線上優先兩種策略
分流連結（歸因）	不支援	標準版及以上可用，支援 IP 與 URL 參數捕獲
內容風控	無	專業版：風險詞監控、錢包地址攔截、觸發記錄審計
自動翻譯	未公開說明	標準版含 AI 翻譯，專業版支援 Google/DeepL 專業翻譯
訊息批量群發	未公開說明	按用戶分群批量觸達
支付方式	未公開說明	Stripe 訂閱 + USDT（TRC20）鏈上支付
方案與試用	未公開說明	免費試用 3 天；標準版約 8.99/月，專業版約16.99/月（詳見官網方案頁）

場景案例：從 onlyTG 遷移到 TG-Staff 的團隊體驗

以下為虛構場景，用於說明實際遷移後的變化，非真實客戶案例。

某 Web3 交易平台團隊最初使用 onlyTG 管理 3 個 Bot（用戶支援 Bot、VIP 客戶 Bot、內部通知 Bot）。團隊有 4 名客服人員，但由於 onlyTG 不支援獨立客服帳號，所有客服共用同一個控制台登入。問題逐漸浮現：

• 客服甲誤將測試 Bot 的訊息回覆到正式用戶支援 Bot，引發用戶投訴。
• 一位客服在對話中無意間發送了團隊的新錢包地址，雖然及時收回，但已被用戶截圖傳播。
• 尖峰時段，多個用戶同時諮詢，客服之間互相搶對話，導致部分用戶等待時間超過 10 分鐘。

遷移到 TG-Staff 後，團隊做了以下改動：

1. 為每個客服建立獨立帳號，並將用戶支援 Bot 的權限只開放給客服甲和乙，VIP Bot 開放給客服丙和丁，內部通知 Bot 僅管理員可見。
2. 啟用「在線優先」分流規則，確保每次新對話優先分配給空閒客服。
3. 配置風險詞組，將團隊所有錢包地址加入監控清單，客服發送時彈窗確認，防止誤發。
4. 為不同廣告渠道產生分流連結，追蹤用戶來源，後續最佳化投放策略。

遷移後的第一個月，團隊回饋：對話回應時間從平均 8 分鐘降至 3 分鐘，未再發生訊息誤發事件，並且透過分流連結資料最佳化了廣告預算。

常見問題

問：onlyTG 和 TG-Staff 哪個更適合多 Bot 團隊？
答： 取決於團隊規模與協作需求。onlyTG 適合個人或小團隊管理少量 Bot；TG-Staff 則提供獨立客服帳號、專案級權限、對話分流與內控審計，更適合 3 人以上的協作團隊。

問：TG-Staff 的客服數量如何限制？
答： TG-Staff 按方案支援不同客服額度：標準版支援 3 個客服，專業版支援 20 個客服。每個客服可獨立登入 Web 控制台，接待不同 Telegram 用戶。

問：TG-Staff 是否支援將某個 Bot 的客服權限只開放給特定客服？
答： 支援。在專案設定中，你可以將客服範圍配置為「指定客服」，僅允許所選客服處理該 Bot 的對話，實現權限隔離。

問：onlyTG 有內容風控功能嗎？
答： 目前 onlyTG 未提供類似 TG-Staff 專業版的內控管理功能。TG-Staff 的風險詞監控與錢包地址攔截是 Web3/加密貨幣團隊的重要合規工具。

問：TG-Staff 支援哪些付款方式？
答： 支援 Stripe 訂閱付款（信用卡/簽帳金融卡）以及 USDT（TRC20）鏈上付款，適合偏好加密貨幣付款的用戶。

總結與下一步行動

onlyTG 與 TG-Staff 的核心差異在於 「管理深度」——前者解決的是「把多個 Bot 的訊息集中到一處」，後者解決的是「如何讓多個客服安全、高效、合規地協作」。如果你正在經歷多 Bot 營運中的權限混亂、對話分配不均或合規風險，TG-Staff 的獨立客服機制、專案級權限、對話分流與內控管理，可能是更值得嘗試的方案。