Build a product recommendation quiz with AI

What a recommendation quiz has to do to be worth taking

A recommendation quiz earns its place when it saves somebody a decision they were going to make badly. That means it has to be capable of telling them something they did not already believe, including that the cheap option is enough, or that nothing on the list fits.

The version that fails is easy to recognise. Every path ends at the flagship. Requirements that should be disqualifying are treated as mild preferences. The result appears only after an email address, which turns the whole thing into a form with decoration. None of those are matching failures, they are honesty failures, and visitors detect them faster than you would like.

The demo above is built for a fictional web design studio because a catalogue with four tiers and real incompatibilities is the smallest thing that shows the logic working. Swap the packages for your own products, services, plans or courses and the structure holds.

Hard requirements first, preferences second

The single decision that separates a real engine from a quiz is the order of operations. Requirements eliminate. Preferences score. Elimination runs first, and scoring only ever runs on what survived.

If somebody needs online payments, a package with no checkout is not a weaker match, it is not a match at all. Blending that into a weighted score means a high enough score elsewhere can outvote it, and the quiz will confidently recommend something that physically cannot do the job. The elimination step exists so that outcome is unreachable rather than unlikely.

In this engine the hard rules come from four answers: the main job of the site, its scale, the capabilities marked as genuinely required, and a launch date under three weeks. Budget is a fifth, treated as a ceiling against each package's starting price. Everything else, including how much content help you want and what happens after launch, is preference and can only move a package that is already eligible.

Fixture G on this page proves the ordering rather than asserting it. On the raw fit points the smallest package outscores the largest one, and the engine still refuses to recommend it, because a required capability had already removed it.

The seven questions, and why each one is there

Seven is not an arbitrary length. Each question either eliminates packages, separates two packages that are otherwise tied, or protects the visitor from a recommendation that would go wrong later. A question that does none of those is a question to cut.

Question one asks what the main job of the website is, and it does the heaviest lifting: selling products, running a portal and taking bookings each rule out packages immediately. Question two asks about scale, and it branches. If the job is selling, scale means catalogue size. Otherwise scale means page count. Asking a shop about page count, or a brochure site about product count, is how quizzes signal that nobody thought about the path.

Question three asks which capabilities are genuinely required, phrased as what the site cannot launch without, because a wish list here produces an over specified recommendation. It is the only multiple selection question, and none of these is a real answer that keeps the smaller packages in play. Question four asks how much content help is needed and question five asks what happens after launch. Neither eliminates anything, and both separate packages that the hard rules left tied.

Question six asks how fixed the launch date is. A hard date under three weeks eliminates everything that cannot be built in the time, which is the one place a preference question would do real damage. Question seven asks about budget, treated as a ceiling and nothing else. Budget contributes no fit points anywhere, because letting money add attraction is how a quiz starts steering.

When a branch changes, the answer from the other branch is discarded rather than kept out of sight. Fixture I on this page walks that case: choosing a large catalogue and then changing the goal to enquiries clears the catalogue answer instead of leaving it to eliminate every package except the largest one on a site that has no catalogue at all.

The matching table behind this demo

Every rule the demo applies is published here, and the tables are rendered from the same constants the engine scores with, so the documented rules and the executed rules cannot drift apart.

Read the first table as the catalogue, the second as the eliminations and the third as the tie separators. The prices and timelines belong to a studio that does not exist and are there to make the budget ceiling and the timeline rule do something visible.

Explaining the result, including the packages that lost

A recommendation without a reason is a guess with confidence. The result screen states the winner, gives the specific reasons drawn from the answers that produced it, and then does the part most quizzes skip: it says why each other package was not chosen, naming the requirement that removed it or the margin it lost by.

That second list is what makes the result checkable. Somebody who disagrees can see exactly which answer moved the outcome, change it, and watch the recommendation move. It also does the sales work honestly, because a prospect reading why the larger package was not recommended trusts the recommendation they did get.

The result also shows the answers it was built from, so nothing is attributed to a question the visitor does not remember answering. Compare all packages is available from the result rather than hidden, with the eliminated ones still visible and still explained, because concealing the options that lost is what makes a comparison feel like a funnel.

The no match outcome most quizzes refuse to have

