30 Claude Prompts for SLAs

You are a commercial contracts manager who structures financial remedies for missed service levels. <context> We missed our uptime target twice last quarter and customers are asking what compensation looks like, so I need a formal credit schedule. </context> <inputs> - Uptime target: [UPTIME TARGET] - Monthly recurring fee: [MONTHLY FEE] - Credit percentage by shortfall band: [CREDIT PERCENTAGES] - Maximum credit cap: [MAX CREDIT CAP] - Claim window: [DAYS TO CLAIM] </inputs> <task> Draft a service credit schedule that ties specific uptime shortfall bands to specific credit percentages, including how a customer claims the credit. </task> <constraints> Use a simple banded structure, not a formula customers would need a calculator for. State the claim window and cap clearly. </constraints> <format> Return a table of shortfall band to credit percentage, followed by a short paragraph on the claim process and cap. </format>

You are a contracts attorney specializing in limitation of liability language for technology agreements. <context> Our legal team wants the service credit to be stated as the customer's exclusive remedy for a missed service level, and I need a first draft to bring to them. </context> <inputs> - Remedy type: [SERVICE CREDIT] - Exceptions to sole remedy: [EXCEPTIONS IF ANY] - Governing law: [GOVERNING LAW STATE OR COUNTRY] - Related liability cap clause reference: [LIABILITY CAP SECTION NUMBER] </inputs> <task> Draft a sole and exclusive remedy clause stating that the service credit is the customer's only remedy for a service level failure, with a cross reference to the liability cap section. </task> <constraints> Do not draft language that would conflict with consumer protection statutes. Note any exceptions the business already agreed to. This is a draft for attorney review, not final language. </constraints> <format> Return the clause text, then a bullet list of legal risks this clause type commonly raises. </format>

You are a customer success operations manager writing the customer facing process for claiming service credits. <context> Customers do not know how to request a service credit today and support keeps fielding confused tickets, so I need a clear process written down. </context> <inputs> - Claim submission channel: [SUPPORT PORTAL OR EMAIL] - Required information from customer: [REQUIRED FIELDS] - Internal review timeline: [REVIEW TIMELINE DAYS] - Credit application method: [NEXT INVOICE OR REFUND] </inputs> <task> Write the customer facing steps for requesting a service credit, from submission to how the credit gets applied. </task> <constraints> Write for a non legal audience. Keep each step to one sentence. Avoid internal jargon like ticket queue or triage. </constraints> <format> Return a numbered list of steps, then a short FAQ of two common questions customers ask about credits. </format>

You are a vendor risk manager who negotiates termination rights tied to repeated service failures. <context> A customer is asking for the right to terminate if we miss our service level too many times in a row, and I need a balanced draft to bring to negotiation. </context> <inputs> - Number of consecutive misses that trigger the right: [NUMBER OF MISSES] - Look back period: [LOOK BACK PERIOD MONTHS] - Cure period offered: [CURE PERIOD DAYS] - Termination notice period: [NOTICE PERIOD DAYS] </inputs> <task> Draft a chronic failure clause defining when repeated service level misses give the customer a termination right, including a cure period for the vendor. </task> <constraints> Balance customer protection with a reasonable cure opportunity for the vendor. Do not allow termination on a single miss. </constraints> <format> Return the clause text, then two sentences summarizing the negotiation tradeoff for internal stakeholders. </format>

You are a finance business partner who reviews the financial exposure of service level commitments before they are signed. <context> Our sales team agreed to a service credit cap with a large customer and finance wants to understand the worst case exposure before approving it. </context> <inputs> - Annual contract value: [ANNUAL CONTRACT VALUE] - Proposed credit cap percentage: [CREDIT CAP PERCENTAGE] - Historical uptime performance: [HISTORICAL UPTIME] - Number of similar deals this quarter: [NUMBER OF DEALS] </inputs> <task> Write a short memo estimating the worst case financial exposure of the proposed credit cap across this deal and similar deals in the pipeline. </task> <constraints> Show the math, do not just state a conclusion. Keep the memo under 250 words. Flag if the cap is unusually generous compared to industry norms. </constraints> <format> Return as a memo with a one line recommendation at the top, followed by the calculation and reasoning. </format>

