快速回答

从三个独立 Facet 开始，而不是单一扁平 Category：客户需要什么、有哪些已证实影响或专业风险、什么流程或证据状态控制下一动作。允许 Multi-Label，要求 Provenance/Confidence，把 Priority/Resolution 放在独立字段，并记录每次 Human Correction。

标签是上下文帮助检索、路由、衡量与复核工作；不是 Proof、Priority、Ownership 或 Outcome。
使用多个维度一个 Ticket 可同时是 need.defect_report + risk.multi_user + workflow.specialist_review + workflow.monitoring。
治理变更版本化定义、抽样质量、监控 Co-occurrence/Unlabelled Work，并在标签变化时迁移历史。

三维支持工单标签体系

客户需求

客户要求的 Outcome/Help。优先一个 Primary Need，只有案件确实包含独立工作时才增加第二个。

影响与风险

已观测 Scope、Harm 或 Specialist Trigger。可为零/一个/多个；它们输入 Priority/Incident Decision，但不能替代。

流程与证据

控制下一动作的临时 State。Evidence 变化时移除、替换或保留；不得把临时标签变成永久 Customer Attribute。

每个标签的质量合同

分类体系必要字段
字段目的防止失败
label_id + facet稳定Machine Key与独立维度重命名断裂与单桶混淆
定义+包含/排除共享边界与反例同义漂移与标签重叠
证据+来源解释为何适用把AI置信度当事实
负责人+动作把上下文变成可问责工作装饰标签与无人队列
版本+复核触发安全变更与重新评估历史静默漂移

支持工单分类的25个标签

这些标签是逐一定义的起点。只采用能产生清晰 Action、Query、Control 或 Learning Use Case 的标签；没人使用的 Tag 只会增加噪声。

01

操作指导 need.how_to

NEED

含义

客户希望获得受支持任务的操作说明，尚无证据表明预期行为失败。

包含 / 排除

请求结果是学习流程时包含；可复现失败、缺少权益、访问拒绝、功能缺口或投诉应排除并改贴对应标签。

证据与路由

保留 Task、Product/Version、Attempted Step、看过的文档、Desired Outcome 与 Channel；路由知识库/一线支持，若执行证据显示缺陷则重分类。

02

账户访问 need.account_access

NEED

含义

客户无法登录、验证、恢复、加入，或无法获得预期 Role/Permission。

包含 / 排除

包含 Authentication、Invitation、Recovery、Role、Permission、Lockout、Session Access；排除全站认证事件和疑似 Account Takeover，并增加影响或安全标签。

证据与路由

保留安全 Account ID、Identity State、Affected Role、Exact Error、Time、获准 Device/Session Context 与 Recovery Attempt；路由身份访问 Owner，不索要 Secrets。

03

设置或配置 need.setup_configuration

NEED

含义

客户需要配置受支持的 Product、Workspace、Policy、Workflow、Integration Setting 或 Deployment Option。

包含 / 排除

包含已知能力但配置未完成；排除已知配置后的纯 How-to、Unsupported Feature Request、Integration Failure 与 Product Defect。

证据与路由

保留 Target State、Current Configuration/Version、Environment、Dependency、Change History、Validation Attempt 与 Rollback Need；路由实施或产品专家。

04

功能请求 need.feature_request

NEED

含义

客户要求尚未核验为受支持的 Capability、Behavior、Control、Channel、Format 或 Integration。

包含 / 排除

包含未来能力或已确认缺口；在证据确立前排除对现有功能的误解、配置、访问、缺陷与合同承诺。

证据与路由

保留 Job-to-be-Done、Current Workaround、Affected User、Frequency、Need Evidence、Constraint 与 Requested Outcome；不编造交付日期，路由 Product Discovery。

05

产品缺陷报告 need.defect_report

NEED

含义

在可复现条件下，Observed Behavior 与文档、配置或先前核验的 Expectation 不同。

包含 / 排除

包含有证据依据的可复现差异；排除偏好、Feature Request、Configuration Error、Data-Source Error 或单次误解；不确定时可多标签。

证据与路由

保留 Expected/Observed、Steps、Timestamp、Version、Environment、带 Provenance 的 Log/Screenshot、Frequency、Workaround、Regression Point；路由支持工程。

06

