Mobile Device Management and the Call Center - High Speed, Low Drag and a Better Experience

Mobile phone customer support has remained essentially unchanged since the birth of the industry. Customers have questions or problems, call up on a landline, and describe their problem to a customer support agent over the phone. The person they talk to, particularly on the front line, is often relatively inexperienced and overwhelmed with a wide variety of often not well integrated systems including CRM, knowledge bases, email and IM. In many cases, runners are then sent to fetch a phone to give the CSR something to work with, while manually describing to the subscriber what to do in order to fix whatever problem the subscriber is calling about. While both phones and support systems have seen incremental advances over the years, in the end, the underlying support model where the CSR tells the subscriber what to do and the subscriber navigates an often confusing maze of menus and choices and tries to manually implement what the CSR is describing has remained unchanged. This manual process is inefficient and increasingly incapable of providing effective support for today's more complex mobile phones. It creates waste of billions of dollars annually and results in unmet subscriber expectations. Fortunately advances in the area of mobile technical support have helped eliminate the human abstraction layer between the support representative and the device. These systems are currently running in some of the largest and most advanced mobile networks on the planet, are deployable in short order, and have a demonstrated ROI.

From Spray and Pray to Trust but Verify " The Evolution of Device Management

Mobile Device Management, or MDM, has evolved from its origins as the Open Mobile Alliance's Client Provisioning Protocol (OMA-CP). Due to challenges with power consumption, bandwidth and battery life, most mobile devices do not keep data sessions open all the time. Even data capable devices don't maintain those connections, but rather only open them as needed. To get around this shortcoming, early device management was accomplished by means of a binary SMS containing provisioning information in XML that was used to configure proxy servers, access points, device management clients, email and the like. The drawback to this approach was that although it got around the inability to reach the device over the data channel, it did not provide any sort of confirmation that the desired configuration or changes had actually occurred on the device. Indeed, these binary SMSs, like any other SMSs, are not guaranteed to get there at any particular time, in any particular order, and in fact are not even guaranteed to get to the device at all. And, once received at the device, there is no guarantee that the device will do anything with them. This connectionless approach has been called by some, "Spray and Pray".

The advent of OMA-DM

Lack of feedback was seen as a shortcoming, and thus the OMA Device Management protocol, or OMA-DM came about. OMA-DM specifies that sessions are started by the server, sending the client "notification", usually in the form of a Binary SMS. The client, upon receipt of this notification, contacts the server, typically communicating via XML over HTTP with authentication on both sides. The biggest advantage that OMA-DM provides is that communications are bidirectional " the client, a mobile device, can provide information to the server. This information includes not only confirmation that management actions have been carried out but also can include diagnostic information about the device. In effect, the write only protocol of CP has been largely replaced by the read/write DM protocol, adding considerably to the value of the solution.

Mobile Check " Establishing a Baseline


 In the call center one of the first applications of mobile device management is the identification of the device that the customer is calling about. Integration with the Interactive Voice Response (IVR) system allows the subscriber to provide information such as the MSISDN or dialing number of the mobile device, while on-hold. Once the MSISDN is known, the MDM server can query the device, which, depending on implementations, can return values such as the MSISDN, IMEI, device make, device model, firmware version, battery level, signal strength, Bluetooth and WiFi status, installed applications and other information useful to a CSR trying to support a device.

A challenge in many markets is the branding of the device, which goes hand in hand with the challenges of supporting an unknown device. The same device could have a number of different names depending on the original market it was sold into, which in the case of GSM networks may not be the same market that it ends up being used in. Branding on the device may be limited to just the OEMs name, just the operator's name or in some cases no visible branding at all. The difficulty of walking a person who may be unfamiliar with the device through the removal of the battery from a device yet unknown to the CSR in order to read the IMEI or other identifying strings located under the battery is obvious. Thus knowing the make and model of the device along with the firmware version alone is of tremendous value by itself " combined with insight into battery, signal strength and the status of power hungry peripherals such as WiFi and Bluetooth and the CSR is presented with a full screen of powerful diagnostic data all available as soon as the caller makes it through the queue and the CSR picks up the call.

InnoPath's work with mobile network operators and device makers has shown that just providing simple information about the device and its state, be that the make and model or more detailed information like the exact version of firmware the device is running, is of considerable value. When considering the nature of the call volume faced by mobile network operators and device makers, the ability to shave a few minutes of question and answer off many common types of support calls is often in itself financial justification for mobile device management.

