In Otto for MiWorkspace Units, Refresh functionality is provided to assist with the tracking of workflow associated with updating a customer’s computer, and it includes communicating directly with the customer and unit’s approver.
New in May 2021: Otto Refresh supports at-home refreshes. A Refresh Ticket has a remote_customer setting that is enabled for at-home refreshes. Remote Customer refresh tickets do not use schedule slots and instead provide a tracking number to the customer for the vendor-shipped devices/equipment.
New in June 2021: Otto supports refreshes that take place at a unit specified location via the unit_specified_location flag. These refreshes use schedule slots like normal on-campus refreshes, but the customer is not prompted for a location and is instead informed and reminded that the refresh happens at the unit specified location (configured by the refresh administrators per-unit).
Refresh Tickets may be viewed from the appropriate link in the Navigate toolbar drop-down menu.
You can also search for Refresh Tickets by system name or customer name.
...
Each part of the Refresh workflow is Audited on the Otto Refresh Ticket object. The Audits link is in the Actions card in the upper left of a Refresh Ticket’s page:
...
If a system is being refreshed, it will show an icon.
...
On a system’s page, if it has a refresh ticket, a link is provided.
...
A Refresh Ticket’s Team Dynamix request and tasks are shown on the Team Dynamix card, and may be refreshed with a button click.
...
The Schedule Slots link on the Navigate drop-down menu 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.
...
A refresh ticket may have a delegate. The purpose of the delegate is to allow a VIP’s assistant to handle the details of the refresh process for them. If a refresh ticket has a delegate, communications go to the delegate instead of the user, but otherwise the process is the same. The user never receives communication from Otto if there’s a delegate.
A Refresh Ticket may have no_customer. Tickets like this don’t have users to receive communication and are used to replace loaners and similar equipment.
Process Overview
...
A Refresh Admin does discovery work with external tools and works closely with the unit contacts to select machines that need to be refreshed.
...
When ready, Refresh Admins bring that data to Otto and create a Refresh Ticket Batch of serial numbers. The Refresh Ticket Batch updates the Otto systems from ServiceNow, and alerts the refresh admin about systems that don’t exist in Otto, systems that require groups, systems that don’t have users or support groups assigned, etc.
...
Once the Refresh Ticket Batch is ready, Refresh Tickets are created. Refresh Tickets are assigned Proposed Models (an exact device model type), customized Peripherals (if needed), a delegate (if appropriate), and set to no_customer (if appropriate).
...
A day after creation time, to allow time for the refresh admin to customize settings, a customer (or delegate) is emailed the customer_begin email inviting them to visit Otto. If the customer doesn’t visit Otto, a follow-up reminder email gets sent a week later.
...
If a customer makes a device, peripheral, or software request that requires approval, the refresh ticket is set to requires_approval and awaits the unit approver to take action. Otherwise, the refresh ticket is advanced to pending_ordering and awaits Depot action.
The Unit Approver has a dashboard in Otto to monitor their unit’s refresh tickets, and a set of controls that allows them to approve refresh tickets. They also get sent an email every Friday summarizing the status of their refreshes and reminding them to take action (if needed).
...
Once the refresh ticket advances to pending_ordering, Depot will take over. Depot will group the refresh tickets into convenient Order Groups and generate a manifest of equipment from them. They use that manifest to create a shopping cart which they send to the unit for final approval.
...
Once that has been approved, the refresh tickets in the order group are assigned a PO and a Team Dynamix request item to track the order process.
...
Once the new devices arrive at Depot, replacement systems are assigned to Refresh Tickets in Otto.
For On Campus (Remote Customer: false) Tickets:
As soon as the replacement system is assigned, Otto emails the customer inviting them to pick a Schedule Slot to have their equipment delivered.
As soon as a customer picks a schedule slot, the refresh ticket is advanced to pending_delivery and a TDX Request Item is created (link available on the Otto Refresh Ticket) which provides tasks for Depot and NIT in order to complete the process.
For Remote Customer tickets:
As soon as the replacement system is provided, the customer is emailed with the tracking number.
For Windows systems, the system is automatically prestaged. Otto closes the Prestage Task in TDX, leaving the setup-uniqname-group task for NIT.
For Mac systems, the TDX workflow is initiated but the Mac Engineering Team is emailed a request from Otto to do the at-home MDM setup.
...
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. Intended to be used with Intune/OOBE for Windows systems. Requires Autopilot configuration by Vendor.
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 ServiceNow data 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 ServiceNow data 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:
MiWorkspace Managers and help desk (NIT, Depot, Help Desk) have the ability to see but not edit Refresh Tickets, Schedule Slots, Device Models, and Peripherals.
Only Refresh Administrators (particular members of Depot and NIT) may create and edit Refresh Tickets.
MiWorkspace Managers (NIT and Depot) may change and delete a refresh ticket’s schedule slot in order to handle the scenario where a customer changes their mind after their schedule slot has been chosen.
MiWorkspace Admins (NIT Leads) may also delete un-selected Schedule Slots in order to clear slots for unit events and staffing considerations.
Approvers for each organization are configured inside Otto by an Otto App Admin (MWS Engineering) by assigning an Mcommunity group.
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 organization, 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.
No Customer: Enabled by default if the help desk tool indicates that this isn’t a primary machine. If chosen, no emails are sent and the ticket immediately advances to pending_ordering.
Remote Customer: Indicates a situation where the device is shipped off-campus, usually by a vendor. For windows systems, this also instructs Otto to prestage the replacement system with the MDM prestage typeRefresh 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
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.
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 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.