性能问题 need.performance_issue

NEED

含义

客户报告 Latency、Timeout、Throughput、Resource 或 Responsiveness 超出有证据的预期。

包含 / 排除

包含测量或可重复的慢/超时；排除完全不可用、未经核验的本地设备归因、无证据的“很慢”或账单/感受投诉。

证据与路由

保留 Operation、Timestamp/Timezone、Region、Tenant、Volume、Percentile/Sample、Baseline、Trace/Request ID、Network Context 与 Workaround；路由性能 Owner。

07

集成问题 need.integration_issue

NEED

含义

OpenMax 与其他 API、Connector、Webhook、Identity Provider 或业务系统的明确边界处 Data/Action 失败。

包含 / 排除

包含边界上的 Authentication、Schema、Mapping、Rate、Delivery 或 State-Sync Failure；排除无边界的原生缺陷及不受支持 Connector 请求。

证据与路由

保留 System/Version、Direction、Endpoint/Connector、Safe Request/Response ID、Status/Error、Timestamp、Retry/Webhook State、Mapping、Recent Change 与 Ownership Boundary。

08

数据或报表问题 need.data_report_issue

NEED

含义

客户质疑 Missing、Delayed、Duplicated、Inconsistent、Transformed、Exported 或 Calculated Data。

包含 / 排除

包含 Lineage、Sync、Aggregation、Dashboard、Export 或 Metric Dispute；排除已确认纯 Access、与数据无关 UI Defect 及新分析功能请求。

证据与路由

保留 Source/Destination、Record/Metric Definition、Query/Filter、Time Range/Zone、Expected/Observed Value、Freshness、Sample ID、Lineage、Transformation Version 与 Reconciliation Result。

09

账单或付款问题 need.billing_payment

NEED

含义

客户询问 Invoice、Price、Plan Charge、Tax、Payment Status、Credit、Payment Method 或 Account Balance。

包含 / 排除

包含尚未形成最终 Refund/Cancellation 决定的解释或对账请求；排除正式退款/取消、疑似欺诈和已确认使用缺陷，必要时多标签。

证据与路由

保留 Merchant Entity、Invoice/Payment ID、Amount/Currency、Line Item、Tax/Discount Basis、Payment State、Plan/Version、Prior Credit、Customer Question 与 Finance Owner。

10

退款或取消请求 need.refund_cancel

NEED

含义

客户明确要求 Refund、Credit、Reversal、Subscription Cancellation、Stop Renewal 或其他商业补救。

包含 / 排除

即使资格未知也包含所请求结果；不得把标签当 Approval、Legal Entitlement、Fraud Evidence 或 Completed Refund，Complaint/Billing 另贴。

证据与路由

保留 Exact Request、Transaction/Contract Reference、Requested Effective Date、客户原话理由、Fulfillment/Usage、Prior Recovery、Dispute State、Policy Candidate、Authority 与 Decision State。

11

关键任务受阻 risk.task_blocked

RISK

含义

没有合理 Workaround 能让受影响客户完成有时间要求的核心任务。

包含 / 排除

包含被阻结果证据，而非只有情绪；若有有效 Workaround 或已由更广事件表示则排除。Priority 另算。

证据与路由

保留 Blocked Task、Affected Identity/Role、Business Deadline/Source、Workaround Attempt、Dependency、Start Time、Impact Owner 与 Next Reassessment；路由紧急度复核。

12

多用户影响 risk.multi_user

RISK

含义

已核验证据显示同一问题影响多个独立 User、Account、Tenant、Region 或 Workflow。

包含 / 排除

包含有证据的共同模式；不得从单一激烈报告、重复消息或表面相关症状推断范围。监控未确认前不升级为全站。

证据与路由

保留 Distinct Affected Unit、已知 Denominator、First/Last Observed、Common Signature、Correlation Method、Sample ID、Confidence 与 Incident Link；路由范围复核。

13

服务降级 risk.service_degradation

RISK

含义

Monitoring 或相互印证的报告显示共享服务的 Availability、Correctness、Capacity 或 Performance 下降。

包含 / 排除

包含已验证共享服务状态或 Incident Link；排除孤立 Ticket、本地 Configuration、已沟通 Planned Maintenance 与已恢复历史事件。

证据与路由

