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.
Once the TDX Req is marked complete, Otto will see that and will mark the Refresh Ticket Complete within 12 hours. This ends the refresh process.
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 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 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 type.
Add Comment