« December 2003 | Main | February 2004 »
January 4, 2004
To better customer service (Part 1)
Jim writes about developing a passion for excellent customer service as one area he'd like to focus this year.
I recently attended a professional development course to get some formal training on customer service. I've learned customer service in the trenches, as an employee, as a manager, and as a business owner. I was excited to go through a formal class and think about the experiences I've had on my own.
The most important point I got from the class is that good customer service is a learned skill, and is based primarily on good communications, which is also a learned skill. I've worked in a lot of jobs, including my own company, and at each one there was always a lot of discussion (usually in a lecturing or reprimanding tone of voice) about customer service. But I've never received any formal (or informal, even) training in good communications or good customer service.
If I were to hire someone who didn't graduate high school and had no formal training, I could hardly blame them if they couldn't write a decent email or create a P&L for me. Companies even spend several thousand dollars each year on professional training for each employee, to keep them current in their field of work.
Yet when employees can't work effectively as a team, or engage in productive conflicts, or provide good customer service, many businesses seem to draw a blank, and the best they can manage is to encourage employees to do "better" at communicating and customer service.
How?
Formal training is a necessary beginning. Training will give people a direction for improving. Consistent improvements in communications between employees and with customers can only happen when employees (and managers) are given a recipe for change. It will also get people thinking cricially about the underlying issues of communications and customer service, and place them in a frame of mind to analyze and improve their own skills in these areas.
I highly recommend the class I took (the next one is Jan 20). I consider myself pretty good at customer service, and I learned a lot from the class. For those who are not an employee at UofU, I'd recommend finding out if your HR department offers a similar class (they might be willing--even excited--to arrange one if they don't), or find one at a community college or professional training center near you.
Tomorrow I will write about some of the specifics I have learned from my own experience and from the class.
Posted by pete at 8:45 PM
January 3, 2004
Prevent repeat tech mistakes, with tech
I love it when something technical actually works, especially when it's to keep me from looking stupid (again).
Several months ago, I was informed that I was supposed to be submitting quarterly reports on our Internet2 usage. Since a year ago. The report itself is simple (percentage of traffic used by each type of customer), but collecting the data is pretty rough. Since there's a lot of data to analyze, I set up a script to collect the data every day. Then, I decided to save myself some work by setting up a script that runs once a quarter and emails me the data for the report. Then I wouldn't have to remember to do the report.
January 1 when I checked my email, there was the data. Monday morning I'll put the report together, email it out, and maybe get kudos for having remembered to do it.
I've had a few other similar experiences recently. A few weeks ago our login authentication system was acting erradically. Just figuring out what was wrong was tough, since the problem only showed up sporadically, one out of every 4-20 login attempts. While diagnosing, I wrote a script that would repeatedly make login attempts, and from that we were able to find and resolve the problem (kind of--after lots of packet captures, we rebooted the authentication server and everything worked).
This was the second time in a few months that this problem had happened. So I took that script and set it up to make 100 login attempts three times daily and send out a notification if any failed. I don't think we'll be surprised by this issue again.
There are lots of other examples, of how programming a simple (well, usually simple) script has been a critical part of diagnosing a problem or proactively preventing a problem from happening again. Too bad this isn't a book I'm writing, so I could go on.
I've told many people that network engineers are only half as useful as they could be if they aren't programmers. It's issues like this that remind me how valuable it is to know Perl or another programming language well enough to resolve problems on the fly, and make the network more reliable even when it's a rare problem I'm resolving.
Posted by pete at 8:59 AM | Comments (1)
January 2, 2004
TiVo 3x storage, in an hour
One of the projects I've been hoping to finish over the holiday break is upgrading my DirecTiVo (TiVo built into a DirecTV receiver) so it can store more than 35 hours. When I first got it, I thought 35 hours would be more than I could ever use. But after recording a few movies, a few episodes of Monster Garage and Monster House, things start getting deleted before I can watch them.
A few weeks ago I picked up a 5400RPM 80GB HDD off of eBay for $45 (shipping included). Thought I could add at least another 40 hours of recording time.
Tonight I started the process at 11pm. Carefully following the Hinsdale How-to, I backed up the existing drive, tested the backup, and then started on the expansion. I was pleasantly surprised to find that my TiVo had just a single 40GB drive instead of two 17.5GB drives I had expected. This made the upgrade simple and fast. Just add the new drive and tell the existing one about it.
An hour later, my TiVo says that I now have 106 hours of recording time. And I didn't lose any of my settings, season passports, or recorded programs.
Now, if I could find something on TV worth recording. Discovery Specials, here I come.
Posted by pete at 11:55 PM
January 1, 2004
Installing Gentoo Linux, going on 96 hours
After seeing Mike's success with installing Gentoo Linux, I decided to take a stab at it.
Turns out that Linux doesn't work so well installing on non-standard equipment. Like the Sony VAIO R505 laptop. Which has an IDE CDROM connected via the IEEE1394 bus. CD-ROMs boot just fine. But once booted, when Linux tries to read the CD-ROM, it can't find it. I'm sure that Sony has a great story for why this is cool, but it sure is a pain.
Very long story short, I finally was able to boot with Trinux from a floppy, then manually copy Gentoo (Stage 3) onto the hard drive, and bootstrap Gentoo. Of course, once Gentoo was completely installed, I could load the drivers in the right order (SCSI, IDE-over-SCSI, then IEEE1394) so Linux could see the CDROM.
I wish Gentoo had a Stage 4 and Stage 5, which would include XFree, GNOME and OpenOffice. I can kind of cobble that together from the LiveCD, but it's not as smooth as Stage3. So, it looks to me like getting through Stage3 was roughly 30% of the overall process. Compiling XFree, GNOME and OpenOffice are at least as much, if not more time. And I still need to get the wireless card working.
On the other hand, it's darn cool having a Linux installation that is exactly what I want, compiled optimally for my machine, and nothing extra using memory and disk space. Next time, I expect it'll be faster, too.
Posted by pete at 11:27 PM