| Table of Contents | ||||
|---|---|---|---|---|
|
...
Level | Quick Definition | Expected Response Time | Expected Resolution Time |
|---|---|---|---|
Level 1 (Most Urgent) *Level 1 issues are the only issue type handled during the After-Hours On-Call Period. | Used when there is an error that causes the Software to entirely fail to function and/or crash the system on which the Software is installed | Within 1 hr of submission if submitted during Business Hours or After-Hours On-Call Period. | Within 24 hrs of submission (Except when a new version is required, in which case resolution in the code will be completed during business hours). |
Level 2 (High Importance) | Used when there is an error that causes supported elements of the Software to fail to operate materially with no workaround but does not render the system on which the Software is installed inoperable | Expect the first response from a service agent within 9 business hours if submitted during business hours. | Within 5 business days assuming proper notification and planning guidelines were met (Except when a new version is required, in which case Aspenware will address a fix in code within 2 release versions). |
Level 3 (Medium importance) | Used when an error produces an inconvenient situation in which the Software operates substantially per the Specifications but causes or results in substandard or erratic performance. | Expect the first response from a service agent within 3 business days of submission if submitted during business hours. | Within 10 business days (Except when a release is required, in which case Aspenware will address a fix in code within 6 release versions. However, a resolution is ultimately at Aspenware’s sole discretion). |
Level 4 (Low importance) | The classification used when there is an Error that is minor or that is cosmetic in nature and does not result in reduced performance. | Expect the first response from a service agent within 5 business days of submission if submitted during business hours. | Within 20 business days (Except when a release is required, in which there is no expectation that the code change will be addressed as Level 4 software defects are at Aspenware’s sole discretion). |
...
If reporting an issue that has not yet been reproduced, first attempt to reproduce. Take notes on the steps taken, and collect necessary information and details (accounts experiencing the issue, products experiencing the issue including links to the customer-facing PDP and admin editor page, steps to reproduce, browser and OS used, time of occurrence, etc.) that will help troubleshoot the issue.
When creating a ticket, include additional contacts, enter a subject, a description, and attach any necessary files. Please include as much of the following context as possible:
Detailed steps to reproduce
Impacted product header code, and component code
Links to the impacted product (guest-facing link to the PDP and links to the admin product editor page)
Screenshots/Screen recordings (the more legible, the better) We recommend using http://loom.com.
The device, browser, and version details where the issue is occurring if unable to reproduce across all browsers
The exact time of day when this started happening (including time zone information)
Specific user details if relevant (email, account setup in RTP)
Order details if relevant (alternate order id, products ordered, etc.)
Any helpful background information
...
If reporting an issue with an API through Aspenware’s Headless Commerce API offering with ResortOS, please follow the steps below:
Confirm with your development team that the issue is caused by the Aspenware API.
This should include running queries through Postman to determine where the issue lies. If an issue is identified through Postman, that information should be sent to Aspenware support.
Once an issue is identified with the Aspenware APIs, please open a ticket through Freshdesk and include ROS in the subject line. Please include the following information. (A template is currently in progress for use when submitting these tickets.)
API you are experiencing issues with
Values you are using
Screenshots from the Postman queries
A defined communication process between Aspenware and your development team for Headless integrations must be established before you Go-Live with the Aspenware Headless Commerce integration.
| Info |
|---|
NOTE: If submitting a ticket and detail to understand/reproduce the issue is missing, Aspenware’s team members will likely respond asking for this detail, which will slow down the resolution of the issue. The more detail you can provide upfront, the faster we can help you resolve your support issues. |
...
Customers should not fall further than 4 releases behind in their production code at any time. Not staying on current versions can result in the lack of resolution of bugs, errors, and other issues with Aspenware products.
Production environments will not be updated without first notifying and seeking consent from the customer. This raises the importance of customer contact availability - see customer expectations section below.
Before scheduling a release to production, customers are expected to smoke test and approve the code version for their production environment. All functionality that is unique to the customer and not widely adopted should be tested by the customer with each upgrade. For example, if you use subscriptions these should be specially tested with each upgrade.
We offer scheduled release timelines within business hours and do not offer routine releases outside of Business Hours or on Fridays.
If you are integrating with Aspenware’s Headless Commerce APIs, your development team may be required to coordinate with during upgrades. This should only be true if there are breaking changes introduced with a version. If there are no breaking changes, you should follow the same processes outlined here. Your Aspenware representative will provide guidance on whether an upgrade has a breaking change to the APIs.
B2: Customer Expectations During Upgrades
...