From the daily archives:

Tuesday, March 24, 2009


(Click picture to see full-sized)

This is a great example of how poor service design drove an unnecessary support call.

I received my TxTag toll tag in the mail, along with a TxTag starter kit. (TxTag is the Texas version of an EZPass toll tag thingy.)

I read through the welcome letter, looked at the card, and noticed something: the number on the tag did NOT match the number on the welcome letter. My first thought: oh crap, they sent me the wrong tag, and now someone else has MY tag..and is probably racking up toll charges with it!

Great, I thought. Now I have to call the Texas DoT and chase down a solution to this problem. So I picked up the phone, slogged through their barely-tolerable IVR, and finally got a human. When I explained my issue to the rep, he said that everything was actually fine.

It turns out that everyone is actually assigned a *tolltag* number and an *account* number…and even though they both start with a (very Bond-esque) 007, they do not have to match.

Well great…so I basically wasted about 20 minutes feeling like my account was screwed up and figuring out how to contact the agency, only to find out that their poor service design was at fault.

This is not the right way to kick off a relationship with a new customer.

{ 2 comments }

My latest column at UXmatters was just posted. It’s part 2 of my December article “The User Experience of Enterprise Software Matters.” Again, my main points are:

Organizations making enterprise-level technology selections often do an incomplete job of assessing the real-world effects of the new applications they impose on their staffs’ workflows and processes.

and:

The technology selection process typically neglects methods of evaluating the goodness of fit between the enterprise users’ processes, workflow, and needs, and the vendors’ solutions. Organizations could avoid many a rollout disaster simply by testing the usability of vendors’ solutions with employees during a trial phase.

In this part 2, I pick up where part 1’s “j’accuse” leaves off, and actually provide a framework for enterprise user experience practitioners to employ when trying to get involved in the assessment of enterprise software under consideration by their organization. Rather than recap it all here, I’ll just point you to the article.

The User Experience of Enterprise Software Matters ::? Paul Sherman

{ 0 comments }