Some combinations of requirements cannot be satisfied by anything in the catalogue. A hard three week launch date with member accounts and a budget under a thousand pounds is not an unusual request, and there is no package that meets it, because the constraints conflict with each other rather than with the catalogue.

The engine says so. It names every requirement that is in conflict, lists what would have to move for something to become possible, and recommends nothing. Quietly pushing the largest package here would hide the fact that the timeline or the budget has to change first, and the conversation that follows would go wrong at the worst possible moment.

This is also the outcome that makes every other outcome credible. A quiz that can say no is a quiz whose yes means something.

Test the engine before you trust it

Matching logic fails silently. A weight typo does not throw an error, it just recommends the wrong thing to a category of visitor you never test by hand. The defence is a fixed set of inputs with known correct outcomes, run every time the rules change.

These are computed live by the same engine the demo runs, so if a rule changes and one of these outcomes is now wrong, this page shows it rather than hiding it.

What happens when someone finishes the quiz

The recommendation is shown immediately and in full. Nothing about it is held back, blurred or exchanged for contact details. If the visitor closes the tab having learnt that they need the middle package, the quiz did its job.

A contact step is legitimate after that, and it works better there anyway, because somebody who has just been told what they need has a reason to talk to you. Ask for the minimum that lets you follow up, say what the follow up will be, and make clear that they already have the answer. Send it to me is a fair offer. Enter your email to see your result is not.

If you do collect anything, send back the same recommendation the visitor saw, including the reasons, rather than a generic brochure. A mismatch between the on screen result and the emailed one is the fastest way to lose the trust the quiz just built.

Data handling is part of the design

The demo on this page submits nowhere. Answers live in component state, they are not persisted, and closing the tab discards them. That is stated on the result screen rather than buried, because a claim about data handling is worth nothing if the visitor has to take it on faith after the fact.

If your version does collect responses, be specific in the same place the visitor answers: what is stored, who reads it, how long it is kept and what happens if they ask for it to be deleted. Quiz answers describing budget, timeline and business requirements are commercially sensitive and should be treated as such.

Keep the recommendation logic and the contact capture separate. When they are entangled, a change to the form ends up changing the matching, and nobody notices until a prospect is told the wrong thing.

The master prompt

This builds the whole recommendation experience as a single self contained page, including every question, the hard eligibility rules, the fit weights and the no match outcome. It carries no Sentway dependency, so it is useful whether or not you ever publish through us. It states the matching logic explicitly, because that is the part an AI will otherwise quietly invent.

Build a single self contained HTML page: a product recommendation quiz that behaves like a real decision engine. No frameworks, no build step, no external requests, no analytics, no fonts loaded from a CDN. All CSS and JavaScript inline. It must work offline when saved to disk.

THE CATALOGUE
The four package catalogue below is a worked example for a fictional web design studio. Build the page with it as it stands. Do not stop and ask me for a catalogue first.
When I give you a real catalogue, replace the example packages, prices, boundaries and capabilities with the real data I supply, keeping the same structure. Never invent a price, a boundary, a supported capability or an exclusion that I have not given you. If a fact about a real package is missing, leave it out and tell me it is missing rather than filling the gap.

EXAMPLE CATALOGUE
1. Launch, from GBP 795, typical build 1 to 2 weeks. Boundary: up to 5 pages. Supports: up to 5 pages, contact and enquiry forms. Does not support: appointment booking, checkout, member accounts, file portal, custom integration, standard CRM or email integration.
2. Growth, from GBP 1,495, typical build 3 to 4 weeks. Boundary: up to 20 pages. Supports: up to 20 pages, appointment booking, standard CRM or email integration. Does not support: checkout, member accounts, file portal, custom integration.
3. Commerce, from GBP 2,750, typical build 4 to 6 weeks. Boundary: up to 100 products. Supports: catalogue up to 100 products, checkout and payments, standard CRM or email integration. Does not support: appointment booking, member accounts, file portal, custom integration.
4. Custom, from GBP 4,500, typical build 6 weeks or more. Boundary: no page or product ceiling. Supports: everything above plus complex workflows, member accounts, private file portal, custom API integration.

THE SEVEN QUESTIONS
Ask one question per screen, with a visible position indicator reading "n of 7".

Q1. What is the main job of the website? Single choice.
- Look credible and explain what we do
- Generate more enquiries
- Let people book or request appointments
- Sell products online
- Run a portal, account area or custom workflow

