dojo.md 0.1.0

package/courses/customer-support-escalation/scenarios/level-2/vip-executive-escalation.yaml

@@ -0,0 +1,81 @@
+meta:
+  id: vip-executive-escalation
+  level: 2
+  course: customer-support-escalation
+  type: output
+  description: "Handle VIP and executive escalation — manage high-value customer issues with appropriate urgency, personalization, and executive-level communication"
+  tags: [support, escalation, vip, executive, high-value, intermediate]
+
+state: {}
+
+trigger: |
+  VIP and executive escalations require a different approach than
+  standard escalation. These customers often have direct access to
+  your leadership, their issues carry disproportionate business
+  impact, and the communication style must match their expectations.
+
+  Part 1: VIP escalation framework
+  1. Identifying VIP customers (revenue tier, strategic accounts,
+     executive contacts, influencer/media)
+  2. VIP escalation paths (dedicated queue, named account managers,
+     executive sponsors)
+  3. Communication tone for VIP escalations (executive-level
+     language, no scripts, personalized)
+  4. When VIP status doesn't change the right answer (policy
+     is policy, but delivery changes)
+
+  Part 2: Handle VIP escalation scenarios
+
+  Scenario 1 — Executive email from a Fortune 500 CTO:
+  "Your platform had 3 outages this quarter. Our SLA guarantees
+  99.9% uptime and you've delivered 99.2%. I need a call with your
+  VP of Engineering to discuss reliability improvements and our
+  contract renewal terms. Please arrange this by Thursday."
+  (Customer: $180K ARR, 2-year contract renewing in 60 days)
+  - Write the internal escalation to your VP of Engineering
+  - Write the response to the CTO
+  - Prepare the briefing document for the VP's call
+
+  Scenario 2 — Board member's personal account:
+  Your CEO's assistant emails: "One of our board members, [Name],
+  is having trouble with their personal account. Can you prioritize
+  this?" The issue is a standard password reset.
+  - Handle appropriately (VIP treatment without circumventing
+    security)
+  - Write the response to the CEO's assistant
+  - Write the direct communication to the board member
+
+  Scenario 3 — Social media influencer escalation:
+  A tech influencer with 500K followers tweets: "Been trying to
+  get @YourCompany to fix my account for 2 weeks. Starting to
+  think they don't care about customers. Thread incoming..."
+  (The ticket exists — it was assigned but fell through the cracks)
+  - Write the escalation plan (support, PR, social media)
+  - Write the public response (on Twitter)
+  - Write the private outreach to the influencer
+  - Write the internal post-mortem note
+
+  Scenario 4 — The "I know your CEO" customer:
+  "I play golf with your CEO, Tom. If this isn't resolved today,
+  I'm calling him directly. You really don't want that to happen."
+  Context: Standard customer, $50/month plan, issue is a legitimate
+  billing error of $50. The claim may or may not be true.
+  - Write the response that handles this professionally
+
+assertions:
+  - type: llm_judge
+    criteria: "The CTO escalation includes a briefing document — the VP of Engineering gets customer history, SLA data, contract renewal context, and talking points"
+    weight: 0.25
+    description: "Executive briefing preparation"
+  - type: llm_judge
+    criteria: "The board member's password reset doesn't skip security — VIP treatment means priority and communication style, not bypassing identity verification"
+    weight: 0.25
+    description: "Security maintained for VIP"
+  - type: llm_judge
+    criteria: "The influencer response is both public and private — the public response shows responsiveness while the private outreach offers genuine resolution"
+    weight: 0.25
+    description: "Dual public-private influencer response"
+  - type: llm_judge
+    criteria: "The 'I know your CEO' customer is handled without intimidation — the response focuses on resolving the issue rather than being influenced by the name-drop"
+    weight: 0.25
+    description: "Name-drop handled professionally"

package/courses/customer-support-escalation/scenarios/level-3/crisis-escalation-protocols.yaml

