Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Current »

Refresh Overview

Refresh Tickets coordinate refresh activity for customers on campus and at home.

Support Staff can create and manage refresh tickets in bulk. Customers are emailed and invited to visit a customized web page. The Customers screen invites Customers to walk the Refresh Wizard to confirm their location, address, device, peripherals, and software information.

Approvers are provided an interface to approve refresh tickets and are reminded weekly of their unit’s refresh tickets. Approvers are defined on a refresh ticket’s Refresh Config. Once a refresh ticket is approved, MiWorkspace staff order and prepare the equipment.

There are a variety of styles and options that guide the behavior of each refresh ticket.

Styles

  • Remote Customer (@home) Refresh for Windows or Mac

    • Refresh Wizard requires a shipping address. When a replacement system and tracking number are input Otto emails them directly to the customer

  • On Prem refresh for Windows or Mac

    • Invites customer to walk the wizard to confirm on campus address. When a replacement system is provided, the customer is emailed inviting them to pick a schedule slot for a day1 appointment.

  • User Specified Location

    • Invites customer to walk the wizard but specifies a location for them to visit at the schedule slot’s time.

    • Customer picks a schedule slot as normal, but communications stress the unit specified location.

  • A Delegate receives all communication instead of the User for VIPs.

  • No Customer tickets are for labs and loaner systems. No emails are sent.

  • Bump Down

    • Replacement system is provided at ticket creation. Supports legacy/recycled devices.

Options:

  • Can Customize Computer: Without this, the customer is merely notified of which device has been selected for them (the proposed model). With this enabled, the customer is allowed to pick a different device from a list of all approved models for their refresh config, and they may also indicate that none of the available models in the list are adequate.

  • Can Customize Computer Platform: When enabled, this feature also allows the customer to select systems of a different platform than their Proposed Model.

  • Can Request Different Device: If Can Customize Computer is disabled, this allows customers to indicate that the proposed model is inadequate.

  • Can Customize Peripherals: Allows the customer to select any approved peripheral for their organization. This also allows them to modify any peripheral bundle items. If this is not enabled, they simple see any items from their peripheral bundle displayed.

  • Can Customize Software: Allows the customer to request specific pieces of software from a curated catalog.

Schedule Slots

  • Customers pick a Schedule Slot for on-prem refreshes for the day1 time. This day1 time also defines the build/deliver events for depot and NIT.

  • The Schedule Slots that are available to customers are defined by Schedule Slot Preferences. This allows each Support Team to define their own schedule of availability for customer refreshes.

  • Schedule Slot Admins (NIT leads) are expected to define and monitor their Schedule Slot Preferences.

  • Schedule Slots are created each night 5 weeks in the future. Therefore Schedule Slot Changes are not immediately reflected.

  • Schedule Slot Admins may also delete schedule slots from the calendar in order to react to scheduling/staffing issues

Schedules and Reschedules

  • Every Otto ticket creates a corresponding TDX ticket and tasks. Each Refresh Ticket links to its TDX ticket.

  • If a refresh ticket’s day1 must be rescheduled, Otto allows you to Trigger a Customer Reschedule, or directly assign a new schedule slot. When this happens, Otto updates its TDX ticket and tasks, and emails the customer with a new appointment reminder.

Notes

  • Replacement Windows systems are automatically prestaged and Otto closes the TDX prestage task.

  • Otto Emails the Mac Engineering team each time a Mac replacement system for @home is assigned for MDM setup.

  • The emails Otto sends to a customer are logged on the Refresh Ticket. The Audits track the lifecycle of Otto properties, the Events track changes made to TDX and other external sources.

  • Otto sends a Slack message to a refresh ticket’s support team when the TDX ticket is created for on-prem tickets.

The Schedule Slots link on the refresh tickets page provides a calendar overview of all of the schedule slots in Otto. You can filter this calendar by Support Team.

Additionally, calendar links are provided at the bottom of the page that you can subscribe to in order to see the Schedule Slot times on your own calendar.

Terms:

  • A Refresh Ticket has an Existing System which is the customer’s current machine that is being replaced.

  • A Refresh Ticket has a User who is the customer who uses the existing system. The User is assigned from TDX when the Refresh Ticket is created.

  • A Refresh Ticket gets assigned a Replacement System which is the new system that’s being given to the customer.

  • A Refresh Ticket has a Group, which is the Otto group that the replacement system is placed in when it's assigned.

  • A Refresh Ticket has a Support Team, which is assigned from TDX when the Refresh Ticket is created.

  • The Customer eventually picks a Schedule Slot which represents the date and time they are available for NIT to deliver and setup their Replacement System.

Access:

  • 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.

  • Refresh Managers include all of NIT and they may Reschedule and put On Hold refresh tickets. They may also provide location information for pending_location_info tickets in order to advance them -tbd.

  • Schedule Slot Admins (NIT lead staff) may edit Schedule Slot Preferences which provide the schedule for Otto create new schedule slots on an ongoing basis

Timeline

  1. A Refresh 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.

  2. 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.

  3. Refresh Tickets are created by Refresh Administrator, either from a Refresh Ticket Batch, the Bulk creator, or from any existing system

    1. No-Customer tickets advance immediately to pending_ordering.

    2. Customer tickets are flagged to send an email in a business day.

      1. Tickets created before the end of the business day will send an invite the next business morning at 10:05 AM.

      2. Business hours are 5AM-6PM.

      3. Otto knows about Holidays and University Season Days

      4. If the ticket has a delegate, all communications go to the delegate instead of the user

  4. The first page of the Wizard is the location page

    1. 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.

    2. At Home/Remote Customer tickets require a valid shipping address

    3. On Prem tickets pre-populate the form with the existing system’s TDX location data, and prompts the customer to review and/or edit.

      1. 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.

  5. The customer has 14 business days to walk the wizard. They are sent two reminder emails, after 5 business days and after 10.

  6. Finally after 14 Days the ticket is automatically advanced to pending_location_information. (tbd)

  7. Pending Location Information tickets are highlighted in the Problems area of Refresh Tickets. (tbd)

  8. Pending Location Information tickets require support staff to fill out the location form for the customer to advance the ticket to pending ordering (tbd)

  9. 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.

    1. 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.

    2. Refresh Tickets are immediately set to pending ITSM existence and await a successful lookup in TDX.

      1. 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.

      2. On Prem tickets get set to pending schedule slot discovery

        1. Twice a day these tickets are evaluated for advancement if there are enough available schedule slots available in their support team

        2. Upon advancement, the customer is emailed and invited to pick a schedule slot and the ticket is set to pending_customer_scheduling

        3. On Prem tickets can be rescheduled by the customer or support staff (and refresh admins can reschedule in bulk even) or put on hold.

      3. Remote tickets get set to pending delivery and a tracking email is sent to the customer.

      4. No Customer tickets get set to delivery scheduled and a generic 12am schedule slot is created for them.

  10. 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.

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.