The Working Case Study

Next to white papers, case studies are the most popular tool in the technical marketers 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. Theyre 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 customers company. This should be very positive - since youre 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 theyre already placing themselves in the best possible light.

Then move on to the business challenge. Dont 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.

Dont go all over the map. If the project is fairly narrow or specific, you wont 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. Theyd do a case study all right, but you wouldnt want them to. If youre the hapless individual setting up the initial interview, be sure that the customer really is happy and is open to talking to you. Otherwise theyll just give you an earful. Fix: promise the customer that youll 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 theyre Fort Knox, but they dont want their clients to dream that a problem ever existed in the first place. Fix: Forget it. Theyll never give you permission to produce the study. Besides, theyre 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. Dont 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 doesnt think youve got the technical chops. Usually both. Fix: Understand the technology youre interviewing about. You dont have to be an engineer, but you should understand IT pressures and issues. Ask leading questions, but if they clam up and wont talk, thank them and hang up. Tell your customer contact that youre so happy you got to talk to the technician, and now could you talk to a project manager too