...
Refresh Administrators are selected staff in NIT who can create and edit refresh tickets, batches, and configs. Refresh Admins may reschedule refresh tickets in bulk on the Admin tab.
NIT may view all refresh activity and may Reschedule refresh tickets.
Schedule Slot Admins (NIT lead staff) may edit Schedule Slot Preferences, which are necessary to schedule on prem refreshes
Timeline
A Refresh Ticket is Config must exist or be created. It provides the fundamental parameters (including Approvers and Approved Models) for refresh tickets. Any refresh ticket can have any refresh config.
Usually Refresh Tickets are created in bulk and can be managed with Refresh Ticket Batches. Create a Refresh Ticket Batch and provide the serial numbers of the systems to be replaced. The Batch will provide the ability to lookup existing systems and to create refresh tickets in bulk from them.
Refresh Tickets are created by Refresh Administrator, either from a Refresh Ticket Batch, the Bulk creator, or from any existing system
No-Customer tickets advance immediately to pending_ordering.
Customer tickets are flagged to send an email in a business day.
Tickets created before the end of the business day will send an invite the next business morning at 10:05 AM.
Business hours are 5AM-6PM.
Otto knows about Holidays and University Season Days
If the ticket has a delegate, all communications go to the delegate instead of the user
The first page of the Wizard is the location page
Unit Specified Location tickets require no input here. Instead they inform the customer that refreshes take place at a particular location. The schedule slot reminder emails that are sent later also display the unit specified location and indicate the customer needs to be there.
At Home/Remote Customer tickets require a valid shipping address
On Prem tickets pre-populate the form with the existing system’s TDX location data, and prompts the customer to review and/or edit.
If the user provides a different location than the one shown, a Changed Location event and TDX ticket is created to prompt NIT to confirm TDX’s location data for the customer/systems.
The customer has 14 business days to walk the wizard. They are sent two reminder emails, after 5 business days and after 10.
Finally after 14 Days the ticket is automatically advanced to pending_location_information. (tbd)
Pending Location Information tickets are highlighted in the Problems area of Refresh Tickets. (tbd)
Pending Location Information tickets require support staff to fill out the location form for the customer to advance the ticket to pending ordering (tbd)
Pending Ordering tickets are advanced when a replacement system is assigned via the Order Group/Bulk Actions (admin) area of the Refresh Tickets. Refresh Tickets can be advanced with or without order groups.
Refresh Tickets do NOT advance when a replacement system is assigned when editing a single refresh ticket. The purpose of the field on the refresh ticket form is to allow the replacement system to be exchanged/replaced due to hardware failure etc. Help text on the form itself indicates this as well.
Refresh Tickets are immediately set to pending ITSM existence and awaits await a successful lookup in TDX.
This lookup is enqueued and usually happens pretty fast but if there’s a lot of tickets it could several minutes before all of the tickets have looked up. If the system is not discovered in TDX, it will stay in this status. Systems in this status are shown in the Problems focus of the Refresh Tickets page.
On Prem tickets get set to pending schedule slot discovery
Twice a day these tickets are evaluated for advancement if there are enough available schedule slots available in their support team
Upon advancement, the customer is emailed and invited to pick a schedule slot and the ticket is set to pending_customer_scheduling
On Prem tickets can be rescheduled by the customer or support staff (and refresh admins can reschedule in bulk even) or put on hold.
Remote tickets get set to pending delivery and a tracking email is sent to the customer.
No Customer tickets get set to delivery scheduled and a generic 12am schedule slot is created for them.
Remote_customer tickets in pending_delivery and on-prem tickets in delivery_scheduled check TDX every day for ticket installation and completion. When Otto sees the TDX ticket is installed and/or closed, the refresh ticket is updated.
...