如何避免把 KPI 與 Kanban 看板上的日常任務混為一談？

只需問一個問題：這是球場記分板，還是場上的戰術動作？KPI 或 KR 是衡量結果的記分板（例如每週水療預訂額 $12,000 或完成 40 次 VIP 回訪）；Kanban 看板上的任務則是帶有負責人和截止日期、用來推動記分板變化的具體動作（例如「設計冬季水療專案海報」或「致電 20 位老會員」）。在 DING OS 中，您在目標模組建立結果指標，並在 Kanban 看板關聯具體執行卡片。

每個週期設定多少個 OKR 和 KPI 最合理（3-5 聚焦法則）？

為確保團隊專注，每個週期應控制在 3 到 5 個重點：(1) 場館或部門每季設定 3 到 5 個策略 Objectives；(2) 每個 Objective 掛鉤 3 到 5 條可衡量的 KR - 如果列了 8 到 10 條，代表把日常任務當成了 KR；(3) 每個職務或員工每月配置 3 到 5 項核心 KPI（如直營營收、完單量、回應時效 SLA）；(4) 所有日常執行事項放入 Kanban 看板，並關聯回這 3-5 個核心目標。

指標分配器（Quota Planner）如何向員工拆解營收目標？

無須手動為每位櫃台接待或銷售顧問逐行建立 KPI，只需開啟目標模組點擊 Quota Planner，輸入場館總目標（例如月營收 $60,000 或 300 筆預訂），勾選參與員工並選擇平均分配或自訂權重，系統就會自動為每位員工產生關聯父目標的子 KPI，並依已結帳訂單（booking.owner）即時彙總業績。

目標模組與 Kanban 看板之間的雙向聯動是如何運作的？

Kanban 看板上的每張任務卡都可以直接關聯到某個 OKR、KR 或 KPI。反過來，當某個目標在目標檢視中出現落後或風險預警時，管理者可開啟跟進抽屜點擊「+ 新增任務至看板」，立即派發補救行動卡。若目標的資料來源設為「已完成任務」，將關聯卡片拖入已完成欄會自動增加目標進度。

DING OS 如何獨立運作或與既有 ERP、POS、PMS 系統協同工作？

DING OS 將 AI 銷售對話、零佣金 QR 與櫃台收銀、自帶回饋金錢包的自有 CRM、OKR 與 KPI 目標管理及 Kanban 看板融為一體。您既可以用 DING OS 獨立管理整家場館，也可以透過標準化 CSV 匯出或 Webhook 同步，與既有後台 ERP 或 PMS（如 Opera、Cloudbeds、Mews、Square、iPOS、KiotViet）無縫配合。

DING OS 與傳統收銀系統有什麼差別？

傳統收銀機只在顧客決定買單後記錄付款。DING OS 驅動完整的商業與營運閉環：售前提供全天候 14 語言 AI 銷售顧問與郵件自動解析，售中支援零佣金 QR 點單、櫃台收銀與開台實耗核銷，售後透過 100% 自有 CRM 與會員回饋金驅動回購，並將 OKR、KPI、Kanban 看板與員工即時業績歸屬打通。

入站 SMTP 郵件同步如何解析電商平台訂單與 OTA 預訂？

每個工作區都會分配一個形如 [slug]@getding.io 的專屬接收位址。當您的郵件伺服器將訂單通知（TikTok Shop、Shopee）、預訂憑證（Booking.com、Agoda、球場預訂平台）或 B2B 詢價信轉寄至該位址時，邊緣 MIME 解析器會自動剝離 HTML 追蹤碼，擷取客戶姓名、商品明細、預約時間、參考單號與金額並直接推入櫃台即時佇列。

郵件處理管道如何防止轉寄無窮迴圈和重複建單？

系統透過三層機制攔截迴圈：(1) api.getding.io 發出的所有信件皆帶有 X-Ding-Generated: true 與 Auto-Submitted: auto-generated 標頭，回流時在 SMTP 邊緣直接丟棄；(2) 解析器計算 30 天冪等雜湊 sha256(organization_id + ":" + reference)，重複轉寄僅更新原紀錄；(3) 來自 *@getding.io 與 @trip.express 系統網域的信件會被自動過濾。

多個部門信箱能否同時轉寄到同一個工作區接收位址？