Mobile Check and Correct " Doing the Needful



 Studies have shown that many of the device related support calls seen in most call centers are related to configuration, with common applications such as Email, APNs, Internet Settings, ActiveSync and MMS being common call drivers. These applications are often poorly understood by subscribers and even with an experienced, skilled CSR it can take considerable time to walk the subscriber through correctly configuring them manually.

A more sophisticated approach involves using the MDM server to query the handset, pulling the observed values for these applications. With resources such as common email provider configuration databases available on the open market combined with knowledge of APNs and MMS settings appropriate to the operator, it is possible to provide expected values for these application configurations. These expected values can be compared with observed values and should a delta exist the differences can be highlighted and presented to the CSR. In such cases it is also possible to provide even a relatively inexperienced CSR with a "one click fix" button which would trigger a DM session which would then reset broken settings to known good values.

This capability of MDM is valuable for a number of reasons. One is that this provides a consistent interface for the CSR. While different devices, such as an HTC Kaiser or Nokia E71 are vastly different from the perspective of manual configuration, the CSR is presented with a single, constant interface allowing fast and easy access to needed parameters and settings.

The other is that this approach, where multiple parameters can be checked and then fixed with over-the-air technology, saves considerable time and while saving time helps eliminate human error. Avoiding discussions of "was that a 'c' or a 'z'" saves time. Beyond just saving time, it also helps ensure that the problem actually gets fixed, which helps with both first time resolution (FTR) and customer satisfaction, directly impacting churn.

Mobile Update " Avoiding Recalls, Pushing Upgrades

Another aspect of MDM involves providing updates to devices in the field. While desktop operating systems provide mechanisms for updates such as Ubuntu Update Manager or Windows Update, mobile devices are typically updated by Firmware Over The Air " or FOTA, a process standardized by OMA's FUMO (Firmware Update Management Object).

The ability to update mobile devices in the field provides the network operator or device manufacturer with some significant advantages in terms of time to market, reducing support costs and providing a better, more bug-free user experience. While the process of updating the phone may at first glance seem simple, under the hood FOTA is one of the more complex device management actions.


 First the device maker provides a new version of firmware. An application running on a PC, the Delta Manager, then generates a "Diff Package". The generation of the diff package involves sophisticated compression algorithms and content awareness, understanding not only source code changes but also address shift and relative references which change across the two versions. Blocks are copied, shifted and moved and the entire process can be optimized for file size, decompression speed or in cases where resources are limited spread across two or more update sessions.

It is also critical for proper failsafe and rollback mechanisms to be in place. A well implemented FOTA client, unlike most firmware update mechanisms, can recover from a loss of power or other interruption without bricking the device. Should errors be detected, the FOTA client should be able to roll back the changes and return the phone to its prior state. Once the update is complete the device should inform the server, providing confirmation of a successful upgrade.

Own the Device

Other capabilities provided by MDM useful in support organizations include Lock and Wipe, a feature defined by OMA LAWMO (Lock and Wipe Management Object) which allows the CSR to remotely lock and if needed, wipe the device. The potential of Lock and Wipe to avoid potentially embarrassing situations if the phone is lost goes without saying. Some clients support factory reset as part of their LAWMO implementation, yielding a very blank slate indeed.

Beyond just keeping sensitive files such as roadmap.ppt, salary.xls or vegas.jpg out of the hands of others, MDM can provide control over device hardware through OMA DCMO, Device Control Management Object. Via DCMO a CSR can turn on or off Bluetooth, WiFi, cameras or even power-cycle the entire device " all useful when trying to provide over the air support.

Wrapping Up

Until fairly recently wireless support has remained pretty much the same, a very manual and highly interactive, time consuming and costly process. With the advent of mobile device management, particularly OMA-DM, which provides not only the ability to configure the phone but also visibility into either what you have done or what you need to do, times have changed. Even Tier 1 CSRs are able to quickly and successfully close fairly complex tickets that would have in the past taken 30 minutes or more of fairly expensive support time. Problems which may have been hard to diagnose are now far easier to resolve and those problems which may have been time consuming to fix can in many cases be dealt with in some cases with a single click. Even relatively conservative financial models have shown the industry-wide cost of delivering customer care to be in excess of $25 billion/year, making first year savings of over $50m a very real possibility for Tier 1 operators. With such savings on the table combined with payback times which can in some cases be less than one year, the question of whether or not do implement MDM for customer care has changed more to a when and how for most major operators.