如何把支持会话总结为6个CRM字段

快速答案

不要让AI生成一段Free-Form Summary后直接粘贴CRM。定义六个有版本的字段：Customer Need；Verified Context；Action/Observed Result；Current State/Unresolved Item；Next Action/Owner/Time；Evidence/Uncertainty/Handoff Limit。提取主张时附Source Pointer，验证Type/Permission，对重大或冲突内容要求复核，再用Idempotency写入并保留旧值。

六字段六职责不得混合Fact、Action、Status、Promise或Provenance。

证据优先于流畅没有依据的流畅句子不是安全CRM值。

安全写入Validate、Review、Diff、Write Once、Verify并保留History。

选择字段名前的三条设计规则

映射到决策

每个Field必须帮助明确Reader进行Decide、Route、Act、Verify或Measure。若无法说明Downstream Decision，就不要新建字段或把文本交给模型。

值与证据分离

Field存紧凑Operational Value，旁边存Permission-Aware Source Pointer。复制整段Transcript会增加Privacy、Staleness、Contradiction与Access Risk。

使用受控空值与冲突

Unavailable、Not Applicable、Awaiting Verification、Restricted与Conflicting是不同状态。不能用“合理措辞”补缺失值；重大冲突路由给Human。

六个CRM字段合同

先把以下内容作为Logical Contract，再映射到CRM真实Object、Property、Association、Sensitivity Label、Pipeline与Permission。示例值均为假设，并刻意保留不确定性。

客户需求与请求结果

customer_need

记录Customer Task、Affected Object、Expected/Observed Result与Requested Remedy，保留客户原意而非Agent Diagnosis。多个Need分开，不能压成模糊Topic。

允许输入: Customer Message、已认证Form Field、Reviewer获准查看的Attachment与Explicit Correction。
写入与验证规则: 写成一个可测试陈述，引用或链接决定性语句；标记Ambiguity，不编造Motivation、Urgency、Sentiment、Identity或Business Impact。
示例值: 客户无法导出8月Invoice CSV；期望包含全部Line Item；请求在其说明的Finance Review前获得可用导出。

已核验语境与限制

verified_context

只记录会改变Diagnosis、Permission、Policy、Routing或Safe Answer的语境：Product/Version、Workspace/Account Reference、Channel、Locale、Environment、Date、Plan、Region、Access Role与Constraint。

允许输入: System-of-Record Property、Tool Response、Verified Identity Result、Current Policy/Version、Service Status与Customer-Confirmed Environment。
写入与验证规则: 每个值标记Verified、Customer-Stated、Inferred、Stale、Unavailable或Conflicting；移除Secret与无关个人数据，受限Identifier放Protected Field。
示例值: Web App · Export Module v3 · Workspace已Tokenize · Admin Role已验证 · en-GB · August Date Range · 检查时未发现Service Incident。

已执行动作与可观察结果

actions_results

按时间记录重要Diagnosis、Communication、Approval、Tool、Policy与Remediation Action；每个Action配Actor、Time、Input、Result与Evidence，不能只写“已排查”。

允许输入: Conversation Event、Tool-Call Log、Approval、Ticket History、Status Check、Sent Message与Customer-Visible Test。
写入与验证规则: 区分Attempted、Succeeded、Failed、Rolled Back、Skipped与Proposed；不能把API Acknowledgement写成Customer-Visible Success，也不能隐藏Duplicate Execution。
示例值: Agent复现空行；用Idempotency Key将Export Job 842重试一次；Job完成，但下载文件仍缺Tax Line。

当前状态、处置与未解决事项

current_state

说明请求当前处于Resolved、Partially Resolved、Blocked、Awaiting Customer、Awaiting Internal Work、Monitoring或Closed，并列出每个Unresolved Issue Unit。

允许输入: Latest Customer-Visible Verification、Ticket Status History、Incident/Problem Link、Dependency State、Specialist Decision与Reopen Evidence。
写入与验证规则: 使用统一Disposition Vocabulary。Reply、Handoff、Queued Job、Workaround或Agent Belief都不等于Resolution；写明Observation Time及会让状态过期的条件。
示例值: 14:20 UTC时Partially Resolved：Base Invoice Row可正确导出；Tax Row仍缺失；关联Defect INC-217由Finance Integrations复核。

下一动作、责任人与时间承诺

next_action

把Open State转为一个可问责Next Event：Action、Responsible Person/Team、Prerequisite、Due Time/Timezone或Trigger、Customer Update、Fallback与Escalation Condition。

允许输入: SLA/Internal Target、Queue Ownership、Accepted Handoff、Dependency Commitment、Approval、Calendar/Workflow Event与Customer Preference。
写入与验证规则: 区分Internal Target与Contractual Promise；不用“ASAP/很快”。若时间未知，写明Next Checkpoint与更新责任人。
示例值: Finance Integrations负责Defect Validation；即使无Fix，也须在9月4日16:00 UTC前更新客户；若确认第二个Tenant则升级给Incident Lead。

证据、不确定性与交接护栏

evidence_limits

保留可让下一位Human核验其他五字段的Evidence Map：Source Message/Event ID、Relevant Version、Confidence/Abstention、Contradiction、Restricted-Data Pointer、Correction History、Summary Producer与Review Status。

允许输入: Immutable Conversation-Part ID、Timestamp、Record/Property History、Tool Request/Result Reference、Policy Link、Model/Workflow Version、Reviewer Decision与Override Reason。
写入与验证规则: 不要把不必要Transcript全文粘进CRM；下一Owner无法访问的证据不能当作可核验引用；Fact、Customer Statement、Model Proposal、Human Decision与Unknown须分开。
示例值: Need: Message 18–21 · Context: Property History P55 · Action: Tool Event T90 · Message 24与SLA v6的Timing冲突 · 写入前需Human Review。