可以。orders@yourbrand.com、sales@yourcompany.com、reservations@yourvenue.com 等多個來源信箱皆可轉寄至同一個 [slug]@getding.io 位址。分類器會檢查原始收件人標頭與內文，精準路由至訂單、詢價、預訂或客服佇列。

開啟郵件轉寄會影響公司主信箱正常收信嗎？

完全不會。Google Workspace、Microsoft 365、Zoho Mail 與 cPanel 的轉寄規則皆採用雙投遞模式（「在收件匣中保留副本」）。每封信件都會先投遞至您的企業主信箱，再同步轉寄一份副本給 DING OS，企業信箱始終是您的安全主存檔。

如果入站郵件量超過方案月度包含額度會怎樣？

營業期間絕不會限流或中斷郵件接收。超出月度包含額度的部分依方案費率計費（Starter 每封 $0.04，Business $0.03，Enterprise $0.02，Free 版每月 30 封免費後為 $0.05，可由 $100-$300 AI 啟動贈金抵扣）。管理員可在帳務設定中配置月度上限與 80%、100% 用量提醒。

Starter、Business 與 Enterprise 方案的自訂網域路由如何運作？

Starter（含 1 個）、Business（含 3 個）與 Enterprise（含 10 個）方案支援綁定如 ding.yourbrand.com 的品牌子網域。HTTPS 請求到達 Cloudflare 邊緣代理（proxy.getding.io）後，會即時比對 api.getding.io 中已驗證的網域註冊表，無須用戶端跳轉即可直接呈現品牌專屬頁面。

驗證網域所有權並簽發 TLS 憑證需要設定哪些 DNS 紀錄？

只需在您的 DNS 服務商處新增兩筆紀錄：(1) 主機紀錄 ding 指向 proxy.getding.io 的 CNAME 紀錄；(2) 主機紀錄 _ding-challenge 填寫工作區加密驗證金鑰的 TXT 紀錄。兩筆紀錄公開解析生效後，系統將自動簽發並續期 DV TLS 1.3 憑證。

DNS 解析生效和憑證簽發通常需要多長時間？

使用較低 TTL（300 秒或自動）時，DNS 驗證與邊緣憑證簽發通常在 60 至 180 秒內完成。如果您的根網域設定了 CAA 紀錄，請確保允許 letsencrypt.org 與 pki.goog 簽發憑證。

DING OS 如何對線下實體點位和線上虛擬服務點進行建模？

所有服務點皆透過統一的 Unit 模型涵蓋 DING OS 全部 13 個產業類別，且所有訂閱方案皆可無限量產生點位 QR 立牌。

為什麼顧客掃描 QR 碼後點位編號處於鎖定狀態？

每個 QR 碼都內嵌了帶簽章的點位參數（例如 UNIT #04 或 REF #12）。掃碼後商城會在整個工作階段期間將該編號唯讀鎖定，防止顧客手動誤切桌號、球場號或房號而把訂單掛到他人帳單上。

沙龍、工作室以及牙科或醫美櫃檯能否在不儲存病歷的前提下使用預約分類？

可以。預約分類專為商業接待場景打造，涵蓋含準備緩衝的時段排程、0%手續費 QR 訂金收款、多堂數方案核銷與自動到店提醒。DING OS 是商業收銀與排程系統而非電子病歷平台，臨床診斷、病歷紀錄與處方皆由執業機構保存在獨立的合規醫療軟體中。

當櫃台裝置處於靜音狀態時，如何確保即時收到新單提醒？

櫃台調度透過持久 WebSocket 連線（wss://api.getding.io/v1/ws）執行聲光雙重提醒。每張新工單都會彈出常駐視覺通知橫幅，標明點位編號、客戶姓名、業務類別與待處理動作，同時播放 880Hz Web Audio 提示音；視覺卡片完全獨立於硬體喇叭開關運作。

結帳前的開台實耗盤點核銷（Open-Tab）是如何處理的？

在酒廊、球場邊飲品服務或飯店迷你吧等開台場景中，員工與客人可隨時向活躍帳單追加商品。結帳收款前，櫃台人員執行 reconcile_order 盤點實際消耗數量（例如配送 24 瓶、實耗 17 瓶、退回 7 瓶），再鎖定最終稅務發票。

系統如何記錄員工業績歸屬與銷售表現？

