合同续约跟踪规范：提醒与审批

一个续约跟踪器需要解决的问题

合同续约跟踪器存在的原因是同样的问题不断重复发生：续约日期被错过、负责人不明确、重要信息散落在邮件、表格和共享盘里。当有人终于注意到续约时，通常已经太晚，无法谈判、取消或安排预算。

跟踪器应能在几秒内回答基本问题：

• 正在续约的是什么（供应商/客户、合同、服务）
• 何时续约（通知截止、到期日、自动续约日）
• 谁必须采取行动（业务负责人、法务、财务、采购）
• 下一步是什么（审查、审批、签字、付款）
• 有什么变更（备注、决定以及谁批准的）

目标是让续约过程一致且没有意外或临时加班。这需要可靠的日期、明确的负责人和反映真实情况的状态。如果合同标注为 "Under review"（审核中），人们应该能够看到是什么阻碍了流程以及谁负责下一步。

把范围保持务实：提醒要足够提前以便产生作用，审批要送到合适的人，相关人员要有可见性以便他们计划，审计记录要展示清晰的历史。文档存储可以简单到附件或指向签署副本所在位置，但关键条款和截止日期必须始终易于查找。

相关人员与职责

续约跟踪器只有在所有权明确时才有效。如果每个人都是“负责的”，那就没人真正负责。

大多数团队最终会有一小组角色：

• 合同负责人（Contract owner）： 负责推进续约、确认需求、谈判条款并保持日期准确。
• 申请人（Requester）： 使用该服务的人员或团队；确认是否续约、降级或取消。
• 财务（Finance）： 审核预算、付款条款、供应商设置和费用变动。
• 法务（Legal）： 审查条款、红线和风险项；确认适用的模板或条款集。
• 部门主管（Department head）： 当支出或范围超过阈值时，作为最终的业务审批人。

将审批者与仅需被通知的人分开。审批者能改变结果（批准、拒绝、要求修改）。被通知的相关人员收到更新，但不会阻塞流程。

用两个字段表示所有权：primary owner（主要负责人）和 backup owner（后备负责人）。后备在休假、岗位变动和紧急续约时很重要。一个简单规则通常有效：如果主要负责人在规定时间内未采取行动，通知后备并允许其接手。

不要忽视供应商一侧。按角色存储供应商联系人而不是单个邮箱，因为不同的人处理不同问题。大多数团队至少需要销售联系人（商业条款）、账单联系人（发票与付款）和支持联系人（服务问题与升级）。

示例：市场团队申请续约一款分析工具。合同负责人确认使用情况和提议的等级，财务批准支出，法务批准条款，只有当年度总额超过阈值时部门主管才批准。其他人保持知情，这样续约不会被卡住。

实体模型：你实际需要的表

当你把长期存在的合同记录与每次续约周期分开时，续约跟踪器效果最好。这能保持历史清晰并使提醒可预测。

核心表

从一小组表开始，并保持字段务实：

• Vendors： 法定名称、注册信息、地址、风险等级、是否激活。
• Contracts： vendor_id、服务名称、起始日期、结束日期、续约条款（自动续约、通知期）、合同金额、币种、负责人。
• Contacts： 内部及供应商联系人，包含类型（vendor/internal）、角色（法务、财务、服务负责人）、首选渠道（email/SMS/Telegram）、is_primary。
• Documents： 文件元数据及类型（原件、修订、续约报价、备注）和简短描述。
• RenewalCases： contract_id、周期开始/结束、目标决策日期、当前阶段/状态、原因（续约、重新谈判、终止）。

在实际中，Contracts 变化缓慢。RenewalCases 记录本次周期发生的事：谁批准、收到的报价以及决策时间。

防止数据混乱的关系设计

以便你能毫不费力地回答“我们通知谁？”和“上次我们怎么决定的？”：

• Vendors 与 Contracts 是一对多，Contracts 与 RenewalCases 是一对多
• Contracts 与 Contacts 是多对多（通过像 ContractContacts 的连接表并带有角色字段）
• RenewalCases 与 Documents 是一对多（报价和备注附着到周期）

示例：一个有 60 天通知期的 SaaS 合同应有一个 Contracts 记录，但每年创建一个新的 RenewalCase。2025 年的案件保存了报价、审批和决策日期，而不会覆盖 2024 年的数据。

推动续约的日期、条款和状态

续约跟踪器只有在日期和状态明确无歧义时才有用。将日期作为事实来源，并让每个状态反映团队下一步需要做什么。

从一小组必填日期开始：

• 起始日期 和 当前期限结束日期
• 通知截止（结束日期减去通知期）
• 取消截止（有时与通知截止相同，有时不同）
• 下次自动续约日期（仅当自动续约启用时）
• 上次续约于

将自动续约设为简单布尔值（AutoRenew = true/false），并配套明确条款：续约期限长度（例如 12 个月）、续约节奏（月度/年度/多年）以及续约日期是从结束日计算还是从发票日期计算。

计算下一次续约日期时，每个合同只用一种规则（月度加 1 个月，年度加 12 个月，多年加 N 年）。如果提前续约，事先决定新结束日期如何计算：要么是旧结束日期加期限，要么是续约日期加期限。将该选择存储起来，避免后续变化。

状态应匹配实际工作步骤并始终暗示下一步的负责人。一个简单集合通常足够：upcoming（即将到期，基于日期）、in review、waiting approval、approved、renewed、canceled。

明确处理边缘情况：

• 未知结束日期： 标记为 "date missing" 并在修复前阻止提醒。
• 永续（Evergreen）合同： 无结束日期，但添加周期性评审日期。
• 一次性采购： 无续约，但保留支出历史。

示例：一个 12 个月自动续约且通知期为 60 天的合同，可能在结束日前 90 天切换为 "upcoming"，如果在通知截止前未作决定则升级处理。

审批：阶段与路由规则

审批是续约跟踪器要么节省时间要么制造混乱的地方。保持阶段简单，路由规则足够严格以确保高风险或高价值续约不会漏掉。

常见阶段集合：

• 负责人审核（Owner review）
• 经理审批（Manager approval）
• 财务审批（Finance approval）
• 法务审批（Legal approval）
• 安全或采购审批（Security or Procurement approval，仅在需要时）

路由应基于规则而非手动操作。合同价值、供应商风险等级和合同类型通常覆盖大多数情况。例如，低风险且金额低的续约可能只需经理和财务审批。高价值、高风险或涉及数据处理的续约应加入法务和安全审批。

定义审批何时开始的清晰触发器。典型触发器有：创建续约案件、收到报价或价格变动。将价格或关键条款变更视为审批重置。如果在审批开始后报价发生了变化，重新打开所需阶段以确保最终签字与当前条款一致。

审批动作应明确：approve、reject、request changes。"Request changes" 应暂停流程并将任务返回给负责人并附上必要评论。拒绝应要求给出原因并指明下一步（重新谈判、取消或更换供应商）。

示例：一笔 3 万美元的高风险 SaaS 续约应按 Owner -> Manager -> Finance -> Legal -> Security 的顺序路由。

提醒与升级规则

提醒系统是区分值得信赖的跟踪器与会被忽视的跟踪器的关键。要在合适的里程碑发送提醒、在合适的时间发出消息，并在工作完成时立即停止提醒。

区分不同的里程碑。大多数续约有两个重要日期：通知截止（取消或重新谈判的最后日期）和续约日（合同续约的日期）。首先将提醒绑定到通知截止，因为错过它通常代价更高。

每个里程碑的简单日程：

• 提前 90 天
• 提前 60 天
• 提前 30 天
• 提前 14 天
• 提前 7 天

升级应由缺乏行动触发，而不是仅由时间触发。定义什么算作行动，例如负责人确认、选择决策（续约、取消、重新谈判）或提交审批请求。

实用的升级链：

• 如果在提醒后 3 个工作日内无动作，通知后备负责人。
• 如果再过 5 个工作日仍无动作，通知负责人的经理。
• 如果通知截止在 7 天内且仍无决策，通知法务/采购的群邮箱。
• 对于高价值续约，在提前 30 天时也通知财务。

在负责人的时区的工作时间内发送消息（例如周一到周五 9:00-17:00）。如果缺少负责人的时区，则回退到该合同所属业务单元的时区。

停止条件必须严格。一旦续约案件标记为 Approved、Renewed、Canceled 或 Replaced，该案件的所有后续提醒应立即停止。如果负责人在通知截止前 60 天选择了 "Renegotiate"，则暂停通知提醒并切换到谈判和审批的后续跟进。

通知内容规则与模板

当合适的人在合适的时间收到合适的信息时，通知才有效。保持邮件、应用内和聊天内容一致，这样没人需要去问这条消息是关于什么的。

按步骤划分的典型受众：

• 合同负责人：始终接收每个里程碑的通知
• 当前审批人：仅在需要他们采取行动时通知
• 关注者（法务、采购、客户团队）：在状态变化和审批完成时通知
• 财务：当需要 PO 或支出超过阈值时通知
• 升级经理：仅在逾期或审批停滞后通知

