Support Resolution
Purpose
To resolve customer and community support requests consistently, with clear response time expectations and a closed feedback loop.
Owner
Predrag Tasevski — Community & Integrations
Trigger
This process starts when a support request arrives — via FreeScout (email), Discord (#support), Matrix, or GitHub Issues.
Steps
- Ticket created — All support requests are centralised in FreeScout. Requests arriving via Discord or Matrix are copied to FreeScout by Alexander as a new conversation. GitHub Issues that are support requests (not bug reports) are also logged. \\Tool: FreeScout
- Triage (within 4 business hours) — Alexander triages the ticket: Is it a bug, a feature request, or a usage question? Assigns a label and priority (P0 critical / P1 high / P2 normal). \\Tool: FreeScout
- First response (within 1 business day) — Alexander sends an acknowledgement and initial response. For usage questions: answer directly or link to documentation. For bugs: confirm reproduction and log in GitHub Issues. \\Tool: FreeScout, GitHub
- Resolution — For usage questions: close the ticket once the customer confirms resolution. For bugs: Peter reviews and schedules a fix. Alexander notifies the customer of the expected fix timeline. \\Tool: FreeScout, GitHub
- Close and log — Ticket marked resolved in FreeScout. If the issue reveals a documentation gap, Alexander opens a documentation task in OpenProject. If the issue reveals a product gap, it goes on the Issues List. \\Tool: FreeScout, OpenProject
Response Time Targets
| Priority | First Response | Resolution Target |
|---|---|---|
| P0 — Critical (data loss, auth failure, outage) | 2 hours | 24 hours |
| P1 — High (feature broken, workaround available) | 4 business hours | 3 business days |
| P2 — Normal (usage question, minor issue) | 1 business day | 5 business days |
Tools
- FreeScout — primary support inbox
- GitHub Issues — bug tracking
- Discord / Matrix — community support channels
- OpenProject — documentation and product improvement tasks