Case History Formatting

Research shows that over 70% of customers base at least part of their buying decisions on simple trust and credibility. In other words, they base it on faith that you can solve their problem.

And while there are a number of ways that you can create this trust and credibility during the marketing and sales process, providing prospects with case histories about past instances where you've helped other customers is one of the fastest, easiest, least expensive, most scalable, and most reliable ways available.

To be sure, people have many different views about what a case history is, and what functions it serves. For example, many companies publish case histories to illustrate the features and benefits, or applications, of their products or services. Others publish case histories to promote their brand. And still others publish case histories to motivate and educate their salespeople.

In our experience however, the most important function of the case history (besides garnering attention) is to establish trust and credibility between you and your prospect, particularly early in the sell cycle. And while there are many ways to do that - such as with how you conduct yourself on a call, or with references (which we'll talk about later) - only a case history that's properly written can reliably build trust when you're not around.

Getting more specific, the goal of the case history, in our view, is to create the belief in the prospect's mind that you understand their needs and problems, that you have a solution, and that you are driven to deliver the benefits of solving their problems for them. This is what builds trust, because if the prospect believes that you genuinely understand his problem, he is more likely to believe that you will direct your efforts to solving it - especially when he's not there to direct you. And it creates confidence because your public acknowledgment of the benefits you delivered to your previous customers implies that you will be driven to deliver these same, or analogous, benefits for your next.

In other words, case histories are all about creating a belief - a belief in you.

In contrast to stories, case histories that focus on the features and capabilities of the product are, by definition, disconnected from the customer and his needs, and therefore they don't create trust. This is because when you focus primarily on your capabilities, you're focusing on yourself - not the customer. And therefore the prospect can't relate to it. Likewise, case histories that promote your brand are meaningless to a prospect (in B2B, at least,) who is standing there with a mess on his hands. He's not interested in who he associates himself with at the moment; he's only interested in cleaning up the mess.

Even references are extremely problematic in creating trust and credibility. You can begin to understand why if you consider that most business owners (as well as their marketing and sales staffs) spend inordinate amounts of time, effort and money articulating the uniqueness of their company and its products. To then imply (via your case history) that they're just like some other company (or worse, just like a competitor from whom they may be actively trying to differentiate themselves,) is inherently alienating to them. And so reference-based case histories can actually do more harm than good.

(In fact, in our view, references in general are fundamentally flawed, as they reflect an inability of the decision-maker to actually make a decision - and so, instead, they trust someone else's decision-making process. But that's a story for another day.)

In any event, looked at this way, a case history need be nothing more than a short story with a beginning, a middle, and an end. In the beginning there was a business with a problem. In the middle, you came along and solved it. And in the end there was a satisfied customer who was better off than they were before - as you ride off into the sunset. You can embellish it a little, such as by talking about what failed solution the customer tried before they called you, which adds a little drama. You can throw in some element of urgency due to impending doom. And you can add an epilog about how great life became for the customer after you finished doing your thing. But it's basically a three-act play - a bedtime story for the decision maker who, for a very obvious reason, can't fall asleep.

With this as background, we can now talk about the two primary types of case histories, attributed and unattributed. That is, given that we're going to tell a story about an instance where we helped a customer, we have a choice: Should we identify the customer or not?

In our experience, case histories that identify the customer are simply not as effective as case histories where the customer's identity is masked. This is partly because of the "I'm not like them" uniqueness argument from above. And it's partly because the identity of the customer distracts the reader from the point of the story. Making matters worse, case histories with attribution are also far more expensive and time consuming to produce. They inevitably involve legal issues. And they always suffer from the "too many cooks spoil the broth" syndrome.

But if you're going to insist on attribution, here's how to write it:

Key Elements in Writing Effective "Attributed" Case Histories

The most important factor in writing a case history with attribution is having a contact in the customer's organization who is committed to getting it published. If you don't have an internal advocate or sponsor, then the process will get bogged down in the information-gathering phase, and it may never come to fruition.

Because of the need for a sponsor, though, you should assume that whomever you recruit is going to want to get something out of their sponsorship. It may be recognition, such as by being quoted, or being formally associated with a successful event so that they might qualify for a promotion. Or it may be something more, such as recognition for their boss, or publicity for their company. This, of course, brings office politics into the picture; but you may actually be able to use this process to your advantage.

Regardless, your sponsor must have the authority to provide you with the information you need, as well as the ability to guide the document through the various approvals. This will generally include, at least, the marketing and legal departments. But it may also include the functional departments that were involved in the application. And so your development process for the case history should start by identifying the approval chain in both the customer's and your organizations, even before you start writing. And if there are third party approvals involved, they need to be identified as well.

Once you've identified the approval process, you can begin drafting the case history. As described above, the basic outline of the paragraphs that make up a good case history is as follows:

1. Background of the customer (who they are, what business they're in, what their goals were/are)
2. Description of the problem, who was affected by it, as well as its costs and consequences. Ideally, you should also talk about what would happen if the problem weren't solved.
3. Optionally, you can talk about what the customer tried to do in order to solve the problem, but that didn't work.
4. Describe that they called you, that you assessed their needs, and that you implemented your solution. (This section should be brief, ideally as if you delivered a "black box" solution.)
5. Describe the resolution of the problem, and the benefits that the customer gained as a result of your having solved the problem.

Once you've created this draft of the case history, you can then start shopping the approvals. Note that creating an attributed case history begs for those whose approval you need to embellish it like a Christmas tree. For example, if you need the approval of a Product Manager, he or she is likely to want to include extraneous information about the product. If you need the approval of a Marketing Manager, he or she is going to want you to include extraneous promotional verbiage. And if you need the approval of the Project Manager, he or she is likely to want to brag about the project.

In each case, you'll need to make a choice as to whether to include the information or not. In our experience, everything that you add that dilutes the drama of the story ("there was a damsel in distress, and you came along on a white horse and saved the day") should be resisted. But because you opted for attribution, which necessitates approvals, you may not have such flexibility.

As you request approvals, you will inevitably be driven to interview other participants, add verbiage, and gain additional approvals. In our experience, your best approach will be to accept all input, and allow the document to grow to monstrous proportions. Be sure to annotate the document with the source of the extra verbiage, though, as that will make it easier to remove it later on when you go for your second round of approvals.

Once you've gathered everyone's input, do your best to organize it in the form discussed earlier, i.e. the five paragraph essay. Because you now have a lot of extraneous material such as product descriptions, branding verbiage and project descriptions, you may be able to get away with placing some of it in insets (e.g. text boxes) rather than in the main body of the case history, which can preserve your format. But if not, then you will be stuck with an editing job - one that may end up burying the whole drama of the piece.

Either way, after you've drafted a working version of the case history that includes the input from all of the relevant (or irrelevant, as the case may be) departments, you should now go for your next round of approvals. Ideally, there won't be many more additions, modifications or deletions, but be prepared to have to re-draft the document, and re-solicit your approvals. And again, do whatever you can to preserve the core of the story (i.e. there was a problem, it was painful, they called us in, we solved it, and things got better). But it may be a losing battle.

Key Elements in Writing Effective "Unattributed" Case Histories

At LeadGen.com, we recommend the use of unattributed case histories. We believe that using a case history that identifies the customer runs the risk of alienating prospects who read it because most are heavily biased by claims of their own uniqueness. And so suggesting that the prospect is just like another company, specifically one that clearly has a problem, is fundamentally insulting. And it therefore inserts an immediate "personal" objection into the sales process.

In addition, attributed case histories are often embarrassing to the customer involved, as they publicly display a weakness (albeit one that has now been solved). Most companies are justifiably loath to show the spot on the back of their tie, but you risk asking them to do it when you ask for attribution.

Attributed case studies can also take months of work to complete, and may involve multiple departments, interests and legal issues. Each approver will have their own agenda, and will often add paragraphs that distract from the primary purpose of the piece - that of creating trust and credibility by demonstrating that you can solve problems. Unattributed case histories, on the other hand, are fast and easy to produce, and can tell the story the way you want it to be told.

To be sure, some people will raise the objection that a case history that has attribution has more credibility. But as we indicated before, most prospects will prefer to distance themselves from the subject of the story - even if they have the exact same problem. ("Oh yeah, we know those guys. And we're nothing like them!") And so credibility is actually destroyed by attribution. And attribution often makes the story irrelevant.

Other people will raise the concern that a case history that has attribution can also serve as a reference, an application example, or an illustration of value. But this raises a number of issues. First, asking an important document like a case history to do double duty is unnecessary. Testimonials (assuming that you collect them) are a much less expensive way to achieve the reference goal. Sell sheets are a much more effective, and a much less expensive, way to describe applications. And a simple Economic Value to the Customer model is a much more meaningful way to show your ROI.

Nevertheless, another thing that prospects will ask is "What's it like to do business with you", for which a case history is also often seen as an object lesson. A problem arises with attributed case histories, though, in that we tend to tell too much in them. That is, when we tell a simple story about a customer who has a problem, and about how we came along and waved a magic wand to make it go away, the prospect is reassured. But when we lard it with names, we start to look like we're bragging - and it becomes about us rather than the customer. And when we pile on product capabilities, promotional jargon or process steps, it becomes a novel rather than a short story; and doing business with you starts to look complicated rather than simple.

Instead, we recommend that you produce pure, unattributed case histories, as many of them as you possibly can, that stand alone as morality plays, short stories where the victim is rescued from a fate worse than death by you and your band of merry problem solvers - which brings us back to the basic outline, with one notable exception in the first line:

1. Background of the customer (what type of business they're in, what their goals were/are)
2. Description of the problem, who was affected by it, as well as its costs and consequences. Ideally, you should also talk about what would happen if the problem weren't solved.
3. Optionally, you can talk about what the customer tried to do in order to solve the problem, but that didn't work.
4. Describe that they called you, that you assessed their needs, and that you implemented your solution. (This section should be brief, ideally as if you delivered a "black box" solution.)
5. Describe the resolution of the problem, and the benefits that the customer gained as a result of your having solved the problem.

Clearly, this type of document doesn't require approval from the customer, and so its cycle time can be measured in hours, not months. It's inexpensive to produce. And it's focused on doing the one job it needs to do: to create credibility that you understand the customer's problem, and have to ability to solve it.

What more do you need?

An Example

To illustrate the methodology, below is a case history that you can use as a template. Hopefully, it will help you understand how to write a good case history, while showing how it engenders trust and credibility in the vendor (who just happens to be us).

The Problem:

A 100-year-old Philadelphia-area metal fabrication company was an expert in building "large round things" like pressure vessels, tanks, and high-end storage equipment for food processors and manufacturers. But their business had taken a significant downturn in the recent past, and they needed to penetrate some new markets in order to survive. This was complicated by the fact that the owner wanted to retire, and was looking to sell the company. But the lack of new business in their pipeline was jeopardizing the sale.

What They Tried:

Leveraging their experience in high-pressure processes, the company's three-man sales team tried targeting the power generation market, but they couldn't get in the door. They went after the utilities directly, who told them to call the systems manufacturers. But when they went after the system manufacturers, they told them to call the utilities. So the company ended up spending six months and tens of thousands of dollars going around in circles, and the sale of the company was on the rocks.

Our Solution:

Through a mutual friend, the company asked LeadGen.com to take a look at the problem; and, on examination, several things became clear. First, the company was positioned poorly. They were trying to sell on the basis of their capabilities, instead of their applications and value. And they were giving up way too early in what turned out to be a very long and complex prospecting process. We quickly re-positioned their offerings, however, and developed a multi-pronged prospecting approach to go after the systems manufacturers - targeting planning, manufacturing, resource management and sales simultaneously.

Results:

When you're selling large, complex industrial items, it doesn't take many sales to have a big revenue impact. And when you find one need, you often find a lot of problems behind it - which is exactly what happened. LeadGen.com got the client into two of the largest power generation manufacturers in the world, both of whom had critical shortages that the client could address, and both of whom quickly placed large, early orders for equipment.

The sales that resulted from the program amounted to more than $6,000,000, which was more than 200% of what they had booked the previous year. And it generated substantial, positive cash flow for over two years following the close, and insured that the sale of the company would successfully go through.

Conclusion

In reading this case history, ask yourself, Do you care who the client is? If you're like most people, the answer is no. Knowing it would probably be a distraction. And in fact, if you're like most people, you're probably thinking about your own sales problem, and how maybe LeadGen.com might be able to solve it.

And that's the point.

To enter / edit your own Case Histories, click here.