Use this workflow when a customer submits feedback and/or complaints.
In all cases, tag the ticket with the "feedback" label. We may build a separate feedback channel, but until then, simply mark the ZenDesk tickets for review. Our community team and support managers will work through these.
For feedback/complaints involving bugs, please follow the appropriate issues/escalation procedures and provide the customer with the created links. Advise the customer that it is best to follow/comment/participate in the issue rather than through the ZenDesk ticket. While all issues are important, product and infrastructure teams will prioritize the issues as needed, and support will not have much control of that.
For feature requests, guide the customer on how to create the issues in CE/EE. If it is not a bug, it is preferable that the customer create the issue themselves - this is especially true in cases where the app/feature is working as intended.
If a customer requests a refund, CC AR to the ZenDesk ticket if the subscription is less than 45 days old. Reply to the customer that the billing team is reviewing the refund request. If the subscription is greater than 45 days old, it does not qualify for refund. There may be special circumstances where we may refund past the 45 days - if you believe a case qualifies for this, CC a manager for approval.
There may be cases where a customer will simply be unsatisfied with all available solutions and/or steps taken to solve problems they are facing or have faced. Deescalate the situation the best you can - apologize as necessary, offer solutions or alternatives that may work. Most importantly, in this situation, allow the customer to vent and assure that their feedback is taken very seriously. In some cases, you may want to CC a manager, especially if you feel threatened or harassed.
It is important to note that apologies should be sincere - this includes not apologizing when not necessary. Phrases like "I'm sorry that you're having trouble…" can sound ingenuine and "script like". Apologies can also be seen as an admission of guilt, which should not happen when a problem is not the fault of GitLab (such as when a feature works as intended but not the way customer wants).