SLA 服务等级协议提示词（起草框架：服务范围、可用性与响应时限指标、度量方法、服务补偿、免责情形与评审机制）
软件、云服务、运维外包、客服外包等业务需要向客户提供或向供应商索要 SLA 时用：按业务梳理应写进协议的服务指标、计算口径、未达标的补偿方式和例外情形，形成一份可交给法务完善的草案。
通用大模型 对话模型通用
你是一名服务管理顾问，熟悉服务等级协议的常见结构。你提醒我：SLA 里的每一个指标都必须说清「怎么量、谁来量、从什么时候开始算」，否则出现争议时双方各执一词；承诺的数值必须是技术与人力确实做得到的。 服务类型与内容：[服务内容] 我方角色（服务提供方 / 采购方）：[我方角色] 服务时间（全天、工作日等）：[服务时间] 目前实际能达到的服务水平（历史数据）：[实际水平] 客户或我方最在意的指标：[关注指标] 可接受的补偿方式与上限：[补偿方式] 对应的主合同情况：[主合同情况] 请输出 SLA 草案框架与要点： 1. 文件结构（条款目录）：定义、服务范围与不包含的内容、服务时间、服务指标、度量与报告、事件分级与响应、服务补偿、除外情形、变更与评审、沟通与升级联系机制。 2. 定义条款：对「可用性」「停机时间」「计划内维护」「响应时间」「解决时间」「工作日」等术语给出建议定义；指出每个定义里最容易产生分歧的地方。 3. 服务指标表：指标 | 定义与计算公式 | 目标值 | 度量周期 | 数据来源 | 度量方。可用性按「（周期总时长 − 不可用时长）÷ 周期总时长」计算，并写明计划内维护是否计入。目标值参考 [实际水平] 留出余量，标「待技术与业务确认」，不要直接写行业里常见的高标准数值。 4. 事件分级与时限：各级事件的判定、响应时限与解决或提供临时方案的时限；时限从什么时刻起算（客户报告、系统告警或我方确认）。 5. 度量与报告：多久出一次服务报告、包含什么、客户对数据有异议时如何核对。 6. 服务补偿：未达标时的补偿形式（服务费抵扣、延长服务期等）与分档；补偿上限；客户申请补偿的时限与流程；补偿是否为唯一救济需由法务判断并标注。 7. 除外情形：不可抗力、客户自身原因、第三方网络、计划内维护、客户未按要求配合等；提醒除外条款不宜过宽。 8. 站在 [我方角色] 的立场，列出谈判时应争取的 5 点和可以让步的 3 点。 9. 需要法务确认的条款清单与需要技术确认的数值清单。 10. 一页给客户或管理层看的白话摘要。 约束：不引用具体法律条文；不替我承诺数值；所有数值标注来源或「待确认」。
高亮处换成你自己的内容：[服务内容]、[我方角色]、[服务时间]、[实际水平]、[关注指标]、[补偿方式]、[主合同情况]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[实际水平] 非常关键，把过去半年真实的可用性、平均响应时间写上。SLA 的目标值应该比真实水平略保守，而不是照抄别人的宣传数字。[我方角色] 决定立场：作为提供方要防范过宽的承诺，作为采购方则要盯紧度量方式和除外条款。
常见失败与调整：
- 指标没有计算口径：只写「可用性不低于若干」而不写怎么算、谁来算，等于没写。逐个检查指标表的「定义与计算公式」「度量方」两列。
- 除外情形写得像口袋条款：采购方会直接删掉，谈判反而被动。让 AI 把每条除外情形收窄到具体情况。
- 把 SLA 当成营销材料：承诺做不到的数值，后果是真实的赔付。
示例输出
示例，仅供参考（虚构：一家软件公司向企业客户提供在线审批系统，我方为服务提供方）
服务指标表（节选，目标值待技术与业务确认）
| 指标 | 定义与计算 | 目标值 | 周期 | 度量方 |
|---|---|---|---|---|
| 月度可用性 | （当月总分钟数 − 不可用分钟数）÷ 当月总分钟数；计划内维护不计入不可用时长 | 99.5% | 自然月 | 我方监控系统，客户可申请核对日志 |
| 严重事件响应时间 | 自客户通过约定渠道报告起，至我方工程师首次回复 | 30 分钟（7×24） | 单次 | 工单系统记录 |
| 一般问题响应时间 | 同上 | 4 个工作小时 | 单次 | 工单系统记录 |
容易产生分歧的定义：「不可用」——建议定义为「核心功能（登录、提交审批、审批操作）无法使用且持续 5 分钟以上」，避免个别页面加载慢被计为停机。
应争取的要点（节选）：计划内维护提前 3 个工作日通知即不计入停机；补偿以当月服务费的一定比例为上限；客户需在次月 15 日前提出补偿申请。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～