TL;DR

This is a long post and I’m infodumping to provide context for the problems I’m facing. I’m working with a particularly thorny migration problem from Aeries Devices to IncidentIQ, and looking for ideas or feedback on how I might improve the process of managing student accountability with Chromebooks for our Device Wrangler staff.

The Setup

Device Wranglers are not IT folk. Most of them are Secretaries or Librarians. Usually there is only one per school site. They don’t have backup. Training is possible but ease of use, speed and simplicity is paramount.

Previously, our Device Wranglers would use Aeries Devices to manage student Chromebooks. When devices were checked in, they could make notes on the asset. Aeries automatically links all previous assets to a student record, so that a Device Wrangler could see the history of the student and their devices. This was helpful in identifying “frequent fliers;” students that would break or lose their device often. This feature in Aeries allowed for documentation and accountability, which could be passed on to the Admin staff at each site. The staff were used to this process, and to their credit, it was reasonably fast to execute. Find student → District Assets → Student Assets→ Checkbox to show all devices ever assigned to the student with notes. Here’s a sanitized screenshot for reference from Aeries.

It’s important to know that this process was both fast and easy for the Device Wranglers. It’s 6 clicks to edit an asset note, and only 5 to view the history of a student’s devices. These folks handle all the mass deployments of Chromebooks to students, so their process needs to be airtight and as on-rails as we can make it. I want them doing less work, not more.

Incident IQ

In IncidentIQ, I’m having a hard time simplifying this process:

1. Look up asset (Asset Explorer)
2. Identify if the Chromebook belongs to the student handing it in (Asset Explorer)
3. Check in the Chromebook (Check In/Out screen or Batch Check In)
4. Create a ticket (if needed)  (Check In/Out screen or Batch Check In)
5. Check out new Chromebook  (Check In/Out screen or Batch Check Out)

Separately, I’m having a hard time simplifying the process of looking up all devices previously owned by a student and what, if any, issues were tied to the device. This issue comes up “frequently,” though what that means in terms of time, energy and cost, I couldn’t say.

I can see all tickets submitted on behalf of a student. I can see in the student’s profile all devices ever un/assigned to the student. I can’t find a way to quickly marry those two views together and also see why a device was issued or removed from the student account. Here are some of the challenges with navigation / ease of use.

1. Checking in an asset doesn’t give you a spot to add notes to the asset. You have to leave the checkin screen to edit the asset and add notes. Adding notes to the asset doesn’t exactly help us in the long run. We’d need to clear the notes field periodically so that old notes don’t carry forward when devices are repaired and reissued. Notes also don’t tie students to assets for accountability. 7 clicks and 1 barcode scan to type in the notes field.
2. Creating a ticket requires stepping through the ticket creation process. Quick Tickets and Ticket Templates aren’t available when creating a ticket from the checkin and asset screens. This takes longer than the previous process. 6 clicks and a barcode scan to the Description field for a ticket, plus 1 click for submit.
3. Creating a View is possible using the “Previous Owner” and “Model Category: Computers > Chromebooks”, but that view has to either be manually filtered to the student in question, or recreated for each use case. In either case, it’s not fast, and requires legwork on the Device Wrangler’s end. 10 clicks to create a functional new view. 4 or 5 to modify an existing (unshared) view.
4. Looking at the Student profile, under Revisions, I can see devices checked in/out to the student. This menu is not easy to find and only provides the serial number. No additional details, notes or tickets. 4 clicks and a long scroll.
5. Looking at the Student profile, I can see all tickets on behalf of (more on this) the student, but no singular view that ties current & previous assets to the tickets. I don’t know at a glance if the 4 tickets submitted for this Chromebook are different devices, or the same device.

To add another wrinkle, we’re trying to reduce the notifications and ticket bloat that our Device Wrangler staff see. See this feature request for more granular notifications. 

To solve for this, we’ve created a rule when a ticket is submitted for Chromebook Repairs, it sets the reporter and “on behalf of” to a service account and removes all followers to mute unneeded notifications from IIQ. Our device wranglers submit 10+ tickets a day and we want their dashboards to only show tickets that are legitimate issues for them, not a mass of tickets for devices that will get picked up and repaired at a future date. Once those tickets are created, they no longer need to interact with the ticket. A byproduct of this rule is that those tickets are no longer tied to the student record, so we lose the ability to report on broken device tickets for those students. I’m working on tweaking this ruleset.

Current Attempts

1. I’ve tried to create both a Quick Ticket and a Ticket Template to streamline the process of getting tickets created. The problem with this effort is QTs and TTs don’t ask for an asset on creation, which negates tying the student to the ticket to the asset and getting that holistic view. They also aren’t available when creating a ticket from an asset or from the Checkin/Checkout or Batch Check In/Out screens.
2. Tweaking the rules engine. I’m working on removing the reporter and followers, but keeping the on behalf of set to the student so we can keep track of the tickets. This gets me closer to my goal of student accountability, at the cost of Device Wrangler time in creating tickets.
3. Tell Device Wranglers not to care as much. This is more of a policy than a process, but our budgets have some buffer for broken devices. We don’t discipline or fine the students if they break devices. So the whole “research frequent fliers” issue goes away if we just stop caring as much about individual devices, and just do check ins and check outs. Our check-in process automatically wipes the device, and missing or broken devices are automatically locked through the rules engine. Either the device will come back from another student, or it won’t and we’ll eat the cost either way. This saves Device Wranglers time because they’re just blindly checking devices. No student accountability.

Conclusion

Device Wranglers are constantly bouncing between the Users and Assets tabs, trying to find devices the student used to have before checking out a new device. It involves lots of copying and pasting, clicking through for notes, and is generally a slower and more complex experience than what they were used to.

They also want to help. They want to give us info about the broken devices, and keep students accountable for damaging district resources. IIQ has made this harder for them, and that’s not cool.

All right, that was a lot. I worked through some things. I think we’re all tired. So, what tools in IncidentIQ can I use to help these poor beleaguered folks be more productive?