Whitepaper

An article on a site ends when the reader leaves. The trouble starts when that reader wants to use what they read inside their own company. What a practitioner evaluating a tool needs is not an explanation but something to put in front of their management, and a blog post is hard to place there.

Sofia heard that request three times in a row at Pagedeck. People evaluating the product asked whether there was material they could use for an internal write-up. She sent blog links, and one of them came back saying it read like promotion rather than something the company had published. A link pasted into an internal email didn't carry the weight needed to reach a decision maker.

A whitepaper is built to carry that weight. It puts evidence where assertions would be, names its sources, and comes as one file. Offering it as a download in exchange for contact details also means you know who read it.

Twelve to twenty pages is typical, split into six parts. Keeping the order is half of what makes this format work.

1. A one-page summary. Put the conclusion at the front. When a practitioner forwards this file to a decision maker, that page is all the second reader reads. Write the other nineteen pages well and drop this one, and the handoff breaks.
2. The problem. State what the problem is and who it lands on, with numbers. Not "meeting notes get scattered" but "62 of 100 people responsible for them failed to find the current version last month."
3. The evidence. Attach data and sources. For your own research, give the sample size and when it was collected; for outside material, the institution and the year. A number you can't source is better left out — one questionable figure pulls the whole document's credibility down with it. One sourced figure carries more than five unsourced ones.
4. The approach. Describe how the problem can be solved at the level of method. Don't name the product here. What the reader came for is a way to handle the problem; once that convinces them, the product comes next.
5. Examples. One or two short instances where the method actually worked. Covering one customer's results in depth is the job of a case study, so a few lines are enough here.
6. The next step. Put one call to action (CTA) on the final page. A demo request or a consultation — one, not three. Line up three and none of them gets pressed.

Keep product content under a fifth of the total and place it at the back. If the first half is a product introduction, the file can't be used for an internal write-up, which removes the reason this format exists.

More than one person writes it, and more than one person reads it.

Three roles build it. A marketer sets the topic and structure and works the prose, someone who actually knows the subject supplies the evidence and the method, and a designer lays it out with tables and diagrams. At Pagedeck, Ravi takes the front of that and Sofia passes along what she hears from customers. Start to finish it takes two to four weeks, which makes one or two per quarter a realistic pace.

Readers split into two. One is the practitioner who downloaded it; the other is the decision maker that practitioner forwards it to. The first reads the problem and the evidence, the second reads only the summary page. Because both have to be served by one file, the opening page and the dozen pages behind it are written for different readers.

Distribution is fixed. A landing page, the standalone screen built to drive one action, collects a name and an email, and the file goes to whoever submits it. The contact details left behind are a lead, and that's the line between this format and an article left open to everyone. The exchange also filters: someone unwilling to leave an email was unlikely to forward the file either.

It gets read in the middle of an evaluation. The problem is known and the approach is being chosen, and no product has been picked yet. It stays useful for a year or two, and once the research figures inside go stale it starts subtracting credibility instead of adding it. Numbers tagged with a year have to be refreshed or pulled when that year passes.

"This is three blog posts stapled together. Without evidence it can't be used for an internal write-up."

The format looks right while failing the job it exists for.

"Seven of the twelve pages are about the product. Push that to the back and fill the front with the problem."

The structure and the reader's purpose have come apart.

"We can't reuse last year's survey figures. The source carries the year on it."

The age of a number sets the credibility of the document.

Ravi built a twelve-page document on keeping meeting notes in order. The first page was pulled out as a conclusions-only summary, results from an internal survey of 94 responses went into the problem section with the sample size and collection date attached, and product content starts on page eleven.

Downloads over three months came to 340. Tracing the ones that turned into conversations, Sofia found that in most of them the practitioner said they had forwarded the file to their manager as-is. Pulling out the summary page paid for itself right there. Most downloads produced nothing at all, and Ravi treats that ratio as normal for the format rather than as a failure.

The most common reading is that length is what makes something a whitepaper, because twenty pages is the first thing you notice. What actually separates this document is whether it can be cited. Citability, not page count, is the test. Sources attached to the evidence are what let a reader copy a line into their own report. Write twenty pages of unsourced assertion and people will download it, but the file won't travel to a second person inside their company.

Reading download counts as the result is the other one, since it's the easiest number to collect. What this format is after is the file passing through one more pair of hands. If 340 downloads produced no forwarding, all that accumulated is contact details, and the place to fix is the summary page and the evidence rather than the advertising.