Support Policy

1. Purpose

This policy explains how elyXion receives, prioritises, communicates, and closes support requests. The SLA contains target times; the Order Form defines purchased coverage.

2. Eligibility

Support is available to authorised contacts for in-scope services. elyXion may verify identity and authority before disclosing information or performing sensitive actions. End users may be redirected through the Customer’s internal service desk where agreed.

3. Request Types

• **Incident:** unplanned interruption or degradation.
• **Service request:** standard access, information, or administrative request.
• **Change:** addition, modification, or removal that may affect service.
• **Problem:** underlying cause of one or more incidents.
• **Security event:** observable occurrence requiring security triage.

4. Submitting a Useful Request

Include business impact, affected users and systems, start time, error messages, recent changes, steps already taken, urgency, contact details, and safe diagnostic evidence. Do not submit passwords, private keys, access tokens, or unnecessary personal data.

5. Triage and Priority

elyXion validates scope, impact, urgency, and security. Priority may differ from the submitter’s selection. Duplicate reports may be linked to a major incident.

6. Remote and On-site Support

Support is remote by default. On-site work requires agreement and may incur travel time and expenses. elyXion will use approved secure access methods and least-privilege permissions.

7. Changes

Routine pre-authorised changes may follow standard procedures. Material or high-risk changes require approval, testing, scheduling, and rollback planning. Emergency changes may be implemented to contain active risk and documented afterwards.

8. Vendor Escalation

elyXion may open and coordinate cases with Microsoft or other vendors if included and if the Customer provides required licences, permissions, and information. Vendor response and resolution are governed by vendor terms.

9. Communication

Updates are provided through the ticket or agreed incident channel. Customers should keep operational contacts current. Sensitive information will be limited to recipients who need it.

10. Closure and Reopening

A request may close when service is restored, the request is fulfilled, the Customer accepts the outcome, further action is out of scope, or the Customer does not respond after [NUMBER] reminders over [PERIOD]. A recurrence may be reopened or logged as a new issue depending on reporting and metrics.

11. Root-cause Analysis

Root-cause analysis is not automatic for every incident. It may be provided for qualifying major incidents, recurring problems, or where purchased. It reflects evidence available and may change if new evidence emerges.

12. Supported Configurations

elyXion supports versions, features, and architectures listed in the service scope and Lifecycle Policy. Best-effort assistance for unsupported systems does not create ongoing support.

13. Customer Obligations

Customers must maintain approved contacts, access, licences, backups, documentation, and vendor agreements; follow security requirements; and test outcomes where requested. Delays in these obligations pause applicable targets.

14. Feedback and Complaints

Service concerns should first be raised with the service owner. Formal complaints may be sent to [GENERAL CONTACT EMAIL] and will be acknowledged within [COMPLAINT ACKNOWLEDGEMENT TARGET].