The mission of technical communication is light.

The developers build the cathedral. The technical communicators bring light into the building so that it can be used.

Rose window in Toledo // flickr: wentzelepsy

What type of light sources should be used? Halogen? Sunlight? LEDs?

How should the light source  be handled? Chandeliers? Stained glass? Floodlights?

In technical communication, external constraints help to determine how information is delivered. Here are a few typical ones:

• Medical device documentation is regulated, so the documentation must meet the requirements of the regulatory body.
• The form factor of the product can drive documentation decisions. (A printer with a tiny, one-line screen versus a printer with a large, color touchscreen.)
• A product that is downloaded (as opposed to purchased in a box) will require documentation that accompanies the download or is available online.

“She’s stupid.”

That’s what a shopper recently said about a coworker’s daughter, who is working a part-time retail job. The daughter had been explaining the store’s coupon policy to the customer, who didn’t believe the information. A manager came over and then gave the customer the same information. “She’s stupid,” was the customer’s response to the manager.

As a former retail salesperson and bank teller, I cringe when I hear stories like that. Even though it’s been a few decades years since I worked those jobs, the lessons I learned in customer service (and dealing with difficult situations and people) still serve me well today.

Treating a customer with courtesy—even when said customer may not be behaving in a way to deserve courtesy—is an essential component of good customer service. Courtesy itself can help defuse tension.

That rule applies to our work in technical communication, too, even if we’re not running multiple drive-through lanes at a bank. (Yes, I did that.)

When you’re creating technical content, you have multiple “customers” to consider, and you can offer courteous service to those groups in different ways. Some of these customers include:

• Product developers. Getting information from product developers can demand diplomatic skills that rival those of ambassadors. In Technical Writing 101, Sarah O’Keefe and I offer “(Almost) 30 ways to get information from developers” (pp. 84–85). Many of those suggestions reflect common courtesy, including number 4: “Be respectful of the developer’s time and other commitments. Try to group your questions instead of interrupting her constantly.”
• Writers, editors, and other tech comm team members. Projects go a lot more smoothly when a department works as a team, and there are lots of ways you can show courtesy to your coworkers and make work more pleasant for everyone. For example, following your department’s style guide does a lot more than just create consistent content—adherence to the guidelines demonstrates that you are respectful of others’ schedules. They don’t have to take the time to point out or clean up the inconsistencies you created. Also, when you make a commitment about delivering a draft, attending a meeting, or whatever, you follow through. Think about how many times service providers have disappointed you by not keeping promises. That can put things in perspective when you don’t follow through yourself.
• End users. Your end user is the most important customer you have, so all the good customer service you’ve offered developers, writers, editors, and others in your organization is ultimately for that user. You also treat your users well by writing to the correct audience level; writing content that is above the technical level of the product’s users is the equivalent of saying,  “You’re stupid.” (If  retail salespeople call customers stupid, they get fired, and rightfully so.) Making product information available in audience-appropriate formats is another way to offer good customer service, as is making content accessible to all users.  Keeping end users happy is essential. Losing them means your employer loses demand for its products, which in turn means your employer may no longer have a need for your services.

Even though my job titles and responsibilities have changed a lot over the years, the lessons I learned about good customer service and courtesy from my first jobs still ring true today. No amount of technology, single sourcing, or structured authoring has changed those basic rules.

P.S. Here’s the follow-up to the story about the customer who called my coworker’s daughter stupid. The husband of the customer was so mortified by her comment, he asked her to go to the car. He then apologized and paid for the transaction.

Thanks to Peg Mulligan for hosting my guest post at her blog Content for a Convergent World. I wrote about the evolving role of the gatekeeper and the implications for technical communicators. Read the whole thing.