每筆預訂和訂單都必須記錄非空的 booking.owner 識別碼（對應建立或核銷訂單的登入員工，自動化入站渠道預設為 System AI Ingest）及協同營運角色。DING OS 不預設固定預設抽成比例，由企業財務在月底依內部薪酬制度結算獎金，同時櫃台共用頂欄自動隱藏個人金額。

不同工作區之間的多租戶資料隔離是如何保障的？

api.getding.io 中的所有資料庫讀寫皆強制執行基於已認證工作階段權杖的 organization_id 資料列級別隔離。身分驗證由採用 OIDC 與 DPoP 權杖綁定的 OneUID（uid.one）獨立完成，每家商戶作為獨立資料控制者 100% 擁有自己的客戶 CRM 資料。

營運指南

涵蓋 OKR 與 KPI 目標治理、KR 與 KPI 精準區分、員工指標拆解、Kanban 看板雙向聯動、免 API 郵件自動解析、自訂網域 DNS 設定及櫃台即時調度的實務手冊。

目標治理體系

在飯店、餐飲、沙龍工作室、旅行社與零售門市的日常經營中，目標管理失效往往源於團隊混淆了方向性目標 Objective（O）、突破性關鍵結果（KR）、月度健康度指標（KPI）與日常任務。DING OS 將四層結構清晰拆解，並與即時營收、預訂、員工業績歸屬及 Kanban 看板自動串聯。

開啟目標檢視

1. 目標層級對照表

企業管理標準

層級	建議數量	核心問題	衡量性質	場館真實範例
OKR · Objective 策略目標	每季 3 - 5 項依場館或部門	本季我們要在哪個方向實現突破？	依季度或年度設定的定性方向目標，完成進度（0-100%）由下屬 KR 自動彙總計算。	在第四季成為區域首選的企業宴會與康養度假目的地。
KR · Key Result 關鍵結果	每個 Objective 下 3 - 5 項不超過 5 項 KR	用什麼量化數字證明已達成該 Objective？	隸屬於某個 Objective 的定量里程碑（從基線 X 躍升至目標 Y），衡量新增變革成果。	將企業團建 B2B 宴會營收從 $15,000 提升至 $40,000；會員回購率從 18% 提升至 35%。
KPI · Metric 營運 KPI	每月 3 - 5 項依團隊或員工	日常與月度營運是否維持在標準健康線以上？	獨立持續追蹤的月度定量指標，用於維持營收配額、住房率與服務標準。	月度營收配額 $50,000；客房住房率維持 75% 以上；訂單取消率控制在 2% 以下。
Task · Kanban 執行任務	不限數量關聯回 3 - 5 個目標	今天由誰執行什麼具體動作來推動 KR 與 KPI 數字成長？	Kanban 看板上具備負責人、截止日期與流轉狀態（待辦 ➔ 進行中 ➔ 審核 ➔ 已完成）的執行卡片。	向 30 家合作企業寄送年終尾牙宴會方案；致電 50 位 VIP 會員發送生日禮遇券。

法則 1

為什麼團隊容易混淆 KR 與 KPI

KR 與 KPI 都寫成數字（$40,000、300 筆預訂、85%）。3 秒區分法：想像駕駛汽車，KPI 是儀表板（水溫、油量、巡航車速），每個月都必須維持正常；OKR 是前往新目的地的 GPS 導航路線，而 KR 就是沿途證明你正在接近終點的里程碑。

法則 2

營運 KPI 何時轉化為 KR

如果某項指標運作平穩、只需按月下達常規考核額（如酒吧月營收 $20,000），請建立為獨立 KPI。但當某項 KPI 嚴重下滑或下季計畫發起翻倍專案（透過推出駐唱之夜將酒吧營收從 $20,000 拉升至 $45,000），它就升級為策略 Objective 下的關鍵結果（KR）。

法則 3

防灌水失焦的 3-5 聚焦法則

最常見的管理誤區是一次建立 10-15 個目標，或把日常瑣事塞進 KR 湊出表面 100% 完成率。每季應控制在 3-5 個 Objectives 及各 3-5 個結果型 KR，每位員工每月聚焦 3-5 項與已結帳訂單（booking.owner）掛鉤的 KPI，日常事務全部放入 Kanban 看板執行。

