Feature Requests and Issue Reporting
What is the Difference Between a Feature Request and an Issue Report?
Feature Requests - An idea which you would like implemented into our products.
Issues - a fault found on one of the applications.
How to Keep Track of your Requests
You can keep track of the issues, feature requests, or simple questions you may have raised.
View my requests (Login to Customer Portal in order to see the tickets you have raised, if you do not have access please contact your Product Specialist).
Reporting an Issue
An issue is a defect on the Redbox Management website, app or terminal that causes it to behave in an unexpected way or produce an incorrect result. Some examples of typical issues:
A link is 'broken' and takes the user to a page that doesn't exist.
Submitting a form produces an error message.
A 'price calculator' returns an incorrect calculation.
An element that was present on a design or wireframe (that was signed-off) is missing.
A date is formatted incorrectly for the user's locale (e.g. is in US format whereas it should be UK).
A word is spelled incorrectly.
Often, there can be a certain amount of ambiguity as to what an issue actually is. For example, whether something is working "correctly" can be debatable if a feature is not accurately defined in the project specification or the designs are ambiguous. However, some things certainly are not issues. For example:
I don't like this being blue, can you change it to red (where it was blue in the designs).
Can we add x feature here.
How do I do this?
Make this logo bigger.
Writing an Effective Issue Report
Writing an accurate issue report is key to it being effective. Although some issues may be very obvious to the observer, often there are a number of factors that will cause a defect to occur inconsistently. Communicating your experiences in a succinct manner is crucial to making the issue as easy as possible to reproduce and therefore fix.
The classic example of a poorly written issue summary or description is "This doesn't work". This is unhelpful as it might not be obvious how the feature is broken or what caused it to break in your specific circumstances. Different web browsers or even taking different steps can cause an issue to occur so it is important to give as much information as possible.
So how do we write an effective issue description? The key is to be accurate and descriptive with your information and not make any assumptions.
Where Did the Issue Occur?
Sometimes a widget that works on one page can fail on another. Provide a URL of the page it occurred—just copy it from the address bar of your browser, this can sometimes contain really important information. If you are using a mobile app, let us know which screen of the app has the issue.
What did you Expect to Happen?
If you click a link and expect to be taken to a certain page then mention the expected page. Stating the "wrong page" isn't as helpful as saying the "contact us page". If you entered a value into a field and clicked "calculate" and got the wrong answer, what did you expect the value to be? What did you enter into the field?
What Actually Happened?
Tell us exactly what happened, not "it didn't work". If there's an error message, what was it? It may look like gibberish but developers understand that gibberish. Can't describe something in words? Take a screenshot and attach it to the issue report. This can be exceptionally useful if the defect is visual in nature.
Steps to Reproduce
Obviously, we don't need to know that you had a cup of tea before clicking a link that caused the issue but if you did anything else on the page (especially if it's related) then mention that. If you clicked a particular button (where there are several), mention that. Put yourself in the developer's shoes - they have to re-create your experience so be as descriptive as possible. If possible, re-create the issue yourself. This will allow you to identify the steps you took and make it easier to describe them. This is particularly important if the issue occurs in a system that is reasonably complex such as a lengthy form. Reproducing the issue yourself will also provide insight as to whether the issue is easily reproducible as it might not happen consistently and you will get a better idea of what you did that caused it to occur.
Provide Technical Information
We need to know where the issue occurred, so was it on the Android app, iOS app, website, or management portal? Which web browser you are using is probably the most important piece of information you can provide if the issue was on the website or the management portal. Whether or not you are using a PC or Mac, iPhone, iPad or Android device is also important information.
Avoid Duplication
You can login to the Customer Portal to view the tickets you have already raised and avoid duplication.
How to raise an issue
Visit our Customer Portal (Redbox Support).
Login
Choose one of the options provided (for issues please select Report an Issue)
Fill in the form, make sure you include all the information required for us to reproduce the issue so we can understand what might have caused it
Click Send
Once you raise your issue, you will receive a confirmation email
You will be able to view all the tickets you have raised, by visiting the Customer Portal
You will need to have access to our Customer Portal in order to use our Support System. If you do not have access to our Customer Portal, please contact your Product Specialist.
Requesting a feature
Before making a feature request, please make sure that we do not have an existing function which would support your suggestion or that the function is not broken, in which case you would need to report an issue. If you would like advice on this, please speak to your Product Specialist.
Writing an effective feature request
The goal of the Feature Request is to provide information and communicate what features are needed to improve the product, how useful those features would be, and which features are in development for implementation. The first step in this process is making the Feature Request, and we do this in the format of the User Story. A User Story is a simple, straightforward statement of what you (the user) want to be added to the product (the feature) and why (the benefit) so that other users and our development team can easily understand the request and consider whether they want to spend a vote on that feature.
Please keep it short and simple, and focus on keeping your request clear and concise.
The WHY is important. When you’re writing your feature request, one important thing to remember is that it should be about the problem you’re experiencing, not about offering a specific solution to the problem that you’ve already got in mind. Our best solutions are found when we are able to deeply understand the problems our customers face.
How to make a feature request
Visit our Customer Portal (Redbox Support).
Login.
Choose one of the options provided (for feature requests please select Suggest Feature).
Fill in the form, make sure you include all the information and feel free to include inspirations.
Select Send.
Once you raise your feature request, you will receive a confirmation email.
You will be able to view all the tickets you have raised, by visiting the Customer Portal.
You will need to have access to our Customer Portal in order to use our Support System. If you do not have access to our Customer Portal, please contact your Product Specialist.