> ## Documentation Index
> Fetch the complete documentation index at: https://docs.snowdoughnut.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Landing page brief
> A fill-in workbook for a single landing page: owner, goal, offer, customer profile, and the links to the campaign brief, skeleton, and creative briefs that feed it.
*Fill in the workbook top to bottom. Each section has a concept review dropdown that explains why the section exists so you can decide how to answer it, not what to answer.*
Complete the core sections. They are the minimum a person managing this project needs to hand it off. Open the optional sections only where they apply to your page. If a link doesn't exist yet, leave the field and note who owns creating it.
*Grayed text marked* `E.g. `*is an example. Delete it and replace it with your own. Examples throughout use Doughnut Labs, a company that sells Doughnut Technology, so you can see one filled-in version of the whole brief.*
Owner, developer, URL, goal, offer, customer profile, and the links to the campaign brief, skeleton, and creative briefs.
Traffic and awareness, message priorities, objections, proof, qualification, success metrics, and finished-asset links. Skip the ones that don't fit this page.
Once the core is filled and the linked briefs exist, the page is ready to hand to copy, design, and dev.
## Core sections
### Owner and team
| Role | Fill in |
| :----------------------- | :----------------- |
| [Owner](/glossary#owner) | *E.g. Priya Nadan* |
| Primary developer | *E.g. Sam Okafor* |
| Designer | *E.g. Lin Alvarez* |
| Copywriter | *E.g. Jordan Bell* |
Every brief has one owner: the person accountable for the page from brief to launch, who answers questions and makes the call when the linked briefs disagree. That's separate from the people doing the work. Naming the developer and the creative roles up front means a question about the form behavior or a headline has an obvious destination instead of bouncing around a channel.
Some teams keep this to just the owner and the developer. Others list every contributor including reviewers and approvers. The tradeoff is between a short header that stays current and a fuller one that answers "who do I ask about X" without a follow-up.
### Page URL
**Where will this page live?**
*E.g. doughnutlabs.com/lp/fresh-batch-trial*
The URL is where the finished page will be published. Fixing it early gives the developer somewhere to build, gives paid media the destination to point ads at, and gives everyone a shared reference before the page exists.
If the final URL isn't decided, a placeholder path still helps, as long as it's marked as provisional so nobody hardcodes it into an ad or an email before it's confirmed.
### Goal and conversion action
**What is the one job of this page, and what single action counts as a conversion?**
*E.g. Job: turn cold paid-social traffic into free-trial signups for Doughnut Technology.*
*Primary conversion: user completes the trial signup form.*
*Secondary (not optimized for): newsletter subscribe.*
A landing page works best when it's built around a single job. The goal names the outcome the whole page drives toward, and the conversion action is the specific thing a visitor does that counts as success. When both are explicit, the developer knows what to make prominent, the copywriter knows what every section is driving toward, and everyone can later tell whether the page worked.
A page can still carry secondary actions, a newsletter opt-in or a link to a case study. Naming the one action that matters most keeps those secondary paths from competing with it. A page asked to serve two primary goals equally tends to help neither, and this section is built to catch that early.
### Offer and key message
**What is the offer, and what is the single most important thing the visitor needs to take away?**
| Field | Fill in |
| :----------------- | :------------------------------------------------------------------------------------ |
| Offer | *E.g. 30-day free trial of Doughnut Technology, no card required* |
| Core message | *E.g. Ship a fresh batch of doughnuts to production in one afternoon, not one sprint* |
| Why it matters now | *E.g. Q3 launch; competitors just raised prices, so the free trial is the wedge* |
| Call to Action | *E.g. Start Shipping for Free* |
The offer is what the visitor is being asked to take: the trial, the demo, the download, the purchase. The core message is the one idea they should leave with even if they read nothing else. These come before any discussion of layout or sections, because a page can be well structured and still convert poorly when the offer and the message underneath it are fuzzy.
The offer is the transaction. The message is the reason the transaction is worth it. A page can name its offer clearly and still leave out why anyone should want it, and this section exists to pin that down.
### Customer Profile
**Which customer profile is this page for? Link the entry from the [customer profile library](/customer-profile-library-overview).**
*E.g. Mid-market DevOps leads*
The customer profile is who the page speaks to, pulled from the shared customer profile library rather than re-described from memory each time. Linking the library entry keeps one definition of that customer profile across every campaign, so the copy on this page matches how the same people are described everywhere else.
A page can target more than one customer profile, but each customer profile a page tries to address at once splits the message. Linking the specific library entry, rather than writing a fresh paragraph here, is what keeps this brief consistent with the source and saves the owner from maintaining two versions of the same description.
### Linked briefs
| Resource | Link |
| :----------------------- | :--------------------------------------------------- |
| Marketing campaign brief | *E.g. [Fresh Batch Q3 campaign brief](https://link)* |
| Page skeleton | *E.g. [Fresh Batch LP skeleton](https://link)* |
| Creative brief(s) | *E.g. [Paid social creative brief](https://link)* |
This landing page sits inside a larger system of documents, and the links are what connect them. The campaign brief holds the strategy the page serves. The skeleton is where the page's structure and copy get filled in, built as a separate step after this brief. The creative briefs cover the ads and assets that drive traffic to the page and set the expectation a visitor arrives with.
The links point at live sources on purpose. Each of those documents has its own owner and changes on its own schedule, so copying their contents into this brief would create a second version that quietly goes stale. If a linked brief doesn't exist yet, the gap itself is useful information: it shows what still has to be produced before the page can be built.
### Finished assets
**Links to the final assets once they exist.**
| Asset | Link |
| :--------------------- | :------------------------------------------------- |
| Final copy in skeleton | *E.g. [Fresh Batch skeleton, final](https://link)* |
| Hero image / video | *E.g. [Hero asset](https://link)* |
| Ad creative | *E.g. [Paid social final creative](https://link)* |
| Published page | *E.g. [Live page](https://link)* |
| \[add row] | |
As the page moves from brief to build, the actual deliverables start to exist: final copy in the skeleton, images, ad creative, the published page. Collecting their links in one place turns this brief into the record of where everything ended up, so anyone reviewing or reusing the page later can find the real files instead of hunting through folders and channels.
This section fills in over time rather than at the start. Early on the links are empty, and that's expected; they get added as each asset is finished. A gap here late in the project is a signal that something still isn't done.
## Optional sections
Fill these in where they sharpen the page. Skip any that don't apply. They add detail for the team, but the page can be handed off without them.
### Traffic source and awareness
Optional: the campaign brief may already carry this. Include it here if the developer or copywriter needs it without opening another doc.
**Where is the traffic coming from, and how aware is the visitor when they arrive?**
| Field | Fill in |
| :------------------ | :--------------------------------------------------- |
| Traffic source(s) | *E.g. Cold paid social (Meta, LinkedIn)* |
| Awareness level | *E.g. Problem-aware, not yet aware of Doughnut Labs* |
| Ad or keyword theme | *E.g. "Doughnut deploys that don't go stale"* |
Where a visitor comes from shapes what mindset they arrive in. Someone clicking a branded search result already knows the company; someone hitting a cold paid-social ad has never heard of it and needs a different opening. Awareness level is the same idea from the visitor's side: how much they already understand about the problem and the product before they land.
This lives in the optional section because the campaign brief usually holds it already, and the linked brief is the source of truth. Restating it here is worth doing when the people building the page would otherwise have to leave the brief to find it. Where the two ever disagree, the campaign brief wins, and this field should point back to it.
### Message priorities
**In order, what should the page lead with and what supports it?**
| Priority | Message |
| :--------- | :---------------------------------------------- |
| 1 (leads) | *E.g. One afternoon from idea to shipped batch* |
| 2 | *E.g. No card, no sales call, cancel anytime* |
| 3 | *E.g. Trusted by 400 engineering teams* |
| \[add row] | |
A list of possible messages isn't the same as a plan for using them. Priorities put the messages in order so the copywriter and designer know what leads, what supports, and what can be cut if the page gets long. Without that order, every review turns into a debate about which point should be at the top.
Ordering also makes later feedback concrete. When someone wants to move a message up, the conversation is about the priority list rather than a general opinion about the page, which is easier to resolve.
### Objections
**What might make a visitor hesitate, and what answers it?**
| Objection | How the page addresses it |
| :------------------------------------------ | :--------------------------------------------------------- |
| *E.g. "Setup looks like it'll eat a week."* | *E.g. Show the one-afternoon setup timeline near the top.* |
| *E.g. "Is my data safe during the trial?"* | *E.g. SOC 2 badge and a one-line data policy.* |
| \[add row] | |
A visitor converts when they believe the right things and stop doubting the wrong ones. Objections are the doubts that hold them back: cost, time, trust, whether it actually works. Listing them, and pairing each with how the page answers it, turns a vague "make it persuasive" into specific work the copywriter and designer can do.
The objections that matter vary by customer profile and traffic source. A high-intent search visitor may worry about price and process, while a cold visitor may not yet believe they have the problem at all. Matching the objection to who is actually arriving is what makes this section useful rather than a generic list.
### Proof
**What evidence supports the claims on the page?**
* *E.g. Testimonial: "We shipped a batch in an afternoon." VP Eng, a named customer*
* *E.g. Stat: 400+ teams; 4.8/5 across 900 reviews*
* *E.g. Logo strip: eight recognizable customer logos (with permission)*
* \[add your own]
Proof is what makes a claim believable: testimonials, numbers, logos, certifications, results. Each proof point usually maps to a specific claim or objection, and it does its job when a visitor who doubts the claim sees the reason to trust it right where the doubt would occur.
List the proof the team can actually use, not the proof it wishes it had. A testimonial needs permission; a stat needs to be current and defensible. Writing down what genuinely exists keeps the page honest and keeps the copywriter from building around evidence that was never available.
### Lead qualification
Optional: most relevant when the conversion is a lead or a booked call rather than a direct purchase.
**What does a good lead look like, versus one that wastes the sales team's time?**
| Signal | Fits | Doesn't fit |
| :----------- | :-------------------------- | :------------------------- |
| Company size | *E.g. 50-500 engineers* | *E.g. Solo developer* |
| Role | *E.g. DevOps lead or above* | *E.g. Student, job seeker* |
| \[add row] | | |
When the conversion is a lead, volume alone can be misleading: a page can bring in plenty of submissions that sales then rejects as a poor fit. Qualification describes what a useful lead actually looks like, so messaging, CTA framing, and form fields can attract more of the right people and fewer of the wrong ones.
You don't have to add every filter to the form. Think of this as a shared understanding of who the page is for, which the team can then apply lightly or firmly depending on how much volume versus fit the campaign needs.
### Success metrics
**How will the page be judged, and against what target?**
| Metric | Target |
| :---------------------------------- | :---------------------------- |
| *E.g. Trial signup conversion rate* | *E.g. 6% of landing visitors* |
| *E.g. Cost per qualified signup* | *E.g. Under \$40* |
| \[add row] | |
Naming the metric before launch is what keeps "did the page work" from becoming a matter of opinion afterward. It also tells the developer and designer what the page is optimizing for: a page judged on cost per qualified lead is built differently from one judged on raw signups.
Most pages get revised after launch, and the metric is what guides what to test next. Setting it now gives the first build a standard to be measured against, instead of being called good or bad based on how it looks in review.
## Related resources
* [**Building a landing page**](/landing-page-process) The process this brief runs on, from first brief to registered page.
* [**Landing page library**](/landing-page-library) Check it before briefing a new page. An existing page that fits beats a new build.
* [**Landing page brief concepts**](/landing-page-brief-concepts) The reasoning behind each section in this brief.
* [**Page skeleton**](/landing-page-skeleton) Where the page structure and final copy get filled in after the brief.
* [**Customer profile library**](/customer-profile-library-overview)
* [**Marketing campaign brief**](/marketing-campaign-brief)