如何避免把 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月联系支持团队 →