SLA Definition Prompt Template

ROLE: Customer success operations architect who has designed SLA frameworks for B2B SaaS companies scaling from startup to enterprise — you know that SLAs are operational commitments, not marketing promises, and that an SLA you can't consistently meet is worse than a weaker one you reliably deliver. CONTEXT: SLAs serve two audiences: customers (who use them to set expectations and make purchase decisions) and internal teams (who need clear operational targets to staff and prioritise correctly). The most common SLA failure is writing aspirational targets that the team cannot consistently meet, which generates breach credits, erodes trust, and creates customer success nightmares. This SLA must be achievable with current resourcing while still being competitive. TASK: Define a complete SLA framework for [COMPANY_NAME]'s [PRODUCT_OR_SERVICE] covering [CUSTOMER_TIERS]. Every commitment must be operationally realistic and clearly measured. RULES: • Severity levels must be defined by customer business impact, not just technical severity — P1 means "customer's business is stopped," not "the system is slow" • Response time and resolution time must be clearly distinct — response time is when you acknowledge; resolution time is when it's fixed • Support hours must be stated in specific timezones — not just "business hours" • Escalation paths must name the role, not just the department — "escalated to engineering" is not an escalation path • Measurement methodology must specify: what clock starts, what pauses it (e.g. waiting for customer info), and what breach remedies apply CONSTRAINTS: Present tier comparison as a table. Include at least 2 customer tiers. Flag any commitment that requires infrastructure or staffing investment to meet. EDITABLE VARIABLES: • [COMPANY_NAME] — the company offering the SLA • [PRODUCT_OR_SERVICE] — what the SLA covers • [CUSTOMER_TIERS] — e.g. Standard, Professional, Enterprise • [SUPPORT_HOURS] — available support coverage by tier • [CURRENT_TEAM_CAPACITY] — context for what's operationally achievable OUTPUT FORMAT: Severity Level Definitions (P1–P4 with business impact descriptions) SLA Commitments by Tier (table: severity × tier, response + resolution times) Support Hours by Tier Escalation Path by Severity (with role names) Measurement Methodology (clock start/stop, breach definition) Breach Remedies / SLA Credits SLA Exclusions Operational Investment Flags QUALITY BAR: A support engineer should be able to read the SLA and know exactly what's expected of them for any ticket without asking a manager. A customer reading it should have no reasonable cause for confusion about what they're entitled to.