Understanding Nothing

There was an interesting article in April’s issue of Management Science (the paper linked to has a 2000 date, but seems to be the same paper), on how customers behave in invisible queues (such as when they email on-line retailers, or have to wait for a call-center call to be answered).

The authors note research that show that customers adapt their behaviour to their perceptions of what the wait time should be, formed through accumulated expecience, offset by how important their query is to them.

Contrary to common belief, they show that customers can and do change their expectations and accepted delay time based on perceived system performance – in one study of abandoned calls to a call center, they discovered that 38% of calls were abandoned across all delays at peak times between 100 seconds and 240 seconds.

And so they spend a lot of time with graphs and formulae (and circles and arrows and a paragraph on the back of each one…) showing how to model customers’ patience levels.

This is all well and good of course, but seems to miss the more important question of how to actually set customers’ expectations properly in the first place.

At BlackStar we implemented an auto-response system to incoming emails that said something like “Your email is 24th in our queue, and so we should be able to answer it within 50 minutes.”

It was a fairly simple approximation, with no complex predictive behaviour at all – it merely averaged the time taken to answer each of the last 10 emails. But it was good enough. At peak times, or when we were flooded with emails, the time people were told they’d have to wait rose, and we got a lot less customers deciding we hadn’t answered quickly enough and sending another email, or even telephoning (setting off a terrible vicious cycle that could sometimes take days to work our way back out from).

Loads of customers commented on how wonderful it was, several competitors approached us asking how they could buy the technology, and it was mentioned in at least 3 or 4 press reviews as a sign of how customer friendly we were.

We didn’t need or do any fancy impatience modelling – we just knew that the best way to keep the customers happy was to tell them what you were going to do, and then do it.

Jon Udell talks about client- vs server-side scripting with Radio: Radio pages, for example, are dynamically generated but statically served — a strategy that I like very much on the whole, but sometimes chafe at when nifty features like TrackBack and your search extender show up in MT.

For some time now I’ve been considering moving away from Radio. I like a lot of its features, but whilst I can muddle my way around Radio’s macro system, I find it much easier to do things in Perl. And, as the pages are generated, rather than calculated, there’s lots of nifty things I’d like to do, but can’t.

And then it struck me, that actually I could solve both of these problems in one simple step – SSI.

So, I decided to try to implement one feature I’ve been wanting for quite some time: a “further reading”-type feature, like that at dive into mark etc, that tracks referrers back:

I turned SSI on in Apache for my blog directory, and wrote an Apache Logging Handler that throws the referrer information into a MySQL database. Then I wrote a simple CGI script that tallies up the referrers for a given page, and outputs them as HTML.

Then in my Day Template, I added the line:

<!--#include virtual="/cgi-bin/getlinks?date=<%longDate%>" -->

Now when Radio generates my page, it will include the SSI command in the static page, which in turn will get called at page request time, calculating the HTML to insert in the final document.

Hey presto! Server-side scripting, in Perl, with Radio.

(My only nit is that I have to pass a date with spaces in it as an argument to the CGI script. If anyone knows how I can reformat the ‘longdate’ macro output in Radio, I’d love to hear …)