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:
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 our customer support, as many as two-thirds of the steps involved in managing the support request consist not of analysis or writing a new message, but of manually synchronizing these updates from system to system. If only help desk service providers agreed to, and implemented, a common API for sharing and synchronizing information, the overhead of managing support requests could be reduced 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 New Relic is a founding member of the Networked Help Desk consortium. Although I can’t share any specifics on New Relic’s implementation of this API yet, I can tell you that we’re actively discussing the role of New Relic as a help desk tool, and how our application can participate in this federation of services. One idea we are considering is providing an interface for converting Transaction Traces, Errors, and Incidents into support tickets that can be directly linked to and managed by tracking systems. Another is to allow notes or charts to be attached to existing customer support requests.
So stay tuned…