必需的消息字段

每条通知都应包含相同的核心字段，以便可搜索和便于处理：

• 合同名称和供应商
• 续约到期日（及剩余天数）
• 当前状态和阶段负责人
• 下一步动作（批准、审查报价、确认 PO、谈判）
• 到哪里操作（屏幕名或记录 ID）

仅添加有助于决策的上下文：上次续约结果、当前价格以及是否附有报价。

模板

使用两个版本：适合移动的摘要和适合邮件或应用内的详细版。

SHORT (chat/push)
[Renewal due in {days_left} days] {contract_name} - {vendor}
Status: {status}. Next: {next_action}.
Record: {contract_id}

DETAILED (email/in-app)
Subject: Action needed: {contract_name} renewal by {due_date}

Vendor: {vendor}
Due date: {due_date} ({days_left} days)
Current status: {status}
Next action: {next_action}
Owner: {owner_name}
Approver(s): {approver_list}
Price: {current_price} ({currency})
Last renewal: {last_outcome} on {last_renewal_date}
Quote: {quote_available}
Notes: {key_notes}
Record: {contract_id}

安全规则：将通知视为提示而非数据泄露渠道。如果渠道不安全（例如共享聊天），避免包含敏感字段（银行信息、合同全文、特殊定价条款）。提示收件人在应用内打开记录，在那里权限和审计日志适用。

逐步实施工作流

从基础开始：可靠的数据模型和明确的所有权。

1) 先构建实体

创建核心表并紧密关联它们：Contracts、Vendors、内部利益相关者（用户或团队）和 RenewalCases。Contracts 应引用 Vendor 与 Owner。RenewalCases 应引用 Contract，携带用于提醒的关键日期并保存当前续约状态。

实用规则：一个 Contract 可以随时间拥有多个 RenewalCases，但同时只允许一个活动的 case。

2) 定义状态与校验规则

决定有哪些状态以及每个阶段必须填写的字段。保持严格。没有附带草案续约条款和相关文档就不允许 "Legal review"。没有审批人、审批日期和最终条款日期就不允许标记为 "Approved"。

3) 创建状态工作流

实现以下流程：

• 当合同进入续约窗口时自动创建 RenewalCase
• 将案件在各阶段间流转（Draft、Review、Approved、Sent、Closed）
• 根据供应商、合同类型、金额、风险等级或部门路由任务
• 将每次状态变更记录为审计事件
• 续约完成时关闭案件并更新 Contract

示例：如果合同归 Operations 所有且年价值超过阈值，则在财务审批前要求法务审查。

4) 添加计划提醒与升级检查

运行每日定时任务，查找通知截止临近、动作逾期或某阶段卡住的案件。创建提醒事件和升级（例如通知后备负责人或将经理加入为关注者）。

5) 连接渠道并记录投递

通过人们实际阅读的渠道发送通知（email、SMS、Telegram）。记录每次投递尝试的时间戳、渠道、接收人和结果，以便证明提醒已发送并排查遗漏。

人们每天会用到的界面与报表

当日常界面能快速回答一个问题：我接下来需要做什么？人们才会去更新跟踪器。构建几个匹配真实习惯的视图，而不是一个巨大的仪表盘。

续约日历（团队视图）

日历视图最适合突出截止日期，而不是每个合同的所有细节。展示本周和下月到期的续约，并加上清晰的状态标签。每个条目应突出最重要的日期，通常是通知截止日。一个在 5 月 1 日续约的合同可能在 3 月 1 日之前仍被视为“安全”，日历应突出显示的是通知截止日。

负责人收件箱（我的续约）

这是大多数用户的主页。按通知截止排序，然后按风险等级排序。保持以行动为导向：提交审批、请求法务审查、发送续约通知、跟进供应商。

简短的字段集合就足够：

• 合同名称 + 供应商
• 通知截止 + 续约日期
• 状态 + 下一步
• 风险等级 + 估算月成本

审批队列（我的审批）

审批人需要在不多次点击的情况下看到上下文。每行应包含供应商、合同金额、期限长度、续约类型（自动或手动）、拟议变更（涨价、范围变化），以及审批的截止时间。添加清楚的原因说明为什么它在队列中，例如 “需要财务审批，因为年度支出超过阈值”。

供应商视图（按供应商查看全部）

当供应商来电时，人们需要完整的情况：合同、续约日期、风险等级、未完成动作和当前审批人。此视图有助于防止重复合同并更容易发现集中风险。

人们真的会看的每日报表

保持报表简单并可调度：按月的即将发生支出、风险续约（通知截止在 X 天内）以及按负责人统计的逾期动作。

