Not logged in - Login

Support Process

Customer Case Logging

Any faults with services supplied by ESS must be logged with the Service Desk during Working Hours using the contact details provided in this document. Faults may be logged via telephone, email or the customer portal. However, we strongly suggest that high-priority faults are raised via the telephone to ensure prompt attention.

Cases logged by telephone

On logging a fault, a Service Desk Agent will: -

  • Take the site administrators or nominated persons details
  • Take the details of the fault
  • Issue a case reference number
  • Confirm appropriate triage (troubleshooting / diagnosis / impact / quantity of users affected) has been completed as per the service description.
  • Assign a case priority based on the fault and impact classifications described in the Case Priorities table in the document
  • Request troubleshooting and diagnostics in order to gather enough information to progress the case.
  • Confirm if the user has reviewed the support site for pre-existing help guides, FAQ’s etc and confirmed that, where applicable, these have been followed.

If the fault cannot be resolved during the initial telephone conversation, the fault will be placed in the incident management team's support queue and will be dealt with according to case priority. Customers can check progress via the Customer Service Portal, additionally updates and resolutions are provided via our automated email updates.

All timings for case handling procedure and SLA measurement start from the time the call reference number is issued during the initial call, unless the incident was picked up from our Monitoring Systems.

Cases logged by email

All faults logged by email should include: -

  • The name, role and telephone number of the person logging the fault.
  • The school for which the call is being raised
  • Any Customer fault reference number
  • Full and accurate details of the fault being reported.
  • Full details of all troubleshooting / diagnosis that has taken place by yourselves as per the service description
  • A statement of impact of the issue (e.g. single user, all users etc) If the issue is clear within the email the Service Desk Agent will: -
  • Log the case within the call logging system.
  • Reply to the email detailing the case reference number and priority assigned.

The case will then be placed in the incident management team's support queue, and will be dealt with according to priority. The customer will receive case updates and resolution, according to the case handling procedures described below.

If the issue is not clear within the email the Service Desk Agent will attempt to contact the customer by telephone and /or email to clarify. However, a case will be raised and placed “On Hold” until the further information has been provided.

If the email is received outside Working Hours, ESS will treat the email is if it had been received at the start of the next Working Hours period. Calls raised by email will be logged within 24 hours (1 working day).

Case handling

All cases of any type (e.g. Faults, Service Change Requests, and Information Requests) are allocated a default case priority by the ESS Service Desk at the time of logging.

In circumstances where the effective impact to end users indicates the situation is more serious and the default priority is inadequate, the default priority may be raised following escalation by and in liaison with the agreed Customer contact and Service Desk Team Leader within 30 minutes of the case being raised.

The priority sets the target resolution times for the case as described in the Case Priorities table in this document

Updates to cases will typically be via automated email however, you may obtain further information via Customer Service Portal at any time. Out of hours work

In the event that a Priority 1 (or total service loss) fault is still open at the end of a Working Day, ESS will continue to work on the fault outside of working hours.

If end-user testing is required to validate the resolution or to assist with investigations and the customer representative is not available, the clock will be stopped and the fault will not be worked on outside normal Working Hours.

If a representative is available, then the contact details and methods of communication to be used out of hours will be exchanged between ESS and the representative at the end of the normal Working Hours period.

The agreed Customer contact uses the Customer portal and email services as their primary communications channel, in the event of an Internet or email outage the agreed Customer contact may not be able to use the Customer Service Portal or email facilities, thus for incidents when those services are affected, it is recommended to use the telephone.

When a case reaches the “RESOLVED STATE‟ and we have tried contacting the customer to get the case closed, we will make 3 additional attempts over a period of 1 week and if there is NO response then the case will be closed. If the issue still persists a new case will be opened & the SLA will begin again – a case will NOT be re-opened in these circumstances.

Case Priorities

Priority : 1

Priority Description: Non availability of all Service Components Target Time : 4 hours

Priority : 2

Priority Description: Any issue that is a significant impact to ALL users such as the unavailability of individual service components (e.g. e-mail or VLE) Target Time : 1 working day

Priority : 3

Priority Description: Any issue that causes impact to many users or significant impact to a small proportion of users
Target Time : 3 working days**

Priority : 4

Priority Description: Any issues that cause minor disruption for a single user or a small number of users, or a BAU administration task or request for information (e.g. how to)
Target Time : 4 working days**

Priority : 5

Priority Description: A Feature Request/Change Request
Target Time : 5 working days**

For the avoidance of doubt, P1 is concurrent unavailability of all service platforms (as defined in the various service descriptions). If any given (single) service, such as the email service is working and available for any users, whilst others are unavailable, then a P2 incident shall be raised. P2 shall be used when one or more (but not all) service platforms are unavailable to ALL users of that platform. For the avoidance of doubt, if some users can access/use a platform successfully, whilst others cannot, for example if multiple email servers were deployed and only 1 server was unavailable, then a P3 call shall be raised. P3 shall be used for single service platform unavailability for some users (not all) and for individual user issues – this may include loss of an individual service for a single school.

** The SLA in this case may not cover the final resolution. Where a fault is deemed to be requiring application or infrastructure development, the SLA refers to the time taken for the appropriate team to provide an update to the call detailing any circumvention and confirming that the issue will be resolved either

  • a) service working to requirement,
  • b) resolution will be progressed urgently,
  • c) the issue will be fixed in the next release of the product concerned or
  • d) the issue will be fixed at a future release.

Feature Requests will be reviewed by the teams and the call will be updated confirming if the request is on the backlog for future development or whether the requirement will not be pursued. The call will then be closed.

Items raised as Change Requests will be confirmed as a valid CR within the SLA timescales above and the call will be updated setting the expectation of when the change will be implemented. It is anticipated that most Change Requests will be completed within 15 working days.

Case Conditions

The following case conditions will be used for live cases and are visible to customers via the Customer Service Portal

  • Open
    • Case Open but not yet assigned to an engineer.
  • Assigned
    • Case open and has been assigned to an engineer to progress.
  • On-Hold
    • Customer Unavailable to assist / further information required to progress
  • Resolved
    • Confirmation Not Required. Case will shortly move directly to Closed.
  • Resolved
    • Waiting Customer Confirmation. Case will be closed when customer confirmation of closure has been received or three reasonable attempts at contact have been made with no customer response.
  • Closed
    • Case is resolved and closed.

Reason for Outage (RFO) will be provided in the case closure detail, for situations that caused a complete loss of service.

Support contact details | Who should I contact for support? | What are the Hours of Support? | What should I expect from Support? | Escalation Process