Support Philosophy
Table of Contents
Engineers Support Engineers
Our support team is made up of engineers who use the product daily. Not script-readers, not chatbots pretending to be humans - actual engineers who can read your code, reproduce your issue, and fix it.
Response Times
| Channel | Target Response | Escalation |
|---|---|---|
| Critical bugs (production down) | 1 hour | Immediate page to on-call |
| GitHub Issues | 24 hours | Engineering triage weekly |
| Discord | Same day | Community + team |
| 24 hours | Routed to relevant team | |
| Enterprise Slack | 4 hours | Dedicated account engineer |
Principles
1. Don’t Deflect
If someone asks a question, answer it. Don’t redirect them to docs they’ve already read, don’t ask them to “try again later,” and don’t close issues because they’re old.
If we can’t solve it immediately, we say so honestly and give a timeline.
2. Fix the Root Cause
When a support request reveals a product problem, we don’t just solve the individual case - we fix the underlying issue. Every support ticket is a signal.
- Confusing error message? Rewrite it.
- Docs missing a step? Add it.
- API returning unhelpful responses? Improve it.
3. Public by Default
Support conversations happen in public channels (GitHub, Discord) whenever possible. This means:
- Other users can find answers to the same questions
- We build a searchable knowledge base naturally
- We stay accountable - our response quality is visible
Private channels (email, Slack) are for security-sensitive issues or enterprise-specific configurations.
4. No Tiered Support Theater
We don’t have “Level 1 support” that screens issues before they reach someone who can help. The first person you talk to can solve your problem or will immediately loop in someone who can.
Escalation Path
- Community support - Discord, GitHub issues, docs
- Direct support - email, enterprise Slack
- Engineering escalation - bugs get filed directly into Linear, engineer-to-engineer
- Incident response - production-impacting issues trigger PagerDuty
Measuring Support Quality
- First response time - how fast we acknowledge the issue
- Resolution time - how fast we actually fix it
- Customer effort score - how hard did the customer have to work?
- Issues-to-improvements ratio - what percentage of support tickets led to product changes?