Skip to end of metadata
Go to start of metadata

Overview of "Manage Help Ticket" Use Case

Respond to help ticket, generating Integrated Observatory events on state changes.


Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All

Metadata

Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Actors Integrated Observatory Operator , Observatory Operator, Help Desk Supervisor, Registered User
References  
Uses  
Is Used By  
Extends  
Is Extended By  
In Acceptance Scenarios AS.R2.01A Operate Marine Observatory, AS.R2.01C Operate Integrated Observatory Network, AS.R2.02A Cruise Support, AS.R2.02C Instrument Life Cycle Support
Technical Notes This use case has an Integrated Observatory slant in some of the handling, but analogous Marine Observatory capabilities and processes exist.
Lead Team OPS
Primary Service Resource Management Services
Version 2.4
UC Priority 4
UC Status Mapped + Ready
UX Exposure ONC, MNC

Summary

This information summarizes the Use Case functionality.

Users generate helpdesk requests for integrated or marine observatory support. The ticket is managed in Jira, being assigned and acted upon over time. As issues cause changes to integrated or marine observatories, operational changes are reflected by the observatories to the appropriate operators, updating the appropriate observatory pages (on the web); but any communications on the tickets and their status occur primarily through updates to the Jira tickets. As the helpdesk support tickets move through operational support stages, changes in their Jira state can be seen using Jira; some ticket summary information may also be viewed from viewing windows in the observatory pages. Operators and users can subscribe to receive email notification of changes in any individual ticket.

Assumptions

  • See Comments section for details re Help Desk support.
  • Help Desk does not have to be on-line for tickets to be triaged and appropriate automated contacts initiated for most urgent tickets.
  • Help tickets can be addressed by Help Team members, system developers, and Marine and Integrated Observatory Operators, but all will be treated equally as Observatory Operators for initial ticket management and response.
  • Failures in Integrated and Marine Observatory components do not automatically generate tickets in Release 2. This policy will be revised, at least for some failure types, in future releases.
  • Details of forms are specified in Comments section.
  • Service Level Agreements (SLAs) will specify the time to provide initial response, and to resolve the problem.

Initial State

User has identified a problem and is ready to describe it in a trouble ticket.

Scenario for "Manage Help Ticket" Use Case

  1. OOI Registered User submits trouble ticket from within Integrated Observatory pages, or via OOI web form
    1. The submitting Registered User assigns priority when submitting the ticket.
    2. Ticket is automatically logged and assigned to "IONHELP" or equivalent in JIRA
    3. Defaults are filled out as indicated in Comments below (in particular, Component field is filled out with resource's unique ID if the entry is made from a Resource page)
    4. A non-OOI-member may submit a ticket, but may have to provide a valid email, and/or satisfy a CAPTCHA-style challenge.
  2. Tickets with certain (TBD) characteristics automatically create out-of-band (SMS or pager) contact to operations support.
    1. Necessary to provide critical off-hours support, when a major system is down causing other problems.
    2. Details of the characteristics and notification methods will be designed during Construction, and/or by Operations teams.
  3. Submitting Registered User receives acknowledgment with Help Desk ticket ID.
    1. This is a Jira ticket number. The Integrated Observatory interface would ideally get the ticket ID from Jira and display it, but sending the Jira email to the reporter is an alternative.
  4. Submitting Registered User can review ticket status and progress at any time.
    1. Will have to know the ticket ID, or can see recent history of tickets for a component at that component's page.
    2. This means that the IONHELP tickets must be publicly visible, or Integrated Observatory can display them. Ideally both.
  5. The submitting Registered User adds a comment to the originally submitted tickets.
    1. This could be simply email response. For OOI account holders, it will be possible to interact with Jira as well.
  6. Any operator can subscribe to all tickets, or tickets that meet certain criteria.
    1. This helps operators be sure no tickets relative to him or her are ignored.
    2. Jira provides email notifications to support this.
  7. Initial ticket allocation to operations teams is based on identified component, if any.
    1. Component can be set by Integrated Observatory based on source page, and guessed by Jira based on content of subject.
  8. Help Desk Supervisor reviews all tickets and their assignments, revising as needed.
    1. Help Desk Supervisor has first responsibility to triage unassigned or wrongly assigned tickets, gathering any information needed to assign it to an appropriate staff member.
    2. Ticket priority may be adjusted by the Help Desk Supervisor. If adjustment lowers the priority, an explanation of the change is conveyed to the submitter before or as the change is made.
    3. If ticket assignee is an Integrated or Marine Observatory Operator, the assignee should acknowledge the notification in Jira.
    4. Remaining use case steps are performed by Integrated Observatory operations team only if the ticket is their responsibility. (Other operations teams may follow the same model for their tickets.)
  9. The Help Desk alerts the submitter that the ticket is being worked on and initiates analysis.
    1. This happens via Jira in all cases.
    2. For Urgent tickets, announcements of the service issue is made to the support team.
    3. Acting Observatory Operator will analyze the ticket and provide first level support, gathering any additional information from submitter if needed.
    4. Results of analysis are documented with the ticket.
    5. Help Desk supervisor assigns ticket to Development or Systems Engineer if not resolved.
  10. Work on ticket is resolved and verified
    1. Diagnostic and repair steps are documented in the ticket.
    2. Engineer identifies the problem and resolves the ticket
    3. Resolution of tickets related to Integrated and Marine Observatories is forwarded to the appropriate operators.
    4. Engineer assigns ticket to Quality Supervisor for verification (to be confirmed)
    5. Quality Supervisor updates ticket with status of resolution (to be confirmed)
  11. Help Desk Supervisor updates submitter (the Registered User) with resolution status
    1. Includes whether fix is immediate or put into next release

Scenario Graphic

Final State

Ticket has been addressed and resolution documented.

Comments

There should be a category for tickets that relate to Integrated Observatory functions (e.g., IONHELP). Any tickets auto-generated by the Integrated Observatory would use this category.

The user can complete a form, either from within the Integrated Observatory or the OOI web site, specifying a problem/issue/request. Needed inputs include:

  • Name (automatically filled in if from Integrated Observatory; additional unique identifier information, like unique observatory ID of the user also may be added to ticket)
  • Email (automatically filled in if from Integrated Observatory)
  • Telephone (only if call-back desired and not a member)?
  • Integrated Observatory software version number (automatically filled in if from Integrated Observatory)
  • Date and time (automatically filled in)
  • Identifier of Component affected (automatically filled in if known by Integrated Observatory; additional unique identifier information, like serial number or UUID of the component, or its unique label in that observatory, also may be added to ticket)
  • Subject
  • Message
  • Priority — categories include these or equivalent:
    • Urgent — Critical component or service unavailable
    • High — Critical component is degraded but usable, or non-critical component is down
    • Medium — cannot access a file, feature not working, bug, etc.
    • Low — request a new feature, improvements, suggested screen layouts, etc.

Help Desk office Work Hours will be defined. (The current Work Hours are 8 AM (Eastern) to 5 PM (Pacific) Monday through Friday.) Initial response from Help Desk is proposed as follows (this information is notional, for readers to appreciate the likely operational scenario):

Priority Initial response work hours Initial response off hours
Urgent 5 minutes 15 minutes
High 5 minutes n/a
Medium 15 minutes n/a
Low 1 hour n/a

Resolution time for those issues within Help Desk's area of responsibility

Priority Resolution work hours Resolution off hours
Urgent 1 hour 3 hours
High 2 hour n/a
Medium 4 hours n/a
Low As time permits n/a

In some cases, resolution is not the responsibility of the help desk, and other organizations' SLAs apply.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B

Labels

r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.