4. 服务范围与功能描述条款设计

服务范围与功能描述条款是SaaS合同中最容易引发争议的部分。原因并不复杂：SaaS产品持续迭代，签约时的功能状态与履约中的功能状态往往不同；客户理解的“服务”与供应商理解的“服务”也常常存在偏差。如果合同仅写“提供XX系统服务”或“提供标准SaaS服务”，一旦发生纠纷，双方对“标准”二字的解释可能完全不同。因此，这一条款的核心任务不是把功能写得越多越好，而是把服务边界、功能基线、权限模型、接口能力和变更规则四件事写清楚，使双方对“什么在范围内、什么不在范围内、范围如何变化”形成可验证的共识。

一、服务内容描述：从“一句话”到“可验证基线”

服务内容描述应当回答三个问题：提供什么服务、以什么方式提供、达到什么可用状态。建议采用“服务名称+服务形态+服务对象+服务标准”的结构。例如，不要写“提供客户管理系统”，而应写“提供XX客户关系管理SaaS服务，服务形态为多租户公有云，服务对象为甲方及其授权员工，服务标准为附件一《功能清单》所列功能及附件二《SLA》所载可用性指标”。

这里的关键是把功能清单作为合同附件，而不是在正文中零散罗列。功能清单应逐项标注功能名称、功能说明、所属模块、是否包含在基础订阅中、是否属于增值模块。对于签约时尚未开发或处于测试阶段的功能，必须单独标注“规划中”或“Beta”，并明确其不构成供应商的交付义务，或约定最晚交付时间与未交付的救济方式。这样既避免客户误以为所有演示功能都已包含，也避免供应商被要求交付尚未承诺的能力。

二、用户权限与账号模型：把“谁能做什么”写进合同

用户权限是SaaS合同中最容易被忽略、却最容易产生实际损失的部分。客户往往认为“买了系统就能用所有功能”，而供应商的权限模型可能按角色、按模块、按数据范围进行限制。合同中应明确以下要素：

• 用户类型与数量：区分管理员账号、普通用户账号、只读账号、API账号等，明确各类账号的数量上限及超出后的计费方式。
• 角色与权限矩阵：以表格形式列出角色（如系统管理员、销售主管、销售代表、财务人员）对关键功能的操作权限（查看、新增、编辑、删除、导出、审批）。
• 数据可见范围：明确是按本人、按团队、按部门还是按全公司可见，避免客户误以为所有账号都能看到全部数据。
• 账号共享限制：约定账号仅限授权人员使用，禁止共享，并明确供应商对异常登录的监控与处置权。

权限矩阵不必覆盖全部功能，但应覆盖涉及数据导出、批量删除、权限变更、财务操作等高风险动作。这样在发生数据泄露或误操作时，双方可以依据合同判断责任归属。

三、API接口条款：能力、限制与稳定性承诺

API接口条款需要区分“接口是否存在”与“接口是否可用、是否稳定、是否持续兼容”。建议至少约定以下内容：接口类型（RESTful、Webhook、SDK）、认证方式（API Key、OAuth 2.0）、调用频率限制（如每分钟600次）、单次请求数据量上限、接口版本管理策略、废弃接口的提前通知期（如提前90天）。

对于客户依赖API进行系统集成的场景，还应约定接口可用性目标（如99.9%）和故障响应时间。如果供应商保留调整接口参数的权利，应明确调整不得导致客户现有集成中断，或给予合理的迁移窗口。以下是一个接口条款的示例片段：

接口类型：RESTful API，JSON格式
认证方式：OAuth 2.0 Client Credentials
频率限制：600次/分钟/租户，超限返回429
版本策略：URL路径版本（/v1/、/v2/），旧版本至少维护12个月
废弃通知：提前90天书面通知，并提供迁移文档
可用性目标：99.9%（按月统计，不含计划维护窗口）

四、更新升级义务：区分“维护”与“新增”

SaaS供应商通常会持续发布更新，但客户需要知道：哪些更新是合同义务，哪些是供应商自主决定；更新是否额外收费；更新是否可能导致功能变更或数据迁移。建议将更新分为三类：

• 维护性更新：修复缺陷、安全补丁、性能优化，不改变现有功能逻辑，通常包含在订阅费中，供应商应持续提供。
• 功能性更新：新增功能或增强现有功能，供应商可自主决定是否提供，除非合同明确约定为交付义务。
• 重大版本升级：涉及架构调整、数据模型变更或接口不兼容，应提前通知客户，并明确是否额外收费、是否提供数据迁移支持。

同时应约定“不得单方面减少功能”的原则：供应商不得在订阅期内实质性削减客户已付费的核心功能，除非法律法规要求或双方协商一致。如果确需下线某功能，应提前通知并提供替代方案或按比例退款。

五、范围变更机制：让“加需求”有章可循

即使条款写得再细，客户在履约中仍可能提出新需求。如果没有变更机制，这些需求要么被供应商免费承接导致成本失控，要么被拒绝导致客户不满。建议在合同中约定变更流程：客户以书面形式提出变更请求，供应商在5个工作日内评估对功能、工期、费用的影响并反馈，双方签署变更单后生效。变更单应作为合同附件，与原功能清单具有同等效力。

此外，应明确“未列入功能清单的功能不属于服务范围”，以及“供应商对客户提出的定制开发需求无当然义务”。如果客户需要定制，应单独签署定制开发协议或工作说明书（SOW），明确交付物、验收标准、知识产权归属和费用。

六、可直接使用的功能清单模板字段

以下字段可直接用于附件一《功能清单》的编制，建议以表格形式呈现，每行一个功能点：

综上，服务范围与功能描述条款的设计目标不是追求文字量，而是建立一套可验证、可变更、可追责的边界体系。服务内容基线解决“有什么”，权限模型解决“谁能用”，API条款解决“怎么连”，更新升级条款解决“怎么变”，变更机制解决“加需求怎么办”。五者配合，才能把范围模糊争议压缩到最小。