[Ed. Note: Clearing a bit of backlog from my toPost queue, this has been sitting around since late November. I'll be coming back to this topic soon, as it has been active in my mind. Future posts will result, possibly contradicting several of my points here and hoping to make cleaner distinctions between the various openness types at the end... Look for such buzzy compliance as wiki's, realtime, etc to appear]

Like most technology professionals (and heck, everyday technology users), I spend more of my time than I'd like embroiled in "issues". Issues with the products I use, personally and professionally. When not staring at issues, I periodically find myself musing on what makes for good customer service. Thanks to a bit of a peripatetic career path, I have multiple viewpoints on it, sitting on both sides of the keyboard, as a provider and coordinator, and of course as a recipient of the service provided (and sometimes inflicted) by various vendors I deal with.

Lately I've had the pleasure of observing the engineering team at Mark/Space, and I've concluded that a review of the November 2005 threads in the Mark/Space PalmOS group would be enlightening reading for anyone involved in the provision of technical support.

Some background which may prove helpful in setting the stage...

Mark/Space recently released an upgrade to their Palm OS connectivity software for Mac OSX. This is notable for users in two counts. First of all, Palm has been fairly explicit in their disregard for the Macintosh platform of late, with no planned updates to the desktop software, and a rather well publicized failure to pay attention to basic installation processes on a recent patch update. Secondly, with version 5.0 Mark/Space became the first vendor to provide support (via Apple's SyncServices) for category support between the Palm and Apple's iCalendar and AddressBook applications.

As so many programmers and start ups already know, being first has its risks. Despite previously providing other tools that provide these services (for the Danger HipTop and the Blackberry), the transition to SyncServices for the Palm product quickly proved to be more fraught with peril than any vendor would like to see. Mark/Space's public lists began to fill with negative reports - of dropped connections, mismatched data and, most troubling of all, lost data (insert your own mental note to make solid backups, regularly, here).

But the engineers bounced back admirably. As one reads the unfolding threads, actual developers were involved in answering user questions, providing a degree of detail that could be bewildering, but in its confidence was also reassuring. "Yes," the developers were saying, "we have some big problems here, but we want to fix them, and we need your help to do so." That these emails were sent at all hours of the day, night and weekend was an implicit vote of either the developer's or the company's priority placed on the problems. Issues uncovered in Apple's underlying frameworks were noted as documented for Mark/Space's own vendor. The peculiarities of the PalmOS world were explained.

Importantly, patch releases were quickly placed online and after a pair of them (as of this writing, version 5.02 has been in the wild for a week or so) many problems appeared to be resolved. Not all, but several of the most worrying were. Mark/Space's commitment and relative openness about their struggles was demonstrated,

Not all is perfect, of course. It's proven a bit galling to pay $24.95 (as an upgrade price) for software that quickly proved to be problematic. A T-Shirt or rebate would have been a nice bone to have thrown the early adopters... But the recovery (and the backups!) has taken out most of the bite indeed.

Considering this month along with other support experiences I've had over the last few years, a few thoughts come to mind about what small and large providers should bear in mind - as an organization, but as importantly as individuals involved in daily interactions. Consider this a fungible list of rules, none truly original, the contents in flux, and descriptions largely redundant - because when providing your users with a good support experience, the same issues and solutions will come up again and again and wrap themselves around one another..

Be Open

Make it easy for your customers and users to get in touch with you, by multiple means. Mark/Space runs multiple mailing lists, but also provides a structured incident reporting system. Their developers are good at reminding people to get the bugs into a trackable state whenever possible, but not dismissive of the unstructured concerns raised.

Be Referable

Part of being open is giving people things to point to. Put your FAQs up online, and make them current, though not at the cost of orphaning old versions. Make the email list open to the world when possible. If you have a tracking system, make as much of it user searchable and reportable as economically possible. If only 1% of your community is every going to use it, remember that 1% is almost certainly the 1% that will give you a play by play, a core file, a crash report, and a suggestion that you can actively use.

Use and acknowledge your community

Don't forget that your customers give you more than money. They give you referrals. And they give you ideas about what doesn't work right. Sometimes its things that don't work for ONLY them, but sometimes its things which silently don't work for anyone else either. Take every one of these suggestions and complaints in with grace, even the one-offs.

And if your community is really working, the users in the community will begin to support one another - pointing back to your open FAQs, relating their own fixes.

So what if you've got their money.

So you have the customer's hard earned money, and you have a EULA that makes no representation about the suitability of the product for flying an airplane, washing the car or saving a file to disk successfully. So what? You not only want their money when you upgrade, or when they get a new job at the next growing company. Treating the customer correctly at every interaction - complaint or compliment - keeps you on the positive side of their list.

Explain. Explain and explain some more.

Do you understand the problem? Do you have a decent clue? Tell the user even as you're developing the fix. And if you don't yet understand the problem, ask for the data you need - if users see light at the end of the tunnel, we can be incredibly helpful.

Technorati Tags: customerService, iSync, MarkSpace, PalmOS, technicalSupport, Treo

Posted by esinclai at December 22, 2005 06:53 AM |