Next to white papers, case studies are the most popular tool in the technical marketer's toolkit

The ubiquitous case study can range from a 3- paragraph online snippet to a full-blown magazine article. The most popular case study in the marketing/PR arsenal is the 500-700 word success story. They're not as challenging to write as white papers, but you should structure them for maximum impact.

Different companies use different structures for their case studies, but all should follow the same general pattern: 1. Company overview and challenge 2. Project details 3. Positive results (of course)

Customer Overview and Challenge

Start with a 2-3 paragraph overview of the customer's company. This should be very positive - since you're going to detail a problem the customer was having, the last thing you want to do is make them sound like jerks. So compliment them. Feel free to adapt the overview from their own Website text, where they're already placing themselves in the best possible light.

Then move on to the business challenge. Don't make the customer sound stupid or incompetent. The challenge should always be centered on something good that is happening to them - fast growth, industry prominence, strategic IT changes - whatever. Their challenge should be applicable to your readers' own business issues.

Project Details

No project goes perfectly, but save the debriefing for the longer-form trade journal article. These short case studies should report on the successful project by briefly discussing specific products and benefits.

Don't go all over the map. If the project is fairly narrow or specific, you won't have any trouble sticking with the main point. In the case of large and complex installations, concentrate on the main point. For example, Microsoft Great Plains has more modules than you can shake a stick at. Concentrate on the ones that had the most positive impact on your customer.

Business Benefits

Always quantify improvement when you can. Numbers can be dollar savings, percentages, or other measures of saved staff time, more efficient workflows, better customer service, etc. Be sure that the benefits you list are the benefits the customer perceives - hard costs are most easily quantified, but soft costs may have the higher perceived benefit to a customer. Ideally you will list both.

When NOT to Write a Case Study

What are the most common blocks to partnering with a customer for a case study?

1. Your customer is really unhappy. They'd do a case study all right, but you wouldn't want them to. If you're the hapless individual setting up the initial interview, be sure that the customer really is happy and is open to talking to you. Otherwise they'll just give you an earful. Fix: promise the customer that you'll pass on all of his comments to the technical support team, or whoever you think will best handle it. Then do it, and forget about it.

2. Customers who fear their market will punish them. Prime example: legal firms with security issues. Sure you helped them through a security project and now they're Fort Knox, but they don't want their clients to dream that a problem ever existed in the first place. Fix: Forget it. They'll never give you permission to produce the study. Besides, they're probably right.

3. Your customer is an exacting IT type who is suspicious of the success story format. This customer considers the project a success too, but they dislike purely positive spins - and no project is perfect. Fix: If they are happy for the most part, get a buy-in that the project really was successful. Don't put him off about the negatives, capture those comments too and promise to pass them on. (Then do it.) This is usually enough to secure the interview.

4. Your customer is scared to be interviewed. This is usually the IT guy who did all the footwork, and prefers to stay behind the scenes. He (or she) will either be too nervous to talk, or will despise you because he doesn't think you've got the technical chops. Usually both. Fix: Understand the technology you're interviewing about. You don't have to be an engineer, but you should understand IT pressures and issues. Ask leading questions, but if they clam up and won't talk, thank them and hang up. Tell your customer contact that you're so happy you got to talk to the technician, and now could you talk to a project manager too?