You are a technology contracts drafter who specializes in carve outs for service level agreements. <context> I need a standard set of exclusions so scheduled maintenance and customer caused issues do not count against our uptime commitment. </context> <inputs> - Scheduled maintenance window: [MAINTENANCE WINDOW SCHEDULE] - Customer caused issue examples: [CUSTOMER CAUSED EXAMPLES] - Third party dependency examples: [THIRD PARTY EXAMPLES] - Beta or preview feature policy: [BETA FEATURE POLICY] </inputs> <task> Draft the exclusions section listing what does not count against the uptime commitment, covering maintenance, customer caused issues, third party outages, and beta features. </task> <constraints> Be specific rather than using catch all language like any other cause outside our control. List concrete examples for each category. </constraints> <format> Return as a bulleted list grouped under four subheadings matching the four categories above. </format>

You are a commercial lawyer drafting force majeure protection specific to cloud infrastructure dependencies. <context> We rely on a third party cloud provider and want force majeure language that covers their outages without being so broad it becomes unenforceable. </context> <inputs> - Cloud provider name: [CLOUD PROVIDER] - Notice obligation on trigger: [NOTICE OBLIGATION HOURS] - Mitigation obligation: [MITIGATION STEPS] - Duration before termination right: [DURATION BEFORE TERMINATION] </inputs> <task> Draft a force majeure clause tailored to third party infrastructure outages, including the notice and mitigation obligations on us. </task> <constraints> Avoid open ended language such as any event beyond reasonable control without examples. Name the type of dependency explicitly. </constraints> <format> Return the clause text followed by a short note on jurisdictions where force majeure clauses are interpreted narrowly. </format>

You are an IT operations manager who writes customer facing maintenance notification policies. <context> Customers complain when maintenance windows surprise them, and I need a clear notice policy to include in the service level agreement. </context> <inputs> - Standard maintenance window: [DAY AND TIME] - Advance notice required: [ADVANCE NOTICE HOURS] - Emergency maintenance notice: [EMERGENCY NOTICE MINUTES] - Notification channel: [EMAIL OR STATUS PAGE] </inputs> <task> Draft the maintenance notice policy stating how much advance notice customers get for standard and emergency maintenance, and where notices are posted. </task> <constraints> Distinguish clearly between standard and emergency maintenance. Keep language short enough to also live on a public status page. </constraints> <format> Return two short paragraphs, one for standard maintenance and one for emergency maintenance. </format>

You are a solutions engineer turned contracts reviewer who flags where a customer's own setup can break the service level commitment. <context> We keep getting blamed for downtime that is actually caused by a customer's own configuration or network, and I need language that shifts that responsibility clearly. </context> <inputs> - Common customer caused issues: [MISCONFIGURATION EXAMPLES] - Required customer environment: [MINIMUM REQUIREMENTS] - Customer support obligations: [CUSTOMER SUPPORT DUTIES] - Diagnostic access needed: [DIAGNOSTIC ACCESS TYPE] </inputs> <task> Draft a customer dependency disclaimer clarifying that issues caused by the customer's own environment, configuration, or network are excluded from the service level commitment. </task> <constraints> Be specific about what counts as a customer caused issue. Avoid shifting blame for problems that are actually within our control. </constraints> <format> Return the clause text, then a short bullet list of what the support team should document to prove a customer caused issue. </format>

You are a customer success director who resolves disagreements about whether an incident falls under an exclusion. <context> A customer disputes that a recent outage should be excluded from our uptime calculation, and I need a written process for handling these disagreements consistently. </context> <inputs> - Incident type in dispute: [INCIDENT TYPE] - Evidence available: [LOGS OR MONITORING DATA] - Internal decision maker: [DECISION MAKER ROLE] - Escalation deadline: [ESCALATION DEADLINE DAYS] </inputs> <task> Write a step by step process for resolving disputes over whether an incident qualifies for an exclusion, from initial customer challenge to final internal decision. </task> <constraints> Keep the process fair and documented at each step. Set a firm deadline so disputes do not drag on indefinitely. </constraints> <format> Return a numbered process with a responsible party and deadline listed next to each step. </format>

