This document outlines our operational framework for delivering customer support. It covers our ticketing system, daily processes, queue management, and detailed handling procedures. These processes enable us to fulfill our Customer Happiness & Empowerment Policy in practice.

Support Infrastructure

Ticketing System

All support tickets are managed through Bolddesk at https://support.avaloniaui.net/. This is our single source of truth for customer issues, ensuring nothing falls through the cracks and maintaining transparency across the team.

Service Level Agreements

• Avalonia tickets: 3-day response time for customers with paid support agreements

• XPF: No formal SLA, but we prioritise based on impact and customer tier

• Accelerate: No formal SLA, but we maintain high responsiveness as a premium offering

Note: While XPF and Accelerate don't have formal SLAs, we treat all paying customers with urgency and aim to exceed expectations consistently.

Daily Operations

Morning Support Sync

Every day at 8:30am UTC we gather in the #support Slack channel to:

• Review and assign new tickets to engineers

• Check progress on existing tickets

• Identify blockers requiring escalation

• Ensure that any overdue tickets are addressed

If you regularly attend but cannot make a specific sync, please indicate this in #support. Coordination will happen asynchronously when needed. Attendance is optional but encouraged.

Engineers are encouraged to be proactive. If you can handle a ticket immediately, assign it to yourself without waiting for the sync.

Queue Monitoring Schedule

Daily Checks:

• Unassigned Tickets - Ensure new tickets are promptly assigned

• All Pending Tickets - Review tickets awaiting agent response

• Resolution Overdue Tickets - Address tickets past their resolution deadline

• Response Overdue Tickets - Catch tickets needing immediate response

Weekly Reviews:

• Waiting on Release - Check if stable releases address pending issues

• Waiting for Review - Monitor PR status for merged fixes

• Potentially Forgotten Tickets - Review tickets with no interaction for 30+ days

Support Boundaries and Scope

Protecting Support Value

We regularly receive tickets from non-paying users or paying customers asking questions outside their support scope. While we'd genuinely like to help everyone, providing free support through our dedicated portal undermines the value of our paid offerings and isn't sustainable.

Common out-of-scope scenarios:

• Non-customers attempting to open tickets

• Accelerate customers asking general Avalonia development questions

• XPF customers seeking help with unrelated Avalonia features or generalised cross-platform development assistance

• Community users expecting enterprise-level support

Handling Out-of-Scope Requests

When you encounter these situations:

1. Do not provide technical assistance - Even well-intentioned help sets a precedent that devalues our support tiers

2. Use appropriate canned responses - We maintain templates that politely but firmly explain support boundaries

3. Redirect to appropriate channels - Point non-customers to GitHub, documentation, or sales for support options

4. Close tickets promptly - Don't leave these open as they create false metrics and expectations

Key message to convey: "Your request falls outside the scope of support available to you. This isn't about not wanting to help, it's about maintaining the integrity and value of our support offerings for all customers."

For Accelerate customers asking general Avalonia questions, remind them their support covers Accelerate-specific features and issues, not general framework development assistance.

Ticket Handling Process

1. Validation Phase

Before engaging with any ticket, verify customer eligibility:

• XPF customers: Full support for XPF issues only

• Accelerate customers: Full support for Accelerate issues only

• Avalonia customers: Support only with active paid agreement

For customers without appropriate support agreements or asking out-of-scope questions, use the relevant canned response and close the ticket respectfully.

2. Information Gathering

Ensure tickets contain:

• Clear problem description

• Error messages or unexpected behaviour

• Reproduction code or steps

• Software versions

• Environment details

If information is missing, request specifics and set status to "Waiting on Customer." Close tickets after approximately one month of non-response.

3. Active Resolution

Initial Response:

• For straightforward issues: Provide immediate assistance

• For complex issues: Send acknowledgment using canned response or personalised message

• Update status to "In Progress" when work begins

Engineering Coordination: When development work is required:

1. Create GitHub issue in appropriate repository

2. Link bidirectionally (ticket ↔ GitHub issue)

3. Assign both to responsible engineer

4. Use PR link field when fixes are submitted

4. Documentation Requirements

Private Notes should capture:

• Current blockers or investigation status

• Build availability for testing

• Decision points requiring input

• Development milestones

Customer Communication:

• Provide regular updates on longer-running issues

• Share CI builds when available and appropriate

• Confirm resolution before closing

5. Resolution States

• "Solved" - Customer confirms fix works

• "Waiting on release" - Customer prefers stable version

• "Waiting on Customer" - Pending customer validation

6. Time Tracking

Log all time spent in Bolddesk's worklog feature:

• Minimum 15-minute increments

• Include investigation, development, and communication time

• This data informs support contract value and resource planning

Tools and Resources

Communication Channels

• Bolddesk: Primary ticket management

• GitHub: Issue tracking and code changes

• Slack #support: Team coordination and escalation

Canned Responses

We maintain templates for common scenarios:

• No Support Agreement

• Out of Scope Request

• General ticket acknowledgement

• Information request

• Resolution confirmation

These ensure consistency while allowing personalisation where appropriate.

CI/Build Access

Engineers can provide CI builds to customers with appropriate agreements for pre-release validation. This accelerates resolution and builds confidence in our fixes.

Code Sharing Guidelines

'As-Is' Provision Principle

All code shared with customers, whether sample projects, workarounds, proof-of-concepts, or advanced control implementations, is provided strictly "as-is" with no warranty or ongoing support obligations.

Required Disclaimers

When sharing any code with customers, you must explicitly state:

• The code is provided as-is without warranty

• We cannot provide ongoing support for this specific implementation

• The customer assumes full responsibility for integration and maintenance

• Future product updates may require modifications to the shared code

Common Scenarios

• Sample Projects and Workarounds: When providing sample code to demonstrate a solution, always preface with: "This sample is provided as-is to illustrate the approach. While it addresses your immediate need, we cannot provide ongoing support for this specific implementation."

• Early Access to Advanced Controls: When sharing proof-of-concepts or source code for features not yet in our products: "We're sharing this early proof-of-concept as a gift to help you move forward. Please understand this is experimental code provided as-is. We cannot offer support for integration or maintenance of this code, and it may require significant changes when officially released."

• Custom Solutions: For complex workarounds or customer-specific implementations: "This solution is tailored to your specific case and provided as-is. While it should address your requirements, your team will need to maintain and adapt it as your needs evolve."

Documentation Best Practices

• Include the disclaimer directly in the ticket response, not just in code comments

• Save a copy of shared code in the ticket's private notes for reference

• Note explicitly what version of Avalonia/XPF/Accelerate the code was tested against

• Consider adding a header comment in the code itself stating the as-is nature

What This Protects

This policy ensures:

• Customers have realistic expectations about ongoing support

• We don't create implicit support contracts for custom code

• Engineering time remains focused on product improvements

• We can still be generous with sharing knowledge without creating unsustainable obligations

Being clear about boundaries allows us to be more generous within them. We can share more code and creative solutions when customers understand the terms.

Escalation and Empowerment

Remember that under our Customer Happiness & Empowerment Policy, you have authority to:

• Extend support temporarily for struggling teams

• Add complimentary seats when resolving issues

• Apply account credits for Accelerate customers

• Coordinate care packages through Marlene

Use these tools when they help restore trust or demonstrate our commitment to customer success.

Continuous Improvement

This process is not static. We regularly review:

• Average resolution times

• Customer satisfaction scores

• Common issue patterns

• Process bottlenecks

Suggest improvements in #support or during team meetings. Every interaction teaches us something about how to serve customers better.