Schoolbox Support And Service Availability Policy
Last Updated 31st July 2023
1. General Information
1.1 Schoolbox will provide limited support of the Schoolbox Subscription Services at no additional cost to the Customer.
1.2 Schoolbox Support will only be provided to the Schoolbox Customer Contact Roles (Your Schoolbox Contacts) within your organisation who are appointed responsibility for administration of the Schoolbox Subscription Services.
1.3 We will keep records of who Your Schoolbox Contacts are. Any Support requests we receive from your end-users will be redirected to Your schools’ Schoolbox Contacts.
1.4 Support Includes
(a) Incident Support – Identifying and troubleshooting problems in the system
(b) Root cause analysis
(c) Assistance with issues during installation
(d) Assistance with issues during upgrades
(e) Identifying and creating needed bug reports
(f) Guidance around implementation and configuration
(g) Integration support with other Schoolbox integrations
1.5 Support Does Not Include
(a) Maintenance of non-current versions (see clause 4.2)
(b) Customers not registered for support
(c) Hardware issues
(d) Independent software development
(e) Schoolbox supports major versions for two years after the first major iteration of that version was released (for example, we support Schoolbox 15.0.x for two (2) years after Schoolbox 15.0.0 was released)
(f) Any customisations or modifications to the original core Schoolbox product, whether created by Schoolbox or any other party, this includes:
(i) Troubleshooting custom CSS (Cascading Style Sheets)
(ii) Troubleshooting custom UPS (User Provisioning System) views
(g) Third-party application integrations, databases or third-party plugins
(h) Onsite support
(i) Data manipulation (e.g. bulk data modifications, restoring from backups)
(j) Support in languages other than English
(k) Professional Services including training (consulting, custom development remote and on-site training)
(l) Direct communication with our Professional Services team.
(m) Support for end-users
Onsite support, training and data manipulation is not included in the licence fee and will be charged at our current rates. It is your responsibility to provide support for your staff and students. We highly recommend seeking our training resources and providing your end-users with our support resources listed below and linking to them in your Schoolbox instance side-menu, or internal support page.
2 Accessing Support and Creating a Support Request
2.1 Schoolbox support is provided via the channels listed below:
(a) Online (also referred to as our Support Desk)
Located at support.schoolbox.com.au, this system enables you to:
(i) Create new Support Requests (also called Tickets) for your organisation
(ii) Track existing requests (incl. billable work requests/services)
(iii) Report issues or bugs you experience whilst using our products
To access the Support Desk you need to create an account by visiting the Schoolbox Support Desk Sign-Up page. If you experience any difficulty creating your account, please contact our support team via Email or Telephone (see below).
(b) Email: Optionally (although not our preferred method) you can create a Support Request by emailing firstname.lastname@example.org. In this case, please pay extra attention to the guidelines for creating a support request (see below).
(c) Telephone: Call us on 1300 932 338 (within Australia) or for international on +61 3 9882 6909.
2.2 A Support Request is deemed to have been received by us when:
(a) When you receive an automated email confirmation from our Support Desk system stating that a Ticket has been created, after you have followed the steps outlined in clause 2.3; or
(b) One of Your Schoolbox Contacts connects with one of our dedicated support team members via the Telephone channel listed above.
2.3 Guidelines for Creating a Support Request
Before you create a new Support Request, please refer to the following guidelines:
(b) Have you checked our Help Centre?
(c) Have you asked the community your question?
(e) Got a feature request or idea? Post it to our Feature Requests forum. Also see Implementation and Deprecation of Features & Custom Development Work Requests Policy.
2.4 Support Desk Hours of Operation
(a) Telephone support for Critical issues (see Clause 5.1) will be provided 24 hours a day, 7 days a week.
(d) All support services are not provided during public holidays or scheduled support service disruptions (e.g. company holidays), where we will aim to provide at least 24 hours notice to our Customers on one of our publicly visible channels (Websites or our company social network profiles including but not limited to https://twitter.com/schoolbox, https://www.facebook.com/schoolboxlms, https://www.linkedin.com/company/schoolbox).
(e) Support request response services levels are not affected outside the hours of operation.
If you are trying to reach our team outside of our hours of operation, please create a Support Request and we will respond as soon as possible.
2.5 Additionally, the following resources are available to support you:
(a) Schoolbox Help Centre
Located at help.schoolbox.com.au, our Schoolbox Help Centre is your first stop for learning more about Schoolbox and interacting with our user community. Access to the Help Centre is granted by contacting your Schoolbox administrator and requesting an account. They will then follow the steps detailed on How to access the online training?. We encourage you to provide access to the Help Centre to all of your staff (teachers, administration, etc).
Some of the features included within the Help Centre are:
(i) Teacher training courses (requires an active subscription to our Online Teacher Training Course to access)
(ii) User groups
(iii) Inspiration and best practice examples
(iv) Community Q&A
(v) Idea and feature suggestion
(vii) Job listings
(viii) Release notes and roadmap information
(b) YouTube Channel
There are a large number of videos available on our Schoolbox YouTube Channel: http://www.youtube.com/schoolboxVideo
(c) Accounts and Billing Information
Please refer to the information detailed on Accounts and Billing Information.
3. Schoolbox Bug Fixing Policy
3.1 For the purpose of this policy, a bug means a defect, error or fault in the Schoolbox software, having an adverse effect on the appearance, operation, functionality or performance of the Software.
3.2 Our support includes helping you with workarounds and bug reporting.
3.3 Critical bugs will generally be fixed in the next maintenance release (also called minor releases).
3.4 Non critical bugs will be scheduled according to a variety of considerations.
3.5 Our support team is eager and happy to help verify bugs. Please submit any issues by creating a Support Request.
3.6 Once we receive your bug report we will attempt to reproduce and verify the bug, then lodge the report for you. We’ll also try to construct workarounds if they’re possible.
4. How Schoolbox Approaches Bug Fixing
4.1 Minor (bug fix) releases come out more frequently than major releases and attempt to target the most critical bugs affecting our customers. The notation for a minor release is the final number in the version (i.e. the 1 in 3.0.1).
4.2 Only the current major release will be patched with bug fixes. For this reason, we recommend all customers aim to be running the current major release, to ensure access to the most bug free version of the Service.
4.3 If a bug is related to a Critical issue (as per the table listed under clause 5.1) then it will be fixed in the next minor release provided that:
(a) The fix is technically feasible (i.e. it doesn’t require a major architectural change).
(b) It does not impact the quality or integrity of a product.
4.4 For non-critical bugs, the developer assigned to fixing bugs prioritises the non-critical bug according to these factors:
(a) How many of our supported configurations are affected by the problem.
(b) Whether there is an effective workaround or patch.
(c) How difficult the issue is to fix.
(d) Whether many bugs in one area can be fixed at one time.
4.5 The developers responsible for bug fixing also monitor comments on existing bugs and new bugs submitted in our Support Desk, so you can provide feedback in this way.
4.6 We give high priority consideration to security related issues.
4.7 When considering the priority of a non-critical bug we try to determine a ‘value’ score for a bug which takes into account the severity of the bug from the customer’s perspective, how prevalent the bug is and whether roadmap features may render the bug obsolete. We combine this with a complexity score (i.e. how difficult the bug is). These two dimensions are used when developers self serve from any backlog of bugs or known issues.
5. Support Request Response Service Level Commitment
5.1 When we receive a Support Request, we categorise the Ticket and aim to respond within the time frames listed below, based on the Ticket’s perceived Level of Severity.
|Level of Severity||Description of Severity||Characteristics||On-Premise||Hosted|
|Level 1 – Urgent (Critical)||Critical Business Impact: Schoolbox on your production server is having major issues and requires immediate attention to prevent any damage or data loss. Your business is impacted heavily. You cannot wait and must have this responded to urgently.||2 hr||2 hr|
|Level 2 – High||Significant Business Impact: Some errors have appeared or the service is running slow, but the problem doesn’t look to be getting worse (impacting users, requires a quick response and action).||5 hr||5 hr|
|Level 3 – Normal||Minimal Business Impact: You want an answer but are happy to wait a maximum of three business days to get back to you with an initial response.||72 hr||72 hr|
|Level 4 – Low||Normal Business Impact: Question, comment, documentation issue, other non-impacting issue, or issue occurring on non-production system.||168 hr||168 hr|
5.2 The table above is a guide to illustrate our internal response goals based on historic performance.
5.3 The response may not contain a resolution but it must be addressing the problem or elaborating.
5.4 Follow-up communication is not bound by these response times.
5.5 We make all reasonable efforts to reply to support related emails within two Business Days.
5.6 While Schoolbox attempts to respond to all issues in a timely manner, issues that affect the Service Availability of our Customers’ Production Instances (i.e. Level 1, Level 2) do take priority.
5.7 The support request response service levels commitment described above is for business days only (weekend coverage is limited to L1 – L2 issue only).
6. Service Availability Commitment
6.1 Uptime is defined as the uninterrupted time your Production Instance is available to you.
6.2 Schoolbox commits to provide 99.9% uptime with respect to the Customer’s Service, each calendar year of the Subscription Term, Subject to clause 12.
6.3 Subject to clause 6.2, We will use commercially reasonable efforts to make the Services available 24 hours a day, 7 days a week.
6.4 If in any calendar year this uptime commitment is not met by us and you experience downtime (defined as the Schoolbox service on your production server being completely inaccessible, due to the unscheduled downtime of the Service), then penalties (see Clause 9) may apply.
7. Scheduled and Unscheduled Maintenance
7.1 Regularly scheduled maintenance time does not count as downtime. Maintenance time is regularly scheduled if it is communicated in advance of the maintenance time, via one of the following:
(a) Displayed a notice or delivered a Schoolbox notification on the screen to a sponsor, key contact or support registered contact immediately after signing into the Schoolbox software; or
(b) By email to your Key Contact’s email address provided to us in Your Schoolbox Contacts; or
(c) By publishing a news post on any of our Websites that specifies downtime or maintenance.
7.2 Regularly scheduled maintenance is typically communicated at least twenty four (24) hours in advance, and is scheduled to occur at a time that should limit impact to our Customers use of the Service.
7.3 Schoolbox in its sole discretion may take the Service down for unscheduled maintenance and in that event will attempt to notify our Customers in advance in accordance with the Notice section set forth below. Such unscheduled maintenance will be counted against the uptime guarantee.
8. On-Premise Add-Ons Services Hosted Backup (ADHB) Service Availability Commitment
8.1 The same Service Availability Commitment specified in clause 6. extends to our On-Premise Add-Ons Services Hosted Backup (ADHB) Service.
8.2 Recovery means the process that We will employ to bring your Schoolbox Service back online within a brief period of time.
8.3 Recovery Time Objective (RTO) means the period from the moment the Customer communicates to Us that they require the Disaster Recovery (DR) to be executed until the moment the whole backed up data is recovered.
8.4 The RTO for the On-Premise Add-On – Hosted Backup (ADHB) service will be a maximum of four hours. This timeframe may vary depending on the Customer Domain Name Servers (DNS) Time To Live (TTL) configuration at the time of the recovery request.
9.1 If we fail to meet the Service Availability Commitments listed above we shall provide, as the sole and exclusive remedy, a service credit equal to one month’s fee for the use of the relative Service.
9.2 If our support request response times are not met then in certain circumstances where we agree that we could have reasonably provided a better response time, penalties may apply. If we agree, we shall provide, as the sole and exclusive remedy, a service credit equal to one month’s fee for the use of the relative subscription service.
9.3 Any calculations for matters relating to penalties will be calculated using Schoolbox’s system logs and other records.
10. Credit Request
10.1 In order to receive a credit under this service level commitment, the Customer must request it simply by emailing us at email@example.com, within five days of the end of the end of the applicable calendar year of the Subscription Term.
10.2 If the Customer submits a credit request and does not receive a prompt automated response indicating that the request was received, the Customer must resubmit the request because the submission was not properly received and will not result in a credit.
10.3 Customers who are past due or in default with respect to any payment or any material contractual obligations to Schoolbox are not eligible for any credit under this Service Level Commitment.
10.4 The service credit is valid for up to two years from the year for which the credit was issued.
11 Exclusion of Demo Service and Sandbox Service
11.1 Any Demo Service, sandbox, staging, development or test environments are expressly excluded from any uptime commitment.
12. Support Response and Service Availability Commitment Exclusions
The following exclusions apply to the Service Support Response Service Level Commitment and the Service Availability Commitment:
12.1 Any unavailability, suspension or termination or any other performance issues caused by:
(a) Circumstances beyond our reasonable control, including, for example, an act of God, act of government, flood, fire, earthquake, civil unrest, act of terror,strike or other labor problem (other than one involving Schoolbox employees), Internet service provider failure or delay, your hardware or software issues, a network or device failure external to the data centers we use, including at your site or between your site and our data center, Non-Schoolbox Application, or denial of service attack.
(b) Your use of a Service after we advised you to modify your use of the Service, if you did not modify your use as advised.
(c) Regularly scheduled maintenance times as defined in clause 8.
(d) Technical issue with a third party, related to the provision of the service, that is outside of our control (for example, a non-operational AWS hosting service).
(e) That result from your unauthorised action or lack of action when required, or from your employees, agents, contractors, or vendors, or anyone gaining access to our network by means of your passwords or equipment, or otherwise resulting from your failure to follow appropriate security practices.
(f) That result from faulty input, instructions, or arguments (for example, requests to access files that do not exist);
(g) That result from your attempts to perform operations that exceed prescribed quotas or that resulted from our throttling of suspected abusive behavior;
(h) For licenses or subscriptions not paid for at the time where access to the cloud service/s is required by the Customer.
(i) Scheduled support service disruptions which affect our availability, as specified in clause 2.4 (d) and 2.4 (e).
13.1 The development of the Schoolbox platform is ongoing. Customer feedback and suggestions relating to the ongoing development of Schoolbox is encouraged. The continuing development of the Schoolbox is at the discretion of Schoolbox. For more information please read our Implementation and Deprecation of Features & Custom Development Work Requests Policy.
14.1 Schoolbox is continually under development and being updated. These updates will be made available in the form of releases. We typically class these releases into Minor and Major Releases.
14.2 Major Releases shall occur approximately every six months, but can be more or less frequent at our discretion. Release frequency will be dependent on the development of new features and updates or fault fixes to existing features.
14.3 It will be the responsibility of Schoolbox to install and maintain changes between releases. Each release will be accompanied with a change log (also referred to as Release Notes) detailing all changes.
14.4 Each release will be pre-released to a Staging server prior to deployment into their Production server. During this period we encourage all customers to test all functionality to help identify any issues prior to deployment into Production.
14.5 Critical updates including security or useability fault fixes may be released independently, typically as a Minor Release.
14.6 A security or useability fault must be reported to Schoolbox via the online Submit a Support Request Form or email and include all required information. Please read and share How to provide all the required information to get your issue fixed quickly.
15. Your Obligations
To enable Schoolbox to provide a consistent level of service the following is required by you, the Customer:
15.1 You must ensure your Key Contact and Support Registered Users hold and maintain a reasonable level of knowledge and understanding of the Subscription Services in order to administer the Schoolbox software. This includes but is not limited to:
(a) Being proactive in learning as much as possible about how the software works.
(b) Reading and understanding all of our release notes within a reasonable amount of time after publishing them, including attending our new release webinars
(c) Reading and understanding any communications sent from us relating to the product or our services
(d) Changes to our service offerings
(e) Change to our policies
This is best achieved by subscribing to and regularly checking our Websites, particularly our Schoolbox Help Centre.
If further assistance or upskilling is required, we recommend you consider engaging our Professional Services.
15.2 It is the responsibility of Your Schoolbox Contacts to inform us of any change in the appointment of those contacts, so that we can keep our systems up to date. Upon request, Schoolbox can supply a list of Your Schoolbox Contacts.
15.3 For On-Premise Subscription Services, You must:
(a) Provide and support a stable hardware environment, and network connectivity for the Service to run on.
(b) Ensuring that you have staff who have the reasonably expected technical skills required to support an On-Premise service. This includes but is not limited to:
(i) Comfort running SQL commands and installing a database. It’s best if you have a good Database Administrator (DBA) for database troubleshooting and administration.
(ii) Comfort installing and maintaining production web technologies
(c) Provide remote access to us at all times (24 hours a day, 7 days per week) to your production and any other servers (backup, staging).
(i) This will include direct access to the Schoolbox server via Secure Socket Shell (SSH).
(ii) You must not change or affect our access to the servers without prior approval from us.
(iii) If our ability to support the service is affected due to our access being restricted, we are not liable to meet our service levels under this agreement, until such access is restored and verified in writing by us.
15.4 Failure to meet any of your obligations aforementioned, may mean that we are not liable to meet any of our service levels.