@@ -0,0 +1,77 @@
+meta:
+  id: crisis-escalation-protocols
+  level: 3
+  course: customer-support-escalation
+  type: output
+  description: "Design and execute crisis escalation protocols — handle major incidents, product recalls, data breaches, and PR crises with structured escalation procedures"
+  tags: [support, escalation, crisis, protocols, incident-response, advanced]
+
+state: {}
+
+trigger: |
+  Crisis escalation is fundamentally different from standard
+  escalation. Speed, coordination, and communication precision
+  become critical when the impact extends beyond a single customer
+  to potentially thousands.
+
+  Part 1: Crisis escalation framework
+  1. Crisis severity levels:
+     - SEV 1 (Critical): Full outage, data breach, safety risk
+     - SEV 2 (Major): Partial outage, significant data issue
+     - SEV 3 (Moderate): Degraded performance, workaround available
+     - SEV 4 (Minor): Cosmetic issue, limited impact
+  2. Escalation response matrix by severity
+  3. War room protocol (who's in, roles, cadence)
+  4. External communication protocols (customers, media, regulators)
+
+  Part 2: Execute crisis escalation scenarios
+
+  Scenario 1 — Data breach (SEV 1):
+  At 2:00 AM, your monitoring system detects unauthorized database
+  access. Preliminary analysis shows customer PII (names, emails,
+  hashed passwords) for approximately 50,000 accounts may have been
+  exposed. You're the on-call escalation lead.
+  - Write the immediate escalation chain (who gets called, in order)
+  - Write the initial incident brief
+  - Draft the 1-hour, 4-hour, and 24-hour communication plans
+  - Define the customer notification strategy
+  - Address regulatory notification requirements (GDPR 72-hour rule)
+
+  Scenario 2 — Product safety recall (SEV 1):
+  A children's product is discovered to have a choking hazard.
+  15,000 units have been sold. Three customer complaints mention
+  children putting small parts in their mouths, but no injuries
+  reported yet.
+  - Write the escalation to executive leadership
+  - Write the escalation to legal and product safety
+  - Draft the customer notification (urgency + clarity)
+  - Design the recall process through support channels
+  - Plan for media inquiry handling
+
+  Scenario 3 — Cascading outage (SEV 2):
+  Your payment processing partner goes down at 10 AM on Black
+  Friday. No orders can be processed. Estimated 500 customers per
+  hour are affected. No ETA from the partner.
+  - Write the escalation plan
+  - Draft customer communication for affected transactions
+  - Design the triage process for angry customers
+  - Plan for service recovery once payments resume
+  - Calculate estimated revenue impact for leadership
+
+assertions:
+  - type: llm_judge
+    criteria: "The data breach response follows a structured incident process — security first, then assessment, then communication, with GDPR 72-hour notification addressed"
+    weight: 0.30
+    description: "Structured breach response"
+  - type: llm_judge
+    criteria: "The product safety recall prioritizes child safety — customer notification goes out immediately without waiting for a full investigation"
+    weight: 0.25
+    description: "Safety-first recall response"
+  - type: llm_judge
+    criteria: "The Black Friday outage includes revenue impact — leadership gets both the operational situation and the business impact quantified"
+    weight: 0.25
+    description: "Business impact quantification"
+  - type: llm_judge
+    criteria: "Communication plans are staged — different messages at different time intervals as more information becomes available"
+    weight: 0.20
+    description: "Staged crisis communication"

package/courses/customer-support-escalation/scenarios/level-3/cultural-escalation-differences.yaml

@@ -0,0 +1,93 @@
+meta:
+  id: cultural-escalation-differences
+  level: 3
+  course: customer-support-escalation
+  type: output
+  description: "Navigate cultural differences in escalation — understand how escalation expectations, communication styles, and authority perceptions vary across cultures"
+  tags: [support, escalation, cultural, international, communication, advanced]
+
+state: {}
+
+trigger: |
+  Escalation expectations vary significantly across cultures.
+  What feels like assertive advocacy in one culture may feel like
+  rude aggression in another. Understanding these differences is
+  critical for global support teams.
+
+  Part 1: Cultural dimensions affecting escalation
+  1. Power distance (how comfortable customers are asking for
+     a manager in high vs. low power-distance cultures)
+  2. Directness vs. indirectness (explicit escalation requests
+     vs. subtle dissatisfaction signals)
+  3. Individualism vs. collectivism (personal complaint vs.
+     group/company complaint)
+  4. Time orientation (urgency expectations vary by culture)
+  5. Relationship vs. task orientation (trust-building before
+     resolution vs. immediate resolution focus)
+
+  Part 2: Handle culturally varied escalation scenarios
+
+  Scenario 1 — Japanese customer (indirect communication):
+  A long-standing customer in Japan responds to your resolution
+  attempt with: "Thank you for your kind explanation. I understand
+  your position. I will consider this matter further."
+  Context: In Japanese business culture, this polite response
+  likely means they're dissatisfied but won't directly say so.
+  - Interpret the underlying message
+  - Write a response that addresses possible dissatisfaction
+  - Determine if proactive escalation is appropriate even though
+    the customer hasn't asked for it
+  - Design a follow-up approach that respects cultural norms
+
+  Scenario 2 — German customer (direct + process-oriented):
+  "This is the third occurrence of this error in our billing. I
+  require: 1) A written explanation of the root cause. 2) A
+  corrective action plan with timeline. 3) Confirmation from
+  your quality manager that this has been reviewed."
+  - Respond to the structured request with equal precision
+  - Determine which requests require escalation
+  - Write the escalation that matches this customer's expectations
+  - Design the follow-up cadence
+
+  Scenario 3 — Brazilian customer (relationship-first):
+  A customer starts with extended personal conversation before
+  getting to their issue, mentions they've been loyal for 5 years,
+  tells a story about how the product helped their business, and
+  then mentions a problem almost as an afterthought.
+  - Identify the actual issue beneath the relationship context
+  - Respond in a culturally appropriate way (don't rush to resolution)
+  - Determine if escalation is needed
+  - Maintain the relationship while resolving the issue
+
+  Scenario 4 — US customer (direct, escalation-ready):
+  "I need this resolved today. If your system is broken, get me
+  someone who can fix it. I've been going back and forth for a week
+  and I'm done with the runaround."
+  - Respond to the direct communication style
+  - Assess whether escalation is actually needed or if faster
+    resolution at current tier is the real request
+  - Write the appropriate response
+
+  Part 3: Building cultural competency
+  1. Training agents on cultural signals
+  2. Regional escalation path adaptations
+  3. Language and tone calibration
+  4. When cultural sensitivity conflicts with company policy
+
+assertions:
+  - type: llm_judge
+    criteria: "The Japanese customer's indirect dissatisfaction is correctly read — the polite response is interpreted as unresolved dissatisfaction, and proactive follow-up is offered"
+    weight: 0.30
+    description: "Indirect communication interpretation"
+  - type: llm_judge
+    criteria: "The German customer receives structured, precise responses — the reply matches their communication style with clear action items and timelines"
+    weight: 0.25
+    description: "Process-oriented response matching"
+  - type: llm_judge
+    criteria: "The Brazilian customer's relationship context is respected — the response doesn't skip to resolution but acknowledges the loyalty story before addressing the issue"
+    weight: 0.25
+    description: "Relationship-first respect"
+  - type: llm_judge
+    criteria: "Cultural adaptation doesn't mean lowering standards — all customers get quality resolution regardless of communication style"
+    weight: 0.20
+    description: "Consistent quality across cultures"

package/courses/customer-support-escalation/scenarios/level-3/escalation-automation.yaml

@@ -0,0 +1,82 @@
+meta:
+  id: escalation-automation
+  level: 3
+  course: customer-support-escalation
+  type: output
+  description: "Design escalation automation — create rules, workflows, and AI-assisted routing that handle routine escalations automatically while preserving quality"
+  tags: [support, escalation, automation, workflows, routing, advanced]
+
+state: {}
+
+trigger: |
+  Automation can handle the mechanics of escalation — routing,
+  notification, SLA tracking, and documentation — freeing agents
+  to focus on the human elements: empathy, judgment, and creative
+  problem-solving.
+
+  Part 1: Escalation automation opportunities
+  1. Auto-routing based on ticket category and complexity
+  2. SLA-triggered escalation (auto-escalate at threshold)
+  3. Sentiment-based routing (angry → senior agent)
+  4. Skill-based routing (technical → technical specialist)
+  5. Priority-based routing (VIP → priority queue)
+  6. Notification automation (alert teams, update customers)
+
+  Part 2: Design escalation automation for a support platform
+
+  For a SaaS company using Zendesk, design the following
+  automation rules:
+
+  1. Auto-escalation rules:
+     - SLA-triggered: When a ticket reaches 80% of SLA time,
+       automatically escalate to next tier
+     - Keyword-triggered: When customer uses "lawyer," "lawsuit,"
+       "attorney," auto-route to legal queue
+     - Repeat-contact: When a customer contacts 3+ times about
+       the same issue, auto-escalate to senior agent
+     - Revenue-triggered: When the ticket is from a customer with
+       ARR > $50K, auto-route to VIP queue
+
+     For each rule: define the trigger condition, the action,
+     exceptions, and potential false positive handling.
+
+  2. Notification workflows:
+     - Agent notification when assigned an escalation
+     - Manager notification when SLA is at risk
+     - Customer notification when escalation is created
+     - Team notification when crisis-level escalation triggers
+     - Daily digest of open escalations for team leads
+
+     For each: define timing, channel, content, and recipients.
+
+  3. Escalation routing decision tree:
+     Design an automated routing decision tree that examines:
+     - Ticket category → appropriate team
+     - Customer tier → priority level
+     - Issue severity → urgency level
+     - Agent availability → assignment
+     - Time of day → on-call routing
+
+  4. Quality safeguards:
+     - When should automation be overridden by human judgment?
+     - How to handle edge cases that don't fit rules?
+     - Monitoring for automation errors (wrong routing)
+     - Regular audit of automation effectiveness
+
+assertions:
+  - type: llm_judge
+    criteria: "Automation rules include false positive handling — the keyword trigger for 'lawyer' won't auto-escalate a customer saying 'I'm a lawyer by profession'"
+    weight: 0.30
+    description: "False positive handling"
+  - type: llm_judge
+    criteria: "The routing decision tree is comprehensive — it considers category, customer tier, severity, availability, and time of day in a logical sequence"
+    weight: 0.25
+    description: "Comprehensive routing logic"
+  - type: llm_judge
+    criteria: "Quality safeguards preserve human judgment — automation handles mechanics but humans can override when edge cases don't fit the rules"
+    weight: 0.25
+    description: "Human override preservation"
+  - type: llm_judge
+    criteria: "Notification timing is appropriate — urgent notifications are immediate while digest summaries are daily, not everything is treated as urgent"
+    weight: 0.20
+    description: "Appropriate notification timing"

package/courses/customer-support-escalation/scenarios/level-3/escalation-metrics-reporting.yaml

@@ -0,0 +1,87 @@
+meta:
+  id: escalation-metrics-reporting
+  level: 3
+  course: customer-support-escalation
+  type: output
+  description: "Build escalation metrics and reporting — track escalation rates, quality, outcomes, and trends to drive continuous improvement"
+  tags: [support, escalation, metrics, reporting, analytics, advanced]
+
+state: {}
+
+trigger: |
+  What gets measured gets managed. An escalation metrics program
+  provides visibility into escalation health, identifies trends,
+  and proves the ROI of improvement initiatives.
+
+  Part 1: Core escalation metrics
+  Design a comprehensive escalation metrics framework:
+
+  1. Volume metrics:
+     - Escalation rate (% of tickets escalated)
+     - Escalation rate by tier (L1→L2, L2→L3, to management)
+     - Escalation rate by channel (chat, email, phone)
+     - Escalation rate by agent
+     - Escalation rate by issue category
+     Define targets and benchmarks for each.
+
+  2. Quality metrics:
+     - Escalation accuracy (was escalation necessary?)
+     - Documentation completeness score
+     - Routing accuracy (sent to correct team?)
+     - De-escalation attempt rate (tried before escalating?)
+     Define scoring criteria and target scores.
+
+  3. Outcome metrics:
+     - Time to escalation (how long before agent escalates)
+     - Time to resolution after escalation
+     - Re-escalation rate (escalated again after first attempt)
+     - Customer satisfaction for escalated tickets vs. non-escalated
+     - Churn rate for escalated customers
+     Define targets and benchmarks.
+
+  4. Trend metrics:
+     - Escalation rate trend (weekly, monthly, quarterly)
+     - New escalation categories emerging
+     - Seasonal patterns in escalation
+     - Correlation with product releases, outages, promotions
+
+  Part 2: Build reporting dashboards
+
+  1. Agent-level dashboard:
+     What does an individual agent see about their own escalation
+     performance? Design the view with specific metrics, comparisons,
+     and improvement suggestions.
+
+  2. Manager-level dashboard:
+     What does a support manager need for weekly team review?
+     Design the view with team aggregates, individual outliers,
+     and trend analysis.
+
+  3. Executive-level dashboard:
+     What does the VP of Support present to leadership quarterly?
+     Design the view focusing on business impact, improvement
+     trends, and resource needs.
+
+  Part 3: Using metrics to drive improvement
+  1. Identifying training needs from metrics
+  2. Justifying headcount or tool investment
+  3. Proving escalation program ROI
+  4. Setting realistic improvement targets
+
+assertions:
+  - type: llm_judge
+    criteria: "Metrics cover volume, quality, outcomes, and trends — the framework isn't just 'escalation rate' but a multi-dimensional view"
+    weight: 0.30
+    description: "Multi-dimensional metrics framework"
+  - type: llm_judge
+    criteria: "Dashboards serve different audiences — agents see their own performance, managers see team health, executives see business impact"
+    weight: 0.25
+    description: "Audience-appropriate dashboards"
+  - type: llm_judge
+    criteria: "Benchmarks and targets are provided — each metric has a reasonable target and industry benchmark for comparison"
+    weight: 0.25
+    description: "Benchmarked metrics"
+  - type: llm_judge
+    criteria: "Metrics connect to actionable improvements — the framework shows how to use data to identify training needs and justify investment"
+    weight: 0.20
+    description: "Actionable metrics usage"

package/courses/customer-support-escalation/scenarios/level-3/escalation-process-design.yaml

@@ -0,0 +1,76 @@
+meta:
+  id: escalation-process-design
+  level: 3
+  course: customer-support-escalation
+  type: output
+  description: "Design a complete escalation process — create the policies, workflows, decision trees, and documentation standards for a support organization"
+  tags: [support, escalation, process-design, policy, workflow, advanced]
+
+state: {}
+
+trigger: |
+  A well-designed escalation process turns individual judgment
+  calls into consistent, repeatable procedures. It gives agents
+  confidence to make decisions and ensures customers receive
+  predictable, quality experiences.
+
+  Design the complete escalation process for "CloudOps" — a B2B
+  SaaS company with:
+  - 100 support agents (75 L1, 20 L2, 5 L3)
+  - 4 specialist teams (billing, technical, security, compliance)
+  - 15,000 tickets/month
+  - Customer tiers: Starter, Professional, Enterprise
+  - Current escalation rate: 28% (target: 18%)
+
+  1. Escalation policy document:
+     - Purpose and scope
+     - Escalation types and definitions
+     - Authority levels by tier (what each tier can do)
+     - Escalation criteria (when to escalate, with specific rules)
+     - SLA requirements per tier and customer level
+     - Documentation requirements
+     - Communication standards
+     - Exceptions and override procedures
+
+  2. Escalation decision tree:
+     Create a visual-friendly decision tree that agents can follow:
+     - Is this a safety/security issue? → Immediate escalation
+     - Does this exceed my authority? → Escalate to appropriate tier
+     - Has the customer requested a manager? → Attempt de-escalation
+       first, then escalate if requested again
+     - Am I stuck after X minutes? → Escalate with documentation
+     Include at least 8 decision points with clear paths.
+
+  3. Escalation templates:
+     Create standardized templates for:
+     - L1 → L2 escalation note
+     - L2 → L3 escalation note
+     - Escalation to management
+     - Customer escalation acknowledgment
+     - Customer escalation update (in progress)
+     - Customer escalation resolution
+     Each template should be practical and easy to fill out.
+
+  4. Escalation governance:
+     - Weekly escalation review meeting agenda
+     - Monthly escalation quality audit process
+     - Quarterly escalation process improvement cycle
+     - Annual escalation policy review and update
+
+assertions:
+  - type: llm_judge
+    criteria: "The escalation policy covers authority levels clearly — each tier knows exactly what they can and cannot do, eliminating ambiguity"
+    weight: 0.30
+    description: "Clear authority levels"
+  - type: llm_judge
+    criteria: "The decision tree is practical — agents can follow it in real-time without extensive interpretation"
+    weight: 0.25
+    description: "Practical decision tree"
+  - type: llm_judge
+    criteria: "Templates reduce documentation friction — they're structured enough to ensure completeness but not so rigid that agents spend more time filling them than helping customers"
+    weight: 0.25
+    description: "Friction-reducing templates"
+  - type: llm_judge
+    criteria: "Governance includes regular review — the process is designed to evolve through weekly, monthly, quarterly, and annual review cycles"
+    weight: 0.20
+    description: "Evolving governance process"

package/courses/customer-support-escalation/scenarios/level-3/escalation-root-cause-analysis.yaml

@@ -0,0 +1,93 @@
+meta:
+  id: escalation-root-cause-analysis
+  level: 3
+  course: customer-support-escalation
+  type: output
+  description: "Perform root cause analysis on escalation patterns — identify systemic issues driving escalation volume and design interventions to address them"
+  tags: [support, escalation, root-cause, analysis, patterns, advanced]
+
+state: {}
+
+trigger: |
+  Individual escalations solve individual problems. Root cause
+  analysis of escalation patterns solves systemic problems. A
+  single RCA that eliminates a category of escalation can save
+  thousands of hours annually.
+
+  Part 1: RCA methodology for escalations
+  1. Data collection: categorize escalations by reason, team,
+     outcome, customer segment, time, agent
+  2. Pattern identification: what clusters emerge?
+  3. Root cause techniques: 5 Whys, fishbone diagram, Pareto
+  4. Intervention design: what change addresses the root cause?
+  5. Impact measurement: did the intervention work?
+
+  Part 2: Analyze escalation data and identify root causes
+
+  Dataset (last 90 days, SaaS company, 2,500 escalations):
+
+  By reason:
+  - Refund authority exceeded: 680 (27.2%)
+  - Technical beyond L1 capability: 525 (21.0%)
+  - Customer demands manager: 420 (16.8%)
+  - Policy exception needed: 310 (12.4%)
+  - Cross-department coordination: 275 (11.0%)
+  - Compliance/legal concern: 165 (6.6%)
+  - Other: 125 (5.0%)
+
+  By outcome:
+  - Resolved by L2 within SLA: 55%
+  - Resolved by L2 beyond SLA: 20%
+  - Re-escalated to L3/management: 15%
+  - Customer churned during escalation: 10%
+
+  By agent (top escalators):
+  - Agent A: 280 escalations (avg team: 100)
+  - Agent B: 250 escalations
+  - Agent C: 220 escalations
+  - Agent D: 45 escalations (lowest)
+
+  Additional data:
+  - 40% of "customer demands manager" resolved without manager
+    intervention (the L2 agent resolved it)
+  - 60% of "refund authority exceeded" were for amounts $26-$50
+    (agent limit is $25)
+  - Re-escalation rate highest for technical issues (35%)
+  - 10% churn rate during escalation = ~$250K annual revenue loss
+
+  1. Perform the analysis:
+     - Apply Pareto principle (which causes drive 80% of escalations?)
+     - Run 5 Whys on the top 3 causes
+     - Calculate the cost of each escalation category
+     - Identify the highest-ROI interventions
+
+  2. Design intervention plan:
+     - For each root cause: proposed fix, implementation cost,
+       expected escalation reduction, timeline
+     - Prioritize by ROI
+     - Identify quick wins vs. structural changes
+
+  3. Create the RCA presentation for leadership:
+     - Current state with data visualization
+     - Root causes identified
+     - Proposed interventions with expected impact
+     - Investment required vs. cost savings
+     - Implementation timeline
+
+assertions:
+  - type: llm_judge
+    criteria: "The Pareto analysis correctly identifies that refund authority and technical capability drive nearly 50% of escalations — these are the highest-ROI targets"
+    weight: 0.30
+    description: "Correct Pareto analysis"
+  - type: llm_judge
+    criteria: "The 5 Whys dig to actual root causes — refund authority limit of $25 when 60% of escalated refunds are $26-$50 points to a policy fix, not a training fix"
+    weight: 0.25
+    description: "Deep root cause identification"
+  - type: llm_judge
+    criteria: "The high-escalation agents are analyzed fairly — Agent A's 280 escalations might indicate a training need, or might indicate they handle the hardest tickets"
+    weight: 0.25
+    description: "Fair agent analysis"
+  - type: llm_judge
+    criteria: "The churn-during-escalation cost ($250K) is used to justify investment — the business case connects escalation improvement to revenue retention"
+    weight: 0.20
+    description: "Revenue-justified investment"

package/courses/customer-support-escalation/scenarios/level-3/escalation-shift-advanced.yaml

@@ -0,0 +1,79 @@
+meta:
+  id: escalation-shift-advanced
+  level: 3
+  course: customer-support-escalation
+  type: output
+  description: "Simulate an advanced escalation management shift — handle overlapping crises, resource constraints, and complex multi-thread escalation coordination"
+  tags: [support, escalation, simulation, advanced-shift, crisis, advanced]
+
+state: {}
+
+trigger: |
+  You're the senior escalation manager on a Friday afternoon.
+  Half the team is out for a holiday weekend. Multiple situations
+  are developing simultaneously.
+
+  Resources available:
+  - 2 L2 agents (one billing, one general — technical specialist
+    is on PTO)
+  - 1 team lead (available but also covering another team)
+  - Engineering on-call (but they're already handling a SEV 2)
+  - Legal team: email only, responds within 4 hours
+  - You (can handle escalations directly if needed)
+
+  Timeline of events:
+
+  2:00 PM — Developing situation:
+  Social media team alerts you: a customer's negative experience
+  thread on Reddit is gaining traction (2,000 upvotes in 3 hours).
+  The customer claims they were promised a feature during the
+  sales process that doesn't exist. Screenshots of sales emails
+  are included.
+
+  2:15 PM — Incoming escalation:
+  Enterprise customer (top 10 account, $250K ARR) reports their
+  entire data analytics module is showing incorrect numbers.
+  They're presenting to their board on Monday using this data.
+  Engineering on-call is already occupied with the SEV 2.
+
+  2:30 PM — Escalating crisis:
+  The Reddit thread has been picked up by a tech news website.
+  A reporter has emailed your press@company email asking for
+  comment. The sales VP wants to know "how did this happen?"
+
+  2:45 PM — New escalation:
+  A customer in the EU submits a GDPR erasure request. They're a
+  free trial user who also has a pending support ticket about a
+  billing error during their trial.
+
+  3:00 PM — Situation worsens:
+  The enterprise customer's CTO calls your main phone line directly
+  and is transferred to you. They're upset: "If I present wrong
+  numbers to my board, heads will roll — including the decision
+  to use your product."
+
+  Handle the full afternoon:
+  1. Prioritize all situations with reasoning
+  2. Allocate your limited resources
+  3. Write key communications for each thread
+  4. Identify what you personally handle vs. delegate
+  5. Write the end-of-day executive summary
+  6. Prepare the Monday morning handoff
+
+assertions:
+  - type: llm_judge
+    criteria: "The enterprise CTO call gets personal attention — a $250K ARR customer facing a board presentation crisis needs the senior person, not delegation"
+    weight: 0.25
+    description: "Enterprise CTO personal handling"
+  - type: llm_judge
+    criteria: "The Reddit situation is managed across PR, sales, and support — the reporter inquiry, the sales VP's question, and the customer's complaint are all addressed"
+    weight: 0.25
+    description: "Multi-team Reddit crisis management"
+  - type: llm_judge
+    criteria: "Resource constraints are acknowledged and managed — the response doesn't pretend all situations can be handled simultaneously with limited staff"
+    weight: 0.25
+    description: "Realistic resource constraint management"
+  - type: llm_judge
+    criteria: "The GDPR request isn't deprioritized despite being less urgent — the 30-day regulatory deadline is noted even while handling more immediate crises"
+    weight: 0.25
+    description: "Regulatory compliance maintained"