保留 Service/Component、Telemetry Source、Threshold/Baseline、Region、Affected Scope、Start/Recovery Time、Incident ID/Status、Workaround、Owner 与 Next Update。

14

安全信号 risk.security_signal

RISK

含义

Ticket 含 Unauthorized Access、Credential Compromise、Malicious Activity、Vulnerable Behavior 或 CIA Risk 指标。

包含 / 排除

包含需要 Security Review 的 Signal；标签不是 Breach、Attacker Identity 或 Customer Fault 证明。排除无安全指标的普通访问问题。

证据与路由

保留最小 Indicator、Source/Time、Affected Asset/Account、Safe Artifact Location、Exposure Window、Containment State、Security Owner、Disclosure Restriction 与 Incident Link；Tag 不放 Secrets。

15

隐私信号 risk.privacy_signal

RISK

含义

Ticket 可能涉及 Personal Data Collection、Access、Disclosure、Correction、Deletion、Consent、Retention、Identity Right 或 Unintended Exposure。

包含 / 排除

包含需 Specialist Triage 的潜在隐私问题；不得凭不完整文本断言违规或身份。排除无个人数据语境的泛保密措辞。

证据与路由

按最小必要保留 Data Category/Subject Relationship、System、Event Time、Lawful Request/Authority State、Exposure Hypothesis、Access Restriction、Privacy Owner、Deadline Source 与 Correction Trail。

16

无障碍障碍 risk.accessibility_barrier

RISK

含义

用户因 Accessibility Barrier 或不兼容 Accommodation 无法感知、理解、导航、操作、沟通或完成任务。

包含 / 排除

包含报告或观测的障碍及不可访问支持交互；不得依据残障假设推断能力，应保留客户请求 Format/Accommodation。

证据与路由

保留 Affected Task/Content/Control、仅在自愿相关时记录 Assistive Technology、Environment、Expected/Observed、Requested Accommodation、Alternative Quality、Deadline、Accessibility Owner 与 Review。

17

投诉或升级 risk.complaint_escalation

RISK

含义

客户表达需回应的不满、质疑处理或 Finding、要求复核、声称不公平待遇，或启动 External Complaint Route。

包含 / 排除

包含表达与 Requested Review，但不能因语气就认定 Misconduct 或提高 Priority；只有本地定义允许时才排除同次联系已解决的不满。

证据与路由

保留 Customer Words、Issue、Requested Outcome、Prior Case/Decision、Review Right/Deadline Source、Conflict Check、Accessibility/Representative Need、Independent Owner、Next Update 与 Non-Retaliation Control。

18

身份或权限未核验 evidence.identity_unverified

EVIDENCE

含义

流程缺少足够且获准的证据，无法依赖 Requester Identity、Account Relationship、Representative Authority 或 Requested Action Authorization。

包含 / 排除

作为临时 Evidence State，而非对诚信的判断；Verification 成功或明确采用无需身份的安全服务路径后移除。

证据与路由

保留 Verification Requirement、Permitted Method、Attempt、Result、Confidence、Representative Document Location、Access Restriction、Expiry、Owner 与 Safe Next Step；Label 不存 Credential。

19

证据缺失 evidence.missing

EVIDENCE

含义

因一个或多个 Required Record、Observation、Permission、Version 或 Confirmation 缺失/不可用，明确决定无法作出。

包含 / 排除

只有 Missing Item 与 Decision Dependency 已命名时包含；排除泛化“需更多信息”、其他系统已有事实及过度收集请求。

证据与路由

保留 Missing Field/Artifact、必要原因、Lawful Access Source、Request Owner、Customer/Internal Dependency、Due Time、Alternative Evidence、Status 与 Expiry；提醒不得归咎客户。

20

可能重复 evidence.duplicate_candidate

EVIDENCE

含义

两个或多个 Ticket 可能描述同一客户问题、Event、Transaction 或 Root Cause，但尚未验证等价。

包含 / 排除

建立 Candidate Link；不得仅凭相似措辞、Email、Timing 或 Model Similarity 合并。排除相关但不同的 Person、Transaction、Remedy 或 Privacy Boundary。

证据与路由

保留 Candidate ID、Match Signal、Difference、Identity/Authorization Boundary、Primary Record Proposal、Customer-History Plan、Human Merge Decision、Linkage 与 Undo Path；不删除。

