当 CRM 字段跨系统冲突、无主、过期或自定义字段泛滥时…

为 CRM 的营收关键字段建立并运营字段级治理：明确每个字段的唯一负责人、系统 of record、写入优先级、冲突规则、刷新 SLA、执行机制、生命周期和治理节奏。

适用场景

解决思路

1. 只治理营收关键字段，不治理所有字段；从 references/field-ownership-and-dictionary.md 中的源字段列表开始，仅通过 intake 扩展。
2. 每个字段指定一个具名人类负责人，不是团队；把字段分配给消费它的职能，而不是填充它的职能。
3. 按字段指定 system of record，绝不是按系统或对象；其他副本明确为派生；空白永不覆盖已填充，不管时间戳。
4. 不要把销售代表作为最后执行机制；优先自动化、集成写入、enrichment、默认值，而不是 required-field 压力。
5. 设计并运营常设系统；没有 ownership map、lifecycle、scheduled cadence 的清理不是治理；清理结束当天 decay 恢复。
6. 每个阈值标注来源：公司公开实践、从业者共识、或从用户数据推导；警告流传统计，如 30% CRM 数据每年衰减、CRM 数据只有 40-60% 准确，不得作为事实；引用机制：现实变化、多写入同步无 per-field authority 会静默覆盖；不要把 vendor 专有复合分数当行业标准。
7. 范围边界：记录去重和合并机制不在此范围；常规卫生清扫、阶段退出标准、预测可靠性、路由逻辑属于 Reference 中的 sibling skills；本技能写这些作业消费的字段规则。
8. B2B：治理稀疏、慢数据；处理长周期、account hierarchies、buying committees、rep-entry layer 默认不可靠；协调多个职能写入同一 account。
9. B2C：治理高容量、实时行为数据，由无 rep 层系统写入；把 consent/preference 字段和 retention schedules 作为一等治理字段；consent policy 由 marketing 拥有，sync reliability 由 platform ops 拥有；即使 page creative 联邦化，consent logic 仍集中。
10. B2C identity resolution 无 B2B 等价；区分 deterministic exact-identifier 与 probabilistic；B2B 通过 domain matching 在 account 层解析身份。
11. B2B 和 B2C 相同点：per-field system-of-record designation、blank-never-overwrites-populated、enrichment risk tiering、last-verified-as-distinct-from-last-modified；在交付物中说明这是 reasoned synthesis 而非 published claim。
12. 设计前先访谈；每条消息一个问题；尽可能多选；已答则跳过。
13. 问：哪个 CRM，哪些其他系统写入它：marketing automation、billing、product database、enrichment providers、support desk、data warehouse？
14. 问：能否导出或让查询范围内对象的字段列表？每个核心对象大约多少自定义字段？
15. 问：哪些字段目前供给 forecasting、routing、compensation、executive reporting？以此种子治理集。
16. 问：驱动症状：字段跨系统矛盾、值神秘回退、过期数据、字段泛滥、没人知道谁拥有什么？
17. 问：今天谁做数据运营：专职 RevOps、CRM admin、IT、无人？
18. 问：是否有字段文档或字典，在哪里？
19. 问：哪些 enrichment providers 写入 CRM，写入哪些字段？
20. 问：B2B、B2C 或两者？是否有 consent/data-protection obligations？
21. 问：是否有现有治理论坛？现在谁批准新字段？
22. 问：典型销售周期长度和记录量？用于校准 SLA 和阈值。
23. 问：必须在什么日期前就位：审计、董事会报告周期、CRM 迁移，还是当前没人相信预测？
24. 问：你想要一次性纠正今天错误字段，还是随字段增加持续生效的复利治理系统？
25. 问：努力上限：本季度 admin hours、任何 integration engineering capacity、销售组织在绕过你之前能吸收多少摩擦？
26. 最后三个问题决定 Workflow 步骤 4 和 6 的选项排序，所以设计前先问：硬日期会提升 config-only rungs，如 restricted picklists、defaults、scheduled pull、augment-only enrichment，把 conditional validation 和 real-time push 排到下一周期而非放弃。
27. 复利授权会提升 per-role permissions、conditional required-at-stage、lifecycle and cadence，降级 default values，因为 default values 只是补症状不建规则。
28. 无 integration engineering capacity 会直接删除 real-time push。
29. 销售组织已敌视 required fields 会删除 rep-entered fields 的 hard required。
30. 记录每个删除到 spec；被排除的选项停在列表底部会在下一次升级时作为范围重新出现。
31. 运行 Interview；确认 scope boundary：field rules，不是 dedup，不是 hygiene sweeps，不是 stage design。
32. 划定治理集：从 references/field-ownership-and-dictionary.md 的 revenue-critical lists 开始，加入所有供给 forecasting/routing/comp/reporting 的字段，并刻意设上限。
33. 按字段分配 ownership：consumer-ownership principle，一个具名人，默认按职能 RACI 拆分，见同一 reference。
34. 构建 per-field system-of-record map：为每个治理字段记录 authoritative system、write precedence、replication pattern、enrichment write strategy with risk tier、conflict-resolution tier，见 references/system-of-record-rules.md。
35. 在 system-of-record map 中做 replication 排序：efficiency 为 scheduled pull > reconciliation-only > real-time push。默认所有治理字段按 freshness SLA 所需 cadence 用 scheduled pull；仅当一个 stale sync cycle 改变动作而非报告时，才把字段提升到 real-time push。Real-time push 在此排序中被饿死，新鲜度最好、比率最差；降级时在 spec 中点名；若已有 event bus 或 iPaaS 在运行且边际字段成本为零，则翻转顺序。
36. 在 system-of-record map 中做 enrichment 排序：efficiency 为 augment > append > overwrite。默认整个治理集用 augment；仅当 provider 定义上权威且存储值没有 verification stamp 时，才转 overwrite。Overwrite 同样被饿死，且它是唯一能纠正已错误值的模式。
37. 写 map 前，依据 references/system-of-record-rules.md 中的 value、effort、compliance-cost axes、ties，以及删除选项而非降级的 constraints，根据 Interview 重排 replication 和 enrichment。
38. 按字段类别设置 refresh SLAs，设计 last-verified tracking 与 trigger-based re-verification，见 references/freshness-slas.md；给每个 SLA 的 provenance 打标签。
39. 按字段从 references/enforcement-menu.md 选择 enforcement，按 value per unit of effort 排序而非按轻重。
40. 在 enforcement 中采用 efficiency 排序：picklist > conditional-required > defaults > permissions > layout > hard-required。第一遍默认 restricted picklists 加 defaults；对任何在已知 transition 被决策读取的字段，升级到 conditional required-at-stage。
41. Per-role permissions 和 hard required 在此排序中被饿死：两者都有廉价 rung 买不到的真实价值，且都在效率轮中输；当一个治理字段有两个 writer 忽略其 system-of-record designation 时，立即提升 permissions；仅当没有该值的记录无法裁决时，才 hard required。
42. 绝不默认 hard-required；一个只选廉价 rung 的项目最终得到字典里没人信任的字段。
43. 建立 lifecycle 和 cadence：intake question set、approval/rejection criteria、deprecation process、council membership、meeting rhythm、decision rights，见 references/field-lifecycle.md。
44. 用 working-default column set（ownership reference）编译 dictionary。当 live CRM 可直接查询时，从其 metadata 生成初始行；否则从用户导出构建，并将未验证行标为未验证。
45. 按 Output Shape 一次一节输出交付物供用户验证，基于 references/worked-examples.md 中匹配示例。
46. 检查 Pass Threshold；迭代直到成立。如果 harness 有 persistent memory，存储 governed-field list、ownership map、system-of-record decisions，使 cadence reviews 和 dispute resolutions 从它们开始；否则 dictionary 本身是 durable artifact，告诉用户如此对待。
47. Output Shape 每条 threshold line 带 provenance tag。
48. Output Shape 包含 Scope：objects in scope、governed-field count vs total field count、motion（B2B/B2C/both）、options deleted by the user's constraints、which constraint deleted each。
49. Output Shape 包含 Ownership map：field -> named owner（a person）+ owning function。
50. Output Shape 包含 System of record：field -> authoritative system、write precedence、replication pattern、enrichment strategy + risk tier、conflict rule。
51. Output Shape 包含 Freshness SLAs：field/category -> refresh cadence、re-verification triggers、last-verified tracking plan。
52. Output Shape 包含 Enforcement：field -> mechanism + why it beat the rung below it + rollout note。
53. Output Shape 包含 Dictionary：column set、initial rows、dictionary-vs-live-CRM reconciliation plan。
54. Output Shape 包含 Lifecycle：intake form、approval/rejection criteria、deprecation process、utilization-review threshold。
55. Output Shape 包含 Cadence：council membership、weekly/monthly/quarterly rhythm、decision rights、escalation path。
56. Output Shape 包含 Metrics：baseline values captured、KPI targets、first review date。
57. Pass Threshold：每个治理字段必须有一个具名个人 owner，绝不是团队名。
58. Pass Threshold：每个治理字段必须恰好有一个 system of record。
59. Pass Threshold：每个治理字段必须对每个触及它的 sync 声明 write-precedence 和 conflict rule。
60. Pass Threshold：每个治理字段必须有 refresh SLA，或显式 event-driven designation。
61. Pass Threshold：每个治理字段必须有至少一个 enforcement mechanism。
62. Pass Threshold：每个治理字段必须有一个 dictionary row。
63. Pass Threshold：没有治理字段有两个 writer 而没有声明 winner；enrichment 绝不自动应用于 identity 或 downstream-trigger fields。
64. Pass Threshold：Dictionary spot-check：抽样 10-15 个治理字段与 live CRM 对比 type、picklist values、required-ness、description present；至少 95% 一致；这是从用户自身 drift 数据收紧的工作标准，不是 published standard。
65. Pass Threshold：Cadence 存在于日历上，有具名 attendee 和文档化 decision rights；仅政策文档按定义失败此阈值。
66. Pass Threshold：迭代直到全部四条成立；如果本次无法 live-CRM verification，标记 spot-check pending，并安排为 council 第一个议程项。
67. Common Failure Modes 修复：字段由团队拥有，如 RevOps owns it，会导致所有人拥有等于没人拥有；修复：每个字段一个具名人，姓名在 dictionary 中可见。
68. Common Failure Modes 修复：治理所有字段会稀释努力并导致治理不可行；修复：治理 revenue-critical set；仅通过 intake 扩展。
69. Common Failure Modes 修复：Make-it-required reflex 会让 n/a 和垃圾条目通过并导致采用崩溃；修复：按 efficiency order，先 picklists 和 defaults，conditional validation 先于 hard-required。
70. Common Failure Modes 修复：Enrichment 覆盖已验证值会静默破坏可信数据；修复：默认 augment/append；仅在 enrichment 是指定 authority 时 overwrite；对所有写入做 risk-tier。
71. Common Failure Modes 修复：双向同步且无 per-field authority 会导致值反复、静默覆盖、数据错误升级；修复：per-field system of record 加 last-synced conflict detection。
72. Common Failure Modes 修复：一次性清理误认为治理会让 decay 立即恢复；修复：lifecycle + cadence；清理是系统输出，不是系统。
73. Common Failure Modes 修复：Council 从不开会会让政策腐烂、请求绕过 intake；修复：安排 weekly triage 与 decision rights；会议是机制。
74. Common Failure Modes 修复：治理交给 IT 会让业务不再信任定义；修复：RevOps 拥有它；stewardship 是 business role。
75. Common Failure Modes 修复：孤立一次性字段会造成泛滥、重复字段、部落知识；修复：intake 带 duplicate check；utilization review；deprecation queue。
76. Common Failure Modes 修复：成功衡量为 reps filled more fields 会让 fill rate 上升但 accuracy 下降；修复：衡量 conflict rate、staleness、verified coverage。
77. KPI：跟踪 governed fields 的 field fill rate，不是所有字段。
78. KPI：跟踪 field utilization：在 reports/automation 中被消费，而非仅被填充。
79. KPI：跟踪 staleness distribution：距 last verified 的时间，按字段。
80. KPI：跟踪 cross-system conflict rate per sync run。
81. KPI：跟踪 validation-failure rate；尖峰表示摩擦，在庆祝 enforcement 前检查 junk-value workarounds。
82. KPI：跟踪 time-to-approve a field request；从业者目标：从请求到发布少于一周。
83. KPI：跟踪 custom-field count trend，intake 建立后应趋平。
84. KPI：绝不报告 reps filled more fields 为成功；gate 强迫垃圾条目时 fill 上升 accuracy 下降。
85. KPI：每季度重新运行 dictionary spot-check；drift 上升意味着 reconciliation loop 坏了。
86. 当 scoping governed set、assign owners、building dictionary 时，读 references/field-ownership-and-dictionary.md。
87. 当 mapping authority across systems 时，读 references/system-of-record-rules.md。
88. 当 setting refresh cadences 时，读 references/freshness-slas.md。
89. 当 choosing enforcement 时，读 references/enforcement-menu.md。
90. 当 standing up intake、deprecation、council 时，读 references/field-lifecycle.md。
91. 当 shaping deliverable 时，读 references/worked-examples.md。
92. 对于 recurring stale-deal sweeps 和 completeness audits，见 mbfinotti/revops-skills@sales-pipeline-hygiene；它每周执行本技能定义一次的内容。
93. 对于 stage exit criteria design，见 mbfinotti/revops-skills@pipeline-stage-definition-audit；stage fields 在这里仅作为 governed picklists。
94. 对于 forecast reliability built on top of governed fields，见 mbfinotti/revops-skills@sales-forecast-diagnostic。
95. 对于 routing logic that consumes governed routing fields，见 mbfinotti/revops-skills@lead-routing。
96. 对于 company-level data governance 和 cross-team data contracts，见 mbfinotti/revops-skills@revenue-data-governance-strategy；本技能停留在 CRM field level。

适用边界 · 注意事项

• 不用于组织级、对象级 source-of-truth 政策；这类需求应使用 mbfinotti/revops-skills@revenue-data-governance-strategy。
• 不用于记录去重和合并机制。
• 不用于常规 hygiene sweeps、stage exit criteria、forecast reliability、routing logic；这些属于 sibling skills。