How to add conditional logic to a landing page that gives buyers an answer

A conditional landing page uses a visitor's answers to decide what happens next. That can mean showing a relevant question, calculating an estimate or displaying a different result.

To add conditional logic well, start with the answer the buyer needs. Then define the inputs, rules and exceptions required to produce it.

This guide walks through a cleaning-service example. The aim is to help someone understand the likely scope and cost of a visit before they contact you, while giving your team a clear brief if they do.

1. Define the answer before you build the questions

“Get a personalised result” is too vague to design around. Write down what the page will actually return.

For our example, the promise is:

See an estimated price range for your clean, what it includes and what we need to confirm.

That result needs more than a number. It needs a service description, a few assumptions and an appropriate next step.

Decide where the page should stop, too. A routine residential clean might be straightforward to estimate. A job involving a specialist hazard should not receive the same automated answer.

These are proposed rules for our example business, not claims about the default behaviour of a template.

2. Separate essential inputs from follow-up details

Ask for information when it changes the estimate, establishes whether you can help or prepares the next step.

For a cleaning estimate, that might include:

• Service: routine clean, deep clean or move-out clean.
• Home size: bedrooms and bathrooms.
• Condition: normal upkeep, substantial build-up or specialist work.
• Relevant scope: details specific to the selected service.

Do not ask for an email address to calculate the number of bathrooms. Keep contact details for the point where the buyer wants you to respond.

A useful test for every question is: “What will we do differently because of this answer?” If the answer is nothing, remove it or move it to a later conversation.

Avoid asking people to assess things they cannot reasonably know. “How many cleaner hours do you require?” asks the customer to do your estimating. Ask about the home and use your own rules to determine the work.

3. Map the conditions in plain English

Before opening a logic editor, make a short rule list your team can read.

For our example:

• If someone chooses routine clean, ask whether they want a one-off visit or recurring service.
• If they choose move-out clean, ask whether the property will be empty.
• If they choose specialist work, explain what information you need to assess it instead of showing a standard estimate.

The point is not to make every visitor follow a different path. Shared questions should stay shared. Only branch where the answer changes what you need to know.

Give each rule a clear condition and consequence. “Show this sometimes” is not a usable specification. “Show the empty-property question only for move-out cleans” is.

Also define what happens when a visitor goes back. If they change move-out clean to routine clean, the old empty-property answer should not quietly affect the new estimate.

4. Keep visibility rules separate from pricing rules

Hiding a question and calculating a price are different jobs.

A visibility rule decides whether the empty-property question appears. A pricing rule decides which service rate, size allowance and approved extras apply.

Write the calculation independently of the screen layout. For example:

Estimate = selected service allowance + home-size allowance + applicable extras.

That is a model to adapt, not a ready-made cleaning tariff. Use your own records to decide the rates and what combinations they cover.

For an extra with a fixed charge, the rule should be explicit: add the charge when the extra is selected and applicable; otherwise add zero. Do not assume hiding a field removes its previous value from a calculation.

For rules with more than one condition:

• AND means both conditions must be true, such as move-out service AND an empty property.
• OR means either condition is enough, such as specialist work OR a location outside your service area.
• A fallback defines what happens when no ordinary rule fits.

ConvertSite's IF function can return different values depending on whether a condition is true or false. Keep separate decisions readable rather than building one large formula that nobody wants to change.

If two rules could apply at once, decide which takes priority. An out-of-area visitor should not receive a confident booking invitation just because the rest of their answers match a standard service.

5. Build the questions, logic and result together

In ConvertSite, use the Components panel to add the inputs and result content, and the Logic panel for conditional behaviour. The builder guide explains the panels and preview workflow.

Name questions and calculations by their job, such as service type, bathroom allowance and estimate total. That makes later changes easier to trace.

Build one complete ordinary path first:

1. The visitor provides the relevant details.
2. Your rules produce a result.
3. The page explains that result and offers the next step.

Then add the alternative paths and exceptions. Starting with every possible variation makes it harder to tell whether the basic journey works.

The Home Cleaning Quote Calculator template is a relevant starting point. It combines service type, home size, condition and frequency, then shows a price range, crew size, visit length and cleaner hours before asking for contact details.

The conditional follow-ups in this guide are suggested adaptations, not a description of every feature already configured in that template. Replace its sample pricing, policies and proof before using it for your business.

6. Make the result understandable and the next step honest

A result should explain what the page has worked out, not simply announce “You qualify”.

For a standard clean, show the selected service, estimated range, included work and what could change the final price. For specialist work, explain why a standard estimate would be unreliable and what your team needs to assess.

Match the call to action to the actual process:

• Request this clean when the team still needs to confirm the job.
• Ask about specialist work when an assessment is needed.
• Check availability only when the next step genuinely checks availability.

A calculated estimate does not establish that you have a team free on the requested day. Avoid turning one useful answer into an unsupported promise.

Make changing answers predictable, too. Newly relevant questions should appear in context. Do not unexpectedly send visitors to another page or move their focus when they select an option. These are practical applications of predictable input behaviour.

7. Test changes of mind, not just the happy path

Open the preview and work through complete journeys before publishing. Test on mobile as well as desktop.

Use a small test sheet with the inputs, expected result and actual result. Include these cases:

• A standard job with the expected estimate and scope.
• Each service-specific follow-up.
• A visitor changing an earlier answer after entering later details.
• An optional extra selected, then made irrelevant by another choice.
• A blank required answer and a hidden field that was previously required.
• Values exactly at a pricing boundary, plus one below and one above.
• An unsupported job that should receive an explanation rather than a price.

Check the result text as carefully as the calculation. The number might update while an old service label or recommendation remains.

If the visitor requests a response, test the handoff using your own test details and a controlled destination. Confirm that your team receives the current choices and the result the visitor saw, without obsolete answers causing confusion.

Keep the rules maintainable after launch

Assign someone to own the pricing and scope rules. Keep the test cases with those rules, and run them again when rates, service areas or available options change.

After launch, look beyond form completions. Are people reaching the result? Do the requests contain usable information? Does the team repeatedly correct the same estimate or explain the same missing detail?

Conditional logic is useful when it helps the buyer make progress and leaves the team with an experience it can maintain. Start with one answer you can reliably provide, build the rules around it and expand only when the next branch earns its place.