When it comes to supporting mobile analytics implementations, what we do after we go live is as critical as what we do before. Technology support is art as much as it is science. If you add to the mix global deployments, remote access, language and cultural barriers, we face a daunting task especially when supported by virtual teams without on-site personnel. Two key elements should guide your approach: quickly identify the root cause for immediate relief and put in place safeguards to prevent future occurrences.
Let’s take a look at several mobile analytics support best practices.
Start with scope and impact
Always start with an assessment of the impact on the user community. You want to quickly identify the scope so you can avoid any unnecessary work if it’s an insulated case. For example:
- Are you able to replicate the issue yourself?
- Are there other users reporting the same or a similar issue?
The goal here is to figure out if this is a system-wide concern.
Identify the mobile analytics layer(s) affected
Mobile analytics implementations consist of many layers that need to be considered when users requestsupport. Think of this like a leak that a plumber needs to find. The sooner you can identify the layer affected the sooner you can address it. For example, determine if the issue is with the:
- Device/App – the user can’t install or open the app
- Access Rights – the user doesn’t see or can’t access the report
- Report – the user can’t run the report and gets an error message
- Content – the user has questions about the data displayed on the report
- Functionality – the user can’t figure out how to do something on the app
Test with a system account or a standard device
For example, if the issue is related to data displayed on a report, you can use a system account that impersonates a specific user’s access rights. If that works, you can focus on other areas.
Similarly, if you suspect a device-related issue, you can test it on a mobile device with standard configuration. You should always have one handy to do a quick sanity check.
Use critical thinking as a doctor should
Once you determine the scope and identify the layer(s) affected, you need to apply critical thinking just the same way doctors should with their patients. Yes, we need to rely on the symptoms that the patient (user) is describing (especially if that’s all we have) but it’s our responsibility to ask additional questions to eliminate as many variables as we can until we can reach a diagnosis or have enough clues to decide on the next steps. For example, if the user is complaining that he/she can’t access the system, ask:
- Is this a new device that the user received as a replacement?
- Is the device current with the latest updates?
- Did the user change roles, resulting in changes with his/her corporate profile?
A picture is worth a thousand words
There’s a reason why we say “a picture is worth a thousand words.” Don’t try to describe or explain to your users where to go on their device (or what to do) if there’s an opportunity to share your screen so they can see exactly what you’re talking about.
Conversely, don’t ask them to tell or describe to you what they’re seeing on their device. Ask them to send you a screenshot of their screen. Teach them how to do this simple task, and you would be surprised how much this investment will pay off.
The longevity of every technology product or project will depend heavily on the quality of your support system. And it all starts with leadership that promotes teams driven by a commitment to excellence in customer service. Such teams will display tenacity, critical thinking, perseverance, and, most importantly, a passion for excellence.
Stay tuned for my next blog in the Mobile Analytics Design series.