A requirements document that every vendor can tick is not a requirements document — it is a brochure request. The one-page format in this guide replaces feature wishlists with your workloads, your numbers and your disqualifiers, and it will do more to shorten your shortlist than any comparison chart.
Start from workloads, not features
The standard failure mode is writing requirements as a feature list — HTTP/3, WAF, instant purge, edge compute — because every serious vendor claims every feature, so the list eliminates nobody. Workloads discriminate where features cannot. "Deliver a 40 GB game patch to 200k concurrent downloaders on launch morning" and "serve a checkout page that must never cache" and "stream a nightly live event to Gulf audiences" are requirements that vendors meet very differently, even though all three map to the same feature checkboxes. Write down your top three to five workloads as one-sentence scenarios with the audience, the object type, and the moment that stresses it. Everything else in the document exists to serve those sentences.
Put numbers on everything
Each workload sentence then gets its numbers: monthly volume (GB and requests — requests matter more than most buyers expect, per the pricing analyses in this library), peak-to-average ratio, object size distribution, cacheability split, and audience geography by country, not region. If you do not have these numbers, extracting them from origin logs or your current CDN's reporting is the first task — a requirements document without numbers produces proposals without numbers, and you will be comparing adjectives. Two numbers deserve special care: the peak (because capacity questions are the ones vendors answer most evasively) and the geography tail (because the last 10% of your audience often drives the shortlist more than the first 90%, as the regional surveys in our comparison section show).
Separate must-haves from disqualifiers
A must-have written as "support for signed URLs" invites a checkbox. The same requirement written as a disqualifier — "we eliminate any vendor whose token scheme cannot be validated in our existing player SDK without a client update" — forces a real answer. Convert every genuine constraint into disqualifier form: compliance boundaries (data residency, sub-processor lists), technical integration limits (your DNS setup, your certificate policy, your CI pipeline), and commercial red lines (no auto-renew, no per-rule pricing surprises, the contract clauses covered in how to read a CDN contract). Three to six real disqualifiers is normal; twenty means you have not decided what matters.
The one-page template
The page has five blocks. Workloads: the three-to-five scenario sentences, each with its numbers. Traffic profile: total volume, request count, peak ratio, cacheability, geography table. Disqualifiers: the hard constraints in eliminating form. Evaluation plan: how you will test — which objects, which measurement points, what passes (the method from the benchmark guide slots directly in here). Commercial frame: contract length you will accept, commit appetite, and the reference-price band you expect, informed by what a CDN should cost. One page is a discipline, not a limit — appendices can carry the log extracts, but if the page itself does not fit on a page, the requirements are not yet decisions.
How to use it in vendor conversations
Send the page before the first call and structure the call as a walkthrough of it — vendors who respond to your workloads with relevant specifics self-select in; vendors who respond with a deck self-select out. Refuse to accept "yes" as an answer to any disqualifier: ask how, in what configuration, at what price line. And keep the page versioned — requirements discovered mid-evaluation are normal, but they should be written down and sent to all candidates, because an evaluation where different vendors answered different questions produces a decision you cannot defend. The page's final service comes at renewal time, when it becomes the baseline for asking what changed.