Handling Feature Requests

Modified on Tue, 27 Oct at 5:59 PM

TABLE OF CONTENTS

Overview

We love receiving customer feedback and ideas for new features. This has always been and always will be a driving factor for the success of Cloud Retailer.


Occasionally, we can put some of these requests into production quickly, while others may never make it there. While we strive to meet the needs and wants of our customers, there are many factors that play into which features are adopted and when.


For any new feature in Cloud Retailer, we have to evaluate the full life-cycle of the change: designing it, building it, testing it, documenting it, and supporting it in every release after that, for every store. Because of these factors, not all requests will be approved. This article explains how to submit a request, the criteria we use to decide which requests we build, and what happens when a request is declined.


How do I submit a feature request?

You can enter your request in the Feature Requests section of the helpdesk. Please note that you must be logged into the support portal to access this feature and log a request.


This section allows other customers a chance to upvote feature requests they want as well and gives us a way to measure interest in a feature.


  1. Search first. If someone has already asked for the same thing, upvote their post with the Do you have this question too? link and add a reply describing how it would help your store.
  2. If nobody has asked yet, start a new post and tell us:
    • whether it is for the Back Office or the POS;
    • what you want it to do;
    • why you want it, with a real example from your store;
    • how critical it is to your business, and roughly how much time or money it would save;
    • what you do today instead, if anything.
  3. Add a screenshot of the screen you have in mind, if you can.


For more guidelines on logging your feature request, check out Submitting and upvoting Cloud Retailer Feature Requests.


How do we decide which requests to build?

Every request is reviewed against the criteria below. A request doesn't have to score well on all of them, but one that falls short on several is unlikely to be built.


#CriterionThe question we ask
1ReachHave multiple stores asked for this, or something like it? Will it help most of our customers, not just one? Having multiple customers request the same feature tells us that this is something people really want and can bring more immediate value for multiple users.
2Business impactDoes it remove a real pain point? Is there a clear, real-world example of the problem? Saving labor, preventing lost sales or shrink, keeping a store compliant, or ending a question stores regularly have to call us about counts for more than convenience.
3Existing alternativeCan you already get the same result another way, with a setting, a report filter, tags, a worksheet or a different workflow? If so, we will usually show you that way instead of building a second one.
4Fit with the productWill it keep Cloud Retailer easy to use for everyone? If a change helps one store but adds extra steps or clutter for every other store, or works differently from the rest of the system, it is not a good fit.
5Effort and riskHow large is the change, and what could it break? A request that needs changes in several parts of the system, or that touches the sale, payments, taxes, inventory costing or syncing between registers and the Back Office, needs much more design and testing than a change to a report.
6Long-term supportCan our whole support team understand, explain and troubleshoot it for years to come, and can it be documented clearly? A feature that only one person could support, or that depends on an outside service we don't control, carries a cost long after it's implemented.
7Security and complianceWould it weaken the protection of card data, customer information or employee permissions, or make it harder for stores to follow tax and alcohol sales rules? We will not build a request that does.


On the flip side, if there is only a single request for a more involved change, it may not make the cut, or it may take some time to make its way in. In the end, we must always consider what is best for all users.


NOTE: We often look for a broader version of a request that solves the same problem for more stores. For example, a request to allow only cash for one type of product might be built as a general way to limit which tenders any product can use. The result may look a little different from what you asked for, but it will still solve your problem.


What can happen to my request?

  • Already possible. Cloud Retailer can already do this, or something close to it. We will show you how.
  • Need more information. We don't yet understand the problem well enough to judge it. We will ask you questions on your post.
  • Planned. The request meets the criteria and is on our development list. We can't promise a release date, because the design, building and testing work varies for each request.
  • Future Consideration. It's a fair idea, but it doesn't fit into our current plans, so it isn't something we will work on for now. We will keep it on file and may review it again in the future.
  • Declined. We have decided not to add it to the product. We will tell you why it didn't meet our criteria.


Can a declined request be reconsidered?

Yes. A decision is based on what we know at the time. If more stores ask for the same thing, or you can show us an impact we didn't see (a compliance requirement, or a measurable cost to your store), reply on the post and we will review it again.


How do I find out when new features are released?

Be sure to watch for new features as they are released by checking out the Release Notes Forum.


Questions about a request? Contact us at support@cloudretailer.com or 320-230-2282.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article