2. 目標閉環落地四步驟

第 1 步：選擇正確的目標分類

進入 任務 ➔ 目標 點擊 建立目標。選擇 OKR · 策略目標 時將開啟內嵌關鍵結果建構器，可一次定義 2-4 條量化 KR；選擇 KPI · 營運指標 時則直接顯示初始基線、目標值與單位輸入欄。

第 2 步：綁定即時業務資料來源

為每條 KR 或 KPI 綁定五種資料來源之一：營收（自動加總已結帳帳單）、預訂數（已完成訂單）、業績歸屬（基於 booking.owner 即時統計）、已完成任務（自動統計移入已完成欄的關聯 Kanban 卡片）或 手動更新。

第 3 步：使用 Quota Planner 一鍵拆解指標

點擊工具列 Quota Planner，輸入場館總目標（如月營收 $60,000），勾選參與員工並選擇平均分配或依權重分配，系統將自動產生關聯的子 KPI 並即時追蹤達成進度。

第 4 步：向 Kanban 看板派發補救任務

系統自動對比實際完成率與週期時間進度，標記落後或風險目標。開啟目標 進度更新 抽屜並點擊 + 新增任務至看板，即可將帶有目標標籤的執行卡片直接派發至 Kanban 看板。

系統架構

DING OS 是多租戶商業、預訂與櫃台調度作業系統。既可獨立承載門市全流程營運，也可部署在既有財務或旅宿管理帳本前端，將非結構化入站郵件、店內 QR 點單與開台核銷統一匯聚至單一即時佇列。

核心子系統	接入端點	運作規範
入站 MIME 解析引擎	POST /v1/email/ingest/	在 Cloudflare 邊緣節點接收寄往 `[slug]@getding.io` 的 SMTP 流量，擷取結構化欄位（客戶、明細、排程、單號、總價），並執行 30 天 SHA-256 冪等防重。
邊緣網域路由代理	proxy.getding.io	將自訂子網域（`ding.yourbrand.com`）與租戶代碼（`[slug].getding.io`）映射至獨立隔離容器，並全自動簽發與續期 DV TLS 1.3 憑證。
櫃台即時調度匯流排	wss://api.getding.io/v1/ws	向所有配對櫃台終端即時推送工單狀態流轉（`pending`, `confirmed`, `ready`, `completed`），同步觸發視覺橫幅與 880Hz 音訊提醒。
多模式帳單引擎	POST /v1/counter/	執行即時結帳、分時單元預約及開台消費盤點核銷（`reconcile_order`），強制記錄負責員工代碼（`booking.owner`）。

與既有財務及管理軟體並行協同

DING OS 可獨立運作，也可與既有後台會計軟體並行協同，無須更動原有會計科目表或稅務總帳。

前台獲客與履約層（DING OS）

郵件訂單與預訂自動擷取、14 語言 QR 自助商城、對話式詢價收集（capture_inquiry）、開台實耗盤點及櫃台即時調度。

後台財務總帳層（ERP, POS, PMS）

法定營業稅電子發票開立、總帳傳票入帳、日終班次結轉、客房房卡製卡，以及透過 CSV 或 Webhook 同步扣減倉庫庫存。

郵件自動同步

無須開發 API，只需將郵件伺服器中的訂單通知、OTA 預訂確認信與 B2B 詢價單轉寄至工作區專屬接收位址。系統直接解析入站 MIME 內容並寫入調度佇列，無須輪詢 IMAP 或儲存信箱密碼。

工作區專屬接收位址

雙投遞主信箱保護機制

設定轉寄規則時請務必開啟 「在收件匣中保留副本」。您的企業主信箱（[email protected], [email protected], [email protected]）始終完整保留每封原始信件作為主存檔，同時由 DING OS 並行處理轉寄副本。

開啟 Gmail 設定 ➔ 查看所有設定 ➔ 轉寄和 POP/IMAP 分頁。
選擇 新增轉寄地址 並輸入 [slug]@getding.io。
Google 會寄送驗證信至工作區。開啟 DING OS 收件匣 取得確認連結並核准轉寄。
開啟 篩選器和封鎖的地址 ➔ 建立新篩選器，在包含字詞中填入 subject:(Order OR Quote OR Booking OR Reservation OR Confirmation)。
勾選 轉寄到 [slug]@getding.io，保持 略過收件匣 未勾選以保留原信，最後儲存篩選器。

