CleverPad Support Services
Effective: June 01, 2021
Customer is allowed any number of contacts per region not exceeding the number of software license holders in the region who may report issues. All issues should be funneled through these contacts. The contacts should verify an issue is valid before reporting it to Provider Technical Support. Issues must be reported with a detailed problem description, a method for repeatedly reproducing the problem, and reasonable access to the contact who reported the issue. Any delay in providing the foregoing will extend the response times set forth previously in this agreement.
Support Response Agreement:
Provider provides responses based on issue priority. The following Table 1 indicates the target resolution time by priority. These are the goals that the Provider’s Technical Support strives to achieve. Although there are various circumstances that can prevent the obtainment of these goals, Provider will strive to meet these goals whenever possible. These targets are subject to change based on revised Customer needs and historical performance.
Business Day – Business Days are defined as 08:00 a.m. Pacific Time to 06:00 p.m. pacific Time, Monday through Friday excluding Holidays.
Business Hour – Any sixty (60) minute period within the aforementioned Business Day.
|S1-CRITICAL||Immediate if live phone contact; within 1 Business Hour if non-live contact||1 Business Days||10 Business Days|
|S2-HIGH||Immediate if live phone contact; within 1 Business Hour if non-live||2 Business Days||20 Business Days|
|S3-MEDIUM||Within 3 Business Hours||5 Business Days||As Appropriate (may be included in the next software release rather than as a patch, depending on the issue)|
|S4-LOW||Within 4 Business Hours||10 Business Days||As Appropriate (typically included in the next software release rather than as a patch)|
|ENHANCEMENT REQUEST||Within 48 Business Hours||N/A||As applicable to the enhancement|
NOTE: The following defines the categories above:
Acknowledgement: Provider Technical Support acknowledges via email that Customer has logged an issue and provides the issue number to Customer. If Customer phones in a Critical Issue, Provider Technical Support will acknowledge via a returned phone call.
Workaround: If possible, Provider will implement a temporary Workaround to allow Customer to move past the issue and continue processing. Customer will implement temporary procedures provided by Provider which enables comparable availability, stability, and/or performance while Provider works on permanent solutions. If a Workaround is not possible, Provider will move directly to providing a permanent fix.
Permanent Fix: Provider will deliver a permanent fix that resolves the issue within the stated time frame. When the fix is delivered, Customer is expected to Test the fix in their environment as soon as possible. Once Customer has tested and acknowledged that the fix has resolved the issue, the Help Desk case for the issue will be closed. If the fix does not resolve the issue, Customer should notify Provider Technical Support immediately. This contact should include detailed test results documenting the fact that the issue has not been resolved. Provider’s Technical Support will acknowledge receipt of this issue, investigate, and provide a revised fix (if needed) to Customer in a timely manner.
NOTE: If additional information is required from Customer to resolve the issue, Provider’s Technical Support will request that information. The time requirements stated in the Table 1 above are suspended during the time the Help Desk is waiting for a response from Customer. Once a response is received, the time requirements resume where they left off.
When an issue is logged with Provider’s Technical Support and further information is requested from Customer, Provider Software requires a timely response. Provider’s Technical Support will send a follow-up email to Customer on the fifth (5th) business day following the initial request for information to remind Customer that a response is required. Five (5) business days later a second (2nd) follow-up email will be sent to Customer requesting a response.
Definition of standard severity levels:
Examples: Provider Service cannot be accessed to conduct critical business functions; Data corruption occurs under normal circumstances; Crashes which terminate a user session; Frozen accounts; Provider stability or performance prevents normal business functions.
Examples: Imports/Exports not working except by manual intervention by Customer staff; Major functionality broken or compromised, and a workaround exist; Slow performance which severely impedes productivity; Exception Errors which allow processing and functionality to continue; incorrect calculated values.
Examples: Minor functionality broken where a Workaround exists; marginal performance which slightly impedes productivity; Help system issues.
S4 – Low
Examples: Cosmetic issues, Provider Services inconsistencies where normal business functions are unaffected.
Enhancement requests may be made to further enhance the functionality of the Provider Services product. Enhancements or code alterations to the Provider Services product are considered Change Orders. All Change Orders received from Customers are prioritized in terms of their fit with the Company’s roadmap, the usability of the Change Order across a broader spectrum of Customers, costs, resources, etc. All Change Orders are considered billable engagements and Provider reserves the right to refuse any Change Orders for any reason.
Work plan for open cases:
All cases are initially responded to and owned by the Technical Support team member. The assigned support engineer will continue to work on the case until it is resolved to Customer’s satisfaction. Updates will be communicated to Customer by the support engineer based upon the frequency and method desired by Customer.
Root Cause Analysis for SLA failures:
Promptly after receipt of a notice from Customer of Provider’s Service Level failure, Provider shall commence diligent efforts to perform a root cause analysis, (ii) within fifteen (15) business days provide a preliminary root-cause analysis for such Service Level failure, (iii) within thirty (30) days provide a final root-cause analysis for such Service Level failure, (iv) provide Customer with a report detailing the cause of such Service Level failure, (vi) provide Customer with reasonable evidence that such Service Level will not be repeated and (vii) make written recommendations to Customer for improvement in procedures.
Root cause analysis for S1 and S2 issues:
For any S1 and S2 issues, a formal root cause analysis documenting the root cause of the issue, along with actions and controls put in place to mitigate the risk of the issue reoccurring in the future shall be provided within two (2) business days of any temporary repair or Workaround. Root cause analysis shall be updated within two (2) business days of completion of the permanent repair.
During investigation of a case, it may be determined (by the “Sustaining Engineering” an Engineer will provide engineering product support for released products through product end of life with specific areas of focus being diagnosing, reproducing, fixing Software problems, and in general troubleshoot Software products to assist customers with problem isolation and resolution at the source code level) that the case represents a product defect within the Provider Services. If this determination is made, the case will be escalated to the Vice President for the assignment of a Sustaining Engineer.
The Sustaining Engineer will assume ownership of an escalated case and work the case, providing updated communications to Customer by the original support engineer based upon the frequency and method desired by Customer. Communication will continue until the case is resolved to Customer’s satisfaction.
Self-Service Support Portal :
Customer can specify named support portal user accounts. Those users can create new support cases, view and update existing support cases, and access a searchable knowledge base. The “Self-Service Support Portal” means the mechanism to be used to track every support incident given a unique case number. This case number will be emailed directly to Customer. All changes in status or updates made to each case will be communicated automatically to Customer via email.
Closure of Cases:
Once a viable solution to a case is determined by Provider and confirmed by Customer or deployed, the case will be closed in accordance with the following guidelines:
Closure via support assistance on the first call – At the conclusion of the call, the Support representative will issue a case id to Customer for future reference. The case will be closed within the Customer Relationship Management (“CRM”) system.
Closure via investigation and resolution of an open support case – Once a viable solution (which meets Customer’s requirements) is found and communicated to Customer, the case will remain open for five (5) business days pending Customer confirmation. If a confirmation from Customer is not received within five (5) business days from the solution communication, the case will be closed in the CRM system. After this period, if a case needs to be reopened, a new case will be initiated with reference to the closed case.
Closure via a software update (for cases escalated to Sustaining Engineering) – Once a software update is produced, (which meets Customer’s requirements) deployed and communicated to Customer, the case will remain open for five (5) business days pending Customer confirmation. It is expected that a customer confirmation for S1 and S2 issues occur within two (2) business days and five (5) business days respectively. If a confirmation from Customer is not received within five (5) business days from the solution communication, the case will be closed in the CRM system. After this period, if a case needs to be reopened, a new case will be initiated with reference to the closed case.
a. Service Level Agreement Warranty or “SLA” Warranty.
For fee-based Provider Services only (i.e., excluding Trials) and as long as applicable Fees are paid as they become due and the terms of this Agreement are complied with, Provider warrants to Customer the level of performance. Provider makes no SLA Warranty for Provider Services available at or through Customer’s Site, meaning that Provider is not responsible for the public internet or for Customer’s internal systems.
Provider warrants to Customer that Provider Services will perform substantially as described in the Agreement and the Schedules to this Agreement provided that Customer shall give Provider prompt written notice of any Performance problem which notice must be received during the Term. Provider makes no warranty for use of the Provider Services outside the scope described in this Agreement. This warranty is void to the extent the performance problems are due to problems with Customer or Authorized User’s network, desktop, third-party software applications, hardware or network connectivity to the Site; electrical or internet access disruptions; and/or misuse of the Provider Services by an Authorized User. This warranty applies until this Agreement, or the applicable Order or Schedule is terminated.
The following definitions apply to the SLA Warranty above in this Section: