This procedure details how to deal with user requests for support.
The goal is to maximise the user satisfaction with the use of the Yield Protocol, particularly when obtaining unexpected outcomes, while taking into account the limited availability of support resources.
- As soon as a request for support is voiced in any of the available channels (Discord), a support operator will take ownership of it. The goal is to acknowledge to the user their support request, and to make him aware of the process to resolution.
- The support operator/s will be defined by a rota system. If there aren't enough support operators to provide 24/7 support, the supported time periods will be pinned on Discord.
- The support operator will direct the affected user to a DM channel and keep all issue information private to the Yield team.
- The support operator will triage the issue, and log it in the support log, giving the support log id to the user.
- If the issue can be confirmed as an ongoing threat of loss of funds for the users or the protocol, or a one-time loss of more than $100,000 the support operator will invoke the Emergency Procedure (link).
- If the issue is localized to one user and doesn't threaten a further loss of funds, the support operator will try to solve it. For that he can refer to the knowledge base of known issues and solutions (link). The user will be informed that he will be contacted for further steps no longer than 4h from this time.
- The user will be informed that losses due to the fault of the protocol will be reimbursed after the resolution of the issue for up to $1,000 for individual request, and $10,000 for an issue that is repeated over time to several users. User losses beyond those limits will be decided by governance.
- If the support operator is unable to work towards a resolution, this will be communicated to the user, and a timeframe for a further update will be given, of no more than 24h.
- Alternatively, the issue can be handed over to another willing support operator. The user will be informed of this and the new operator will introduce himself to the user.
- If the support operator can't solve the issue, the user will be informed that the issue is being escalated to frontend/backend engineering, and that an update will be given no later than 24h from this time. This escalation doesn't require the escalation engineer to be woken up. The knowledge base of know issues will be updated to reflect the new issue.
- For an escalated support issue, the escalation engineer will introduce himself to the user, describe the issue as he understands it for confirmation, and give the user a time estimate for the next update based on workload and estimated complexity of the issue.
- Regular updates on progress will be given to the user no more than 24h apart, with an expectation for the time of the next update.
- Upon resolution, the user will be informed of the status, and the knowledge base of know issues will be updated with the resolution or workaround.