You are a customer support director designing the tier structure for a new support offering. <context> We are launching a paid premium support tier alongside our standard support and need clear documentation of what each tier includes. </context> <inputs> - Standard tier features: [STANDARD FEATURES] - Premium tier features: [PREMIUM FEATURES] - Premium tier price: [PREMIUM PRICE] - Support hours by tier: [SUPPORT HOURS] </inputs> <task> Write a comparison document explaining what each support tier includes, so both sales and customers can understand the difference clearly. </task> <constraints> Avoid vague terms like priority support without defining what priority actually means in hours or channels. Keep it customer readable. </constraints> <format> Return a comparison table with tiers as columns, followed by a two sentence summary of who should choose which tier. </format>

You are an enterprise account management lead defining the dedicated contact model for top tier customers. <context> Our enterprise tier customers want a named contact instead of a general support queue, and I need to define how that model works operationally. </context> <inputs> - Contact role title: [CONTACT ROLE TITLE] - Backup coverage plan: [BACKUP PLAN] - Response time commitment: [RESPONSE TIME] - Communication channels: [COMMUNICATION CHANNELS] </inputs> <task> Draft the named contact policy explaining the role, backup coverage when that person is unavailable, and the response commitment tied to this model. </task> <constraints> Make the backup plan concrete, not just a note that coverage will be arranged. State response commitments in hours. </constraints> <format> Return as a short policy document with three labeled sections, Role, Backup Coverage, and Response Commitment. </format>

You are a support operations manager who documents how issues move up the escalation ladder when they are not resolved on time. <context> We need a written escalation ladder so customers know exactly who to contact if an issue is not resolved within the committed time. </context> <inputs> - Level one contact: [LEVEL ONE CONTACT] - Level two contact: [LEVEL TWO CONTACT] - Level three contact: [LEVEL THREE CONTACT] - Time before each escalation: [ESCALATION TIMING] </inputs> <task> Write the escalation ladder showing each level, who the contact is, and how long an issue sits at that level before moving up. </task> <constraints> Use exact time thresholds, not phrases like if not resolved soon. Keep each level description to one or two sentences. </constraints> <format> Return as a numbered ladder from level one to level three, with contact and timing listed for each. </format>

You are a global support strategy lead planning language and timezone coverage commitments for an international customer base. <context> We are expanding into new regions and need to define what language and timezone coverage our support commitment actually includes. </context> <inputs> - Languages supported: [SUPPORTED LANGUAGES] - Coverage hours by region: [REGION HOURS] - Regions with 24/7 coverage: [24/7 REGIONS] - Translation or interpretation policy: [TRANSLATION POLICY] </inputs> <task> Draft a coverage clause stating which languages and timezones are covered, and what happens for requests outside those languages or hours. </task> <constraints> Be explicit about gaps in coverage rather than implying global coverage exists. State the fallback for unsupported languages. </constraints> <format> Return the clause text, then a short table listing region, hours, and supported languages. </format>

You are a technical support manager standardizing how support tickets get classified by priority. <context> Our support agents classify ticket priority inconsistently and it is affecting whether we meet our response commitments, so I need clear priority definitions. </context> <inputs> - Priority levels: [P1, P2, P3, P4] - Business impact examples per level: [IMPACT EXAMPLES] - Who can reclassify a ticket: [RECLASSIFICATION AUTHORITY] - Customer notification on reclassification: [NOTIFICATION REQUIREMENT] </inputs> <task> Write priority level definitions for support tickets with concrete business impact examples for each level, and the rule for who can reclassify a ticket. </task> <constraints> Use concrete, observable criteria for each level, not subjective judgment calls. Keep each definition to two sentences. </constraints> <format> Return a table with columns for priority level, definition, example, and reclassification rule. </format>

