部门协作约定可以用一张“协作事项约定表”承载：先写清协作事项与涉及部门，再约定双方职责、交付物、响应时限、交接方式、升级路径和复盘节奏，最后补上生效范围与变更规则。本文提供可直接复制填写的空白表格、逐字段填写说明、必填与选填区分、一份完整填写示例，以及约定生效后的调整维护方法，适合需要把口头默契变成书面约定的部门负责人和协作接口人使用。
要点总览（TL;DR）
- 部门协作约定可以用一张“协作事项约定表”承载，分为表头信息区、协作事项逐条填写区、复盘与变更记录区三部分，复制后逐行填写即可使用。
- 协作事项、双方职责、交付物、响应时限属于必填字段；审批人、交接方式、升级路径按协作复杂度条件必填；复盘节奏与变更记录可先留空。
- 响应时限建议分两段写：首次响应时间和完整交付时间；升级路径一般设两级，先接口人协商，再提交部门负责人。
- 约定生效后由维护人负责版本递增、变更登记和复盘组织；人员变动、部门调整或连续两个复盘周期无人执行时，需要更新或重新约定。
可复制空白模板：部门协作约定表
下面这张表分为三个区域：表头信息区、协作事项逐条填写区、复盘与变更记录区。使用时把表格复制到文档或在线表格中，按行逐条填写协作事项；事项较多时，在填写区继续增加行即可，表头与记录区结构保持不变。
| 表头信息区 | |||
|---|---|---|---|
| 约定名称 | 版本 | ||
| 涉及部门 | 生效日期 | ||
| 维护人 | 审批人 | ||
| 序号 | 协作事项 | 发起方职责 | 配合方职责 | 交付物 | 响应时限 | 交接方式 | 升级路径 |
|---|---|---|---|---|---|---|---|
| 1 | |||||||
| 2 | |||||||
| 3 |
| 复盘与变更记录区 | |||
|---|---|---|---|
| 复盘节奏 | 复盘触发条件 | ||
| 变更日期 | 变更内容 | 变更原因 | 确认人 |
字段说明：每个格子该填什么
同一张表被不同部门使用时，最容易出现理解偏差的是“职责”和“时限”两栏。下面按模板顺序说明每个字段的填写口径，填写时以这些口径为准，避免各部门各写各的。
表头信息区
- 约定名称：写清协作范围，例如“市场部与设计部物料协作约定”，名称中体现双方部门，便于日后检索和区分同类约定。
- 涉及部门：列出全部参与部门，包括发起方、配合方以及需要知情的管理部门；只写两个部门时也要写全称，避免简称歧义。
- 生效日期：写约定开始执行的日期，与审批完成日期区分开；生效日期之前发生的协作事项按原方式处理。
- 版本：从 V1.0 起编，每次实质性修改递增，便于对照历史版本。
- 维护人：填写负责收集变更需求、组织复盘、更新表格的人，通常由主要发起部门的接口人担任。
- 审批人：填写对约定内容有确认权的负责人，一般为双方部门负责人；涉及资源投入时增加上级审批人。
协作事项逐条填写区
- 协作事项：用“动作＋对象”描述一件可独立完成的事，例如“月度活动物料的视觉设计交付”。一件事写一行，避免把多个环节塞进同一行。
- 发起方职责：写发起方在事项开始前和过程中需要完成的具体动作，例如提供需求说明、确认素材、指定对接人。
- 配合方职责：写配合方承接事项时的具体动作，例如排期、产出初稿、按反馈修改。职责写到动作层面，便于事后判断是否履行。
- 交付物：写清交付的具体形态和数量，例如“设计源文件 1 套＋导出图 3 张”，避免只写“设计稿”这类模糊表述。
- 响应时限：分两段写，第一段是首次响应时间，第二段是完整交付时间，例如“收到需求后 1 个工作日内确认排期，5 个工作日内交付初稿”。时限取值按组织实际节奏设定，模板中的数字仅作示例。
- 交接方式：写清交付物通过什么渠道传递、由谁确认接收，例如“上传至共享目录并在协作群内通知对接人，对接人确认后视为交接完成”。
- 升级路径：写清时限未达成或出现分歧时的处理顺序，格式为“先由双方接口人协商，1 个工作日内未解决则提交双方部门负责人”。升级层级不宜过多，一般两级即可。
复盘与变更记录区
- 复盘节奏：写固定复盘周期，例如“每季度一次”，并注明由维护人组织。
- 复盘触发条件：写需要临时复盘的情形，例如“同一事项连续两次超时”或“部门接口人变更”。
- 变更记录：每次修改约定时记录变更日期、变更内容、变更原因和确认人，与表头版本号对应，形成可追溯的修改轨迹。
必填与选填：哪些字段不能空
字段是否必填，取决于它是否影响责任判断。凡是事后需要据此判断“谁该做什么、做到什么程度”的字段，都应当填写；只影响查阅便利的字段，可以根据协作复杂度取舍。
| 字段 | 填写要求 | 原因与适用条件 |
|---|---|---|
| 约定名称、涉及部门、生效日期、版本 | 必填 | 缺少任一项，约定无法确定适用范围和有效版本，后续变更也无从对照。 |
| 维护人 | 必填 | 约定需要有人负责更新和答疑，否则容易填完即搁置。 |
| 协作事项、发起方职责、配合方职责 | 必填 | 这三项构成约定的核心，缺任何一项都无法判断责任归属。 |
| 交付物 | 必填 | 交付物是验收依据，写不清会导致“做完了但不算完成”的争议。 |
| 响应时限 | 必填 | 没有时限的约定无法衡量是否履约；时限取值可按事项紧急程度分档。 |
| 审批人 | 条件必填 | 涉及资源投入、跨两级以上部门或对外交付时必填；部门内部小范围约定可由双方负责人兼任。 |
| 交接方式 | 条件必填 | 交付物需要跨系统或跨地点传递时必填；双方在同一办公地点当面交接时可简写。 |
| 升级路径 | 条件必填 | 事项有时限要求或曾发生过延误时必填；低频、低风险的辅助事项可暂不填写。 |
| 复盘节奏、复盘触发条件 | 选填 | 长期运行的约定建议填写；一次性或短期协作事项可不设固定复盘。 |
| 变更记录 | 选填（首次填写时） | 首次发布时留空，发生第一次修改后开始记录，此后每次变更必填。 |
协作复杂度不同，字段取舍也不同。两个部门之间单一事项的约定，填齐必填项即可投入使用；涉及三个以上部门、多个事项并行或与考核挂钩的约定，建议把条件必填项全部补齐，并设置固定复盘节奏。留空的字段要在表头备注中写明补填时机，例如“升级路径待首次复盘后补充”，避免长期空缺无人跟进。
填写示例：一份完整的部门协作约定
以下示例为演示情景，部门名称和时限取值均为虚构，仅用于说明各字段的填写方式，实际使用时按本组织情况替换。
| 表头信息区 | |||
|---|---|---|---|
| 约定名称 | 市场部与设计部物料协作约定 | 版本 | V1.0 |
| 涉及部门 | 市场部、设计部 | 生效日期 | 2025年3月1日 |
| 维护人 | 市场部接口人（活动策划岗） | 审批人 | 市场部负责人、设计部负责人 |
| 序号 | 协作事项 | 发起方职责 | 配合方职责 | 交付物 | 响应时限 | 交接方式 | 升级路径 |
|---|---|---|---|---|---|---|---|
| 1 | 月度活动主视觉设计 | 每月 25 日前提交下月活动需求说明，含活动主题、尺寸要求和参考案例；指定一名对接人 | 收到需求后确认排期，按约定时间交付初稿，根据反馈完成两轮修改 | 主视觉源文件 1 套、适配尺寸导出图 3 张 | 收到需求后 1 个工作日内确认排期，5 个工作日内交付初稿，修改反馈后 2 个工作日内交付终稿 | 上传至共享目录并在协作群通知对接人，对接人确认后视为交接完成 | 超时 1 个工作日由双方接口人协商；仍未解决提交双方部门负责人 |
| 2 | 临时物料加急设计 | 说明加急原因和最终使用时间，提供完整文案素材 | 评估当前排期后答复能否承接，承接后优先安排 | 按需求说明中列明的物料清单交付 | 收到需求后 4 小时内答复是否承接，承接后 1 个工作日内交付 | 同事项 1，加急情况可先口头确认再补书面记录 | 设计部排期无法承接时，由市场部负责人决定是否调整活动时间或另寻资源 |
| 复盘与变更记录区 | |||
|---|---|---|---|
| 复盘节奏 | 每季度一次，由维护人组织双方接口人参加 | 复盘触发条件 | 同一事项连续两次超时，或任一方接口人变更 |
| 变更日期 | 变更内容 | 变更原因 | 确认人 |
| 2025年6月5日 | 事项 1 初稿交付时限由 5 个工作日调整为 7 个工作日 | 季度复盘发现活动高峰期设计排期紧张，原时限难以稳定达成 | 双方部门负责人 |
对照字段说明可以看出：事项 1 的“响应时限”按首次响应和完整交付分两段写，与说明中的口径一致；“升级路径”采用两级结构，先接口人协商、再部门负责人介入；“交付物”写明了形态和数量，可以直接作为验收依据。事项 2 是加急场景，时限更短，并在交接方式中允许先口头确认再补记录，体现了不同事项可以有不同的严格程度。
调整与维护：约定怎么改、谁来改
约定填完只是开始。部门协作约定要持续起作用，需要明确谁负责更新、什么时候复盘、什么情况下重新约定。以下操作要点可以直接写进约定的复盘与变更记录区。
- 版本与变更记录同步维护：每次修改协作事项、时限或职责，由维护人在变更记录区登记日期、内容、原因和确认人，同时把表头版本号递增。只改内容不记变更，会让后续接手的人无法判断当前版本的来由。
- 按固定节奏复盘：按约定中的复盘节奏组织双方接口人对账，重点看超时事项、职责边界模糊的事项和新增协作需求。复盘结论要么修改约定，要么明确无需调整，两种结果都记入变更记录。
- 设置临时复盘触发条件：出现连续超时、职责争议升级到负责人层面、协作量明显增加等情况时，不等固定复盘时间，由维护人发起临时复盘。
- 人员变动时更新接口信息：接口人、维护人或审批人变更时，在变更记录中登记新的人员和生效时间，并通知对方部门；职责本身不因人员更换而失效，新接口人按原约定继续执行。
- 部门调整时重审涉及范围：部门合并、拆分或职责划转后，由维护人检查每条协作事项的发起方和配合方是否仍然成立，不成立的条目修改或停用，并在变更记录中说明。
- 判断约定是否失效：协作事项已不再发生、双方职责已由其他制度覆盖、或连续两个复盘周期无人执行时，可以判定约定失效；失效时在表头标注停用日期，需要时重新拟定新版本，不直接在旧表上大改。
当协作事项需要逐条跟踪状态时，可以把约定表中的事项、交付物和时限对应到协作工具中的工作项，由发起方提交、配合方更新进度、交接时附上交付物，超时情况按升级路径流转到相应负责人。ONES 可以承载这类工作项与交付物的状态流转，让约定中的时限和交接记录有据可查；具体使用方式按团队现有的工具环境安排即可。
常见问题
两个部门只协作一类事项，模板可以精简到什么程度？
可以只保留表头信息区和一行协作事项。表头至少填写约定名称、涉及部门、生效日期、版本和维护人；协作事项行填齐协作事项、发起方职责、配合方职责、交付物和响应时限。审批人可由双方部门负责人兼任，交接方式在当面交接时可简写，升级路径在低频低风险事项上可暂不填写，但要在表头备注中写明补填时机。
约定中的响应时限应该由谁定，定不下来怎么办？
时限通常由配合方根据实际排期能力提出，发起方确认，双方部门负责人审批。定不下来的常见原因是发起方按理想节奏要求、配合方按峰值负荷评估。可以把时限拆成首次响应和完整交付两段分别讨论，并参考过去三个月的实际交付记录取值。首次约定可以先设一个试行时限，在第一次复盘时按实际执行情况调整，并在变更记录中登记调整原因。
接口人换人后，原来的协作约定还有效吗？
约定本身继续有效，职责不因人员更换而失效。维护人需要在变更记录区登记新接口人的姓名和生效时间，并通知对方部门。如果新接口人对原约定中的职责或时限有异议，按变更流程提出，由双方部门负责人确认后再修改，避免口头改约定造成执行口径不一致。
约定写好后放在哪里，怎么保证双方都能查到最新版本？
建议放在双方都能访问的共享文档或知识库中，由维护人统一管理编辑权限，表头版本号与变更记录保持同步。对外只保留一个当前有效版本的入口，历史版本归档留存但不作为执行依据。协作事项需要逐条跟踪进度时，可以把事项、交付物和时限对应到协作工具中的工作项，由发起方提交、配合方更新状态，交接时附上交付物，超时按升级路径流转。
什么情况下应该重新拟定一份新约定，而不是在旧表上修改？
协作事项已不再发生、双方职责已被其他制度覆盖、或连续两个复盘周期无人执行时，可以判定原约定失效。失效时在表头标注停用日期，需要恢复或建立新的协作关系时重新拟定新版本。涉及部门合并拆分、协作范围大幅变化的情况，也建议新起一份约定，旧表归档，便于日后追溯当时的责任边界。
