Home
  Directory of Free Articles
  Submit and Receive Articles Free
Submit your Articles Free 
Retrieve Free Artices for your WebSite  

SUBMIT YOUR ARTICLE chessbaron.co.uk | www.fine-jewellery-boxes.com | Private Equity

Can't find what you're looking for? Search:


10821 - 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 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?





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 760-249-6071 or e-mail her at chris@keywordcopy.com, and start that white paper selling!





This article was posted on July 07, 2004







Free Articles Content is King - Get better SEO and search engine traffic by articles from TooBoring Inc.

Now on

TooBoring Inc. Categories: Home | Chess | Coping with Grief | Sales | Marketing | Public Speaking | Auto and Trucks | Business and Finance | Computers and Internet | Education | Family | Food and Drink | Gadgets and Gizmos | Health | Hobbies and Interests | Home Improvement | Humor | Kids and Teens | Legal | Men | Music and Movies | Online Business | Parenting | Pets and Animals | Politics and Government | Recreation and Sport | Relationships | Religion | Self Improvement And Motivation | SEO and Site Promotion | Travel and Leisure | Web Design and Development | Women | Writing

submit articles                   Other Sites  |  Visitor Stats  |  Contact
“Baron Turner (also known as Barry) is a participant in the Amazon Europe S.à r.l. Associates Programme, an affiliate advertising
programme designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.co.uk, Javari.co.uk.”