Two Seven

Seth Godin writes in his post License to stall about business-to-business sales. He explains that the majority of people you encounter are empowered to stall, to say ‘No’, since they are easier to train and are safer.

The reason this system evolved is straightforward: the yes people are rare in a typical organization, because they have responsibility and power. So they are busy and need to be protected.

I totally see how this works, but Iimmediately thought that this paradigm was equally relevant in the area of Customer Services.

How often is it that – unless we have a very trivial request – the first person we speak to will be able to help us right away? “I’ll just put you through to so-and-so”, or “I need to talk to my manager/supervisor. Can I call you back?” are par for the course.

I am becoming convinced that for any given company, having quality Customer Service is more important than the quality of their product or service. For a large established company, quality Customer Service seems to me to be more important than sales or acquiring new customers. And yet it seems that the larger the company, the poorer the customer service. They have huge outsourced, off-shore, standardised, systems that have you pushing every number on the keypad before you get through to the wrong department, who aren’t able to help you and aren’t able to transfer you to the appropriate person.

These systems are set up to be defensive – the goal is to reduce cost, which means getting rid of the customer as soon as possible. That is not customer service.

Oh, and customer service also includes website usability, IA and quality of your search tool; read Lance Wiggs’ experience with Dell.

I’ve still not heard back from Dell about the dead graphics adapter in my Inspiron notebook, either. But that’s another post.

Read it here.

I’ve had a blog post in draft for ages, but this isn’t it. The draft post has extensive tables of stats that lie half-finished, but it was getting a bit out-of-hand, so here’s a very abridged version.

The post looked at benchmarking the JavaScript performance of various browsers. Here is a sneak preview:

Of course these stats mean nothing without some explanation, so here goes.
I’m using the SunSpider JavaScript benchmark. You should read what it’s benchmarking – it does a bunch of core JavaScript stuff, like raytracing and string operations and stuff, no DOM or browser API tests.
I ran these tests under Windows XP, on a Dell Inspiron 9300.

My draft post was/is going to also include the browsers on my MacBook Pro, as well as results from the Mootools Slickspeed JavaScript framework benchmark tool.

The results are interesting, especially with IE6 thrown into the mix. The separation between the old and new generations of browsers is clear.
Opera 10.00 alpha was only released yesterday, running on a new rendering engine, Presto 2.2, which utilizes Opera’s new futhark JavaScript engine, and so I expected it to be a bit faster than it is; Safari, FF3, and Chrome are all faster.

Google Chrome is considerably faster that the others.

I do most of my work on the Mac, and so use Firefox with its extensive array of invaluable extensions, particularly Joe Hewitt’s Firebug, and Chris Pederick’s Web Developer Toolbar. On the PC, I use Firefox, and occasionally Chrome, when I feel the need for speed.

Queued outside Vodafone’s Queen St, Auckland, store.

Hi John and Ben!

Jake Scott commented on my previous post and drew my attention to the ASP.NET MVC framework.

Now that Jake mentions it, I do recall hearing something about an ASP.NET MVC framework a while ago.

While this looks like a great step in the right direction, there are already MVC application development frameworks around that can easily produce great front-end code; Ruby on Rails, Django, Cake, just to name a few.

I guess the question isn’t so much ‘why does ASP .NET produce such poor web front-ends?’, but probably something more along the lines of ‘why is the ASP .NET platform chosen to build these sites over other seemingly more suitable platforms or frameworks?’ or even, ‘why are these sites built with a complete disregard for good front-end coding practices?’.

It’s one thing to have the right tools at your disposal, but it’s another to know which tools are the most appropriate for the task at hand, and secondly, how best to use your chosen tools.