部门协作约定要解决的是跨部门交接反复出问题的地方：把每个交接点写成一条能执行的条款，说明谁在什么时点、基于什么输入、交付什么、由谁确认、异常找谁。本文按“筛选协作点—起草条款—明确角色—套用模板—示例演示—生效检查”的顺序，给出一套可直接使用的步骤、字段模板和检查清单，适用于一般部门之间的日常协作。
要点总览（TL;DR）
- 先按交接频次高、返工代价大、争议次数多三个标准筛选协作点，把约定控制在十项以内，优先解决最痛的交接环节。
- 每条条款写清协作事项、触发条件、输入、动作、输出、确认人、异常处理，时限和生效范围按需补充，避免“及时沟通”这类无法检查的表述。
- 约定由发起人牵头起草、双方部门负责人确认、维护人管理版本与变更，四类角色的职责和交付物在发布时一并写明。
- 发布后挂到具体工作项和评审节点上，让交接动作能引用条款编号，条款才不止停留在文档里。
- 发布后一个完整周期内按引用次数、争议次数、返工情况核对，长期无人引用或业务已消失的条款按变更流程修订或下线。
先定范围：哪些协作点值得写进约定
协作约定容易写偏，常见原因是把部门职责、岗位说明书的内容也搬进来，条款越写越多，真正出问题的地方反而被淹没。筛选协作点的判断标准是：这个交接点是否反复消耗双方的时间。符合以下任一条件的协作点，优先写进约定。
- 交接频次高：每周甚至每天都要发生的交接，例如需求提出、数据提供、物料领用、客户信息转交。频次高意味着小摩擦会被不断放大，条款的收益最直接。
- 返工代价大：一旦输入不完整或交付不合格，下游需要整体重做，例如方案评审前的资料准备、对外报价前的成本核算。
- 争议次数多：近三个月内双方就“该谁做、什么时候给、算不算完成”发生过两次以上分歧的交接点。
筛选时还要划清边界。本文讨论的是一般部门协作，例如市场与销售之间的线索交接、人力与业务之间的用人需求确认、财务与业务之间的费用审核。明确业务产品研发链路的协同流程设计、供应商与外部伙伴的协作约定，属于另外的主题，不纳入本文的约定范围；如果这些场景也需要约定，应单独制定，避免一份文档承担过多内容。
筛选完成后，输出一份待约定协作点清单，作为后续起草的输入。清单至少包含四列：协作事项、涉及部门、筛选依据（频次、返工代价或争议次数）、当前主要问题。清单控制在十项以内，先解决最痛的几项，比一次性铺开更容易落地。
核心答案与操作步骤：把协作点写成可执行条款
从草稿到发布分为四步，每一步都有明确的输入、动作、输出和完成标志。四步走完，一份可发布的协作约定就成型了。
步骤一：收集问题与现有做法
输入：近三个月的协作摩擦记录，包括邮件往来、群聊中的争议、返工记录、延期说明，以及双方目前实际在用的做法。动作：按待约定协作点清单逐项整理，每项写清“现在怎么做的、哪里卡住、卡住时双方各自怎么处理”。输出：每个协作点一页问题记录。完成标志：每个协作点都能说出一到两个具体事例，而不是“沟通不畅”这类笼统描述。
步骤二：逐条起草条款
输入：步骤一的问题记录。动作：把每个协作点写成一条条款，条款必须覆盖输入、动作、输出、确认人、异常路径五个要素。起草时用双方都能核对的表述，例如“销售在合同签署后一个工作日内，将客户联系人、服务范围、特殊承诺三项信息提交至交付负责人”，避免“及时沟通”“积极配合”这类无法检查的措辞。输出：条款草案，每条独立成段并编号。完成标志：任意一条条款拿出来，双方对“什么时候算开始、什么算完成、出问题找谁”的回答一致。
步骤三：双方评审并确认责任人
输入：条款草案。动作：组织一次双方部门参与的评审，逐条确认三件事——条款描述是否符合实际、确认人是否到位、异常路径是否有人接。评审中出现的分歧当场记录，能当场定稿的定稿，不能定稿的指定负责人和期限。输出：评审后的定稿条款，每条标注双方确认人。完成标志：双方部门负责人对全部条款签字或书面确认，无遗留未决项。
步骤四：发布与版本管理
输入：定稿条款。动作：将约定发布到双方都能访问的位置，标注版本号、生效日期和适用范围；同时建立一份约定清单，记录每条条款的编号、主题、责任人和最近一次修订时间。后续每次修订都更新版本号并保留历史版本。输出：已发布的协作约定与约定清单。完成标志：双方成员能在日常工作中找到并引用当前版本，旧版本明确标注为已失效。
条款发布后需要挂到日常动作上才能持续生效。在ONES中，可以把每条约定对应到具体的工作项类型或文档页面，让交接动作在提交工作项、发起评审时被直接引用；约定文档本身作为共享页面维护版本，评审记录留在对应工作项下，形成“条款—执行—记录”的对应关系。这样条款不再是一份孤立文档，而是每次交接都能查到的依据。
角色及交付物：谁起草、谁确认、谁维护
协作约定涉及四类角色，职责和交付物各不相同。角色不清是约定流于形式的主要原因之一，建议在发布时就把四类角色写进文档首页。
| 角色 | 主要职责 | 交付物 | 确认方式 |
|---|---|---|---|
| 发起人/协调人 | 牵头筛选协作点、组织起草与评审、跟踪发布 | 待约定协作点清单、条款草案、评审记录 | 向双方负责人提交评审结论 |
| 双方部门负责人 | 确认条款符合业务实际、指定确认人和异常处理人 | 条款确认意见 | 签字或书面确认 |
| 执行角色 | 按条款完成交接动作，记录异常 | 交接记录、异常反馈 | 在工作项或交接记录中留痕 |
| 维护人 | 维护约定清单、处理变更、组织定期复盘 | 更新后的约定版本、复盘纪要 | 版本发布通知 |
约定变更的路径要与制定路径保持一致：任何一方提出变更，先说明触发原因（例如业务调整、原条款无法执行、出现新的争议点），由维护人登记，涉及双方职责的变更需双方负责人确认后发布新版本。只影响表述、不改变责任归属的修订，可由维护人直接更新并通知双方。变更记录保留在约定清单中，便于回溯。
条款模板：一条协作约定应包含的字段
一条可执行的条款由九个字段构成。其中协作事项、触发条件、输入、动作、输出、确认人、异常处理为必填，时限和生效范围为选填；时限在交接有时效要求时必填，生效范围在条款只适用于特定业务线或区域时填写。
| 字段 | 说明 | 填写要求 |
|---|---|---|
| 协作事项 | 这条约定管的是哪个交接点 | 必填，用一句话概括 |
| 触发条件 | 什么情况下条款开始生效 | 必填，写可观察的事件 |
| 输入 | 发起方需要提供的信息或材料 | 必填，列明具体项 |
| 动作 | 接收方在收到输入后做什么 | 必填，写动作而非态度 |
| 输出 | 交付物及其合格标准 | 必填，写清可检查的结果 |
| 确认人 | 由谁判定交接完成 | 必填，写到岗位 |
| 时限 | 各环节的完成时间要求 | 选填，有时效要求时必填 |
| 异常处理 | 输入缺失、超时、质量不合格时找谁、怎么处理 | 必填，写清升级路径 |
| 生效范围 | 条款适用的部门、业务线或区域 | 选填，默认适用于双方全部协作 |
填写示例：
- 协作事项：市场活动名单向销售团队的交接。
- 触发条件：市场活动结束后的第一个工作日。
- 输入：活动参与名单（含姓名、联系方式、意向等级）、活动沟通记录摘要。
- 动作：销售对接人核对名单完整性，按意向等级分配跟进人。
- 输出：分配完成的跟进清单，每条记录标注跟进人和首次联系时间。
- 确认人：销售团队负责人。
- 时限：名单交接后两个工作日内完成分配。
- 异常处理：名单缺失关键字段时，销售对接人当日反馈市场活动负责人补全；超过时限未分配，由销售负责人协调。
- 生效范围：适用于市场部与销售部之间的全部线下活动名单交接。
示例：一次跨部门需求交接的约定写法
以下示例为演示情景，用于说明从问题到条款的转化过程，不代表任何具体组织的实际案例。
背景：需求部门（业务团队）向交付部门（运营支持团队）提出系统配置调整需求，双方在交接环节反复出现返工。
问题描述：业务团队通过即时消息提出需求，信息时有时无；运营支持团队收到后常因缺少背景说明而反复询问；需求完成后业务团队认为不符合预期，双方对“需求已确认”的理解不一致；出现延期时无人主动说明原因。
对应条款：
- 业务团队提出配置调整需求时，需提交需求说明，包含调整对象、期望效果、影响范围、期望完成时间四项内容；缺少任一项，运营支持团队可退回补充。
- 运营支持团队在收到完整需求后一个工作日内给出评估结论（可执行、需澄清、不可执行），需澄清的列明具体问题。
- 需求执行前，由业务团队负责人在需求单上确认方案，确认后视为需求锁定，后续变更按变更流程处理。
- 预计无法按期完成时，运营支持团队在到期前一个工作日说明原因和新的完成时间。
- 异常路径：需求被退回两次以上仍未补齐，由双方负责人协商处理。
挂到工作项与评审节点：将上述条款对应到需求类工作项的必填字段和状态流转——提交时校验四项内容是否齐全，评估结论作为状态流转的条件，负责人确认作为进入执行的前置节点，延期说明作为到期提醒的触发动作。条款中的每个时点都能在工作项记录中找到对应痕迹。
可迁移的写法规律：先写清问题发生的具体环节，再把每个环节转成“谁—何时—基于什么—做什么—交付什么—谁确认—异常找谁”的结构；把确认动作前置到执行之前，减少事后争议；把异常路径写成可触发的条件，而不是“及时沟通”。
完成检查：约定是否真正生效
约定发布不等于生效。建议在发布后的一个完整周期（例如一个季度）内，按以下清单逐项核对。
| 检查项 | 判断标准 | 核对方式 |
|---|---|---|
| 条款完整性 | 每条条款的必填字段齐全，无“及时”“尽量”等无法检查的表述 | 逐条对照字段模板检查 |
| 责任人明确性 | 每条条款的确认人和异常处理人都能对应到具体岗位 | 抽查条款，向执行人确认是否知道找谁 |
| 异常路径可用 | 至少发生过一次异常并按条款路径处理完成 | 查看异常记录及处理结果 |
| 引用情况 | 交接动作中能引用到条款编号，而非凭记忆执行 | 统计周期内工作项或交接记录中对条款的引用次数 |
| 争议变化 | 同一协作点的争议次数较制定前下降 | 对比制定前后的争议记录 |
| 返工情况 | 因输入不全或标准不清导致的返工减少 | 查看返工记录及原因分类 |
检查结果分三种处理方式：条款被稳定引用、争议和返工明显减少的，保留并纳入常规复盘；条款长期无人引用或执行人普遍不清楚的，说明条款与实际动作脱节，需要修订表述或调整挂接方式；因业务变化导致协作点本身消失的，按变更流程下线该条款，并在约定清单中标注失效日期和原因。修订与下线同样需要双方负责人确认，避免单方面修改造成新的分歧。
约定清单建议每季度复盘一次，复盘时重点看三件事：新增了哪些高频争议点、哪些条款从未被引用、哪些条款的异常路径从未被触发。前两项指向条款设计问题，第三项可能说明异常处理机制还没有真正被使用，需要在实际交接中主动验证。
常见问题
协作约定和部门职责说明书有什么区别，能不能合并成一份？
两者管的对象不同。职责说明书回答“这个部门负责什么”，协作约定回答“两个部门在某个交接点上，谁在什么时点、基于什么输入、交付什么、由谁确认、异常找谁”。合并写容易让条款变成职责罗列，真正出问题的交接点被淹没。
实际操作中可以分开维护：职责说明书由各部门自己维护，协作约定由双方共同确认。如果一份文档里两类内容都有，建议把协作条款单独成章并编号，便于日常引用和后续修订。
双方对某条约定始终谈不拢，起草阶段应该怎么处理？
先判断分歧属于哪一类。如果是对事实的认知不同（例如现在到底怎么做的、问题出在哪个环节），回到步骤一的问题记录，用具体事例对齐；如果是责任归属或资源投入的分歧，单靠协调人难以定论，应提交双方部门负责人协商，并把分歧点、双方立场和待决事项记录下来。
暂时无法定稿的条款不要勉强发布，可以标注“待定”并指定负责人和期限，其余条款先发布执行。遗留项在下次评审时优先处理，避免整份约定因一条卡住而搁置。
条款发布后执行人不按约定做，约定还有意义吗？
先排查原因，再决定处理方式。常见原因有三类：条款与实际动作脱节，执行人按约定做反而更慢；条款没有被挂到日常工具和流程里，执行时想不起来；确认人和异常路径不明确，执行人不知道找谁。
前两类需要修订条款或调整挂接方式，例如把必填字段做进工作项提交环节、把确认动作设为状态流转条件；第三类需要补齐责任人信息。如果条款本身合理、挂接也到位，仍出现长期不执行，则属于执行问题，应由双方负责人按约定中的异常路径处理，而不是继续增加条款数量。
约定应该多久复盘一次，复盘要准备什么材料？
建议每季度复盘一次，与约定清单的维护节奏一致。复盘材料包括：周期内各条款的引用记录、同一协作点的争议记录、因输入不全或标准不清导致的返工记录，以及新增的高频问题。
复盘重点看三件事：新增了哪些高频争议点、哪些条款从未被引用、哪些条款的异常路径从未被触发。前两项指向条款设计问题，第三项提示异常处理机制可能还没有被真正使用，需要在后续交接中主动验证。复盘结论落到约定清单上，明确保留、修订或下线的条款。
部门业务调整后，原有协作约定怎么处理？
按变更流程处理，避免单方面修改。业务调整导致协作点本身消失的，由维护人登记下线，在约定清单中标注失效日期和原因，并通知双方；协作点仍在但交接方式变化的，按变更路径提出修订，涉及双方职责的变更需双方负责人确认后发布新版本。
只影响表述、不改变责任归属的修订，可由维护人直接更新并通知双方。无论哪种情况，历史版本都应保留，便于回溯当时的约定内容。
