Mobile Device Repositories

 CEM, Device Management  Comments Off on Mobile Device Repositories
Nov 212011

One of the first requirement for mobile portals is to provide customized and optimized content which will enable a consistent customer experience throughout the mobile channel. Mobile portals should convert the content to the desired format on the fly before the content hits the consumer device.

In order to do this conversion, portal (or conversion enabling tool underneath it) needs to “know” the device. The device information should be listed in a central repository where it can easily be searched and extracted. Another important point is to have this information stored up-to-date at all times.

Most mobile device management software provide this kind of central repository. Some mobile portal products are also packed with this kind of information. If you are using a commercial and supported product, you can rely on the vendor to maintain this information. (It could be a nightmare to maintain this information by yourself.)

There is a nice, open-source initiative named Wurfl if you haven’t heard about it yet. You can reach it at here.

From this platform, you can download the latest mobile device repository in XML format and use it in your applications.

It also has a web interface where you can search a specific device.

After locating  the device you are looking for, you can reach information categories such as:

  • Product Information
  • Display Information
  • Markup Language/CSS/Ajax Support
  • Ajax Support
  • Playback/Streaming Protocol Support
  • Chips (NFC, GPS etc.)

Having and maintaining an up-to-date device information repository is a must for todays’ mobile telecommunication operator. Delivering a consistent customer experience in the mobile channel, effective support processes, effective device campaigns all require you to have this kind of repository.

From SQM to Customer SLA Management

 SLA Management, SQM  Comments Off on From SQM to Customer SLA Management
Nov 102011
Customers will expect you to deliver the quality of service you have committed in the presales phase. Most of the operators, however, fell short on delivering this expectation and service outages occur every time.Most operators who do not trust their current network, do not implement any customer SLA management process. Lacking an end to end view, these operators just accept trouble tickets coming from the customer side. Also since most telecommunications regulatory bodies enforce customer SLA management processes, CSP calculates the SLAs based on customer facing trouble ticket information.

This reactive, primitive approach is no longer welcomed by today’s corporate customers. These customers expect more reporting capabilities that will also include outages that they are not aware of.

If the customer has a current SQM process, this could be an enabler for an effective customer SLA  management system. When a process name includes  “Customer” in it, you should be careful. If you show an outage to the customer in a report, you give them the option to claim a rebate. Therefore, we, as CSPs, need to adjust the outages after the outage has already occurred.

Most SQM systems will not allow you to edit already occurred outage events.  Therefore, these events should be exported to another system(NW DWH, EDWH ) for further correlation with force-major outage information.

If the CSP has not invested in an SQM solution before, they could utilize a Network Analytics (NW DWH) solution but this will not provide all the benefits that an SQM system brings. The best combination would always be SQM and Customer SLA Management solutions working together in a fully managed reporting environment.

OK, but how can we correlate force-major outage with a service outage information coming from a network probe for example? Or the question should be, how can we identify the force-major? The key component in here could be the service management platform where the problem management processes have been implemented. SQM systems will auto populate resource facing incidents for proactive recoveries. These incidents can after be inspected for a common root cause and if the root cause of the outage is not because an operator fault, it can be excluded in the force-major list.