The Working Case Study

The Working Case Study

by: Christine Taylor

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 fullblown magazine article. The most popular case study in the marketing/PR arsenal is the 500700 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 23 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 longerform 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 buyin 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?

About The Author

Christine Taylor is an expert copywriter for the technology industry. Call her today for help with your white paper, trade journal article, case study, positioning document, or any other B2B marketing piece. Call 7602496071 or email her at [email protected], and start that white paper selling!

This article was posted on July 07, 2004

by Christine Taylor