21

需要客户操作 workflow.customer_action

WORKFLOW

含义

进展依赖组织无法代做、已清楚解释且合理可访问的特定客户动作。

包含 / 排除

仅在 Action、Reason 与 Safe Method 明确时包含；排除内部工作、已有信息、不合理负担、不可访问步骤、Secret Request 或用标签静默暂停 SLA。

证据与路由

保留 Action、Reason、Minimum Input、Secure/Accessible Method、Instruction、Due/Expiry Basis、Delivery Status、Alternative、Reminder Plan、Owner 与仍继续的内部工作。

22

需要内部操作 workflow.internal_action

WORKFLOW

含义

进展依赖指定内部团队完成 Investigation、Configuration、Correction、Approval、Deployment、Reconciliation 或 Communication。

包含 / 排除

包含具体且有 Owner 的 Action；排除把“Engineering/Back Office”当无人 Queue，也不能让内部依赖从客户 Next Update 中消失。

证据与路由

保留 Action、Owner/Backup、Acceptance Evidence、Dependency、Priority、Start/Due/Review Time、Status、Blocker、Customer Update Owner、Completion Proof 与 Miss Recovery。

23

需要专业复核 workflow.specialist_review

WORKFLOW

含义

某项决定需要合格 Security、Privacy、Safety、Accessibility、Legal、Fraud、Finance、Tax、Compliance、Incident 或其他领域权限。

包含 / 排除

包含所需 Specialty 与 Decision；不得把标签当 Violation、Breach、Fraud、Liability 或 Entitlement 证据。排除不需专业判断的普通升级。

证据与路由

保留 Trigger、Specialty、Question、Bounded Evidence Package、Access Class、Reviewer/Backup、Deadline Source、Decision Authority、Outcome、Rationale、Restriction 与 Reassessment。

24

监控或验证 workflow.monitoring

WORKFLOW

含义

即时动作已完成或已有 Containment，但 Expected Result、Recurrence、Recovery、Delivery、Synchronization 或 Stability 仍需观察。

包含 / 排除

包含可测 Observation Plan；排除没有 Signal、Owner、Threshold 或 End Condition 的被动等待，沉默不等于恢复。

证据与路由

保留 Signal/Query、Baseline、Expected Result、Scope、Cadence、Threshold、Start/End、Owner、Alert Route、Customer Update、Success/Failure Decision 与 Evidence Snapshot。

25

已重开 workflow.reopened

WORKFLOW

含义

先前 Resolved/Closed Ticket 因 Issue Recurrence、Remedy Failure、Material Evidence Change、客户质疑结果或依赖工作未完成而再次激活。

包含 / 排除

包含与旧 Closure 相连的新 Activation Event；排除无关新问题和普通售后提问，范围不同则新建或关联 Ticket。

证据与路由

保留 Prior Closure Decision/Evidence、Reopen Trigger/Time、Changed Fact、Recurrence Signature、Failed Remedy/Dependency、Customer Words、New Owner/Priority、Correction Notice 与 Next Review。

完整案例：“CSV导出坏了”两次变更标签

客户说：“财务团队的CSV导出坏了。”Classifier 因文本含“export”和“finance”建议 need.data_report_issue 与 risk.task_blocked；两者都是 Hypothesis，不是结论。

  1. 保留原始报告。 Ticket 保留 Customer Words、Tenant、Role、Export Type、Time、UI Error 与脱敏 Request ID；不因“finance”推断 Priority。
  2. 第一次纠正。 人工仅在一个新 Role 复现 403；数据完整且 Admin 可导出。标签改为 need.account_access + evidence.missing，并检查预期 Role Policy；因有已验证 Workaround，移除 risk.task_blocked。
  3. 新范围证据。 Monitoring 发现部署后创建的18个 Tenant 有同样 Policy Mismatch。增加 need.defect_report + risk.multi_user + workflow.specialist_review；关联 Case 但不合并客户身份。
  4. 恢复证据。 受控修复后保留 workflow.monitoring，直到 Telemetry 与抽样 Export 确认恢复。Label History 记录 Model Proposal、人工增删、Evidence、Time 与 Owner。

如何治理和衡量分类体系

