Service Level Agreement
Support Services
1. Effective date
2. Definitions
“Product” means the software detailed under Appendix A that the Client would like the Provider to provide support services for.
“Standard Business Hours” means 08:00 to 18:00 hours of the countries/locations of the Support Team members servicing the ticket, not including Saturday, Sunday or public holidays.
“Critical issues” as defined in Appendix B.
“Non-Critical Issues” as defined in Appendix B.
“Familiarization Stage” means the period during which The Provider acquaints themselves with the project requirements and scope. This stage may occur at any time during the term of the agreement and applies to any new developers or engineers who join the project and require knowledge transfer.
3. Construction
In the event of a conflict between the terms of this Agreement and the terms of the Software Services Agreement (“SSA) dated #DATE OF SSA# the terms of this Agreement shall apply, but only to the extent of such conflict.
It is hereby clarified that this Agreement is to be read in conjunction with the SSA and shall serve as an addendum thereto.
4. Type of Services
The Provider will deliver support services to the Client for the purpose of addressing Critical Issues (as defined in Appendix A) for the Product.
Any new features or functionality improvements to the Product, updating libraries, or Non-Critical Issues are beyond the scope of this Agreement and shall be governed by a separate Agreement.
5. Ticket Submission and Quota
Tickets serve as the formal mechanism for the Client to request support services under this Agreement. The following stipulates the ticket submission process and associated quota:
– Ticket Submission: The Client shall submit a Ticket for each separate instance requiring resolution of a Critical Issue. Tickets must not be utilized for Non-Critical Issues or requests for new features or functionality improvements, which are governed by separate Agreements.
– Ticket Quota: The total number of Tickets the Client is entitled to submit per quarter is contingent upon the selected support package as detailed in the Pricing section of this Agreement. Tickets submitted for issues outside the scope of Critical Issues will be considered invalid and will be calculated against the Ticket Quota for that quarter.
Ticket Submission Process: The Client shall submit Tickets for support services exclusively through Scopic’s Support Portal at support.scopicsoftware.com. The Client acknowledges that any ticket submitted through channels other than the designated system may not be recognized as valid.
Only in the event of temporary unavailability or malfunctioning of the designated ticketing system, may the Client submit Tickets via email to support@scopicsoftware.com as a backup mechanism. The Provider shall endeavor to promptly acknowledge, and address Tickets submitted through this alternate method. However, the Provider shall not be held liable for delays or disruptions caused by the failure of the primary ticketing system.
The Provider is committed to addressing each valid Ticket in accordance with the terms herein and within the stipulated Engineering Response Time (defined in Section 6).
6. Response Time
The Provider guarantees an Engineering Response Time of #NUMBER IN LETTERS# (#NUMBER#) hours for all support ticket requests. This timeframe refers to the period within which our engineering will begin addressing the reported issue.
Should the Provider fail to commence responding to the reported issue within the stipulated #NUMBER#-hours period, the support fee for the subsequent billing cycle will be waived. This waiver represents the sole remedy for any delayed response, and no further penalties or damages shall apply.
7. Resolution Time
Our Support Team is committed to addressing reported issues in the tickets promptly and efficiently. While the Provider endeavors to respond to issues swiftly, specific resolution times cannot be guaranteed. The resolution timeline may vary depending on the complexity and nature of the problem encountered.
8. Support Team
The Support Team is a team of people that will be handling Client’s support tickets. The Provider will strive to have engineer(s) familiar with the Product to handle Support Tickets, but this is not guaranteed and the Provider reserves the right to engage other engineers with the relevant skills to handle a Support Ticket. The Provider is entitled to bill for hours spent on the familiarization stage of the project, including acquiring the necessary knowledge for the support services, and understanding the Client’s legacy system prior to performing support services.
9. Pricing
The Pricing for this service consists of the Familiarization Service Fee, Quarterly Processing Fee, and Support Hourly Work.
Familiarization Service Fee
Familiarization Service Fee is applicable at the Familiarization Stage and is $#HOURLY RATE# per hour.
Quarterly Processing Fee
The Quarterly Processing Fee is a quarterly recurring fee that allows the Provider to organize and keep the service operational.
The Quarterly Processing Fee is applied for the processing of tickets within each quarter.
The starting Quarterly Processing Fee is $600 per quarter for the processing of up to five (5) tickets.
For each ticket processed beyond the allocated five (5) for each quarter, those tickets will be charged at $50 per ticket.
This Quarterly Processing Fee is charged separately to the Support Hourly Work rates set out below.
Support Hourly Work
The Support Hourly Work is the work performed by the Support Team after receiving a ticket, plus work conducted during the familiarization stage.
This Support Hourly Work will be invoiced at $#HOURLY RATE# per hour during the Standard Business Hours.
Any response work required outside of the Standard Business Hours will be charged at twice the hourly rate specified for Support Hourly Work. Time during off hours support is measured in 1 hour increments. In the event that a ticket is received on a holiday, the hourly rate for response work will be $#2X OF THE RATE FOR STANDARD BUSINESS HOURS#. The holidays considered will be those recognized in the country where the engineer assigned to the project is located.
The rates stipulated under this Section can be raised given a 1-month email notice with the following restrictions:
- can be increased no more than once within a 12-month period;
- cannot be increased in the first 6 months of the agreement;
- increase cannot be more than 10%.
10. Payment terms
Quarterly Processing Fee:
The Quarterly Processing Fee will be billed quarterly, and is payable upfront on the commencement of this agreement, being the date of signature of both parties. If the services commence when the quarter has already begun, pro-rated Service Fee and Ticket Quota will apply.
Support Hourly Work and Additional Support Tickets:
Charges for any hourly work to resolve tickets and additional support tickets will be invoiced separately, and on a monthly basis, with payment terms of Net 30.
11. Termination for Convenience
Either party may terminate this Statement of Work for convenience in writing at any time during a quarter. Should the Client elect to terminate this Agreement for convenience, they will continue to receive Support Services until the end of the current paid quarter. Similarly, if the Provider elects to terminate this Agreement for convenience, they will continue to provide Support Services until the end of the current paid quarter. If the notice is given less than 30 days before the end of the quarter, the parties will agree if the service discontinues at the end of the quarter or continues for another month after the end of the quarter. In case the parties agree to continue for another month, a prorated pricing will apply.
12. Limitation of Liability
To the fullest extent permitted by law, the Provider shall not be liable to the Client under this Agreement for any lost profits, incidental, indirect, special, punitive, or consequential damages, including such damages arising from any type or manner of commercial, business, or financial loss, even if Provider had actual or constructive knowledge of the possibility of such damages and regardless of whether such damages were foreseeable.
Provider’s liability is limited to the amount paid by the Client in the 12 months prior to the event giving rise to the liability.
13. Signatures
Provider: Scopic Inc. Address: 11 Apex Dr Ste 300A PMB 2021 Marlborough MA 01752 US Name: Mladen Lazic Title: Chief Operating Officer Date: Signature: _____________________
| Client: #PARTY B NAME# Address: #PARTY B ADDRESS# Name: #PARTY B CONTACT NAME# Title: #PARTY B CONTACT NAME TITLE# Date: Signature: _____________________
|
APPENDIX A
- Type of the Product
- Name of the Product
- OS to be maintained
- Libraries
- Technologies
- Link to the Product in AppStore/GooglePlay
- Link to the Customer’s Bug reports
- Client’s contact email
APPENDIX B
Support Service – Issue Categorization
Every support ticket that comes through one of our support channels will need to be categorized. The need for categorization arises in circumstances where the Support Services apply only to issues categorized as “Critical”, while issues categorized as “Non-Critical” should not be handled as part of the Support Services but as part of the regular Development Services.
Critical Issues
A critical or ‘showstopper’ issue in software refers to a defect in the application that is so severe it prevents the use of the software. This kind of issue can manifest in various forms, but typically it includes issues that:
- Completely halts the operation:The software either crashes or becomes non-responsive, making it impossible to continue using it.
- Causes data loss or corruption:These bugs might result in the loss of critical user data or corrupt the data to an extent that it becomes unusable.
- Poses a serious security risk:If a bug allows unauthorized access or exposes sensitive information, it is considered critical due to the potential harm it can cause.
- Severely impairs essential functionalities:This occurs when key features of the software don’t work as intended, rendering the primary purpose of the software unachievable.
In essence, a critical issue is any issue that occurs and that needs attention because it significantly impacts the software’s functionality, security, and obstructs the normal workflow or the end-user experience.
Non-Critical Issues
A Non-Critical issue in software is a type of defect that, while undesirable, does not significantly impede the functionality of the software or severely degrade the user experience. From the support service perspective, an issue that was present for some time but has just been recently discovered will in most cases be classified as Non-Critical. These issues are often lower in priority, and are characterized by the following:
- Minimal Impact on Functionality:
Where non-critical bugs may cause minor inconveniences or issues, but they do not prevent the software from performing its essential functions.
- Workaround Available:
Often, there is a simple workaround for these types of bugs, allowing users to still achieve their goals without significant extra effort.
- Limited Scope:
The bug might affect only a small portion of the software’s features or be encountered only under specific and less common conditions.
- Cosmetic Issues:
Visual glitches or UI imperfections that don’t interfere with the core functions of the software are considered non-critical. Examples include misaligned text, minor color inconsistencies, or small layout issues.
- Non-Essential Features Affected:
The bug may impact features that are not central to the primary use of the software, so the overall functionality remains largely intact.
- No Data Loss or Security Risk:
Non-critical bugs do not pose a risk of data loss, data corruption, or security vulnerabilities.
- Performance Issues under Non-Standard Conditions:
Performance might be slightly affected under conditions that are not typical for the average user, but it does not degrade the general performance significantly.
- Intermittent Issues:
Non-critical bugs are those that occur sporadically and are not consistently reproducible, making them less disruptive and less of a priority.
- Any issues not specifically identified as Critical within Appendix B shall be regarded as Non-critical.
Due to their lower impact, Non-Critical issues might be scheduled for correction in future updates or patches rather than within the timeframe specified for Critical Issues in this agreement and will be governed by a different SOW.
