diff --git a/.changeset/service-index-escalation-residue.md b/.changeset/service-index-escalation-residue.md new file mode 100644 index 000000000..6dbdb0d66 --- /dev/null +++ b/.changeset/service-index-escalation-residue.md @@ -0,0 +1,45 @@ +--- +'hotcrm': patch +--- + +按 flow / hook 源码写实 `content/docs/service/index.mdx` 上残留的五条升级与通知说法,三语同步(#904)。 + +服务域的落地页是大多数读者最先读到的一页。`service/sla-and-escalation`(#876 / #886)与 +`service/cases`(#850 / #887)的同族说法已经逐条写实之后,本页的「一个典型工单的生命周期」 +与「系统为你做的事」两处清单仍在原样承诺重新分配、一个不存在的分支、两个不存在的收件人 +和一个不存在的横幅 —— 读者拿到的是自相矛盾的两套描述,而更显眼的那一套是错的。五条按 +兄弟页已落地的口径写实,`content/docs/service/index.zh-Hans.mdx` / +`content/docs/service/index.zh-Hant.mdx` 同步: + +- **升级不会把工单重新分配给资深客服。** 生命周期第 5 步写的是「如果卡住了(或紧急,或来自 + 客户),升级流程会将其重新分配给资深客服」。`src/flows/case-escalation.flow.ts` 的 + `update_record` 节点只写 `is_escalated` / `escalation_reason` / `escalated_date` / + `status`,从不碰 `owner_id` —— 节点注释开头就是 `No owner reassignment`,因为 + `{caseRecord.owner_id.manager}` 穿不透 lookup、会插值成字面量 `undefined`;升级通知的正文 + 自己写着 `It remains assigned to you.`。现在写实为:升级把工单标记为 *Escalated* 并提醒 + 它的负责人,不做交接;交到资深客服手里仍是一个需要有人手动完成的步骤。 +- **没有 `High + Customer` 这条分支。** 同一步里的「或来自客户」,以及「自动升级——将紧急工单 + 或高优先级客户工单升级给资深客服」,说的是同一个不存在的东西:start 条件全文只有 + `record.priority == "critical"`,全仓 24 个 flow 没有任何一处读取账户类型。现在写实为: + 只有 Critical 会自动升级,High 工单永远不会(无论账户是什么),升级它靠的是工单记录上的 + **Escalate Case** 按钮。 +- **「紧急时通知」发给工单负责人,不发给支持经理。** 该行说的其实就是工单升级流程的 `notify` + 节点,`recipients` 只有 `{caseRecord.owner_id}` 一项,`support_manager@example.com` 在 + `src/` 下零命中。现在写实为站内消息 + 邮件发给**工单负责人**,并点名说清这个收件人不存在。 +- **「升级时通知」不发任何邮件。** `escalation_team@example.com` 全仓零命中,状态转为 + escalated 触发的是 `src/objects/case.hook.ts` 的 `case_status_side_effects` 钩子开出的那条 + **次日到期、优先级为紧急、归账户负责人**的跟进任务。现在写实为这条真实归属。 +- **SLA 违约没有红色横幅。** `grep -rn "banner" src/` 在整个 app 里只有 + `src/objects/opportunity.object.ts` 的一句无关注释 —— 没有任何横幅机制。违约的真实表现是 + `is_sla_violated` 被置真、工单被升级,外加 `src/flows/case-sla-monitor.flow.ts` 的 `notify` + 节点发给 `{currentCase.owner_id}` 一人的站内消息 + 邮件。 + +沿用 #876 / #886 已确立的写法:读者来找的那几个词 —— 资深客服、支持经理、升级团队、红色横幅 +—— 都点名说清**不做**,并写出真正的归属,而不是静默删掉、留下一个「页面大概是忘了写」的印象。 +本页只陈述当前行为,不预判升级*是否应该*改派、High *是否应该*自动升级(#595 / #596 的产品问题)。 +同段中经核对属实的三条(工单分流技能定优先级、关闭时标记解决时间、未写解决方案不能关单) +保持不动。顺带把生命周期第 5 步的中文页内链去掉了英文锚点 `#case-escalation` —— 两个中文页的 +标题是中文,该锚点在这两页上落不到任何位置(#755 / #762 惯例)。 + +纯文档改动,3 个文件。未触碰 `src/**`,没有任何 flow、hook、条件、收件人或字段发生变化 —— +是页面向已经在跑的行为对齐。Fixes #904. diff --git a/content/docs/service/index.mdx b/content/docs/service/index.mdx index 275f28a12..ee650346b 100644 --- a/content/docs/service/index.mdx +++ b/content/docs/service/index.mdx @@ -27,17 +27,17 @@ New ──► In Progress ──► Waiting on Customer ──► Resolved ─ 2. **Priority is assigned** — Low, Medium, High or Critical. *Critical* alerts the support manager immediately. 3. **SLA target is calculated** — every case gets a deadline based on priority. 4. **Agent works the case**, moving status as they go. -5. **If it's stuck** (or critical, or a customer's), the [escalation process](/docs/service/sla-and-escalation#case-escalation) reassigns it to a senior agent. +5. **If it's Critical** (or its SLA due date passes), the [escalation process](/docs/service/sla-and-escalation#case-escalation) flags the case as *Escalated* and alerts its owner. It does **not** reassign it — there is no hand-off to senior staff or to a manager — and no escalation condition reads the account, so a *Customer*'s case gets no branch of its own. 6. **Resolution is recorded**, the resolution time is auto-stamped, and the case is closed. ## What the system does for you - **Auto-prioritise** with the Case Triage skill (the Service Copilot reads the case and recommends a priority). -- **Auto-escalate** critical cases or high-priority customer cases to a senior agent. -- **Notify on critical** — emails the support manager whenever a case is set to Critical. -- **Notify on escalation** — emails the escalation team whenever a case is escalated. +- **Auto-escalate** Critical cases — the flow flags them *Escalated* and alerts the owner; it never touches `owner_id`, so nothing is handed to a senior agent. A High case is never escalated automatically, whatever the account is: raising one is the manual **Escalate Case** button. +- **Notify on critical** — inbox message + email to the **case owner** whenever a case is set to Critical. That is the Case Escalation flow's notify node, whose recipient list is `{caseRecord.owner_id}` alone; there is no `support_manager@example.com` recipient anywhere in this app. +- **Notify on escalation** — no email goes to an escalation team: `escalation_team@example.com` exists nowhere in this app. What the *Escalated* status fires is the `case_status_side_effects` hook, which opens an **Urgent follow-up task due tomorrow for the account owner**. - **Stamp resolution time** automatically when a case is closed. -- **Flag SLA breaches** with a red banner once the SLA target passes. +- **Flag SLA breaches** once the SLA target passes — the case is marked **SLA Violated**, escalated, and its owner alerted by inbox + email. No red banner: this app has no banner mechanism. - **Block bad closes** — you can't mark a case Closed without a resolution written. ## Service AI skills diff --git a/content/docs/service/index.zh-Hans.mdx b/content/docs/service/index.zh-Hans.mdx index 5f6674ab2..8a1b63182 100644 --- a/content/docs/service/index.zh-Hans.mdx +++ b/content/docs/service/index.zh-Hans.mdx @@ -27,17 +27,17 @@ New ──► In Progress ──► Waiting on Customer ──► Resolved ─ 2. **分配优先级**——低、中、高或紧急。*紧急*会立即提醒支持经理。 3. **计算 SLA 目标**——每个工单都会根据优先级获得一个截止时间。 4. **客服处理工单**，随进度推进状态。 -5. **如果卡住了**（或紧急，或来自客户），[升级流程](/zh-Hans/docs/service/sla-and-escalation#case-escalation)会将其重新分配给资深客服。 +5. **如果是 Critical**（或 SLA 截止日期已过），[升级流程](/zh-Hans/docs/service/sla-and-escalation)会把工单标记为 *Escalated* 并提醒它的负责人。它**不会**重新分配工单——不存在向资深员工或经理的交接——也没有任何升级条件会读取账户，所以 *Customer* 的工单没有属于自己的分支。 6. **记录解决方案**，自动标记解决时间，并关闭工单。 ## 系统为你做的事 - **自动确定优先级**——通过工单分流技能（Service Copilot 阅读工单并推荐优先级）。 -- **自动升级**——将紧急工单或高优先级客户工单升级给资深客服。 -- **紧急时通知**——每当工单被设为紧急时，向支持经理发送邮件。 -- **升级时通知**——每当工单被升级时，向升级团队发送邮件。 +- **自动升级**——只针对 Critical 工单：流程把它们标记为 *Escalated* 并提醒负责人，从不改写 `owner_id`，因此没有任何工单被交到资深客服手里。High 工单永远不会被自动升级，无论账户是什么：要升级它，靠的是手动的 **Escalate Case** 按钮。 +- **紧急时通知**——每当工单被设为 Critical 时，站内消息 + 邮件只发给**工单负责人**。这就是工单升级流程的 notify 节点，其收件人列表只有 `{caseRecord.owner_id}` 一项；本应用中不存在 `support_manager@example.com` 这个收件人。 +- **升级时通知**——不会给任何升级团队发邮件：`escalation_team@example.com` 在本应用中根本不存在。状态转为 *Escalated* 真正触发的，是 `case_status_side_effects` 钩子开出的那条**次日到期、优先级为紧急、归账户负责人的跟进任务**。 - **标记解决时间**——工单关闭时自动标记。 -- **标记 SLA 违约**——一旦 SLA 目标时间过去，显示红色横幅。 +- **标记 SLA 违约**——一旦 SLA 目标时间过去，工单会被标记为 **SLA 已违约**并升级，其负责人收到站内消息 + 邮件提醒。没有红色横幅：本应用没有任何横幅机制。 - **阻止错误关闭**——未填写解决方案就不能将工单标记为已关闭。 ## Service Copilot diff --git a/content/docs/service/index.zh-Hant.mdx b/content/docs/service/index.zh-Hant.mdx index 45b31cefc..6eeee404f 100644 --- a/content/docs/service/index.zh-Hant.mdx +++ b/content/docs/service/index.zh-Hant.mdx @@ -27,17 +27,17 @@ New ──► In Progress ──► Waiting on Customer ──► Resolved ─ 2. **分配優先順序**——低、中、高或緊急。*緊急*會立即提醒支援經理。 3. **計算 SLA 目標**——每個工單都會根據優先順序獲得一個截止時間。 4. **客服處理工單**，隨進度推進狀態。 -5. **如果卡住了**（或緊急，或來自客戶），[升級流程](/zh-Hant/docs/service/sla-and-escalation#case-escalation)會將其重新分配給資深客服。 +5. **如果是 Critical**（或 SLA 截止日期已過），[升級流程](/zh-Hant/docs/service/sla-and-escalation)會把工單標記為 *Escalated* 並提醒它的負責人。它**不會**重新指派工單——不存在向資深員工或經理的交接——也沒有任何升級條件會讀取帳戶，所以 *Customer* 的工單沒有屬於自己的分支。 6. **記錄解決方案**，自動標記解決時間，並關閉工單。 ## 系統為你做的事 - **自動確定優先順序**——透過工單分流技能（Service Copilot 閱讀工單並推薦優先順序）。 -- **自動升級**——將緊急工單或高優先順序客戶工單升級給資深客服。 -- **緊急時通知**——每當工單被設為緊急時，向支援經理發送郵件。 -- **升級時通知**——每當工單被升級時，向升級團隊發送郵件。 +- **自動升級**——只針對 Critical 工單：流程把它們標記為 *Escalated* 並提醒負責人，從不改寫 `owner_id`，因此沒有任何工單被交到資深客服手裡。High 工單永遠不會被自動升級，無論帳戶是什麼：要升級它，靠的是手動的 **Escalate Case** 按鈕。 +- **緊急時通知**——每當工單被設為 Critical 時，站內訊息 + 郵件只發給**工單負責人**。這就是工單升級流程的 notify 節點，其收件人列表只有 `{caseRecord.owner_id}` 一項；本應用中不存在 `support_manager@example.com` 這個收件人。 +- **升級時通知**——不會給任何升級團隊發郵件：`escalation_team@example.com` 在本應用中根本不存在。狀態轉為 *Escalated* 真正觸發的，是 `case_status_side_effects` 鉤子開出的那條**次日到期、優先順序為緊急、歸帳戶負責人的跟進任務**。 - **標記解決時間**——工單關閉時自動標記。 -- **標記 SLA 違約**——一旦 SLA 目標時間過去，顯示紅色橫幅。 +- **標記 SLA 違約**——一旦 SLA 目標時間過去，工單會被標記為 **SLA 已違約**並升級，其負責人收到站內訊息 + 郵件提醒。沒有紅色橫幅：本應用沒有任何橫幅機制。 - **阻止錯誤關閉**——未填寫解決方案就不能將工單標記為已關閉。 ## Service Copilot