版本与迁移

每个定义有 Owner、Version、Effective Date、Example、Counterexample、Downstream Use 与 Retirement Path。显式映射新旧标签，不能静默重写历史含义。

质量抽样

按 Language、Channel、Product、Label、Confidence、Model/Rule Version、Reviewer、Route 与 Outcome 抽样。Precision/Recall 只能基于有文档且解决分歧的 Review Set。

运营效用

跟踪 Unlabelled Rate、Unknown/Other、Co-occurrence、Correction、Stale Temporary Label、Routing Change、Time to Owner、Reopen、Privacy Defect 与无消费者标签。高频不等于有用。

最低可审计标签记录

ticket_id · label_id · facet · taxonomy_version · proposed_by · model_rule_version · evidence_refs · confidence · assigned_by · assigned_at · reason · corrected_from · correction_reason · expires_at · route_action · owner · downstream_consumers · access_class · review_sample · retention_event

OpenMax 如何治理工单标签

OpenMax 可收集获准 Ticket Context、读取版本化 Definition、以 Evidence Reference/Confidence 建议多个标签、执行 Facet/Incompatibility Rule、请求人工复核、路由 Owner、让临时标签过期、监控变化并保留 Correction。原始敏感内容不进入 Tag Value，专业证据按 Role 限制。

1 · 观察Ticket、Product、Customer Words、System Evidence、Current State
2 · 建议按Facet建议Label并附Evidence、Confidence、Missing Field
3 · 复核人纠正含糊与重大专业路线
4 · 路由与监控分配Owner、过期临时状态并发现Evidence变化
5 · 治理抽样质量、分析使用、版本化定义并安全迁移

误分类、隐私与治理边界

  • 没有合法、必要且专业治理目的时，不得把 Protected Characteristic、Health、Vulnerability、Sentiment、Customer Value、Blame、Fraud 或 Legal Conclusion 编为普通路由标签。
  • Label 不是 Proof、Priority、SLA、Incident Declaration、Root Cause、Ownership、Resolution 或 Customer Consent；应存为独立受治理字段。
  • Tag Name/Value 不得包含 Credential、完整支付数据、个人叙述、Medical Fact、Security Artifact 或 Confidential Investigation Text。
  • Security、Privacy、Safety、Accessibility、Fraud、Discrimination、Complaint、Legal、Regulatory 或 High-Impact Route 必须由合格人员复核。
  • 提供可访问 Correction、Appeal 与 Reopen Path；在合法时按Language/Group监控质量，但不得把敏感数据变成永久Profile。

常见问题

每个Ticket只能一个标签吗？

不。尽量一个 Primary Customer-Need Label，再加零或多个独立 Impact/Risk 与 Workflow/Evidence Label，并避免同义重复。

标签等于优先级吗？

不。Tag 提供 Context；Priority 需独立的 Impact、Urgency、Override、Owner 与 Reassessment Rule。

AI能自动打标签吗？

可在验证阈值内自动分配低后果标签，但必须暴露 Evidence、Version、Confidence、Correction 与 Sampling；专业或不利路线需人工。

何时移除标签？

Evidence 不再适用、Temporary State 过期、人工纠正或 Migration 替换时移除，并保留 Assignment History/Reason。

多少标签算太多？

没有独立 Definition、Action、Query、Control、Owner 或 Learning Consumer 的标签通常多余；衡量使用并安全合并/退役。

OpenMax增加什么？

可读取版本化Definition、建议有Evidence的Label、请求Review、路由工作、过期State、监控Correction并保留可审计Taxonomy History。

来源、编辑方法与限制

OpenMax 编辑复核 Atlassian Request Type/Work Type/ITSM Category 文档、NIST SP 800-61 Rev.3 的事件优先与升级、NIST AI RMF 的文档/监控/人机问责、ISO 10002 投诉语境与 WCAG 2.2 可访问标签和错误支持，再原创形成三维25标签起点与纠正案例。资料于2026年9月3日复核。

范围说明 Atlassian 描述一种服务管理实现；NIST、ISO、W3C 分别支持事件、AI风险、投诉与无障碍边界。没有来源定义本25标签或保证适配。必须用真实 Ticket Sample、User Language、System、Route、Right 与下游 Decision 验证。