Feature Request Procedure

Modified on Fri, 23 Feb at 1:35 PM

At CETA Software, we are always eager to improve our iCFM platform by incorporating valuable feedback and feature requests from our Clients. We understand the importance of evolving our services to meet your needs and enhance your experience. However, it's essential to note that all feature requests undergo a thorough review and prioritisation process by our Development team. This ensures that any new features align with the core functionalities of iCFM and that the complexity of implementing these features leads to significant benefits for our users.


To ensure a smooth and transparent process, we adhere to a structured feature request procedure outlined below. This process helps manage expectations and ensures that both the Client and our team are aligned on the scope, approach, and costs associated with the development work.


CETA guarantees to obtain full approval from the Client before any development begins, and we are committed to ensuring that you are fully informed and satisfied with the proposed development approach and associated costs.


Our Feature Request Procedure:

  1. Initial Submission: The Client submits the feature request via the helpdesk
  2. Information Gathering: CETA responds with Feature Request form to gather more details about the request
  3. Detail Completion: The Client completes the form and returns it to CETA via the helpdesk
  4. Feasibility Review: CETA discusses the feasibility of the feature request at a future development meeting
  5. Decision Making: Depending on the feasibility assessment, the outcome could be:
    • Possible: A meeting is scheduled between the Client and a CETA developer to further discuss the request.
    • Not Possible: The Client is informed, the ticket is closed, and potential workarounds or suggestions, such as utilising our API, may be offered.
  6. Requirements Clarification: The Client and the CETA developer discuss the feature request in detail, including expectations and any adjustments to feasibility
  7. Confirmation: The CETA developer updates the helpdesk ticket with notes for the Client's confirmation or additional comments
  8. Statement of Work: A detailed Statement of Work (SOW) is drafted and internally approved by CETA.
  9. Client Review: The SOW, including a cost breakdown, is sent to the Client for review and approval via helpdesk
  10. Final Agreement: The Client may suggest amendments to the SOW until a final version is agreed upon, signed, and returned by the Client
  11. Invoice and Payment: An invoice for the full cost is issued to the Client. Development work is scheduled once payment is received in full
  12. Development and Testing: CETA schedules and completes the development work, followed by in-house testing. Any issues identified are resolved
  13. Resolution: The helpdesk ticket is updated to "Resolved" once testing is successful
  14. Client Verification: The Client uses the test plan in the SOW to verify satisfaction with the implementation.


Please Note: Any subsequent changes require a new feature request ticket


Should a feature request become business-critical, Clients are encouraged to contact the CETA Customer Success Manager via the helpdesk. We can discuss expedited options, which may incur additional costs.


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