三層無限迴圈抑制協定

1. 系統標頭識別攔截

api.getding.io 發出的通知皆帶有 X-Ding-Generated: true 與 Auto-Submitted: auto-generated 標頭，邊緣 SMTP 節點收到後會直接丟棄。

2. 30 天單號雜湊防重

入站工單依 sha256(organization_id + ":" + reference) 建立 30 天索引，重複轉寄僅更新既有紀錄狀態而不會重複建單。

3. 系統寄件網域過濾

凡 Return-Path 或 From 符合 *@getding.io 與 @trip.express 的信件皆在 AI 解析前自動攔截。

全渠道串接指南

Zalo 官方帳號（ZBS 與 ZNS）、Telegram 機器人、WhatsApp Cloud API、Messenger、開放銀行（VietQR, SePay）、Stripe、PayPal 及 OTA 平台分步設定指南。

階段 1：啟用 Zalo 應用與 Webhook

developers.zalo.me

開啟 developers.zalo.me 選擇您的應用程式，將右上角狀態開關切換為 Active，避免回傳 -209 錯誤碼。
在 Domain verification 中輸入 workspace.getding.io，複製 zalo-platform-site-verification 驗證標籤貼至 工作區 ➔ 追蹤設定 並完成驗證。
在 Products ➔ Official Account API ➔ General settings 中申請 OA 資料管理與使用者訊息管理權限。
在 Webhooks 中將回呼網址設為，並啟用 user_send_text、user_send_image 與 oa_send_text 事件。

階段 2：產生 OAuth 權杖並開啟 25 小時自動續期

API Explorer

開啟 developers.zalo.me/tools/explorer，選擇應用程式與 OA Access Token 並授權您的官方帳號。
複製產生的 OA Access Token（效期 25 小時）與 Refresh Token（效期 3 個月），以及應用設定中的 App ID 與 App Secret。
將四項參數填入 渠道整合 ➔ Zalo OA ➔ 連線設定，DING OS 每 25 小時會在背景自動更新權杖確保訊息不中斷。

階段 3：連結 ZCA 企業帳戶

business.zalo.me

若建立 ZBS 範本時應用程式下拉選單為空，請開啟 business.zalo.me ➔ 選擇 ZCA 帳戶 ➔ Settings ➔ Applications ➔ Link application 並輸入 Zalo App ID。
OA 雙向客服訊息說明（錯誤碼 -224）：透過 openapi.zalo.me/v3.0/oa/message/cs 傳送回覆需開通 1 個月試用或付費 OA 方案（zalo.cloud/oa/pricing）。免費版下 DING OS 會自動複製 AI 回覆草稿並一鍵開啟 oa.zalo.me/chatv2。

階段 4：ZNS 標誌規格與範本參數對應

account.zalo.cloud

Zalo ZNS 要求上傳兩張透明背景橫向 PNG 標誌（淺色與深色模式各一，尺寸 400 x 96 px，50:12 比例置中對齊）。請從 Zalo 官方範本庫建立四類標準範本（Order, Transfer, Rating, Voucher），並依以下對照表綁定參數：

範本類型	參數鍵名	Zalo 技術類型
Order, Rating	order_code	Mã số (30)
Order（CTA 連結）	order_id	URL (200)
Order	phone_number	Thông tin liên hệ (50)
Order, Transfer	price	Số lượng / Số tiền (20)
Order	status	Trạng thái giao dịch (30)
Order	date	Thời gian (20)
Order	name	Tên khách hàng (30)
Transfer, Rating, Voucher	customer_name	Tên khách hàng (30)
Transfer	contract_number	Mã số (30)
Transfer	transfer_amount	Tiền tệ (VNĐ) (12)
Transfer	bank_transfer_note	Bank Transfer Note (90)
Rating	order_date	Thời gian (20)
Voucher	customer_id	Mã số (30)
Voucher	voucher_code	Mã số (30)
Voucher	start_date	Thời gian (20)
Voucher	expire	Thời gian (20)

標準審核備註（140 字元以內）

Gửi tự động xác nhận mã đơn, tổng tiền và trạng thái ngay khi khách đặt dịch vụ thành công. Không chứa quảng cáo.

自訂網域 DNS 紀錄

