Unified Web Feedback

If you really want to let us know what you think, there’s any number of ways you can let us know, but these days, we should expect you to chose the web as your primary channel. In other words, we should support you pretty well on Sun’s multiple web venues if you want to provide feedback on our products, services, or simply to let us know that the x4100 page has an apostrophe in the wrong place (which was probably something Iv’e done).

The truth is rather more sobering, as it is for many large-scale web sites. That’s not to say we score badly. Its just that there is room for improvement. In the last year, there has been a team at Sun dedicated to resolving all our customer interaction issues, whether it be from first contact on a sales phone line, or a click on an email link, or even when you get your hands on a piece of Sun hardware and open the box. They’re even looking at the box. One of the key components of that work is understanding the customer journey from first contact through to resolution. That might be manifest as a phone tree, or telesales lifecycle, or as a web feedback system.

One of our biggest tasks in understanding how to design a web infrastructure to support the wide range of web feedback we receive at Sun, is to map the customer journey from first contact, through task filtering and into an internal feedback system. Broadly speaking, this customer interaction can be categorized in three distinct phases; invitation, submission, confirmation. Within those phases, there are a number of related subtasks and subsystems that actually make the thing run (technical term there), but from a design perspective, we’re really considering how to seamlessly manage the transition between phases and ensure a satisfactory conclusion for our customers. In addition, of course, the whole experience should be simple, consistent and concise.

Its a challenging task, and we’re trying to accommodate multiple feedback types across multiple venues, and, naturally, tight project deadlines (which means I should probably be building wireframes instead of writing this). Where we’re focusing our efforts right now is on just how far we can go with contextually-driven feedback. If we’re able to categorize the invitation in terms of the customer task and the current context, we should, in theory, be able to cut a swathe through a task filtering navigation path and drive straight to the submission phase, where any options or forms are specific to the task. However, we can’t be completely confident that our invitations will always be contextually clean. We’ll often use a global navigation component to host a persistent link, and it wouldn’t be enough to simply assume that because a customer clicked on a link labeled ‘feedback’ in a footer on a product page that they are necessarily wanting to provide feedback on that product. They might just want to tell us the site is very slow today. It may also be true that even though they may have accepted an invitation to feed back on a particular product, what they really want to say is that we’ve actually speelled the product incorructly, which we might call a ‘typo’, which as everyone knows, goes straight to the jitterbug queue labeled ‘null’. Only joking.

Why is it unified web feedback? Well, feedback systems evolve, much like web sites evolve. In fact, feedback and venue, in a multi-venue operation such as we have at Sun, are inextricably linked, so we’ve nurtured distinctly different feedback systems on venues such as sun.com, developer.sun.com, java.sun.com and others. As we try to align operations across venues and increase efficiency for our customers, we’re just trying to get to a place where we can synchronize activities more effectively. As far as design goes, unification, even though I”m cursorily referring to it here, is a sizeable problem, so I’m hoping nobody notices that I haven’t cracked that nut yet.

Listening Post: Aphex Twin: Flaphead