Feature Request & Custom Development Work Request Policy

Throughout your time as a Schoolbox customer, it’s common, at times, for you or your end users to have ideas for new features, or have requests to modify and extend existing functionality within Schoolbox. This is great and we encourage our user community to share their ideas and work closely with us to evolve Schoolbox or customise Schoolbox to specific requirements where required. 

The purpose of this policy is designed to clearly identify the different types of requests we typically receive, how each type is handled and managed and how Schoolbox chooses what to implement. This is important for everyone to understand so that everyone’s expectations are well managed.

There are two types of requests that we typically receive. They are:

• Feature requests.
• Custom development work requests.

Note: Resolution of bugs is distinct from this process and is documented within our Schoolbox Support Policy.

Feature requests are ideas and suggestions for a new feature or feature improvement to Schoolbox. In every major release we aim to implement highly requested features, but popularity is not the only determining factor. There are a range of channels we use to gather feature requests and ideas from, that influence our roadmap decisions and play a factor when we choose what to implement. These channels may include:

• Ideas posted via the Schoolbox Help Centre.
• Product strategy
• Schoolbox Support Desk
• Customer interviews and meetings
• Prospective customer feedback
• Usage data

Channels

Feature requests posted via the Schoolbox Help Centre

There are conversations and new ideas posted on our forums every day. This large volume of posts, comments, votes and interactions, located in our Schoolbox Help Centre (http://help.schoolbox.com.au) is a major source of customer feedback. We recommend you search for existing ideas before posting new duplicate ideas. If an idea already exists, vote for it by posting a comment with your support, or post a comment to further describe your requirements. If you do not find it you may wish to create a new one. Our product team review our most popular voted features and issues on a regular basis.

Product strategy

Our long-term strategic vision for the product and the industries we operate within.

Schoolbox Support Desk

Our support team provides continual feedback and insights into the issues that are challenging for customers, and which are generating the most support requests.

Customer interviews and meetings

We speak with our customers constantly through our account management and professional services projects. We also get the chance to meet them and hear their successes and challenges at the Schoolbox User Meetup, our User Forums and other events and conferences which we attend.

From time to time, our product team conduct customer interviews. Interviews capture ideas and feature requests as well as our customers' high level goals and plans.

Prospective customer feedback

When new customers are assessing Schoolbox, we aim to gather feedback about the features in the platform which they liked and disliked.

Usage data

We measure the success of certain features based on customer usage data.

At times, we may choose to publish information indicating our high level product direction. However, we are not obligated to share specifics on which feature improvements/new features will and will not be implemented. We still aim to provide high level product direction statements, which have typically been in the form of a blog post on our public website or Help Centre.

What is a Feature Request

• A behaviour or action that the system does not currently support
• A changes to an existing workflow or behaviour.
• Additional fields or information being stored and/or retrieved.

Rejecting Feature Requests

There are a range of reasons why a feature request may or may not be implemented. We make no commitments to justify why we make a decision not to implement a feature improvement/new feature request. Reasons we might choose not to implement a feature request include but are not limited to:

• Not enough support or interest from other users.
• Alternative solutions/workarounds exist either in our product or 3rd party products
• Requirements are too specific to a single customer and are of little value to other users.
• Would negatively impact user experience.
• Adds little to no value to an existing workflow solution.
• Effort to implement versus benefits are unbalanced.
• Not a fit for our chosen product direction.

Deprecation (Removal) of Features

Sometimes, for the benefit of the product, our customers or Schoolbox, we may deprecate functionality from our products. When this occurs, we will do our best to communicate to our customers and minimise the impact to our end users, but there is a chance that this may still cause disruption to your use of the product. We apologise for this in advance and ask for your understanding that we will have made the best decision based on product innovation and user experience, for the broadest number of people within our user community.

We are a company that listens to our customers in great depth and with an open mind. We’re heavily engaged with our customers every day and as always, these insights feed back into our product roadmap.

However, it’s important for our customers to understand that we can’t always build everything, and there are times we will not agree with your feedback, ideas or feature requests. It’s our responsibility to accept all  feedback and ideas to make the best possible decisions and lead our product forwards.

A key element of this process is our Feature Request section of HELP above. This is a key driver of Roadmap and engagement with customers.

Previously as a business, we have also considered and delivered Custom Development Work from individual customers. This has been a paid service which has been scoped and planned in partnership with the customer. Whilst this has had success, one of the ongoing challenges has been to ensure it remains compatible and operates as expected, causing frustration for all.

As a result Schoolbox will no longer provide a Custom Development Work option for current customers, rather directing all development requests to our Feature Request page to enable us as a business to make decisions that will support and benefit all customers over time.

This decision has been made with an understanding that Schoolbox has and will continue to provide greater opportunities for schools to engage in their own custom development.

Other options customers might consider to further develop and customize on top of Schoolbox currently include:
Schoolbox APIs 
Custom Java Script and CSS
Custom Profile Buttons

Please note: For those customers with Custom development work in their instance, we as a business will continue to support previous work completed, please understand this may involve additional costs. If and when you might require support with existing Custom Work this should be discussed with your School Engagement Manager.