实操案例：纠正流畅但错误的摘要

本假设案例演示复核逻辑，不是OpenMax客户结果。客户报告Invoice CSV缺少Tax Line。首个模型摘要写“重试后导出已修复；客户今天需要文件”。两句看似有用但均无依据：重试后仍缺Tax Row，客户只说明Finance Review，并没说“今天”。

拒绝无依据解决结论。 Tool Completion只作为Action Result保留；Customer-Visible Export Failure仍是Current State。
纠正时间主张。 Requested Outcome只记录客户说明的Finance Review，不编造Date；Next-Action Field记录团队真实Checkpoint与Timezone。
保留问题边界。 Base Row可导出与Tax Row缺失共同构成Partial Resolution，二者不能互相覆盖。
控制写入。 Human复核冲突结果，查看Proposed Diff，批准五个Field；因Link不可访问退回Evidence Field，Pointer修正后才写入。

安全的七步提取与CRM写入流程

1–2 · 界定与汇集

选择Eligible Channel、Event Range、CRM Object、Target Property、Purpose、Role、Sensitivity与Retention。获取完整且获准的Conversation及关联Tool、Policy、Identity、Status与Record History；保留Message Order与Missing Segment。

3–4 · 提取与对账

以Actor、Source Pointer、Time与State提取Atomic Claim，并只映射一个Field。将Customer Statement与System Evidence对账但不静默覆盖；标记Conflict、Stale Data、Missing Context与Abstention。

5–7 · 验证、写入、核验

验证Schema、Enumeration、Locale、Date、Association、Permission、Sensitivity与Field Length；重大或冲突改动交Human。展示Diff，用Idempotency Key与Actor Identity写入，保留History，回读Record并监控Correction/Failed Handoff。

最低写入回执

summary_run_id · conversation_id · source_event_range · target_object_id · schema_version · field_name · prior_value_hash · proposed_value · evidence_pointer · value_state · producer · reviewer · approval · idempotency_key · write_result · read_back · correction_link · retention_class

OpenMax如何协调证据型会话总结

OpenMax可汇集获授权Conversation/System Context、提取带证据的Atomic Claim、填充六个Draft Field、显示Contradiction/Abstention、验证Target Schema/Permission、请求Human Approval、执行Idempotent Diff、核验Saved Record并路由Correction。Customer Remedy、Policy Interpretation、Sensitive-Data Access、Conflict Decision、Consequential Write与Final Acceptance由人负责。

1 · 收集获准Conversation、System、Policy、History

2 · 取证Atomic Claim、Source、State、Conflict、Abstention

3 · 起草六个独立CRM Field Value与Evidence Pointer

4 · 控制与写入Schema、Permission、Human Review、Diff、Idempotency

5 · 核验Read-Back、History、Handoff、Correction、Monitoring

隐私、准确性与权威记录边界

不得把Credential、完整Payment Detail、Health/Employment Narrative、Security Artifact、Secret或无关Personal Data写入普通CRM Summary Field。
不得用Generated Summary覆盖Transcript、Recording、Ticket History、Approval或Tool Log。摘要是Derived Handoff Artifact，不是每个Fact的Source of Truth。
没有定义且获准的证据，不推断Sentiment、Intent、Protected Trait、Causality、Urgency、Customer Value、Churn Risk、Fault或Resolution。
不能仅因Model Confidence高就执行重大写入。使用Field Validation、Conflict Rule、Role Permission、Human Approval、Idempotency、History、Read-Back、Rollback与Monitoring。

来源、编辑方法与限制

OpenMax编辑复核HubSpot当前Ticket API/Property Architecture（Custom Property、History、Association、Internal Identifier与Sensitivity）、Intercom Conversation-Part Model（Message、Actor与Timestamp），以及NIST AI RMF/Generative AI Profile关于Oversight、Evaluation与Confabulation的内容，再原创综合六字段架构、安全写入流程与假设导出案例。资料于2026年9月3日复核。

范围说明 Vendor文档描述其当前数据模型与限制；NIST提供自愿风险管理指南。没有来源制定通用六字段架构、验证假设值或授权访问/CRM写入。必须在真实环境测试Mapping、Permission、Privacy、Retention、Localization、Field Limit、Review、Rollback与Outcome。

常见问题

摘要应替代Transcript吗？

不。按政策保留获授权Source Record。摘要是带Evidence Pointer、Version、Producer与Correction History的Derived Compact Handoff Artifact。

为什么不用一个Notes字段？

单字段会混合Customer Meaning、Fact、Action、State、Promise与Uncertainty，使Routing、Validation、Permission、History与Measurement不可靠。六个Logical Field可映射Native或Custom Property。

模型能推断缺失Owner或Due Date吗？

不能。模型可依据当前受控规则提出明确标记的Route Proposal；实际Owner必须接受Handoff，未知时间应设置Checkpoint，不能编造Promise。

客户说法与系统证据冲突怎么办？

保留双方Actor、Source与Time；字段标记Conflicting，暂停重大写入并路由给能检查Permission/Authoritative Record的人；不得静默选择更方便的值。

OpenMax可自动化什么？

可协调Authorized Retrieval、Claim Extraction、Source Mapping、Six-Field Drafting、Schema/Permission Validation、Human Review、Idempotent Write、Read-Back、Handoff与Correction Monitoring；重大判断仍由人负责。