Q2 branches on Q1. If the answer to Q1 is "Sell products online", ask:
How large is the product catalogue? Single choice.
- Up to 20 products
- 21 to 100 products
- More than 100 products
Otherwise ask:
How much content does the site need? Single choice.
- 1 to 5 pages
- 6 to 20 pages
- 21 to 40 pages
- More than 40 pages
If the visitor goes back and changes Q1 across that branch, DISCARD the stored Q2 answer and ask Q2 again in its new form. Never carry an answer from one branch into the other.

Q3. Which capabilities are genuinely required? Multiple selection. Helper text: "Choose only what the site cannot launch without. Anything here can rule a package out."
- Appointment booking
- Online payments or checkout
- Standard CRM or email integration
- Customer or member accounts
- Custom API or business system integration
- Private file upload or client portal
- None of these
Selecting "None of these" clears the other selections, and selecting any other option clears "None of these". Selecting nothing is not a valid answer; "None of these" is the way to say no.

Q4. How much help will you need with the content? Single choice.
- It is mostly ready
- Help structuring and sharpening it
- I need substantial writing and content help

Q5. What happens after launch? Single choice.
- Mostly leave it alone
- Make occasional changes
- Run campaigns, tests or regular improvements

Q6. How fixed is the launch date? Single choice. Helper text: "A hard date is treated as a constraint, not a preference."
- Flexible, six weeks or more is fine
- Around three to six weeks
- Under three weeks is essential

Q7. What budget range are you trying to stay within? Single choice. Helper text: "Treated as a ceiling against the illustrative starting price of each package."
- Under GBP 1,000
- GBP 1,000 to GBP 2,000
- GBP 2,000 to GBP 4,000
- GBP 4,000 or more, or flexible

MATCHING LOGIC, IN THIS ORDER
Step 1, eliminate. Apply every hard rule that the answers switch on. A package that fails any rule is ruled out and takes no further part. Record the specific reason for each elimination.

Hard rules from Q1:
- Book or request appointments: only Growth or Custom.
- Sell products online: only Commerce or Custom.
- Portal, account area or custom workflow: only Custom.

Hard rules from Q2:
- Up to 20 products, or 21 to 100 products: only Commerce or Custom.
- More than 100 products: only Custom.
- 1 to 5 pages: no elimination on scale by itself.
- 6 to 20 pages: only Growth or Custom. Launch is bounded at up to 5 pages and cannot carry the scale, and Commerce is a product catalogue package rather than a content site.
- 21 to 40 pages, or more than 40 pages: only Custom.

Hard rules from Q3, one per selected capability:
- Appointment booking: only Growth or Custom.
- Online payments or checkout: only Commerce or Custom.
- Standard CRM or email integration: only Growth, Commerce or Custom.
- Customer or member accounts: only Custom.
- Custom API or business system integration: only Custom.
- Private file upload or client portal: only Custom.

Hard rule from Q6:
- Under three weeks is essential: only Launch.

Hard rule from Q7, applied as a ceiling against the starting price:
- Under GBP 1,000: only packages starting at or below 1,000.
- GBP 1,000 to GBP 2,000: only packages starting at or below 2,000.
- GBP 2,000 to GBP 4,000: only packages starting at or below 4,000.
- GBP 4,000 or more, or flexible: no ceiling.

Step 2, score fit. Score ONLY the packages that survived step 1. Add these points.

Q1:
- Look credible: Launch +3, Growth +2
- Generate more enquiries: Growth +5, Launch +1, Custom +1
- Book or request appointments: Growth +5, Custom +2
- Sell products online: Commerce +5, Custom +2
- Portal or custom workflow: Custom +5

Q2:
- 1 to 5 pages: Launch +2, Growth +1
- 6 to 20 pages: Growth +3, Custom +1
- 21 to 40 pages: Custom +4
- More than 40 pages: Custom +4
- Up to 20 products: Commerce +3, Custom +1
- 21 to 100 products: Commerce +4, Custom +2
- More than 100 products: Custom +4

Q3, per selected capability:
- Appointment booking: Growth +2, Custom +1
- Online payments or checkout: Commerce +2, Custom +1
- Standard CRM or email integration: Growth +2, Commerce +2, Custom +1
- Customer or member accounts: Custom +2
- Custom API or business system integration: Custom +2
- Private file upload or client portal: Custom +2
- None of these: no points

