The ticket type defaults to USER in the case of an EGI user opening the ticket, resulting in a typical GGUS ticket. Other special ticket types are possible in GGUS:

• TEAM and ALARM tickets have a reduced number of issue types in the drop-down menu, and can be opened only by members of the following VOs:
  • ALICE,
  • ATLAS,
  • CMS,
  • LHCb,
  • Biomed,
  • Belle.
• The CMS VO has an own view of GGUS system providing some specific issue types. CMS issue types can only be selected during ticket submit by registered CMS users.

Only tickets with Ticket type = USER (and Scope=EGI) are considered in this procedure. TEAM, ALARM, CMS tickets are not effectively handled by EGI and are considered "VO business" (directly managed by user communities).

The Scope can be EGI or WLCG. For more information: Helpdesk Features

GGUS Tickets Priorities

EGI DMSU Ticket Priorities

Ticket is created with providing in minimum (see Definitions for the explanation of the terms)

• Subject
• Description of the issue
• Ticket category: Incident, service request, Documentation.

• Type of issue (drop-down menu). IMPORTANT: The drop-down list of issue types varies depending on the ticket type (see Definitions).
  

• Priority: (top priority, very urgent, urgent, less urgent) default: less urgent
  • If customer/user plan to adjust the ticket priority from the default value to 'urgent', 'very urgent' or 'top priority' is asked to make sure to add a justification for this change in the problem description field.
• assigning the proper Support Unit is optional, as , if known; setting the Support Unit is possible through a drop-down menu, showing the Support Units as specified in FAQ_Responsible_Units_(GGUS). Automatically ticket is assigned to TPM support group. IMPORTANT: Selecting either a site from the "Notify SITE" drop-down menu or a support unit from the "Assign to support unit" drop-down menu routes the ticket directly to the selected support unit, bypassing the TPM. If selecting a site name the NGI/ROC the site belongs to is set automatically. Hence the ticket is assigned to the relevant NGI/ROC. Additionally the site will receive a notification about the ticket.

EGI Helpdesk tool submission form: https://ggus.eu/?mode=ticket_submit

Re-Categorization, Re-prioritization, Resolution

• Only tickets with Ticket type = USER are considered in this procedure. TEAM, ALARM, CMS tickets are not effectively handled by EGI and are considered "VO business" (directly managed by user communities).
• Try to resolve ticket. If this is not possible, reassign to proper 2nd line Support Unit FAQ_Responsible_Units_(GGUS)
• The TPM team evaluates the priority suggested by the user when the ticket is opened, checks if it is alligned with the rules for priority assignment (see Definitions) and if needed it corrects the priority; this means that the user can suggest a priority, but the authoritative unit to set the priority is always the HelpDesk.
• The TPM team members feed the knowledge base of the Known Error Database provided and maintained by the Problem Management process.
• The TPM reacts with time specified in EGI_DMSU_Ticket_Priorities
• If needed, the TPM can make corrections on the other parameters of the ticket set by the user if needed (type of issue, ticket category, etc.)
• TPM decides whether the ticket contains:
  • operational incident: service degradation that's still within acceptable level according to the SLA. (e.g. outage of a site for a short period of time). In this case TPM continues with the procedure.
  • a complaint: degradation of a service at a level beyond what is tolerated by the SLA. (e.g. outage of a site 50% of the time). In this case the TPM team assigns the ticket to the EGI Operations directly. EGI Operations will then execute CRM.PR.04 Manage service complaints from the customer on behalf of the user, and close the ticket providing a reference to the service complaint opened with CRM and when it confirmed that the complained is properly handled by CRM.
  • a service request: request for support to use a specific service. In this case the TPM team assigns the ticket to the EGI User Community Support Team (ucst@egi.eu). This team will (following CRM1) will initiate customer support, providing response to the user through the helpdesk ticket.

The first line support is provided by an organisation called TPM – Ticket Processing Manager. The TPM team has members who have very good general knowledge. It is an organisation populated by people provided from the Czech NGI. This organisation is responsible for the routing and processing of all active tickets.

The DMSU reacts with the time specified in EGI_DMSU_Ticket_Priorities

As assigned in step 2.1. For tickets that need developers intervention tickets are assigned to 3rd level support.

Three escalation levels are available in EGI Helpdesk for users/customers:

• Escalating ticket to the support unit it is assigned to,
• Escalating the ticket to the support unit and the TPM on shift,
• Escalating the ticket to the support unit, the TPM and the GGUS ticket monitoring.

The escalation levels are reached one by one. It is not possible to choose one of them.

Longstanding tickets are a subject of escalation.

• Operations Tickets (type OPS)
• Middleware Tickets
  • The monitoring of middleware tickets follows the processes described in this FAQ
  • If there are doubts about tickets, please submit a ticket to Operations SU referencing the tickets in question. Operations SU will then escalate this to Technology Collaboration Board
• Other Tickets
  
  • The monitoring process for non-operations and non-middleware tickets is documented in File:Ticket Monitoring.pdf in detail.

1st line support  (TPM)

2nd line support

3rd line support team 

Each support unit can set a ticket to following terminate statuses:

• solved: a solution is found
• unsolved: for tickets that can not be solved due to any reason. 

Each customer can set a ticket to following terminate statuses:

• solved: a solution is found
• unsolved: for tickets that can not be solved due to any reason

When a ticket is set to 'solved' status user/customer may verify the ticket: This status indicates that a user/customer is happy with the provided solution.

"Verified" tickets cannot be further updated, nor re-opened.