A request to “build a funnel” can describe very different jobs. One person expects a focused page with a form. Another expects a sequence of messages, qualification steps, and follow-up. A third expects reporting across the entire path. If the brief never separates those expectations, the project can appear complete to the builder and unfinished to the buyer.
A landing page is a destination. A funnel is a model of movement through defined steps. A page can be part of that model, and it can contain several interactions, but the page alone does not explain the whole sequence. The distinction is useful because it changes what needs to be designed, who needs to participate, and what the finished work should include.
The examples here are illustrative. Different offers need different paths, and the appropriate stack depends on the actual requirements.
Ask what happens before and after the page
Start by writing the visitor’s immediate context. What did they see before arriving? What does that invitation lead them to expect? Then write the next action and what happens after it. These three sentences can expose a surprising amount of hidden scope.
For a simple event announcement, the destination might present the date, explain the event, and link to an existing registration service. The page has a focused job. If the registration service and follow-up already work, the project may genuinely be a page project.
For a consultation offer, the destination may be only one piece. The business might need to qualify the inquiry, assign it to a person, arrange a time, and explain what the visitor should prepare. If those steps do not exist, calling the deliverable a landing page does not make them disappear.
Separate three kinds of work
The first kind is page work: structure, copy, images, forms, and the immediate interaction. The second is journey work: how the visitor moves between steps and receives the promised response. The third is measurement work: which actions are observed and how the team interprets them.
A project may include all three, but they deserve separate lines in the brief. A designer can create a clear form without deciding who follows up. A media buyer can choose a relevant destination without controlling the registration system. An analyst can define an event without changing the customer experience.
Naming the work makes the dependencies visible. It also makes the discussion about cost and timing more concrete. Instead of debating whether a “funnel” should include something, the team can point to the specific task and assign an owner.
A simple page can be the right answer
Consider a product announcement aimed at people who already know the brand. The visitor needs a concise explanation and a route to an existing product page. Adding a sequence of extra screens may create more maintenance without helping the visitor make a decision.
The appropriate scope could be one page, a tested link, and a clear statement of where the visitor goes next. The page still needs accurate content and a usable mobile layout. It simply does not need to become a new system because the word funnel sounds more substantial.
A useful brief would identify the source of the product facts, the approving person, and the destination URL. The acceptance review would check those items directly. That is enough structure to keep a small project honest and manageable.
A short page can hide a larger system
Now imagine a business offering a tailored equipment demonstration. The page itself may be brief: a description, a few questions, and a request button. Behind it, the team needs to know the customer’s location, the relevant equipment, and who is available to arrange the demonstration.
The form’s success state must explain what happens next. The receiving team needs enough information to act. If the offer promises a scheduling step, that step needs an owner. The page cannot fulfill the promise by displaying a generic thank-you message while the request sits unattended.
In this case, the project includes a journey even if the visible page is small. The brief should describe the request, the handoff, the response, and any conditions that affect the path. Those details are part of delivering the offer.
Draw a service map before a wireframe
Use a small table to connect the visitor’s action to the business’s response. Keep it practical enough that the people doing the work can correct it.
| Visitor action | Business response | Responsible function |
|---|---|---|
| Reads the offer | Supplies accurate information | Offer owner |
| Sends a request | Accepts and routes the details | Operations |
| Asks a follow-up question | Answers or assigns the question | Customer-facing team |
| Confirms a next step | Records the agreement | Assigned contact |
The table is not a universal funnel template. It is a prompt for finding work that the page depends on. Your path may need fewer rows or different ones. Remove any step that does not serve the actual offer.
Once the table is agreed, the wireframe becomes easier to discuss. A form field can be tied to a downstream need. A confirmation message can describe a real next step. The design has something concrete to support.
Define a page review and a journey review
A page review checks the destination itself. Is the invitation clear? Are the facts accurate? Can the visitor use the form? Do labels and errors make sense? The review should include the sizes and input methods that matter to the audience.
A journey review follows the request beyond the page. Does the right team receive it? Can that team understand the details? Does the promised response have an owner? What happens when a request cannot be handled as expected? A working submit button is only one part of that review.
Keep these checks separate in the project record so that a pass on one does not imply a pass on the other. This is particularly helpful when different suppliers handle the website and the operational systems.
Decide what the measurements can answer
A page-level observation might tell you that an action occurred on the destination. It may not tell you whether the later conversation happened or whether the visitor was a suitable customer. The team should avoid giving one observation a label that implies all those later steps.
Write the question beside the measurement. “How many accepted requests came through this form?” is different from “How many new customers did this campaign create?” The second question requires more information and a careful account of how the records relate.
The same discipline applies to a funnel report. Google’s guide to attribution provides context for credit assignment in Analytics. A report assembled from several systems should retain the meaning of each source, rather than treating every displayed number as interchangeable evidence.
Rewrite the next brief in plain language
Take a current project and replace “build a funnel” with the work that actually needs to happen. List the page, the next step, the receiving person or system, and the review that will show whether the promise is fulfilled. Note any existing service that the project relies on.
If the result describes a single destination, call it a landing-page project. If it describes a sequence with handoffs, include that sequence in the scope. The terminology matters because it helps people agree on the work. It should make the project easier to deliver and review, rather than making a modest task sound larger than it is.