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