...
Priority: We need to set priority for bugs for us to understand how much functionality is affecting and the impact of it. The scale and corresponding Service Level Objectives are as follows:
...
Issue Priority
...
Definition
...
Time to First Response
...
Resolution Time
...
Fire
...
Impacting core functionality (offers, loyalty, ordering, sign-in) for a significant (>5%) number of users or otherwise bringing significant risk to the market (security breach, GDPR, etc)
...
15min
...
24h
...
High Priority
...
Issues Types and SLOs
Affected function: | Priority | |||
Fire | High | Medium | Low | |
| Insurmountable Error affecting >10% of Users | Insurmountable Error affecting >1% of Users | Surmountable Error affecting >10% of Users | Surmountable Error(s) affecting >1% of users |
CRM (Analytics) | CRM system down or impact in compliance | Degraded analytical accuracy affecting *key funnels | Degraded analytical accuracy affecting multiple events | Degraded analytical accuracy limited to specific events or properties |
CRM (Engagement) | Issues with marketing campaigns may be opened as a fire by default. RBI may downgrade to lower priority based on guest impact (as described above under 1st row). However, tech support will consider the duration of the campaign and endeavor to resolve the issues before the campaign ends. | |||
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
Issue Priority | Time to First Response | Resolution Time |
|---|---|---|
Fire | 15min | 24h |
High Priority | 1h | 1 week |
Medium Priority |
Impacting non-core functionality for many users or transient impact on core functionality
24h | 3 weeks | |
Low Priority | 24h | 6 weeks |
Resolution SLOs are measured against business days (Mon to Fri during working hours) with the exception of High Priority
...
Has a surmountable impact on the user experience for a significant majority of users
...
24h
...
and Fire tickets, which are measured against natural days (Mon to Sun) due to their higher urgency.
Tech Support: 3 strike rule
When troubleshooting your bug ticket, please note that we always test to replicate your reported behavior. When we can no longer reproduce /validate your issue, we heavily rely on your help, to progress the investigation. As soon as we need your feedback we move the ticket to a pending state and wait for further confirmation.
If no help is provided to our Technical experts, our team is stuck and cannot assess your bug as being present. To this extent, please note that if we have initiated 3 attempts to clarify your bug ticket (in 3 distinct days) and if we lack progress, we will close the case directly on the 4th attempt. You can always open a new ticket and reference your closed ticket so that our team resumes investigation.
You can always refer to our escalation process if you feel our work can or needs improving.
How to escalate a bug ?
If you feel your reported IREQ ticket (for Bugs and Fires) does not get the proper attention and/or is not heading towards a satisfactory resolution, please raise an escalation via intl.techsupport.escalations@rbi.com.
This action will create extra awareness to Intl Tech Support Management team.
Escalating to intl.techsupport.escalations@rbi.com is possible when you have an open/closed IREQ and you want to either pass feedback for improvement or raise awareness for a speedy resolution.
Prior to sending an escalation (for IREQ tickets ) please always ensure you’ve updated the ticket beforehand, and that progress continues to be either slow or no visible resolution in sight (in danger of breaching the above mentioned SLO’s). Also, when sending your escalation please mention the IREQ ticket number and reason for escalation.
| Note |
|---|
Please note that intl.techsupport.escalations@rbi.com is not an alternative to open IREQs. |