权限与审计跟踪基础

续约跟踪器只有当人们信任它才会有效。信任来自两点：合适的人能看到合适的内容，以及每次重要变更都有记录。

基于角色的访问（谁能看、谁能做）

从一小组角色开始，仅在需要时扩展：

• Viewer： 查看基本详情和日期，但看不到定价或附件。
• Contract Owner： 编辑其合同、上传文档、发起审批请求。
• Approver（Legal/Finance/Procurement）： 批准或拒绝、添加评论、查看合同金额和关键条款。
• Admin： 管理角色、修改路由规则、处理归档。

将敏感字段与通用字段分开。典型受限项包括合同金额、费率表、银行信息和签署的 PDF。如果某份文档必须广泛共享，存储一个经编辑的摘录版作为单独文件。

审计跟踪（必须记录的内容）

将状态变更、审批和文档更新视为可审计事件。至少捕获：

• 更改者（用户）、更改时间（时间戳）
• 字段或动作（状态、负责人、续约日期、期限、文档上传）
• 旧值 和 新值
• 评论（在拒绝、终止或更改续约日期时必填）
• 来源（UI、自动化、导入），如果可用

对于文档，保留版本并标记一份为 当前签署副本。不要覆盖。保留文件名、版本号、上传者/上传时间以及可选标签如 "Signed v3."。

优先归档而非硬删除。归档的合同应可用于搜索，以便做报告和查看续约历史。

在合同可以继续前，强制校验一些基本项：供应商、负责人、后备负责人、起止日期（或永续标记）、续约类型（自动或手动）、通知期和续约期限。

常见错误及避免方法

最快毁掉续约跟踪器信任的方法是错过你以为已在跟踪的截止日期。

一个常见错误是只用一个 “续约日期” 字段就以为万事大吉。真正的续约关键在于通知期（例如 “提前 60 天通知否则自动续约一年”）。通过至少跟踪：生效日、期限结束日、自动续约标记、通知截止和一个计算出的下一步行动日期来修正此问题，该日期驱动提醒。

另一个问题是提醒没有落脚点。如果负责人不在，消息四处弹跳而没人处理。要求每个合同都有负责人和后备负责人，并在没有它们时阻止设为“Active”。

审批失败的原因是忽视真实阈值。单一路径可能适用于小额续约，但一遇到高风险或高价值合同就会崩溃。路由规则应涵盖几个简单因素：价值区间、风险等级或数据敏感性、合同类型、非标准条款以及部门或成本中心。

当通知没有告诉人们下一步做什么时，它们会被忽略。每条提醒都应包含一个明确的下一步（审查、批准、重新谈判、取消）、截止日期和后果（自动续约、价格上涨、服务中断）。

团队也常忘记记录结果，导致每个周期都从头开始。捕捉结果（renewed、terminated、renegotiated）、新期限细节和一段简短的 “发生了什么变化” 说明。

快速检查与下一步

在宣称完成前，运行一些模拟现实的检查。续约跟踪器通常在边缘情况失败：通知期、缺失负责人以及纸面上看起来没问题却迟迟不动的审批。

快速检查（使用 3 份测试合同）

设置三份样例合同，条款不同：

• 一份自动续约合同，带有通知截止，用来确认你是按通知日期而不是仅按结束日期触发提醒。
• 一份手动续约合同，只有有人批准并签字才会继续。
• 一份多年度合同，带有中期评审日期，用来确认长周期不会打断提醒。

对每份合同，验证提醒先为通知截止触发，再为续约/结束日期触发。选一份合同作为负责人不做任何动作，确认升级会到后备负责人并持续推进直到有人处理。

然后测试审批的端到端流程。让一份合同完成审批路径，另一份走拒绝路径。确认审计轨迹记录了谁决定、何时以及为何这样决定。如果你的日志不能在 10 秒内回答 “发生了什么？”，当截止临近时它们也帮不上忙。

下一步

从小范围开始，只有在基础足够稳固后再扩展：

• 先构建最小版本：核心实体、明确状态和两个提醒（例如首次通知和最终通知）。
• 在提醒可靠后再加入审批流程。
• 强制所有权：每份合同都必须有负责人和后备负责人。
• 在一个团队内试点两周，然后调整提醒时间和升级角色。

如果你想在不写代码的情况下构建内部运维应用，AppMaster (appmaster.io) 是一种可供选择的平台，用于建模数据、构建审批工作流并通过多个渠道发送通知。

一旦这些检查通过，你的续约跟踪器就准备好处理真实合同，而不仅仅是演示中的顺利路径。