Change Request Policy (Feature Requests and Amendments)

Modified on Fri, 13 Jun at 9:39 AM

You can find the Change Requests and New Features of our products here: Ignis Technologies Feature Requests

Introduction

At Ignis Technologies, we strive to continually improve our Software as a Service (SaaS) offerings by incorporating feedback and suggestions from our valued customers. One of the ways we gather this feedback is through change requests (CRs)—submissions that propose new features or modifications to existing functionality.

This article outlines our policy for handling change requests, including how we classify them (as feature requests or tweaks/amendments), how they are evaluated, and how we prioritise and respond to them.


What is a Feature Request?

A Feature Request (FR) is a type of change request submitted by a customer to propose a new feature or a significant enhancement to existing services. Feature requests are categorised as Priority 5 (P5) and are important to us as they help guide the evolution of our product to better meet our customers' needs.


Feature Requests vs. Tweaks and Amendments

We classify change requests into two main categories: Feature Requests (FRs) and Tweaks/Amendments (TAs). Understanding the distinction helps ensure each request is handled appropriately and efficiently.


Feature Requests (FRs)

These are requests for new functionality or significant enhancements. They generally:

  • Introduce new workflows or capabilities not currently supported
  • Extend existing features in a substantial way
  • Require product design, development planning, and testing
  • Involve updates that may impact multiple areas of the system.


Examples include:

  • Adding a new report for analytics

  • Enabling a new method of user authentication

  • Introducing automation for currently manual workflows

  • Changes to an existing feature that is not widely used by other customers and would otherwise require bespoke development 


Tweaks or Amendments (TAs)

These are smaller changes to existing features. They typically:

  • Adjust the behaviour, layout, or terminology of an existing feature

  • Improve usability or clarity without altering core functionality

  • Are low-impact and often require minimal development effort


Examples include:

  • Changing the default date range in a report

  • Renaming buttons for better clarity

  • Adjusting the order of items in a dropdown menu.


Understanding this distinction allows us to prioritise work more effectively and provide clearer communication about the likely timescales and handling of your request. If your submission does not meet the threshold of an FR, we may instead route it through our continuous improvement or support process.


If you're unsure how to categorise your request, please don’t worry—submit it with as much context as possible, and our team will review and advise accordingly.


Submission and Acknowledgement

How to Submit a Feature Request

Customers can submit change requests (FRs or TAs) through our Freshdesk support portal. When submitting a request, please provide as much detail as possible, including:

  • A clear description of the requested change

  • The problem or need the change addresses

  • Any potential benefits or use cases for the change


Acknowledgement of Request

Once a feature request is submitted, it will be acknowledged within 10 business days. This acknowledgement confirms that we have received your request and it is under consideration.


Evaluation and Scheduling

Evaluation Process

Each CR—whether an FR or a TA—undergoes a thorough evaluation process. Our product management team reviews the request to assess:

  • Feasibility from a technical and design perspective

  • Alignment with our product strategy and roadmap

  • Overall benefit to the user base

  • Potential impact on other customers or existing workflows


Even small changes can have unintended consequences across our customer base. As such, we approach every request with a view toward consistency, stability, and long-term value for all users of the Ignis Suite.


The evaluation process is completed within 10 business days from the acknowledgement of the request.


Scheduling or Deferral

After evaluation, the feature request will be either:

  • Scheduled: If the CR aligns with our product roadmap and is feasible, it will be added to our development schedule.
  • Deferred: If the CR does not align with our product strategy, is not feasible, or duplicates existing functionality, it may be deferred. In this case, we will provide feedback explaining the decision. 


Timelines and Service Level (All Change Requests)


It is important to note that neither FRs nor TAs have a defined Service Level Agreement (SLA) for delivery. This means we cannot guarantee a specific timeline for when a request will be implemented and released.

The development and deployment of changes depend on several factors, including:

  • Complexity and scope of the request

  • Resource availability

  • Current product development priorities

  • Broader customer impact and testing requirements.


While smaller changes may occasionally be delivered more quickly, this is not guaranteed.


Keeping You Informed

We understand the importance of keeping our customers informed about the status of their requests. While we do not provide a specific delivery timeline, we commit to maintaining transparent communication throughout the process. You can track the status of your requests through the support portal, where updates will be posted as the request progresses through evaluation and development.


Conclusion

Your feedback is invaluable to us, and all types of change requests—whether FRs or TAs—play a critical role in shaping the future of our services. We appreciate your understanding and patience as we carefully consider and prioritise each request to ensure the continued improvement of our Ignis Suite offerings.


If you have any questions or need further assistance, please do not hesitate to contact our support team.


Thank you for helping us make Ignis Technologies better.


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