Captures ticket resolution delays, misdiagnoses, escalation gaps, SLA breaches, knowledge gaps, and customer churn signals to enable continuous support improvement. Use when: (1) A ticket is resolved late or incorrectly, (2) An SLA breach occurs, (3) A customer reopens a ticket, (4) An escalation pathway fails, (5) A knowledge base search returns no results, (6) CSAT scores drop below threshold, (7) A churn signal is detected in customer communication.
Log support-specific learnings, ticket issues, and feature requests to markdown files for continuous improvement. Captures resolution delays, misdiagnoses, escalation gaps, SLA breaches, knowledge base gaps, and customer churn signals. Important learnings get promoted to KB articles, troubleshooting trees, escalation matrices, or canned responses.
Before logging anything, ensure the .learnings/ directory and files exist in the project or workspace root. If any are missing, create them:
mkdir -p .learnings
[ -f .learnings/LEARNINGS.md ] || printf "# Support Learnings\n\nResolution delays, misdiagnoses, escalation gaps, SLA breaches, knowledge gaps, and churn signals captured during support operations.\n\n**Categories**: resolution_delay | misdiagnosis | escalation_gap | knowledge_gap | sla_breach | customer_churn_signal\n**Areas**: triage | diagnosis | resolution | follow_up | documentation | escalation\n\n---\n" > .learnings/LEARNINGS.md
[ -f .learnings/TICKET_ISSUES.md ] || printf "# Ticket Issues Log\n\nRecurring ticket problems, resolution failures, SLA breaches, and escalation breakdowns.\n\n---\n" > .learnings/TICKET_ISSUES.md
[ -f .learnings/FEATURE_REQUESTS.md ] || printf "# Feature Requests\n\nSupport tooling, automation, and workflow improvement requests.\n\n---\n" > .learnings/FEATURE_REQUESTS.md
Never overwrite existing files. This is a no-op if .learnings/ is already initialised.
Do not log customer PII, account credentials, or internal auth tokens. Use ticket IDs and anonymised references. Prefer short summaries over verbatim customer messages.
If you want automatic reminders, use the opt-in hook workflow described in Hook Integration.
| Situation | Action |
|---|---|
| Repeat ticket from same customer | Log to .learnings/TICKET_ISSUES.md with resolution_delay or misdiagnosis |
| CSAT score drops below threshold | Log to .learnings/LEARNINGS.md with category customer_churn_signal |
| SLA breach on any priority ticket | Log to .learnings/TICKET_ISSUES.md with sla_breach details |
| Misdiagnosis leads to wrong fix | Log to .learnings/TICKET_ISSUES.md with misdiagnosis root cause |
| KB search returns no results | Log to .learnings/LEARNINGS.md with category knowledge_gap |
| Escalation to engineering fails | Log to .learnings/LEARNINGS.md with category escalation_gap |
| Customer uses churn language | Log to .learnings/LEARNINGS.md with category customer_churn_signal |
| Recurring ticket pattern (3+) | Link with **See Also**, consider priority bump |
| Broadly applicable resolution | Promote to KB article, troubleshooting tree, or canned response |
| Reusable triage workflow | Promote to escalation matrix or runbook |
OpenClaw is the primary platform for this skill. It uses workspace-based prompt injection with automatic skill loading.
Via ClawdHub (recommended):
clawdhub install self-improving-support
Manual:
git clone https://github.com/jose-compu/self-improving-support.git ~/.openclaw/skills/self-improving-support
OpenClaw injects these files into every session:
~/.openclaw/workspace/
├── AGENTS.md # Multi-agent workflows, delegation patterns
├── SOUL.md # Behavioral guidelines, personality, principles
├── TOOLS.md # Tool capabilities, integration gotchas
├── MEMORY.md # Long-term memory (main session only)
├── memory/ # Daily memory files
│ └── YYYY-MM-DD.md
└── .learnings/ # This skill's log files
├── LEARNINGS.md
├── TICKET_ISSUES.md
└── FEATURE_REQUESTS.md
mkdir -p ~/.openclaw/workspace/.learnings
Then create the log files (or copy from assets/):
LEARNINGS.md — resolution delays, escalation gaps, knowledge gaps, churn signalsTICKET_ISSUES.md — misdiagnoses, SLA breaches, escalation failures, repeat ticketsFEATURE_REQUESTS.md — support tooling, automation, workflow improvementsWhen support learnings prove broadly applicable, promote them:
| Learning Type | Promote To | Example |
|---|---|---|
| Diagnostic pattern | KB article | "DNS resolution failures always check /etc/resolv.conf first" |
| Triage workflow | Troubleshooting tree | "Login failure decision tree: SSO vs local vs MFA" |
| Escalation insight | Escalation matrix | "Database deadlocks → DBA on-call, not general engineering" |
| Common resolution | Canned response template | "Password reset steps for enterprise SSO customers" |
| Support tone pattern | SOUL.md | "Acknowledge frustration before offering solutions" |
| Triage automation | AGENTS.md | "Auto-categorize tickets by keyword before human triage" |
| Tool configuration | TOOLS.md | "Zendesk macro for bulk SLA extension on outage tickets" |
For automatic reminders at session start:
cp -r hooks/openclaw ~/.openclaw/hooks/self-improving-support
openclaw hooks enable self-improving-support
See references/openclaw-integration.md for complete details.
For Claude Code, Codex, Copilot, or other agents, create .learnings/ in the project or workspace root:
mkdir -p .learnings
Create the files inline using the headers shown above.
Add to AGENTS.md, CLAUDE.md, or .github/copilot-instructions.md:
When support issues or patterns are discovered:
.learnings/TICKET_ISSUES.md, LEARNINGS.md, or FEATURE_REQUESTS.mdAppend to .learnings/LEARNINGS.md:
## [LRN-YYYYMMDD-XXX] category
**Logged**: ISO-8601 timestamp
**Priority**: low | medium | high | critical
**Status**: pending
**Area**: triage | diagnosis | resolution | follow_up | documentation | escalation
### Summary
One-line description of the support insight
### Details
Full context: what support situation occurred, why the outcome was suboptimal,
what the correct triage, diagnosis, or resolution approach is.
Include ticket timeline and relevant customer interaction summary (anonymised).
### Resolution Steps
**What happened:**
Brief timeline of the support interaction and outcome.
**What should have happened:**
The correct workflow or diagnosis path.
### Suggested Action
Specific KB article, escalation rule, or process change to adopt
### Metadata
- Source: repeat_ticket | csat_drop | sla_timer | ticket_reopen | escalation_failure | kb_search_miss
- Channel: email | chat | phone | portal | api
- Product Area: billing | auth | api | dashboard | integrations | infrastructure
- Customer Tier: free | starter | professional | enterprise
- Related Tickets: TKT-12345, TKT-12346
- Tags: tag1, tag2
- See Also: LRN-20250110-001 (if related to existing entry)
- Pattern-Key: misdiagnosis.dns_vs_ssl | escalation.wrong_team (optional)
- Recurrence-Count: 1 (optional)
- First-Seen: 2025-01-15 (optional)
- Last-Seen: 2025-01-15 (optional)
---
Categories for learnings:
| Category | Use When |
|---|---|
resolution_delay | Ticket took significantly longer than SLA target to resolve |
misdiagnosis | Initial diagnosis was incorrect, leading to wasted time or wrong fix |
escalation_gap | Escalation path was unclear, went to wrong team, or was delayed |
knowledge_gap | No KB article existed for a common issue; agent had to research from scratch |
sla_breach | SLA commitment was violated (first response, resolution, or update cadence) |
customer_churn_signal | Customer expressed frustration, cancellation intent, or dissatisfaction |
Append to .learnings/TICKET_ISSUES.md:
## [TKT-YYYYMMDD-XXX] issue_type_or_name
**Logged**: ISO-8601 timestamp
**Priority**: high
**Status**: pending
**Area**: triage | diagnosis | resolution | follow_up | documentation | escalation
### Summary
Brief description of the ticket issue
### Ticket Timeline
| Time | Event |
|------|-------|
| T+0h | Ticket opened by customer |
| T+Xh | First response sent |
| T+Xh | Diagnosis attempted |
| T+Xh | Escalation / resolution |
| T+Xh | Ticket closed or reopened |
### Root Cause
What in the support process caused the issue. Was it a misdiagnosis,
wrong escalation path, missing KB article, or SLA timer oversight?
### Correct Approach
What the agent should have done — the right triage, diagnosis, and
resolution path for this type of ticket.
### Customer Impact
- SLA Status: met | breached (first_response | resolution | update)
- CSAT Impact: none | minor | significant
- Reopened: yes | no
- Escalated: yes (to whom) | no
### Prevention
How to prevent this ticket issue from recurring (KB update, escalation
rule change, training material, canned response).
### Context
- Trigger: repeat_ticket | csat_drop | sla_breach | ticket_reopen | escalation_failure
- Channel: email | chat | phone | portal
- Product Area: billing | auth | api | dashboard | integrations | infrastructure
- Customer Tier: free | starter | professional | enterprise
### Metadata
- Related Tickets: TKT-12345
- Related Files: path/to/runbook.md
- See Also: TKT-20250110-001 (if recurring pattern)
---
Append to .learnings/FEATURE_REQUESTS.md:
## [FEAT-YYYYMMDD-XXX] capability_name
**Logged**: ISO-8601 timestamp
**Priority**: medium
**Status**: pending
**Area**: triage | diagnosis | resolution | follow_up | documentation | escalation
### Requested Capability
What support tool, automation, or workflow improvement is needed
### User Context
Why it's needed, what support workflow it improves, what ticket pattern it addresses
### Complexity Estimate
simple | medium | complex
### Suggested Implementation
How this could be built: Zendesk macro, Intercom workflow, Slack bot, KB template,
escalation rule, auto-categorizer, SLA monitor, CSAT survey trigger
### Metadata
- Frequency: first_time | recurring
- Related Features: existing_tool_or_workflow
---
Format: TYPE-YYYYMMDD-XXX
LRN (learning), TKT (ticket issue), FEAT (feature request)001, A7B)Examples: LRN-20250415-001, TKT-20250415-A3F, FEAT-20250415-002
When an issue is addressed, update the entry:
**Status**: pending → **Status**: resolved### Resolution
- **Resolved**: 2025-01-16T09:00:00Z
- **Action Taken**: Updated KB article / revised escalation matrix / created canned response
- **Notes**: Added troubleshooting tree for DNS resolution failures
Other status values:
in_progress — Actively being investigated or remediatedwont_fix — Decided not to address (add reason in Resolution notes)promoted — Elevated to KB article, troubleshooting tree, or escalation matrixpromoted_to_skill — Extracted as a reusable skillAutomatically log when you encounter:
Repeat Ticket Patterns (→ ticket issue with repeat_ticket trigger):
Negative Sentiment in Customer Messages (→ learning with customer_churn_signal):
SLA Timer Approaching (→ ticket issue with sla_breach trigger):
Ticket Reopened (→ ticket issue with ticket_reopen trigger):
CSAT Below Threshold (→ learning with customer_churn_signal):
Knowledge Base Search Failures (→ learning with knowledge_gap):
| Priority | When to Use | Support Examples |
|---|---|---|
critical | Data loss, service outage affecting customer, security incident | Production outage for enterprise customer, data breach notification, payment processing failure |
high | SLA breach, repeated misdiagnosis, customer churn risk | P1 SLA violated, same misdiagnosis on 3 tickets, enterprise customer threatens cancellation |
medium | Knowledge gap, process improvement, escalation refinement | Missing KB article for common issue, unclear escalation path, triage category missing |
low | Documentation update, canned response refinement, minor process tweak | Typo in KB article, canned response tone adjustment, tag taxonomy cleanup |
Use to filter learnings by support domain:
| Area | Scope |
|---|---|
triage | Initial ticket classification, priority assignment, routing, auto-categorization |
diagnosis | Root cause analysis, symptom-to-cause mapping, diagnostic questioning |
resolution | Fix implementation, workaround delivery, solution verification |
follow_up | Post-resolution check-in, CSAT survey, ticket closure, reopening prevention |
documentation | KB articles, internal runbooks, troubleshooting trees, canned responses |
escalation | Routing to engineering, manager involvement, cross-team handoffs, war rooms |
When a learning is broadly applicable (not a one-off ticket), promote it to permanent support resources.
| Target | What Belongs There |
|---|---|
| KB article | Customer-facing resolution guides, FAQ entries, how-to documents |
| Troubleshooting tree | Decision-flow diagrams for diagnosis (symptom → cause → fix) |
| Escalation matrix | Team routing rules, on-call contacts, severity-based escalation paths |
| Canned response | Pre-approved reply templates for common scenarios |
| Internal runbook | Step-by-step procedures for agents handling specific issue types |
SOUL.md | Support tone and communication patterns, empathy guidelines |
AGENTS.md | Automated triage workflows, ticket routing rules |
**Status**: pending → **Status**: promoted**Promoted**: KB article (or troubleshooting tree, escalation matrix, canned response)Learning → KB article:
Three agents misdiagnosed "502 Bad Gateway" as server-side when the root cause was customer's WAF blocking our API callbacks.
Promoted to: KB article "502 Bad Gateway on API Callbacks" with symptom, common misdiagnosis, actual cause (customer WAF/firewall), and IP whitelist resolution steps.
Learning → Escalation rule:
Enterprise customer escalated to VP after three P2 tickets for the same SSO issue. Each time a different agent started from scratch with no linked history.
Promoted to: Escalation matrix rule — on 3rd ticket for same issue category from enterprise customer, auto-assign previous agent, link history, notify account manager.
If logging something similar to an existing entry:
grep -r "keyword" .learnings/**See Also**: TKT-20250110-001 in MetadataReview .learnings/ at natural breakpoints:
grep -h "Status\*\*: pending" .learnings/*.md | wc -l
grep -B5 "Priority\*\*: high" .learnings/TICKET_ISSUES.md | grep "^## \["
grep -B2 "sla_breach" .learnings/TICKET_ISSUES.md | grep "^## \["
grep -B2 "knowledge_gap" .learnings/LEARNINGS.md | grep "^## \["
Ingest recurring support patterns from simplify-and-harden into KB articles or escalation rules.
pattern_key as the dedupe key..learnings/LEARNINGS.md for existing entry: grep -n "Pattern-Key: <key>" .learnings/LEARNINGS.mdRecurrence-Count, update Last-Seen, add See Also links.LRN-... entry with Source: simplify-and-harden.Promotion threshold: Recurrence-Count >= 3, seen across 2+ customers or channels, within 30-day window.
Targets: KB articles, troubleshooting trees, escalation matrices, canned responses, SOUL.md / AGENTS.md.
Enable automatic reminders through agent hooks. This is opt-in.
Create .claude/settings.json in your project:
{
"hooks": {
"UserPromptSubmit": [{
"matcher": "",
"hooks": [{
"type": "command",
"command": "./skills/self-improving-support/scripts/activator.sh"
}]
}]
}
}
This injects a support-focused learning evaluation reminder after each prompt (~50-100 tokens overhead).
{
"hooks": {
"UserPromptSubmit": [{
"matcher": "",
"hooks": [{
"type": "command",
"command": "./skills/self-improving-support/scripts/activator.sh"
}]
}],
"PostToolUse": [{
"matcher": "Bash",
"hooks": [{
"type": "command",
"command": "./skills/self-improving-support/scripts/error-detector.sh"
}]
}]
}
}
Enable PostToolUse only if you want the hook to inspect command output for SLA breaches, escalation failures, and customer dissatisfaction signals.
| Script | Hook Type | Purpose |
|---|---|---|
scripts/activator.sh | UserPromptSubmit | Reminds to evaluate support learnings after tasks |
scripts/error-detector.sh | PostToolUse (Bash) | Triggers on SLA warnings, escalation gaps, churn signals |
See references/hooks-setup.md for detailed configuration and troubleshooting.
When a support learning is valuable enough to become a reusable skill, extract it.
| Criterion | Description |
|---|---|
| Recurring | Same ticket pattern across 3+ customers or channels |
| Verified | Status is resolved with confirmed resolution and prevention steps |
| Non-obvious | Required actual investigation or escalation to discover |
| Broadly applicable | Not customer-specific; useful across products or support tiers |
| User-flagged | User says "save this as a skill" or similar |
./skills/self-improving-support/scripts/extract-skill.sh skill-name --dry-run
./skills/self-improving-support/scripts/extract-skill.sh skill-name
promoted_to_skill, add Skill-PathIn conversation: "This keeps happening to customers", "Save this resolution as a skill", "Every agent struggles with this", "We need a runbook for this".
In entries: Multiple See Also links, high priority + resolved, knowledge_gap or misdiagnosis with broad applicability, same Pattern-Key across customer tiers.
| Agent | Activation | Detection |
|---|---|---|
| Claude Code | Hooks (UserPromptSubmit, PostToolUse) | Automatic via error-detector.sh |
| Codex CLI | Hooks (same pattern) | Automatic via hook scripts |
| GitHub Copilot | Manual (.github/copilot-instructions.md) | Manual review |
| OpenClaw | Workspace injection + inter-agent messaging | Via session tools |
.learnings/ for recent patterns in your ticket queueKeep learnings local (per-agent):
.learnings/
Track learnings in repo (team-wide): Don't add to .gitignore — learnings become shared knowledge.
Hybrid (track templates, ignore entries):
.learnings/*.md
!.learnings/.gitkeep
This skill is standalone-compatible and stackable with other self-improving skills.
.learnings/support/.learnings/INDEX.mdEvery new entry must include:
**Skill**: support
event + matcher + file + 5m_window; max 1 reminder per skill every 5 minutes.Only trigger this skill automatically for support signals such as:
ticket|sla breach|escalation|incident update|resolution noterepeat issue|handoff|kb gap|customer impactWhen guidance conflicts, apply:
securityengineeringcodingaimeta as tie-breaker.learnings/support/ in stackable mode.