How to route different request types to their own form

Short answer

Put a multi-link page at the start of the workflow with one button per request type, then connect each button to its own form. Every form asks only what that request actually needs, and every submission arrives tagged with the branch it came from. One QR code covers all of them.

Why not one big form

The usual instinct is a single form with a "What is this about?" dropdown. It works, but it costs you on both ends:

A billing question does not need "which product are you evaluating", and a partnership enquiry does not need an invoice number. Asking anyway is the most common reason people abandon a form.

Step-by-step

1. Start with the menu. A multi-link page listing your request types, in the order you want them chosen. Put the most common first.
2. Give each option its own form. Ask only what that branch needs. Sales might want company size; support wants an order number.
3. End each branch. A thank you page confirming what happens next, or a redirect to the relevant part of your site. Tell people when to expect a reply.
4. Check the wiring. Ask the assistant to validate the workflow. Every branch should lead somewhere; an unconnected option is a dead end for whoever picks it.

Getting submissions out

Submissions collect against the link and are visible in the dashboard, where you can filter by branch and export them.

To move them somewhere else automatically — a spreadsheet, a CRM, a channel — connect an integration in Settings → Integrations. Webhooks send each submission to any endpoint as it arrives, and the Zapier, Make.com and n8n integrations cover spreadsheet and CRM destinations without code.

This part is configured in settings rather than by the assistant. The assistant builds the workflow; the integration carries the data onward.

Limits and caveats

• Every option needs a destination. A branch that stops after its form leaves the visitor on a dead end — always finish with a thank you page or a redirect.
• More options means more choosing. Four to six is comfortable; a menu of fifteen defeats the purpose.
• The branch a visitor picked is recorded with the submission, but it is a routing choice, not a verified fact. Someone in a hurry will pick the wrong one.
• Integrations are per workspace, not per link. A webhook receives submissions from every link unless you filter on the receiving end.

Frequently asked questions

Can different branches ask for different fields?

Yes. That is the point of the pattern. Each form is independent.

Can I add a request type later without reprinting the QR code?

Yes. The QR code points at the workflow, not at a fixed page. Add a branch and it appears for the next visitor.

Can two options lead to the same form?

Yes. Connect both buttons to the same step. The choice is still recorded, so you can tell them apart afterwards.

Can I route by something other than a button?

Yes. Conditions can route on country, device, time of day, whether someone has scanned before, or a value they entered earlier. A menu is the right tool when the visitor knows what they want; a condition is right when you already know something about them.

How do I stop one branch getting all the traffic?

Order matters more than anything else. The first option is picked disproportionately, so lead with the request type you most want to receive.