Q4:
- Mostly ready: Launch +1
- Help structuring: Growth +2, Commerce +1
- Substantial writing help: Growth +2, Commerce +1, Custom +2

Q5:
- Mostly leave it alone: Launch +2
- Occasional changes: Growth +2, Commerce +1
- Campaigns, tests or regular improvements: Growth +3, Commerce +2, Custom +2

Q6:
- Flexible: no points
- Three to six weeks: Growth +2, Commerce +2
- Under three weeks: Launch +3

Q7: no points at all. Budget is a ceiling only. Never let budget add attraction to a package.

Step 3, pick. The highest scoring surviving package wins. On a tie, the lower complexity and lower starting price package wins, walking Launch, Growth, Commerce, Custom in that order, and record that the result was decided by the tie break rather than by points.

Step 4, no match. If step 1 removes every package, recommend nothing. Show the requirements that are in conflict, and list what would have to change for something to become possible, naming the specific answers involved. Never fall back to the most expensive package. Never fall back to the cheapest package. Never recommend a package that was eliminated.
Keep the conflict explanation short and deterministic. Work out the smallest set of active rules that still cannot be satisfied together, by dropping rules one at a time in evaluation order and only dropping a rule when the remaining set is still unsatisfiable. State that minimal conflict as one sentence, then list every active requirement with the packages it needs as a second sentence. Do not print one sentence for every pair of conflicting rules; that produces several near duplicate statements saying the same thing.

WHAT THE FIT SCORES ARE
Fit points are internal explanation and debug data for this matching model only. They are not a probability, a confidence level, a match percentage or a quality rating, and they must never be presented as one. If you show them at all, show them inside the comparison view, labelled as this page's matching points on the published fit rules.

THE STRUCTURED DECISION RECORD
Whether or not anything is submitted, build the result as a structured object in memory and make it available to the page. It carries: matching_rules_version, a string version of the rules the result was produced under; completed_on, an ISO 8601 timestamp of when the quiz was completed; the answers to all seven questions; the winner id or no_match; the eligibility state, elimination reasons and fit score for every package; and the explanation strings the visitor saw. A stored recommendation without matching_rules_version and completed_on cannot be interpreted later, because you cannot tell which rules produced it.

THE RESULT SCREEN
Show the recommendation immediately and in full. Do not gate it behind an email address, a sign up, a timer or a scroll. Show:
- The winning package name, its starting price and its typical build time, labelled as illustrative rather than as a quote.
- Why we chose it: specific reasons drawn from the answers, not generic copy.
- Why we did not choose the others: one line per other package, naming the requirement that eliminated it or the margin it lost by.
- Because you said: the answers the recommendation was built from.
- A "Compare all packages" control that reveals every package with its price, timeline, what it supports, what it excludes and its state as Recommended, Eligible or Ruled out, with eliminated packages still visible and still explained.
- A "Change my answers" control that returns to a review of all answers, each individually editable, and recalculates on change.
- A "Start again" control that clears everything.

RESULT FIRST, IDENTITY NEVER
The result is shown before any identity or contact step, always, with no exception. Do not ask for a name, an email address, a company or a phone number at any point before the recommendation is on screen. The default build collects nothing at all and keeps every answer local to the browser tab.
If I ask for lead capture, add it as an optional step AFTER the recommendation, labelled "Send me this recommendation" or "Request a quote". It must not be required to see the result, it must be skippable, and skipping it must leave the whole result visible and usable. Describe it as sending the visitor a copy of a result they can already see. If the visitor uses it, include the structured decision record and a requested_next_action field recording which action they chose.

ACCESSIBILITY
- Group each question's options in a fieldset with the question as the legend.
- Use real radio inputs for single choice and real checkbox inputs for multiple selection, keyboard operable and reachable by tab, visually restyled rather than replaced by div click handlers.
- Visible focus styles on every interactive element.
- Every interactive target, including every answer card and every button, is at least 44 pixels high and comfortably wide enough to hit on a phone.
- Use exactly one small dedicated aria-live="polite" region, and use it only to announce the question position, for example "Question 3 of 7". Do not put aria-live on the results area, the whole page, the comparison view or any large container. A live region wrapped around results makes a screen reader re-read everything on every change.
- The Continue control is disabled until the current question is answered, and the disabled state is conveyed by the disabled attribute and not only by colour.
- Never use colour alone to carry the Recommended, Eligible or Ruled out state; include the text label.
- Respect prefers-reduced-motion: reduce. When it is set, no transitions, no animations and no transforms run anywhere on the page.

