service/sla-and-escalation 剩余六处失实(#903 四族之外):营业时间可配置、SLA 表现报表的四个维度、Breached SLA 视图、Service Board 看板、My Open Cases 排序、Waiting on Customer 暂停 SLA 时钟 #917

发现自 #903 的实施过程(PR #916)。#903 的裁定面被定死在 A(:12)/ B(:32)/ C(:34-38)/ D(:17-19)四族,本条是同页另外一族——页面指向的视图 / 报表 / 配置项是否存在——不在那个切割里,故单独立单,未在该 PR 里顺手改。

基线 origin/main = 7df29789(含 PR #907 / #906 / #908 / #910,平台 17.0.0-rc.3)。行号为 #903 落地前的原始行号;PR #916 使 :12 一节增长 5 行、:29 一节增长 4 行,故其后的行号在该 PR 合并后会位移。三语同页同行号。

事实

1. :23 / :137 —— 营业时间可配置

:23 的引用块:

> Business hours — the system can be configured to count only business hours (e.g., 9-5 Mon-Fri) rather than calendar hours. See Administration › Setup.

:137 的管理员提示又说了一遍(「由你租户的营业时间设定控制」)。全仓 grep -rniE "business.?hour" src/ 只有三处命中,全是产品目录与报价行的描述文案(src/data/catalog.seed.ts:138、src/data/sales.seed.ts:585 / :629),没有任何营业时间配置、日历或计算逻辑。唯一会算 SLA 时间的地方是 src/objects/case.hook.ts:60-64 的 due.setHours(due.getHours() + 4) —— 纯日历小时,不区分工作日与夜间。

2. :47-51 —— SLA 表现报表的四个细分维度

> - Agent (who's hitting their SLA?)
> - Priority (which priority bucket is leaking?)
> - Account tier (are customers being treated worse than prospects?)
> - Month (is performance trending up or down?)

src/reports/case.report.ts:17-29 的 sla_performance 只按一个维度出行:

dataset: 'case_metrics', rows: ['priority'], values: ['case_count', 'avg_sla_violated', 'avg_resolution'],

四个里只有 Priority 是真的。更要紧的是另外三个在数据集层面就不可达:src/datasets/case.dataset.ts:15-21 的 case_metrics 只声明了 status / priority / origin / type / created_date 五个 dimension —— 没有 owner/agent 维度,也没有账户等级维度(crm_account.tier 存在于 src/objects/account.object.ts:344,但 case_metrics 不跨对象取它)。created_date 的 dateGranularity 是 day 而非 month,且该报表根本没把它放进 rows。所以读者按图去报表里找这三个下拉,一个都找不到。

3. :118 / :130 —— 「Breached SLA」列表视图

:118 的推荐节奏表让服务经理每天早上看 Breached SLA + Critical Cases,:130 的经理提示让他「每天早上运行 Breached SLA 列表视图」。src/views/case.view.ts 里 crm_case shipped 的全部 7 个视图是:all_cases(All Cases)、case_workflow(Service Workflow)、sla_calendar(SLA Calendar)、case_timeline(Case Timeline)、my_open_cases(My Open Cases)、escalated_cases(Escalated Cases)、sla_at_risk(⏰ SLA at Risk)。没有叫 Breached SLA 的视图,也没有任何视图以 is_sla_violated: true 为过滤条件 —— 唯一按违约过滤的地方是 src/dashboards/service.dashboard.ts:148 的一个仪表盘部件。同理没有叫 Critical Cases 的视图。

4. :131 —— 「Service Board」看板

> - ✅ Use the Service Board kanban for daily standups.

看板视图是 case_workflow,label: 'Service Workflow'(src/views/case.view.ts:73-75)。tabs 里它显示为 Workflow(:59)。Service Board 这个名字在全仓不存在。

5. :117 —— My Open Cases「按 SLA 截止日期排序」

src/views/case.view.ts:125-138 的 my_open_cases 主排序键是 priority_rank desc,sla_due_date asc 只是次级键:

sort: [
  { field: 'priority_rank', order: 'desc' },
  { field: 'sla_due_date', order: 'asc' },
],

而且在 #903 写实之后这条更要紧:非 critical 工单没有 sla_due_date,次级键对它们整体失效,客服看到的其实是一个纯优先级队列。

6. :125 —— Waiting on Customer 可以暂停 SLA 时钟

> - ✅ Use Waiting on Customer when you're genuinely blocked — depending on your config, this can pause the SLA clock.

没有任何东西会暂停它。全仓写 sla_due_date 的只有 src/objects/case.hook.ts:60-64 一处,只在首次满足 critical 且字段为空时写一次,之后任何状态流转都不会重算或顺延;case_sla_monitor 的过滤条件 status: { $nin: ['resolved', 'closed'] } 也不排除 waiting_customer —— 也就是说,一个挂在等客户回复上的 critical 工单,时钟照走,到点照样被标违约并升级。「depending on your config」指向的那个 config 不存在。

为什么要紧

3、4、5 是「按图找不到东西」的代价:经理照 :130 去找 Breached SLA 视图会扑空,客服照 :117 以为自己的队列按截止时间排。2 更贵一点 —— 服务总监会以为能按客服和账户等级看违约率分布,而这两个维度在语义层根本没有,要做得改 case_metrics。6 是会让人做错事的一条:客服相信切到 Waiting on Customer 能停表,于是不再盯这张单,而系统那边时钟照走。1 是纯粹的配置承诺落空。

边界

• 与 service/sla-and-escalation 的 SLA 跟踪一节仍有四处行为性失实：只有 Critical 拿得到 sla_due_date、违约标记并非只读、"实时倒计时"零实现、High/Medium/Low 的"违约长什么样"描述的其实是优先级行色 #903 / PR docs: 清扫 bare workflows 残留族 —— 引擎里没有「重新评估 5 次」这个计数器，报价对象上也没有可调的计划 (#899) #916 不重叠:service/sla-and-escalation 的 SLA 跟踪一节仍有四处行为性失实：只有 Critical 拿得到 sla_due_date、违约标记并非只读、"实时倒计时"零实现、High/Medium/Low 的"违约长什么样"描述的其实是优先级行色 #903 落在 :8、:12、:17-19、:21、:29-38、:124,本单是 :23、:47-51、:117-118、:125、:130-131、:137,行集互斥。
• 与 service/sla-and-escalation 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886 / service 三页仍写「建议一个解决方案」会检索知识库并起草回复 / Copilot 用知识库对相似历史工单做模式匹配——两个技能都做不到 #890 / PR docs(service): 把升级触发条件、Critical 违约行与三处技能能力主语按源码写实 (#886, #890) #907 不重叠:那两单落在 :16、:57-60、:105、:134;:137 虽在同一个给管理员的提示小节内,但 service/sla-and-escalation 三语还剩两处行为性失实：升级触发条件多出一个不存在的 High+Customer 分支，Critical 违约行承诺「红色横幅 + 通知支持经理」 #886 的切割只覆盖 :134(SLA 目标那条)与 :138-139(升级触发与收件人),营业时间那条未在其中。
• SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595 不预判:营业时间日历、按客服/账户等级的 SLA 分布、Waiting on Customer 停表,是否应该存在都是 SLA policy matrix: per-priority × tier clocks, first-response stamping, escalation that reassigns #595(SLA policy matrix)的产品问题。本单只要求把当前行为写实 —— 要么点名说清不做什么,要么改成指向真实存在的视图与维度。
• 三语同步,口径沿用 docs(automation): 按 flow 源码写实内置流程表两行，并修 opportunity_won_alert 的 description (#851) #870 / docs(flows): name what the flow nodes do, not what they were once meant to do #877 / docs(service): 按 flow 与 hook 写实 SLA 页的升级说明(#876) #885 / docs: 清扫 automation 页之外的「工作流规则」并写实 cases 两条虚构通知 (#850, #887) #894:点名说清不做什么 + 真实归属,不静默删名。

Refs #903 #886 #890 #595