請在您的網域註冊商（Cloudflare, Route 53, GoDaddy 等）新增以下兩筆 DNS 紀錄，將 ding.yourbrand.com 導向邊緣代理。

類型	主機紀錄	必填紀錄值	TTL	狀態
CNAME			自動	待設定
TXT			自動	待設定

若網域代管於 Cloudflare DNS，首次驗證時請將 CNAME 的代理狀態設為僅 DNS（灰色雲朵）。網域管理設定

櫃台調度與提示音

櫃台終端與工作區維持持久 WebSocket 連線（wss://api.getding.io/v1/ws）。每當收到新訂單、預訂或詢價時，終端會同步觸發 880Hz Web Audio 合成提示音與常駐視覺通知橫幅。

聲音提醒設定

請在櫃台平板瀏覽器中授予網站聲音權限，使背景分頁無須觸控即可自動播放 880Hz A5 與 1318.5Hz E6 提示音，並在下方測試喇叭音量。

Chromium網站設定 ➔ 聲音 ➔ 允許

Safari設定 ➔ 網站 ➔ 自動播放 ➔ 允許全部自動播放

常駐視覺橫幅

每張入站工單都會在畫面彈出常駐視覺卡片，清晰顯示服務單元編號、客戶姓名、業務分類與待辦動作，即使裝置靜音也不會漏單。

即時通道wss://api.getding.io/v1/ws

靜音保障常駐工單提醒卡片

服務單元綁定與 QR 碼

所有線下實體與線上虛擬服務點皆透過統一的 Unit 模型涵蓋全部 13 個產業分類：spaces, realty, events, appointments, travel, mobility, retail, sports, spa, amenities, dining, drinks 與 takeaway。所有方案皆可無限量產生 QR 立牌。

位置參數唯讀鎖定

每張 QR 立牌皆內嵌簽章單元代碼（如 UNIT #04 或 REF #12）。顧客掃碼後位置徽章全程唯讀鎖定，防止手動誤改桌號、球場號或房號導致錯掛帳單。

開台消費盤點核銷

啟用開台模式的服務單元支援顧客在場期間隨時加點。結帳前收銀員執行 reconcile_order 核對實際消耗數量並扣減未拆封退回商品。

員工業績歸屬

每筆訂單、現場預訂與核銷帳單皆在 booking.owner 中不可竄改地記錄建立人代碼。自動化渠道入站訂單預設標記為 System AI Ingest，直至櫃台人員接單處理。

績效看板與月底結算

DING OS 從不強制設定固定預設抽成比例。每筆訂單、預訂與任務都會在即時績效看板記錄多角色貢獻（SALES, OPERATIONS, FINANCE, MANAGER, OBSERVER），方便財務團隊依企業內部薪酬制度在月底結算獎金，同時在櫃台共用頂欄隱藏個人金額以保護隱私。

多租戶資料隔離

租戶邊界在 api.getding.io 資料庫查詢層強制執行，每次讀寫請求皆嚴格限定在已認證工作階段所屬的 organization_id 範圍內。

OneUID 身分驗證

員工工作階段透過支援 OIDC 與 DPoP 權杖綁定的 OneUID（uid.one）完成驗證。OneUID 僅核驗身分代碼（sub），絕不儲存商戶 CRM 資料或交易紀錄。

客戶資料 100% 自主所有權

每家商戶在 GDPR 與個人資料保護法規下皆作為獨立資料控制者，100% 擁有自身客戶檔案、聯絡方式與會員回饋金餘額，零跨店資料共享。

常見問題解答

面向場館主理人、營運總監、部門經理與 IT 團隊的技術與實務參考手冊。

KR 與 KPI 都採用量化數字，因此團隊常會混淆。兩者的核心差異在於用途：KPI 衡量每個月都必須持續達標的日常營運健康度（例如客房住房率維持 75% 以上、月營收達到 $50,000、取消率低於 2%）。關鍵結果（KR）始終隸屬於某個策略 Objective（OKR），用於衡量特定週期內從基線 X 到目標 Y 的突破（例如第四季將企業宴會營收從 $15,000 提升到 $40,000）。當某項 KPI 下滑需要專案攻堅扭轉時，它就會進入 Objective 成為一條 KR。

最後更新：2026年11月聯繫支援團隊 →