Skip to the content
SRO support portal

SRO Client Support Portal

The SRO Client Support Portal encompasses all aspects of the support offering. Here you can find all the information regarding handling tickets, classification, etc. 

Ticket Description

Ticket Description Details

Please provide as much information as possible at the point of ticket creation as this will aid the SRO Support Team to identify, diagnose and resolve the issue as quickly and as efficiently as possible.

Incident Description - Details

When populating the details please address the following:

  1. Describe the details of the issue; is it happening to all users or just specific users?
  2. Is this a new issue or has it happened before?
  3. When did this issue first occur?
  4. What work/processes were being carried out when the issue was discovered?
  5. Prior to the start of the issue, had any changes been made to the environment and describe them?
  6. How would you define an acceptable solution to this problem?
  7. What type of environment has this issue occurred on? e.g. Test, Dev, Prod etc.
  8. Please define whether this issue is affecting any deadlines or imminent work?
  9. Have you attempted to resolve this issue yourself? If so what steps/processes have you taken? 
Change Description – Details

Please refer to the SRO Change Request form.

Guidance notes:

Provide as much detail as possible for the change that you require. 

Define a description for:

  1. The reason the change is required.
  2. Key points to be included.
  3. Expected outcomes.

Service Description – Details

Provide as much detail as possible for the Question or How-to to enable the Support Desk to assist you as efficiently as possible.

If it is a request for a new user please attach the SRO User Id Request Template completed with approval.

 

 

Ticket Classification

How to Classify a Ticket

Each ticket can have up to 3 levels of classification and it is essential to classify down to the lowest level possible for each ticket.

Level 1

Initially, each ticket must be classified as either a Service Request, an Incident or a Change.

Service Request Incident Change
A Service Request is a user request for information, advice, user id creation or password reset. An Incident is an unplanned interruption to an IT Service or a reduction in the quality of an IT. A Change is a request for system enhancements, changes to the underlying structure and new developments.

Service Request Examples:

  • Questions and How-Tos
    • How do I set up a Location Hierarchy?
  • Assistance with an unsupported method of system interaction
  • Creation of new user id
  • Password Reset

Incident Examples:

  • The system is inaccessible.
  • Saving any record is not possible.
  • Saving a single record is not possible.
  • Saving a transaction is not possible.

 

Change Examples:

  • Patches – The Customer requests a patch to a higher level.
  • Configuration – Any updates to Maximo.
  • Rule File – A request for a Replication Rule File.

 

Level 2

Specifies the application/product that the ticket relates to:-

DXRE – DataXtend Replication Engine

Maximo – IBM Maximo Asset Management 

SDR – SRO Data Replicator

SDU – SRO Data Utility

 

Level 3

For Incident it indicates the environment, i.e. Production or Non-Production. For Service Request and Change, this suggests the activity required.

Incident Classification Hierarchy

Please click here to access our Client Support Portal.

Link to e-learning

Maximo Support Ticket Priority

Reported Priority

Reported Priority is used to indicate the urgency or impact of the ticket which allows the SRO Support Team to respond and allocate resource based on the business impact.

High-Level Guidance

P1/P2 should be used for Critical / Significant Business Impacting Incidents and Emergency Changes on Production Environments only – It is essential in the instance of P1 tickets that after logging the ticket in the client support portal it is followed up with a phone call to our Support Desk +44 (0) 845 408 4250. P3/P4 should be used for Moderate / Minimal Impacting Incidents, Normal or Standard Changes and Service Requests.


Incident 

Priority 1 – Critical Impact / System Down

A Business Critical software component is inoperable or critical interface has failed. Users are unable to use the program resulting in a significant impact on operations. This condition requires an immediate solution. Priority 1 applies to Production Servers or Production Applications only.

Examples:

System Down: Maximo is not accessible; The Browser returns an error message when trying to load the Login Page.
Critical Impact: Users can log in to the Maximo; Saving records is not possible.

Priority 2 – Significant Impact

A software component is severely restricted in its use causing significant business impact. The Program is usable but is severely limited.
Priority 2 applies to Production Servers or Production Applications only.


Examples:

  • More than 75% of users are affected.
  • Multiple applications are failing. Some system use is still possible.
  • A single application is failing, e.g. no Invoice records can be approved.
Priority 3 – Moderate Impact

A noncritical software component is malfunctioning, causing moderate business impact. The Program is usable with less significant features.
Priority 3 can apply to Production and Non-Production Systems.

Examples:

  • A single application is failing.
  • A single Invoice record cannot be approved.
Priority 4 – Minimal Impact

Minimal Impact: A noncritical software component is malfunctioning, causing minimal impact.
Priority 4 can apply to Production and Non-Production Systems.

Examples:

  • A sub-part of an application is failing, or a single user is affected.
  • A Task-Level status change does not occur but does not affect the progression of the record.
  • The user is unable to enter a transaction (Labor, Material) but was able to previously.

Change 

Priority 1 – Emergency Change 

Emergency Changes are defined as changes required to restore service immediately or to avoid an outage where no other workaround is available. Upon approval, a Change Request may be entered after change implementation and associated with a Priority 1 incident.
Emergency Changes apply to Production Servers or Production Applications only.

Examples:

  • Fix at DB level to resolve an issue
  • Applying an IFIX supplied by Vendor
Priority 2 – Not Applicable to Change

Priority 3 – Normal Change

A Normal Change is a planned change that can be carried out within agreed timescales and complies with the client's change advisory board process, where applicable.

Examples:

  • Configuration Change
  • A patch that is not related to a P1 incident
Priority 4 – Standard Change

Standard changes are a pre-defined subset of Normal Changes that have been identified as having no impact, or outside the scope of the Change Management process. Standard Changes require the submission of a Standard Change Request for tracking and recordkeeping purposes but will not have an associated approval process.

Examples:

  • Rule file Changes

Service Request 

Priority 1 – Not Applicable

Priority 2 – Not Applicable

Priority 3 – Medium 

A medium priority Service Request would be a request to create a new user in our Maximo Client Support System.

Priority 4 – Low 

A low Priority Service Request would be Questions or How To requests.

 

 

 

 

 

 

Resources

Read, watch and download our videos, brochures, case studies and insight documents. 

Newsletter Sign-up