Here’s the final point in a series of four aimed at identifying a “good” IT white paper (and providing helpful hints, should you need to write one). The previous points addressed the importance of the white paper’s introduction, of writing to a specific audience, and of proposing a viable solution. The final point, appropriately enough, considers key features of an effective conclusion.
4. All’s Well that Ends Well…
The first paragraph of the white paper is important, but no less so the conclusion. It should be “practical and memorable,” according to both Michael Stelzner and Ed Gandia, a technology copywriter. And for best effect, it should include a call to action: a clear (doesn’t hurt to say it again) statement that compels the reader to do grab that bull by the horns and make a decision.
The call to action doesn’t have to be overt (an imperative laden with a school principal’s authority), but it should lead the reader towards implementing a solution. Basically, telling readers that a problem exists isn’t enough—the white paper should also tell them how to solve that problem, in a manner that is more targeted and concrete than the introduction. The conclusion (as conclusions generally do) summarizes both the problem and the solution. White papers that aim to go beyond providing information or “thought leadership” may also recommend a specific product, or in the case of IT white papers, a specific IT solution.
That’s the practical part; how to make the conclusion memorable is up to the writer. But again, it might be a smart idea to avoid that smarmy sales pitch, and stick to the facts.
Don’t claim to provide your readers with an “epiphany” (software implementation as religious experience? divinely inspired selections?).
Don’t revert to jargon, because you figure that if your readers have actually made it to the end of the white paper, they must have telepathically acquired everything you learned in your electrical or software engineering degree.
Don’t allude to a solution, shout it out loud.
And don’t cram a bunch of irrelevant diagrams or illustrations in around the concluding paragraphs, as though to distract from the fact that you don’t really have much to offer in the way of a solution. Savvy readers will not be fooled.
Now that you know what to look for in an IT white paper, sifting through the thousands of documents out there will be much easier.
Looking for a specific solution? Check out TEC’s extensive white paper and case study resource site.