The e2open Service Level Guidance (SLG) describes the Customer Service and Application Service offered on the production environments of e2open subscription services. The Service Terms point to it for support, and the Order Form may refer to the service as Annual Maintenance and Support, Customer Service or Customer Support.[1] The SLG states that it is offered by the WiseTech Global Limited entity supplying the services under the customer’s service agreement, and that e2open may update it by posting notice on its website, effective on the date of notice.[2] This article covers the parts that have licensing or compliance consequences: who may contact support, which uptime option is bought, whether disaster recovery is included and how quickly single-tenant customers must upgrade.
Customer helpdesk model and the 20-contact cap
The SLG assumes a two-level support model. The customer “must maintain its own Customer Helpdesk” as the single point of contact for Users, staffed by people able to perform basic diagnostics before referring an Incident to e2open’s customer support organisation.[2] e2open then provides Level 2 support, defined as technical support requiring product expertise for Incidents the customer’s Level 1 team could not resolve.[2]
Contact with e2open is restricted to Customer Authorized Personnel. Their number must not exceed 20 named users, the customer must notify e2open of their names, designations and contact details, and replacements need not less than five business days notice.[2] For a software asset manager this is an entitlement count separate from the User metric in the Service Terms: a group with several business units or outsourced helpdesks needs to check that its authorised contacts remain within 20. Incidents are reported through e2open’s web-based support portal, available 24 hours a day, 365 days a year, and the SLG states that a ticket generates an automated response with its number.[2]
Severity levels and targets
The SLG assigns Incidents to five severity levels. Severity 1 covers inaccessible services or critical loss of functionality; Severity 2 covers significant degradation; Severity 3 minor degradation; Severity 4 service requests and cosmetic issues such as account maintenance; and Severity 5 customer feedback and feature requests.[2] The targets are in the table.
| Severity | Target response | Target resolution | Support hours (resolution) |
|---|---|---|---|
| 1 | 1 hour | 4 hours | 24 x 365 |
| 2 | 4 hours | 48 hours | 24 x 5 |
| 3 | 12 hours | Next scheduled patch release, or as communicated | 24 x 5 |
Actual resolution time excludes time outside support hours and delays not attributable to e2open, and e2open performs a root cause analysis for all critical Severity 1 incidents.[2] The SLG also lists exclusions, including unavailability due to use of the Services in a manner not authorised in the Order Form, force majeure, customer equipment, third-party applications, Scheduled Maintenance and breach of the Order Form or SaaS terms.[2] Because exclusion (a) refers back to the Order Form, a licence overuse or unapproved use can reduce service level protection.
Uptime options
The SLG offers three application uptime commitments for the primary data centre of a customer solution. The commitment is a target: e2open will “use commercially reasonable efforts” to meet it.[2]
| Level | Uptime | Scheduled maintenance | Order Form code |
|---|---|---|---|
| Standard (Included) | 99.5% | 4 hours per week | Included |
| Premier | 99.7% | 4 hours per month | LI-SL-APP-SLA 2 |
| Elite | 99.9% | 4 hours per quarter | LI-SL-APP-SLA 3 |
The Standard level has no secondary data centre, best-effort recovery time and a recovery point objective of 24 hours, and backup and restoration is tested annually.[2] Uptime for a month is 100 percent minus the share of Downtime minutes, after excused downtime for Scheduled Maintenance, and Downtime includes any period in which the services are unavailable or a Severity 1 Incident materially affects normal operation.[2] The part codes appear in the SLG itself, so a licence manager can match them to lines on an Order Form. No prices are published; the catalog SKU rows Application Uptime Premier and Application Uptime Elite record the codes without prices.
Disaster recovery as a separate subscription
A customer may, “where available”, subscribe to inter-site disaster recovery. That option, with the code LI-SL-APP-DR, creates a secondary data centre set-up with frequent data synchronisation, a recovery time objective of 4 hours and a recovery point objective of 4 hours, and an annual failover test managed by e2open.[2] The SLG says that testing is done in the disaster recovery site and does not affect production, and that the head of data centre operations decides whether to declare a disaster, after e2open first tries to recover the solution in the same data centre.[2] The default backup arrangement is daily backups, retained for 30 days, with backups held on site for a minimum of 24 hours and a maximum of 72 hours before replication off site.[2] A customer that assumes it has a four-hour recovery objective must confirm that the Order Form includes the inter-site line.
Maintenance windows
Scheduled Maintenance for both multi-tenant and single-tenant systems occurs on Saturdays or Sundays, with schedules published at least five days in advance, and e2open also performs quarterly common infrastructure maintenance per data centre, with the next year’s schedule published before the end of the calendar year.[2] Emergency Maintenance may occur at any time at e2open’s discretion, with notice as soon as practicable.[2] The customer’s authorised personnel are responsible for telling Users about maintenance that is likely to affect them.[2]
Releases, upgrades and support lifecycle
e2open “generally issues Upgrades of its subscription services in 4 releases per year”, and new versions are available for no additional fee.[2] Assistance with implementing upgrades or retrofitting customisations is provided under a statement of work unless it was bought on the Order Form.[2] The consequences differ by tenancy:
- Multi-tenant solutions. Upgrades deploy automatically during Scheduled Maintenance at no cost, with notice before each deployment.[2]
- Single-tenant solutions. e2open recommends upgrading every 12 to 18 months and requires upgrades no less frequently than every two years, which the SLG equates to eight releases.[2]
The SLG’s support table classifies versions by distance from the current release. The current version and Current - 1 to Current - 3 are supported, Current - 4 to Current - 7 are supported with an upgrade recommendation, Current - 8 to Current - 19 receive commercially reasonable efforts on Severity 1 Incidents only and the customer must upgrade, and Current - 20 or older have no support.[2] If the customer stays on a version older than two years, e2open is relieved of liability for any non-compliance with the SLG or the Order Form that an upgrade to a Supported Version would have avoided, and versions older than five years are out of support.[2]
The Service Terms add a contractual consequence that is easy to miss: the IP indemnity does not apply to claims arising from a failure to keep a single-tenant implementation within 12 releases of the current release.[1] With four releases a year, 12 releases is about three years, so a customer can lose indemnity protection before it reaches the point where support stops. Tracking release distance for each single-tenant instance is therefore a compliance control as well as a technical one.
Checklist
- Record the uptime level and disaster recovery lines for each Order Form and match the codes LI-SL-APP-SLA 2, LI-SL-APP-SLA 3 and LI-SL-APP-DR.
- Keep the list of Customer Authorized Personnel at or below 20 and update e2open on changes.
- For every single-tenant instance, track current release, release distance and the planned upgrade date.
- Keep use inside the Order Form scope so that service level exclusions do not apply.
Out of scope
The SLG does not set credits or refunds for missed uptime; remedies are in the Service Terms warranty clause and the Order Form. It applies to production environments and does not describe non-production environments, pricing or per-application support entitlements.[2][1]