I can hear the protesters. “What do we want? Faster response time! When do we want it? In under 20 nanoseconds!”

Some things have to be snappy. A Web page has to load fast, or your customers will click away. Moving the mouse has to move the cursor without pauses or hesitations. Streaming video should buffer rarely and unobtrusively; it’s almost always better to temporarily degrade the video quality than to pause the playback. And of course, for a touch interface to work well, it must be snappy, which Apple has learned with iOS, and which Google learned with Project Butter.

Those are good, but are not sufficient.

This morning, I went to book a night’s stay at a Days Inn. That chain is part of the Wyndham Hotel Group, and so I had to log into my Wyndham account. Bad news: I couldn’t remember the password. So, I used the password retrieval system, giving my account number and info. The website said to check my e-mail for the reset link.

That’s a good practice, far better than saying, “We’ll mail you your password.” Ugh.

So, I flipped over to my e-mail client. Check for new mail. Nothing. Check again. Nothing. Check again. Nothing. Check the spam folder. Nothing. Check for new mail. Nothing. Check again. Nothing.

I submitted the request for the password reset at 9:15 a.m. The link appeared in my inbox at 10:08 a.m. By that time, I had already booked the stay with Best Western. Sorry, Days Inn!

What happened? The e-mail header didn’t show a transit delay. Certainly, there can be any number of architectural reasons why it took most of an hour to generate an automated e-mail. None of those reasons are good. This is terrible customer service, plain and simple.

It’s not only Wyndham. When I purchase something from Amazon, the confirmation e-mail generally arrives in less than 30 seconds. When I purchase from Barnes & Noble, a confirmation e-mail can take an hour. The worst is Apple: Confirmations of purchases from the iTunes Store can take three days to appear. Three days!

It’s time to examine your policies for generating automated e-mails. You do have policies, right? I would suggest a delay of no more than one minute from when the user performs an action that would generate an e-mail and having the message delivered to the SMTP server.

Set the policy. More importantly, audit the policy on a regular basis, and monitor performance. If password resets are taking 53 minutes to hit the Internet, you have a problem.

Alan Zeichick, founding editor of SD Times, is principal analyst of Camden Associates.