Submitting an Issue, Request or Change

to the Oregon E-Government Service Desk is easy.  Just navigate to the service desk portal, login and click the 'Submit a request' link at the top of the page.  Choose a form that most closely matches your request type and fill in the blanks.   Once the form is complete, click 'Submit' at the bottom of the page and your submission is complete.

Form submissions and emails to [e-mail] create tickets in the service queue.  An automated response is generated and sent to the submitter when a ticket is created to confirm that the service desk has received the request.  The request will be reviewed and responded to within 24 hours.   These tickets are reviewed in the order of receipt and are either fulfilled by service desk staff or assigned to other NIC Oregon team members for attention.  Assigned tickets are added to a team member's existing work queue and will be addressed in order for the most part.

Here is the basic process that most tickets would follow:

• An issue is received at the service desk
• An automated message is sent to the requester to confirm that the submission was received by the ticketing system
• A ticket is created automatically and appears in the ticket queue

At this point, the first review is conducted by service desk staff.

• Staff attempts to determine if enough information has been included to fulfill the request or verify and begin diagnosing an issue.
• Staff will determine Ticket type and set a priority.  More on types and priority here.
• The submission is either worked by service desk staff or assigned to a team member or group that can address the submission.
• If the ticket is worked by service desk staff, it is completed and closed with a resolution message
• If the ticket is assigned to a team member or group, they will communicate with the submitter to get any more information they may need to progress to a resolution.
• An issue or change will be announced as resolved in the ticket and the ticket will be put in a pending status until the requester verifies the resolution.  
• If the requester does not respond to a resolution in over a week, then the ticket may be closed.
• Tickets may be re-opened by the submitter for several days by simply responding to the ticket email. After several days, a follow up issue that automatically sites the original ticket can be created.

Process for a standard change:

• A ticket is received at the service desk and determined to be a standard change.
• The ticket is assigned to the appropriate team member and a message is included informing the requester of the assignment.
• Team members review tickets about once a day and will provide an estimate for when the change might be completed.
• Some changes are quick turn arounds like password resets and access requests for some applications
• Other changes may take some time like adding items to application menus or standing up new E-Commerce services.  
• If a change is digital, meaning that it is either done or not, it can be fulfilled and the ticket closed with a resolution statement.
• Examples of ticket that might be closed without review are some password resets or configuration updates that are easily verified by our team.
• Examples of tickets that may be held for requester approval might be like adding an item to a drop menu or standing up a new E-Commerce service.

Once the change is verified, either by our team or by the requester, the ticket is resolved.  The ticket closes after 5 days and cannot be re-opened after that. 

 

Process for a non-standard change:

• A ticket is received at the service desk and determined to be a non-standard change.
• The request is assigned to the appropriate team member for review and a message is included informing the requester of the assignment.  

Non-standard changes must be reviewed, requirements obtained, the work estimated and a plan presented to the requester that may or may not include a schedule of the work and estimated costs.  Once a plan is agreed upon, the change may or may not be taken out of the service desk queue and treated as it's own project.  This depends on size and scope of the change.