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 條評論
還沒有評論，來搶沙發～