You are a service delivery manager who produces the monthly report customers receive on service level performance. <context> I need a clean monthly report template showing our actual performance against every committed service level metric. </context> <inputs> - Metrics tracked: [UPTIME, RESPONSE TIME, RESOLUTION TIME] - Reporting period: [MONTH OR QUARTER] - Data source: [MONITORING SYSTEM] - Recipient: [CUSTOMER CONTACT] </inputs> <task> Build a monthly service level report template showing target versus actual for each metric, with a short narrative explaining any miss. </task> <constraints> Keep the narrative section honest and specific about root cause. Do not use filler phrases when explaining a miss. </constraints> <format> Return a table of metric, target, actual, and status, followed by a short narrative section for any metric marked as missed. </format>

You are an account manager preparing the service level portion of a quarterly business review for a key account. <context> I am putting together a quarterly business review for a major customer and need the service level performance section to tell a clear story, not just list numbers. </context> <inputs> - Quarter performance data: [QUARTERLY DATA SUMMARY] - Notable incidents this quarter: [NOTABLE INCIDENTS] - Improvement actions taken: [IMPROVEMENT ACTIONS] - Next quarter commitments: [NEXT QUARTER GOALS] </inputs> <task> Write the service level summary section for a quarterly business review, connecting the performance data to the incidents that happened and the actions taken to improve. </task> <constraints> Lead with the honest performance number before the narrative. Keep the tone factual, not promotional. </constraints> <format> Return four short sections, Performance Summary, Notable Incidents, Actions Taken, and Next Quarter Commitments. </format>

You are an operations director who runs the internal review process before a service level agreement is renewed or renegotiated. <context> We are approaching a renewal with a large customer and I want an internal checklist to review our actual performance history before we commit to new terms. </context> <inputs> - Contract end date: [CONTRACT END DATE] - Historical performance data available: [PERFORMANCE DATA SOURCE] - Teams involved in review: [TEAMS INVOLVED] - Renewal risk factors: [KNOWN RISK FACTORS] </inputs> <task> Build an internal checklist for reviewing our historical service level performance before agreeing to renewal terms, covering data review, risk assessment, and sign off. </task> <constraints> Organize by owner and deadline. Include a step for checking whether current commitments are still realistic given actual performance. </constraints> <format> Return a checklist grouped into three phases, Data Review, Risk Assessment, and Sign Off, with an owner and deadline per item. </format>

You are a vendor management lead who runs recurring governance meetings to monitor service level performance with a key vendor or customer. <context> We hold a recurring governance meeting to review service level performance and it keeps running long without covering the important items, so I need a tighter agenda. </context> <inputs> - Meeting frequency: [MONTHLY OR QUARTERLY] - Attendees: [ATTENDEE ROLES] - Standing topics: [STANDING TOPICS] - Open issues to track: [OPEN ISSUES] </inputs> <task> Build a governance meeting agenda with time allocations that covers performance review, open issue tracking, and any upcoming changes to the service level terms. </task> <constraints> Keep total meeting time to sixty minutes. Assign a time box to each agenda item so the meeting stays on schedule. </constraints> <format> Return a numbered agenda with item, owner, and time allocation for each entry. </format>

You are a contracts manager documenting proposed changes to an existing service level agreement before they go to signature. <context> We need to amend an existing service level agreement to change the uptime target and credit structure, and I need a change memo to route internally before drafting the amendment. </context> <inputs> - Current terms: [CURRENT TERMS SUMMARY] - Proposed new terms: [PROPOSED NEW TERMS] - Reason for change: [REASON FOR CHANGE] - Internal approvers needed: [APPROVER ROLES] </inputs> <task> Write a change memo comparing the current and proposed service level terms, explaining the reason for the change, and listing who needs to approve it before the amendment is drafted. </task> <constraints> Show current versus proposed side by side. State the business reason plainly, do not bury it in legal language. </constraints> <format> Return a memo with a comparison table of current versus proposed terms, followed by a short approval routing list. </format>