QUALITY BAR
- The page must look like a premium interactive experience a studio could sell, not a default form. Confident typography, generous spacing, a clear visual identity, a considered result screen.
- Fully responsive with zero horizontal document overflow at 390 pixels wide, which is the width to test explicitly. It should also hold together at 320 pixels. Any wide table or comparison grid scrolls inside its own container rather than widening the document.
- No em dashes anywhere in the copy.
- No invented statistics, no testimonials, no customer logos, no review scores, no urgency countdowns, no fake scarcity. If I have not given you the fact, do not put it on the page.
- Do not send anything anywhere. State on the result screen that answers stayed in the browser.

TEST BEFORE YOU HAND IT BACK
Run every case below and tell me the outcome of each. Do not stop early and do not skip a case because it looks similar to another one.

A. Credibility, 1 to 5 pages, none of these, content ready, leave it alone, flexible, under GBP 1,000. Expect Launch.
B. Enquiries, 6 to 20 pages, appointment booking, help structuring, campaigns and tests, three to six weeks, GBP 1,000 to GBP 2,000. Expect Growth.
C. Sell products online, up to 20 products, payments, content ready, occasional changes, three to six weeks, GBP 2,000 to GBP 4,000. Expect Commerce.
D. Portal or custom workflow, 6 to 20 pages, member accounts and custom integration, substantial writing help, campaigns and tests, flexible, GBP 4,000 or more. Expect Custom.
E. Sell products online, up to 20 products, payments, content ready, occasional changes, flexible, under GBP 1,000. Expect no match. The checkout requirement needs Commerce or Custom and the budget ceiling leaves only Launch. Expect one concise conflict statement, not several near duplicates.
F. Sell products online, up to 20 products, payments, content ready, occasional changes, under three weeks, GBP 4,000 or more. Expect no match. Money is not the blocker, the hard three week date is. Expect one concise conflict statement.
G. Credibility, 1 to 5 pages, member accounts, content ready, leave it alone, flexible, GBP 4,000 or more. Expect Custom. On raw fit points Launch would score higher, and it must stay eliminated because a required capability removed it before scoring.
H. Credibility, 1 to 5 pages, none of these, help structuring, leave it alone, three to six weeks, GBP 1,000 to GBP 2,000. Expect Launch, decided by the tie break rather than by points, and the result must say so.
I. Branch reset, a state transition rather than a scoring case. Answer Q1 as selling products online, answer Q2 as more than 100 products, then go back and change Q1 to generating enquiries. Expect the catalogue answer to be discarded and Q2 to be asked again in its page count form.
J. Package boundary beats soft fit. Credibility, 6 to 20 pages, none of these, content ready, leave it alone, flexible, GBP 4,000 or more. Expect Growth. Every soft signal points at Launch, and Launch must be ruled out because it is bounded at up to 5 pages. Package boundaries outrank soft fit.

Also confirm: the result is reachable with no email address entered anywhere, the page has zero horizontal document overflow at 390 pixels wide, and setting prefers-reduced-motion to reduce stops every transition and animation.

What a structured response looks like

If your version records outcomes, record the decision rather than only the answers. Storing the winner alone means a rules change makes every historical record unreadable, because you can no longer tell whether an old result reflects the old logic or a bug.

The shape below is derived from a controlled fixture through the same engine that runs the demo. It carries the matching rules version, the answers, the eligibility and fit outcome for every package, the eliminations and the explanation strings the visitor saw. That is enough to reconstruct any past recommendation exactly, and enough to answer the question a prospect will eventually ask, which is why the quiz told them that.

{
  "matching_rules_version": "1.0.0",
  "completed_on": "FIXTURE-DATE-NOT-A-REAL-SUBMISSION",
  "answers": {
    "goal": "enquiries",
    "scale": "pages_6_20",
    "capabilities": [
      "booking"
    ],
    "content": "content_structure",
    "optimise": "optimise_high",
    "timeline": "timeline_normal",
    "budget": "budget_2k"
  },
  "winner_id": "growth",
  "no_match": false,
  "tie_broken": false,
  "packages": [
    {
      "id": "launch",
      "eligible": false,
      "fit": null,
      "eliminations": [
        "Launch is bounded at up to 5 pages, so it cannot carry a 6 to 20 page site.",
        "Launch does not support appointment booking."
      ]
    },
    {
      "id": "growth",
      "eligible": true,
      "fit": 17,
      "eliminations": []
    },
    {
      "id": "commerce",
      "eligible": false,
      "fit": null,
      "eliminations": [
        "Commerce is built around a product catalogue rather than a 6 to 20 page content site.",
        "Commerce does not support appointment booking.",
        "Commerce starts at £2,750, above the £1,000 to £2,000 ceiling."
      ]
    },
    {
      "id": "custom",
      "eligible": false,
      "fit": null,
      "eliminations": [
        "Custom starts at £4,500, above the £1,000 to £2,000 ceiling."
      ]
    }
  ],
  "why_winner": [
    "You said the main job is to generate more enquiries, and Growth is built for enquiry generation, bookings and richer content.",
    "Your answer of 6 to 20 pages sits inside the up to 20 pages boundary on Growth.",
    "Growth covers every capability you marked as required: appointment booking.",
    "After launch you plan to run campaigns, tests or regular improvements, and your around three to six weeks timeline fits the 3 to 4 weeks this package typically runs to."
  ],
  "why_others": [
    {
      "id": "launch",
      "name": "Launch",
      "reason": "Launch is bounded at up to 5 pages, so it cannot carry a 6 to 20 page site."
    },
    {
      "id": "commerce",
      "name": "Commerce",
      "reason": "Commerce is built around a product catalogue rather than a 6 to 20 page content site."
    },
    {
      "id": "custom",
      "name": "Custom",
      "reason": "Custom starts at £4,500, above the £1,000 to £2,000 ceiling."
    }
  ],
  "requested_next_action": null,
  "respondent": null
}

Three variants worth building

Before you put this in front of customers

A recommendation is read as advice, and advice you sell against carries a duty to be accurate. These are the checks that keep it defensible.

• Every hard rule reflects something the product genuinely cannot do, not something you would prefer to upsell.
• Elimination runs before scoring, and no amount of fit points can resurrect an eliminated option.
• There is at least one realistic set of answers that produces no match, and you have run it.
• There is at least one realistic set of answers that recommends your cheapest option, and you have run it.
• The recommendation is visible in full before any contact request, with no blur, timer or partial reveal.
• Each other option has a stated reason for not being chosen, drawn from the answers rather than from marketing copy.
• Branch answers are cleared when the branching question changes, and you have tested that path.
• Prices and timelines shown are labelled as illustrative starting points rather than quotes.
• The matching rules are versioned, and stored responses record which version produced them.
• Keyboard only operation works from the first question to the comparison view, and focus is always visible.
• The page holds together at 320 pixels wide with no horizontal overflow.
• If responses are collected, the page says what is stored, who reads it and how long it is kept, at the point of collection.
• The quiz is not used for regulated advice, and it does not imply a professional recommendation it is not qualified to make.

Publishing it, and collecting enquiries if you want them

The page above works on its own. Publishing puts it at a shareable URL you can send to a prospect or link from a proposal, with the whole finder public and no access gate in front of it. If you want enquiries, the prompt adds an optional step after the recommendation, and it submits the answers, the decision and the rules version so the enquiry arrives with its reasoning attached.

Publish your AI-built page

When this format is the wrong choice

A recommendation quiz is the wrong tool when the catalogue does not have real incompatibilities. If every option can do everything and they differ only on price, you need a pricing page, not a decision engine, and a quiz will feel like theatre.

It is wrong when there are only two obvious choices. A side by side comparison page is clearer, faster to read and cheaper to maintain than a quiz that walks somebody through seven questions to tell them what a table would have told them at a glance.

It is wrong when every path leads to the same outcome. If the answers cannot change the recommendation, the questions are decoration and the visitor will work that out.

It is wrong when the respondent cannot reliably self report the data the rules need. If eligibility turns on facts they would have to look up, guess at or misunderstand, the engine is precise about inputs that are wrong.

It is wrong when the catalogue or the rules change faster than you will maintain them. Stale matching logic is more damaging than no quiz, because it recommends things confidently that you no longer sell.

It is wrong when human consultation is genuinely the product. If the value you sell is judgement, a quiz that simulates that judgement undercuts the thing the customer is actually buying.

It is wrong when there is no meaningful decision to make. Do not manufacture a quiz to have a piece of interactive content. A quiz with nothing to decide is a survey with a call to action attached.

Do not use this Blueprint to make regulated, safety critical or high stakes recommendations, including anything where professional judgement, a suitability assessment, validated data or regulatory controls are required. Financial, legal, medical, insurance, tax, employment and safety decisions all sit in that category. A quiz does not remove those obligations, and this page does not give jurisdiction specific legal conclusions. Take advice on what applies to you.

You also do not need Sentway for this. If the finder simply belongs inside a website you already operate, build it there. Sentway is useful when you want it hosted at a public URL without setting hosting up, and optionally want the enquiries coming back where your AI can read them.

Methodology and sources

This engine is an independent worked example. The design draws on published work in three areas: how product finders and recommendation quizzes are built in practice, how choice controls should be grouped and sized so they are usable, and how recommender systems separate hard constraints from soft preferences and explain their output. The sources below informed the framing and are listed so you can check the reasoning rather than take it on trust. Methodology reviewed August 2026.

This is not a validated recommender and it is not an implementation of, certification against, compliance assessment for, or endorsement by any of the organisations or publications listed below. None of them have reviewed it. The catalogue is fictional, the rules and weights are ours, and both are published in full on this page so the engine can be judged on its own terms.

• Typeform Help Center: Use AI to create a product recommendation quiz with TypeformInformed explicit products and endings, matching rules and branching as common product quiz mechanics.
• Typeform: How to craft the ultimate product recommendation quiz with TypeformInformed the practical product finder framing and keeping the experience focused on the decision.
• W3C WAI: Grouping ControlsInformed the fieldset and legend semantic grouping of the radio and checkbox choices.
• Apple Human Interface Guidelines: ButtonsInformed generous interaction targets and visible press states. This is a platform design guideline from Apple, not a web standard.
• Uta et al. 2024, Frontiers in Big Data: Knowledge-based recommender systems, overview and research directionsInformed separating explicit constraints from softer preferences in this worked example.
• Zhang and Chen 2020: Explainable Recommendation, A Survey and New PerspectivesInformed exposing the reasons for a recommendation rather than returning only an outcome.

Questions people ask

Why eliminate options before scoring them?

Because a requirement is not a preference. If a package cannot take payments and the visitor needs payments, no score elsewhere should be able to outvote that. Elimination first makes recommending an impossible option unreachable rather than merely unlikely.

What happens when nothing matches?

The engine recommends nothing, names every requirement that is in conflict and lists what would have to change for something to become possible. Falling back to the largest package would hide the fact that a constraint has to move first.

How are ties broken?

The lower complexity and lower starting price option wins, walking the catalogue from smallest to largest. The result also records that it was decided by the tie break rather than by points, so a near tie is never presented as a clear win.

Why does budget not add any points?

Budget is a ceiling and nothing else. If a larger budget added fit points, the quiz would start steering people towards spending more, which is the exact failure mode that makes recommendation quizzes untrustworthy.

Should I ask for an email before showing the result?

No. The recommendation is the thing you promised, and withholding it turns the quiz into a form with decoration. Offer to send a copy afterwards instead, when the visitor has a reason to want it.

Can I use this for my own catalogue?

Yes. The master prompt asks for your catalogue and rebuilds the whole engine around it, and the matching table above is published in full so you can rebuild the rules in whatever you already use.

Do I need Sentway to build one of these?

No. The page the master prompt produces works anywhere, including saved to disk, and it carries no Sentway dependency. If the finder belongs inside a website you already run, build it there. Sentway is for hosting it at a public URL without setting hosting up and, if you want them, collecting the optional post result enquiries your AI can read back with the answers, the decision and the rules version attached.

Read next

• Build an ROI calculator with AI
• Build a credible AI maturity assessment with AI
• Collect responses from an AI built form
• Connect your AI over MCP

Start free with Sentway

Other blueprints

• Build an ROI calculator with AI
• Build a credible AI maturity assessment with AI