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

Version 1 Next »

  • Each part of the 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:

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

  • Refresh Tickets may be viewed from the appropriate link in the Navigate toolbar dropdown.

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

  • If a Refresh Ticket has a Request Item in ServiceNow, there’s a link from the Refresh Ticket’s page:

Overview

  1. A Refresh Admin does discovery work with external tools and works closely with the unit contacts to select machines that need to be refreshed.

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

  3. 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).

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

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

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

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

  7. Once that has been approved, the refresh tickets in the order group are assigned a PO and a ServiceNow INC to track the order process.

  8. Once the new devices arrive at Depot, replacement systems are assigned to Refresh Tickets in Otto.

  9. As soon as the replacement system is assigned, Otto emails the customer inviting them to pick a Schedule Slot to have their equipment delivered.

  10. As soon as a customer picks a schedule slot, the refresh ticket is advanced to pending_delivery and a ServiceNow Request Item is created (link available on the Otto Refresh Ticket) which provides tasks for Depot and NIT in order to complete the process.

  11. Once the ServiceNow Request Item is marked complete, Otto will see that and will mark the Refresh Ticket Complete. 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 its 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 and configured inside Otto by an Otto App Admin (MWS Engineering).

  • No labels