部门协作约定用来把跨部门之间反复出现的交接写清楚，让双方知道谁在什么时候交付什么、做到什么程度算完成。本文给出一套可直接套用的字段清单、编写步骤、角色分工和完成检查表，适合需要牵头制定或修订约定的负责人使用。协作事项、责任人与时限也可以在ONES的工作项和文档中承载，形成可追踪的执行记录。
要点总览（TL;DR）
- 部门协作约定围绕一件具体的跨部门交接事项展开，每条条款写清触发条件、输入、动作、输出、完成标志、责任人与时限，缺项越多越难执行。
- 编写时先从近一个季度的高频协作事项入手，锁定两三个最容易扯皮的接口，跑通一轮后再扩展，比一次写成大而全的制度更有效。
- 角色上区分发起方、业务负责人、部门对接人、约定维护人和管理者，责任人写到具体的人并设替补，管理者只在升级事项上裁决。
- 约定发布后靠与事项频率匹配的同步节奏、偏差记录和定期复盘维持有效性，并设版本号与过期处理规则。
- 定稿前用检查表逐项确认交付物、完成标志、时限口径、升级路径和双方确认凭证，存在部分满足的条目先补齐再发布。
一份可执行的部门协作约定包含哪些要素
协作约定的最小结构围绕“一件事怎么交接”展开。每一条约定都应能回答：什么情况下启动、谁提供什么、谁做什么、交付什么、什么算完成、超时怎么办。缺少其中任何一项，条款在出现分歧时就难以执行。
下表是建议的字段清单，可作为约定的统一模板。字段数量不必多，但每个字段都要填到可核验的程度。
| 字段 | 填写要求 | 常见问题 |
|---|---|---|
| 协作事项 | 用动宾短语描述一件具体的交接事项，如“月度活动素材交付” | 写成“加强沟通”这类无法执行的口号 |
| 触发条件 | 说明什么时间、什么事件发生后启动该事项，如“活动排期确认后2个工作日内” | 只写“按需”，导致启动时点无人负责 |
| 输入 | 列出启动所需的前置材料、信息或审批，注明由谁提供 | 输入缺失时无人补齐，事项卡在起点 |
| 动作 | 描述承接方要做的关键步骤，控制在可检查的粒度 | 步骤过粗，执行方式因人而异 |
| 输出 | 明确交付物的形式与存放位置，如文档、清单、评审记录 | 只写“提供支持”，没有可验收的产物 |
| 完成标志 | 给出双方都认可的完成判断，如“对方确认接收并回复无修改意见” | 交付即视为完成，后续返工无人跟踪 |
| 责任部门与对接人 | 同时写部门和一个具体的人，并设替补 | 只写部门，出问题时找不到责任人 |
| 时限 | 给出响应时限与交付时限，注明按工作日计算 | 只写“尽快”，无法判断是否超时 |
| 信息同步节奏 | 说明该事项通过什么方式、什么频率同步进展 | 缺少同步安排，双方对进度认知不一致 |
| 冲突与升级路径 | 写明分歧先由谁协调、多久未解决升级到谁 | 没有升级路径，争议停在对接人之间 |
字段之外，约定还应有一个适用范围说明，写清覆盖哪些部门、哪些事项，以及与其他制度的关系。范围写得越具体，后续扩展时越容易判断新事项是否纳入。
从高频接口入手：约定的编写步骤
编写协作约定不必一次覆盖所有部门关系。更有效的做法是先锁定两三个最容易出现扯皮的接口，写成可执行条款，跑通一轮后再扩展。以下五步给出每步的输入、动作与输出。
第一步：盘点并排序协作事项
输入是近一个季度的跨部门协作记录，来源可以包括会议纪要、群聊中的催办、返工记录和口头抱怨。动作是把这些事项归类，按发生频率和争议程度排序。输出是一张候选事项清单，标注每项涉及的部门和建议优先级。排序时优先选择高频且双方都认为有改进空间的事项，避免从争议最大但发生频率低的事项起步。
第二步：确定对接人与交付物
输入是候选事项清单。动作是就每个事项与双方部门负责人确认对接人和替补人选，并共同写出交付物的形式与完成标志。输出是每个事项的责任人对照表和交付物描述。这一步的关键是把“部门负责”落到具体的人，否则后续同步和升级都缺少对象。
第三步：约定同步方式与响应时限
输入是事项清单与双方现有的工作节奏。动作是逐项确定进展同步的方式（例会、异步消息、共享文档更新等）和响应时限，并确认时限在双方现有工作量下可以做到。输出是每项事项的同步安排与时限条款。时限应当写成可计算的口径，例如“收到请求后1个工作日内回复是否承接”。
第四步：双方确认并留出异议窗口
输入是条款初稿。动作是把初稿发给双方对接人和业务负责人，给出固定的异议期，例如三个工作日，收集修改意见并逐条回应。输出是经双方确认的定稿，确认方式可以是邮件回复、文档批注确认或会议纪要签字。异议窗口的作用是让条款在发布前经过一次真实检验，减少执行阶段的临时争议。
第五步：发布与版本管理
输入是定稿。动作是明确发布渠道、生效日期、版本号和维护人，并把旧版本归档。输出是可检索的当前版本和变更记录。版本管理不必复杂，但每次修改都应记录改了什么、为什么改、谁确认，便于后续复盘时追溯。
角色分工：谁写、谁确认、谁维护
协作约定落不了地，常见原因是角色不清：写的人不负责执行，执行的人没参与确认，出问题时没人维护。下表把编写与运行阶段的职责分开列出。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 发起方 | 提出制定或修订需求，组织盘点与起草，推动双方确认 | 候选事项清单、条款初稿 |
| 业务负责人 | 确认条款是否符合业务实际，对资源投入和时限作出承诺 | 确认意见、资源承诺 |
| 各部门对接人 | 参与条款编写，负责本部门一侧的输入、动作与交付，反馈执行偏差 | 本侧条款内容、执行记录 |
| 约定维护人 | 保管当前版本，受理变更申请，组织复盘，更新版本记录 | 版本记录、变更日志 |
| 管理者 | 在升级事项上作出裁决，确认跨部门资源调整 | 裁决结论、调整决定 |
发起方通常由协作事项较多的一方或双方共同指定的负责人担任，不必固定为某个职能部门。维护人可以由发起方兼任，也可以交给日常使用约定最频繁的对接人。变更流程建议保持轻量：对接人提出变更申请，说明原因和影响范围，双方业务负责人确认后由维护人更新版本并通知相关人。
管理者的角色集中在冲突裁决，不介入日常条款编写。升级到管理者的条件应在约定中写清，例如“对接人协商超过两个工作日未达成一致”或“涉及交付时间调整超过一周”。条件明确，升级才不会变成情绪化的告状。
示例：市场与产品部门的素材协作约定
以下为演示情景，用于说明条款如何写成可执行文本，不涉及真实企业数据。
事项背景与触发条件
市场部门在每次对外活动前需要产品部门提供产品介绍素材。触发条件为：活动排期在月度营销例会上确认后，市场对接人在1个工作日内向产品对接人发出素材需求单，注明活动时间、目标受众和素材用途。
双方输入与交付物
市场方输入：活动排期、受众说明、往期素材参考、合规要求。产品方输入：当前版本的产品功能说明、已确认的对外表述口径。产品方交付物：一份产品介绍文档，包含功能要点、适用场景和对外表述注意事项，存放于双方共享的素材目录。市场方交付物：素材使用反馈，说明哪些内容被采用、哪些需要调整。
时限与同步方式
产品方在收到需求单后1个工作日内回复是否承接并确认交付日期；常规素材在活动前5个工作日交付，涉及新功能表述的延长至活动前8个工作日。进展通过共享文档的状态更新同步，双方在每周例会上用5分钟核对在办素材的进度。
异常与升级处理
若产品方无法按期交付，应在原定交付日前2个工作日告知市场方，并给出替代方案，例如先提供简版素材。双方对接人协商未果超过2个工作日，升级至两部门负责人；涉及对外发布时间的调整，由两部门负责人共同决定并通知活动相关方。
完成标志
市场方确认接收素材并回复“无修改意见”或“修改意见已闭环”，视为该次素材协作完成。若活动结束后仍有素材返工，计入下一次复盘记录。
让约定真正被执行：同步、复盘与调整
约定发布只是起点，执行效果取决于是否有稳定的同步节奏和偏差处理机制。同步方式应与事项频率匹配：高频事项适合固定的短会或共享文档的定期更新，低频事项适合在触发时点做一次确认。同步的内容聚焦在办事项的状态、临期风险和需要对方配合的动作，不必逐条复述条款。
执行偏差需要被记录，而不是只在沟通中被提及。记录内容至少包括：哪条约定、偏差表现（超时、交付物不符、未按路径升级）、影响和处理结果。记录可以由对接人在共享文档中随手填写，维护人定期汇总。偏差记录的价值在于为复盘提供事实依据，避免复盘变成印象之争。
复盘周期建议与事项频率挂钩，例如高频事项每季度复盘一次，低频事项每半年或在发生两次以上同类偏差时触发复盘。复盘的输出是具体的调整项：修改时限、补充输入要求、更换同步方式或调整对接人。调整触发条件可以写进约定本身，例如“同一事项连续两次超时”或“对接人岗位变动”。
约定也需要过期处理规则。当某项协作事项不再发生、承接部门调整或相关流程被其他制度覆盖时，应由维护人发起废止或合并，更新版本并通知相关人。长期不更新的约定容易与实际做法脱节，反而增加解释成本。
在工具层面，协作事项、责任人、时限和状态可以在ONES的工作项与文档中承载，偏差记录和版本变更也能留痕，便于复盘时直接调取执行记录，减少另行整理的工作。
完成检查：协作约定是否可用的判断标准
定稿前可用下表逐项自查。每一项都应有明确答案，存在“部分满足”的条目时，先补齐再发布。
| 检查项 | 通过标准 |
|---|---|
| 事项是否具体 | 每条约定对应一件可识别的交接事项，有明确触发条件 |
| 交付物与完成标志 | 每个事项都有可验收的交付物和双方认可的完成判断 |
| 责任人是否到人 | 每个事项写明部门与对接人，并设有替补 |
| 时限是否可计算 | 响应与交付时限有明确口径，能判断是否超时 |
| 同步安排是否明确 | 写明同步方式与频率，且与事项频率匹配 |
| 升级路径是否可操作 | 写明升级条件、升级对象和裁决方式 |
| 是否经过双方确认 | 有异议窗口记录和双方确认凭证 |
| 维护安排是否到位 | 指定维护人，明确变更流程、复盘周期和过期处理规则 |
| 版本是否可追溯 | 有版本号、生效日期和变更记录 |
通过以上检查的约定，通常已经具备执行条件。发布后第一轮执行中出现的偏差，正是下一版修订最直接的输入。
常见问题
协作约定应该覆盖所有部门关系吗？
不必。一次覆盖全部部门关系容易写成大而全的制度，条款变粗、执行变难。更实际的做法是先选两三个高频且双方都认为有改进空间的接口，写成可执行条款，跑通一轮后再扩展。范围说明里写清当前覆盖哪些部门、哪些事项，后续新增时按同一标准判断是否纳入。
对接人岗位变动后，约定里的责任人怎么处理？
把对接人变动列为约定的调整触发条件之一。岗位变动发生时，由维护人发起一次小范围更新：确认新的对接人与替补，核对原有时限在新人工作量下是否仍可做到，更新版本并通知双方。若变动频繁，可在条款中约定由部门负责人指定临时承接人，避免事项在交接空档期无人负责。
双方对某条时限始终谈不拢，约定还能发布吗？
可以先发布其余已达成一致的条款，把争议条款单独标注为待定，并写明暂行的处理方式和重新讨论的时间点。争议条款若涉及关键交付，建议先升级到双方业务负责人裁决，再写入定稿。把分歧藏进模糊表述，执行阶段仍会以同样方式爆发。
低频协作事项也需要写进约定吗？
低频事项可以写，但条款应更简洁，重点放在触发条件、交付物和升级路径上，同步安排按触发时点做一次确认即可。复盘周期也可相应拉长，例如每半年一次，或在同类偏差出现两次以上时触发。高频事项才需要固定的短会或定期状态更新。
约定执行一段时间后没人再提，是不是就该废止？
先判断是事项本身减少，还是执行已经脱离条款。可以调取近期的协作记录，看实际做法与条款是否一致。事项不再发生时，由维护人发起废止或合并；实际做法已经变化但事项仍在发生时，应按变更流程修订条款。长期不更新的约定会与实际做法脱节，增加解释成本。