You are a procurement specialist who evaluates a vendor's proposed service level agreement before it is signed. <context> A vendor sent us a draft service level agreement and I need to identify the weak points before we respond with redlines. </context> <inputs> - Vendor name: [VENDOR NAME] - Uptime target offered: [OFFERED UPTIME] - Credit cap offered: [OFFERED CREDIT CAP] - Our minimum acceptable terms: [MINIMUM ACCEPTABLE TERMS] - Contract value: [CONTRACT VALUE] </inputs> <task> Review the vendor's proposed terms against our minimum acceptable terms and produce a list of redline points with the reasoning behind each one. </task> <constraints> Rank the redline points by priority, not just list them in order. Keep the reasoning for each point to two sentences. This is a draft for legal review, not a final negotiating position. </constraints> <format> Return a numbered list of redline points ordered by priority, each with the current term, the proposed change, and a one line reason. </format>

You are a sourcing analyst who benchmarks service level terms across competing vendor proposals. <context> We are comparing service level agreement terms across three vendor proposals and need a side by side summary before making a decision. </context> <inputs> - Vendor A terms: [VENDOR A TERMS] - Vendor B terms: [VENDOR B TERMS] - Vendor C terms: [VENDOR C TERMS] - Priority criteria: [PRIORITY CRITERIA] </inputs> <task> Compare the service level terms of the three vendors across the priority criteria and highlight which vendor offers the strongest terms on each point. </task> <constraints> Be objective, do not favor a vendor based on brand reputation alone. Note any term that is missing entirely from a proposal. </constraints> <format> Return a comparison table with vendors as columns and criteria as rows, followed by a two sentence recommendation. </format>

You are a legal operations manager preparing a briefing for internal stakeholders before an SLA negotiation. <context> I need to brief our sales and product leadership on the risk tradeoffs in the service level terms we are about to negotiate with a large prospect. </context> <inputs> - Prospect name: [PROSPECT NAME] - Requested uptime target: [REQUESTED UPTIME] - Requested credit terms: [REQUESTED CREDIT TERMS] - Our standard terms: [STANDARD TERMS] - Deal size: [DEAL SIZE] </inputs> <task> Write a short briefing explaining the gap between what the prospect is requesting and our standard terms, and the business risk of agreeing to the gap. </task> <constraints> Keep it under 300 words. Avoid legal jargon since the audience is sales and product leadership, not lawyers. State the risk in plain business terms. </constraints> <format> Return three short sections, The Ask, The Gap, and The Risk, each two to three sentences. </format>

You are an account executive preparing talking points for a service level agreement renewal conversation with an existing customer. <context> Our customer's contract is up for renewal and they are unhappy about a service level miss earlier this year, so I need talking points that address it directly without being defensive. </context> <inputs> - Customer name: [CUSTOMER NAME] - Incident being referenced: [INCIDENT SUMMARY] - Improvements made since: [IMPROVEMENTS MADE] - Renewal terms being proposed: [RENEWAL TERMS] </inputs> <task> Write talking points for the renewal conversation that acknowledge the past incident honestly, describe the improvements made, and present the renewal terms. </task> <constraints> Do not minimize the incident or use defensive language. Keep tone direct and confident, not apologetic beyond a brief acknowledgment. </constraints> <format> Return as a short list of talking points in the order they should come up in conversation. </format>

You are an IT vendor management lead auditing service level terms across multiple vendor contracts for consistency. <context> We rely on several vendors for critical infrastructure and I suspect their service level commitments do not add up to the overall availability our own customers expect, so I need an audit. </context> <inputs> - Vendor list and their uptime commitments: [VENDOR UPTIME LIST] - Our own customer facing uptime commitment: [OUR UPTIME COMMITMENT] - Dependency chain description: [DEPENDENCY CHAIN] - Critical vendors flagged as risk: [CRITICAL VENDORS] </inputs> <task> Analyze whether the combined uptime commitments of our vendors are sufficient to support the uptime commitment we make to our own customers, and flag any gap. </task> <constraints> Show the math on combined dependency risk, do not just assert there is a gap. Identify which single vendor represents the largest risk. </constraints> <format> Return a short calculation section, followed by a ranked list of vendor risk from highest to lowest. </format>