by Staven Bruce
Date Published June 12, 2012 - Last Updated May 11, 2016

 

It’s Monday morning, sometime after 10 a.m., and my staff is off and running. Providing deskside support services to 7,000 users across a 2,000,000-ft2 campus can be a challenging task at any time. But Mondays are especially rough, as the day blurs and bleeds into a collage of locked accounts, new-user setups, lingering weekend issues, and “urgent” requests.

As my staff of forty scatters across the campus to provide user support, communication becomes more critical and more difficult. Armed only with one-way pagers, when staff members leave their PCs to help customers at their desks, it could be quite some time before they return, depending on where they are going, the complexity of the issue when they arrive, and any unexpected users that might stop them for assistance along the way. Away from their desks, my staff’s ability to respond to customer emails, contact each other, or pick up incident tickets from our ticketing system’s queue grinds to a halt.

This frustrating problem affects not only my team, but also our customers. An obvious solution to this issue would be to purchase iPhones, Androids, or BlackBerrys for the team. However, with that solution comes the costly overhead of service plans, which would more than triple the amount we currently spend on paging services. While we’ve looked at other solutions, such as using laptops, tablet PCs, and even netbooks, the form factor of each has been somewhat problematic. More often than not, our pilot users leave these tools at their desk when they head deskside to help customers, ultimately defeating the purpose. What to do?

The Solution 

The idea comes to me one day while I’m boasting to a colleague about the functionality of my iPod touch. Somewhere between debating the merits of Led Zeppelin and explaining how my preferred digital music player can do everything an iPhone can except make calls, it hits me. Why not deploy iPod touches to the entire group?

Take a moment and consider the device for the enterprise. It’s clear there are some real advantages. It runs on the same iOS as the iPhone, but without the monthly service fee. Using our corporate wireless network, the device could provide on-the-go connectivity and resources for my staff. Right out of the box, staff members can send and receive email through their corporate accounts. And with the latest model, the fourth-generation iPod touch, staff can also use the FaceTime feature to talk to one another, or use the camera to share images of on-screen messages, hardware, wiring, etc., with colleagues. More importantly, staff can stay in constant contact with the customer without having to be at their PCs, and can remotely access our ticketing tool.

After some discussion and planning with my leadership team, we made the purchase and jumped in. As with any new solution, we quickly identified the good, the bad, and the ugly sides of the results. And while the good news is that the devices have been an overwhelmingly positive change for my team and our customers, there are some aspects that have been difficult to navigate. While the difficulties have been few, I think it’s a good idea to call them out (and the benefits, too), so you can see how this solution functions in production and how it might work for you.

The Good

Our corporate campus, like many corporate buildings and campuses today, is completely covered by at least one wireless network. Thus, out of the box, staff members immediately have access to the Internet and to email. Chat and texting applications are available via the AppStore, and iPod touch users can also use FaceTime to talk with other iPhone/iPod touch users.

My staff has found a variety of applications that help them provide support, one of the more popular being an RDP client that gives them the ability to remote back to their PCs and access the tools installed there. Having this kind of functionality, staff members have been able to unlock users’ Active Directory accounts while standing with them at their desks.

In addition, our organization’s ticketing tool has a web interface, so as staff members move around the campus, they don’t have to return to their desks to pick up new tickets. This has been a huge benefit, especially in cases where an urgent ticket comes through; any staff member who is close by the affected user can pick up the ticket while on the way to that user’s desk. So in addition to making staff members more productive on the go, the devices have also improved service delivery time for many basic user issues.

The Bad

No solution is perfect, and this one is no exception. Obviously, screen size can be an issue. Using RDP to remote back to a PC can require a lot of scrolling in and out, which can be frustrating. The harder it is to see smaller items, the more zooming you will have to do.

Also, like many corporate solutions, the campus offers public and secure wireless networks. We have found that we can typically access the resources we need without having to attach to the secure network. Internet connectivity for email and paging is available via the public network, and resources such as our ticketing tool can be accessed via a quick challenge and response. Using the secure network, meanwhile, has some additional challenges. Users on the secure network must access it via VPN, which is easily done on an iPod touch. However, users on the corporate Exchange servers are also subject to a policy that requires mobile devices to lock after a few minutes of inactivity. Locking the device essentially puts it to sleep, which kills the VPN connection. As a result, any images, messages, or emails sent during the time the device is asleep are missed until the next time the user connects to the network again via VPN.

This, of course, is rather problematic for my staff, as staying connected is critical to our response time and our SLAs. While removing the Exchange policy for support staff would mitigate this issue, my team continues to look for ways to have the device lock without going to sleep.

The Ugly

Replacing pagers required us to create paging functionality on the iPods, which proved to be quite tricky. Our ticketing system creates email notifications when an alert condition occurs; however, the subject of the notification and the sender are always the same regardless of alert severity (stage one, stage two, or stage three). Unlike BlackBerrys, iOS doesn’t allow users to set specific ringtones based on the alert conditions in a message. Therefore, if sound notification is on, the same tone is played each time any message is received. For a busy staff receiving lots of email, this doesn’t work.

After quite a bit of research, we came up with a solution that was half application, half ingenuity. We purchased a simple application called Pushmail from the AppStore, at a cost of $3 per device. This application gave us the sound-customization options we were looking for. However, before we could take advantage of this functionality, we needed a way to differentiate the type of alert emails we received. Enter our crack scripter, Ken Franklin.

Ken set up a rule on his local Microsoft Outlook client that would trigger a script whenever an email from our ticketing system was received. The script would parse the emails from the ticketing system to determine whether they were stage one, two, or three alerts. Once the determination was made, the associated .ini file runs and an email notification (featuring a specific subject line relating to the alert level) is sent to the Pushmail servers. The specific condition is picked up by the Pushmail app on the device, which triggers a specific ringtone, notifying the analyst of the alert. The process worked so consistently and so well that we required all staff members to install Ken’s solution on their machines.

While it may sound more like a Rube Goldberg device, it’s actually far less complicated than it sounds. In addition, much to our surprise, we found that the response time on this solution was actually faster than the notifications we were receiving from the older paging system. Having been in production for over a year now, we’ve found that the process functions quite well. However, we don’t expect this to be our long-term solution, with potential changes to the iOS and to our ticketing tool coming in the next year. We think that this solution will soon no longer be needed.

*    *    *    *    *

Ultimately, my staff and leadership team have been thrilled with the results of the iPod deployment. We’ve increased our productivity, as well as our communications with our customers. And while my team has focused solely on the iPod solution, there are other options out there. Any Android or BlackBerry device with Wi-Fi could be leveraged for this type of solution.

At the end of the day, we found that there are options for service desk managers and departments struggling to increase functionality, productivity, and customer satisfaction while keeping costs low and ROI high. The iPod solution has been a tremendous win for my team (and Monday mornings are just a little bit more tolerable now!).

 

Staven Bruce is the POS/FRS support manager for Target. Over the course of his fifteen-year career, Staven has led and developed service delivery initiatives for companies as diverse as Thomson Reuters (home of the iPod solution), Getty Images, R.R. Donnelly and Sons, and the San Joaquin Valley Air Pollution Control District. Staven is also an avid Led Zeppelin fan.

Tag(s): technology, desktop support, practices and processes, process

Related:

More from Staven Bruce :

    No articles were found.

Comments: