> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/guides/feature-guides/acquire-and-convert/guide-eligibility-quiz-routing.md). # Building an Eligibility Quiz that Routes to the Right Offer ### Overview A pricing page asks the customer to figure out which plan fits. A **quiz** does the opposite — it asks a few simple questions and *tells* them, routing each answer profile straight to the plan or offer built for them. Fewer choices, less second-guessing, and every customer lands on the option most likely to convert (and to fit). This guide builds a short qualification quiz that branches on the answers and drops each customer onto the right offer — the journey engine's branching and shared context doing the matchmaking. ### The example we'll build **Lumen, a website-builder SaaS,** replaces "compare our 3 plans" with three questions: *What are you building? How many sites? Do you need a team?* A solo blogger lands on **Starter**, a growing store on **Pro**, and a multi-site agency on a **"Talk to us" Enterprise** path — each with the right plan already selected. ### How it works Every journey step can **collect input**, write it to the journey's shared **context**, and the **Flow** tab can **branch** on those values. So a quiz is just: a few input steps → a routing decision → the matching offer step. No quiz "feature" required — it's the core engine. ### Before you begin * The **plans / offers** you'll route to exist in your catalog (for our example: Starter, Pro, and an Enterprise "contact us" path). * You've sketched the **decision logic** — which answer combinations map to which offer. Keep it to a handful of questions; a quiz that's longer than the pricing page it replaces defeats the purpose. ### 1. Create the quiz journey 1. Go to **Content → Journeys** and click **+ New Journey**. 2. Set **Type** to **E-Commerce** (a public, unauthenticated flow) and name it (for example *Plan Finder*). 3. Build the flow: **Question 1 → Question 2 → (Question 3) → Recommended offer → Signup → Billing → Confirmation** ### 2. Collect the answers into context Each question step writes the customer's answer to a context value other steps can read: * Give each quiz step **output variables** for its answer — for example `useCase`, `siteCount`, `needsTeam`. These become part of the journey's shared context. * Keep the questions concrete and few. Each one should genuinely change the recommendation; if it doesn't, cut it. ### 3. Route to the right offer on the Flow tab This is the matchmaking. On the **Flow** tab, branch on the collected answers so each profile reaches its offer step: * `useCase = store` **and** `siteCount > 1` → **Pro** * `needsTeam = yes` **or** `siteCount = many` → **Enterprise (contact us)** * everything else → **Starter** The first matching path wins, so order your branches from most specific to most general. Each branch lands on a **plan step** with the recommended plan presented (preselect it, or carry the choice in context so the plan step opens on the right option). ### 4. Make the recommendation feel chosen-for-them The offer step should say *why* this plan — "Because you're running multiple stores, Pro gives you…". A recommendation the customer understands converts better than one that just appears. Then continue into the normal **Signup → Billing → Confirmation** checkout for the self-serve plans. ### 5. Handle the "route to a human" branch Not every answer should end in self-checkout: * Send the **Enterprise** profile to a **"Talk to us"** step — a contact / book-a-call hand-off instead of a billing step — because those deals close with a person, not a card. * You can still capture their answers to context (and your CRM) so sales opens the conversation already knowing what they need. ### 6. Preview, publish, measure * **Preview** every path — walk each answer combination and confirm it lands on the intended offer. Branch logic is easy to get subtly wrong, so test the edges. * **Publish** and drive traffic to the quiz instead of (or alongside) the pricing page. * On **Analytics**, watch which answer paths convert best — if a branch sends people to a plan they then abandon, the routing (or the plan) needs a rethink. ### Get creative * **Qualify before you quote.** Use the same pattern as a B2B lead-qualifier: a few questions route SMB to self-serve and enterprise to sales. * **Bundle finder.** Route answers to a prebuilt **bundle** rather than a single plan ("you'll want Pro + the analytics add-on"). * **Eligibility gating.** Use a question as a gate — for example route customers in an unsupported region to a waitlist instead of checkout. * **Personalized onboarding.** Carry the quiz answers into the post-purchase flow so onboarding is tailored to what they told you. ### Tips * **Few questions, real consequences.** Every question should change the outcome — otherwise it's friction. * **Order branches specific → general.** The first matching branch wins, so put narrow conditions before catch-alls. * **Always explain the pick.** Tell the customer why the recommended plan fits; a justified recommendation outconverts a mysterious one. ### FAQ **Is there a "quiz" feature to turn on?** No — and you don't need one. A quiz is built from the standard journey engine: input steps write answers to **context**, and the **Flow** tab branches on them to route to the right offer. **How do answers decide the plan?** Each question step writes an **output variable**; your **Flow** branches read those values and send the customer down the matching path to the recommended plan step. **Can a branch go to sales instead of checkout?** Yes. Route that profile (for example Enterprise) to a **contact / book-a-call** step instead of a billing step, optionally capturing their answers to your CRM first. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/guides/feature-guides/acquire-and-convert/guide-eligibility-quiz-routing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.