Building Web 3.0

This article was originally published on the New Relic blog.

When many technology experts speculate on the "next big thing" for the World Wide Web, several commonly mentioned concepts include the Semantic Web, personalization, and intelligent search.

Although these are useful concepts, none are particularly new or revolutionary -- especially when compared with Tim O'Reilly's definition of Web 2.0. Personalization has been around since the late 1990s, when Yahoo! launched the personalized web portal, and Amazon started offering personalized recommendations based on your shopping history. XML has been widely used for over 10 years. Semantic data standards such as Resource Description Framework (RDF) and Web Ontology Language (OWL) matured around 2004. And personalized search tools have been available for many years.

What's lacking from the Web 3.0 conversation is any discussion of interaction and integration between applications and web sites. It's one thing to be able to export, import, and mash-up data. But synchronizing changes to data entities is still either a manual process, or one that requires developing customized integrations with proprietary web services. And when a company employs multiple services to manage various parts of the business process, as mine does, time spent managing that data synchronization adds up quickly over time.

Let's focus on a particular example: the help desk. For many technology companies using cloud services to manage customer support, their environment looks something like this:

Help Desk Services in the Cloud

While many service providers offer an API to allow data to be exported or imported, and even modified in some instances, there has been a lack of common semantics to allow updates to a support request to propagate automatically between these systems. For instance, if a customer support issue is related to a system bug, updating each system of the progress can be a tedious and time consuming process to keep the customer informed of progress, and when the fix is deployed to production.

Although the internal process of managing customer support requests often can be highly customized to suit the requirements of a particular organization, most support tools are built around a common paradigm:

  • A customer sends a support request, or an incident is automatically generated by an incident monitoring system. We'll refer to these requests as tickets.
  • Tickets have a progress status.
  • Tickets are updated with annotations and attachments. These annotations may be public (visible by the customer), or private (visible only to support staff).
  • Customers should be regularly notified of the progress of and updates to a support request.

For many customer support organizations, as much as two-thirds of the overhead involved in support requests involves the manual synchronization of updates from one system to another. If only help desk service providers agreed to, and implemented, a common API for sharing and synchronizing information, these systems could be easily integrated, reducing the overhead of managing support requests greatly. Furthermore, customers would receive more frequent and timely notifications of progress.

Enter the Networked Help Desk: a new open standard for customer support management. This API will allow service providers to seamlessly integrate development tracking, issue tracking, CRM, application monitoring, and call center service systems and create a more efficient and effective customer support infrastructure. I'm very excited that my company is a founding member of the Networked Help Desk consortium, and look forward to sharing the progress of this effort in the future.

Posted by george Thu, 14 Jul 2011 18:15:00 GMT


Trackbacks

Use the following link to trackback from your own site:
http://stardragon.com/trackbacks?article_id=24

Comments

Leave a response

Leave a comment