Tally conditional logic: build a better client intake form

Yes, Tally supports conditional logic on its free plan. It is a useful candidate for client intake when different services need different questions. If everyone should answer the same short set, a fixed form is easier to maintain.

Tally is a form builder. Its current pricing page lists unlimited forms and submissions subject to fair-use rules, with conditional logic included. The benefit is deciding which questions a visitor sees instead of making every prospective client work through every service.

Design the branch before opening the builder

This illustrative agency form collects enough information to choose a next step. It is not a form tested for this article.

Do not require a website address from someone asking for their first website. Do not request account passwords or a full content inventory at inquiry stage. A relevant question can still be premature.

How to set up the conditional questions

These steps follow Tally’s logic documentation. Labels may change; the sample configuration has not been run here.

1. Add a service question with the three choices above, then create the follow-up question blocks.
2. Initially hide service-specific blocks using their block settings. Keep shared contact fields visible.
3. Type /logic. Add a condition for the website choice and use Show blocks for its questions.
4. Add conditions for social media and the unsure path. Address what happens when a visitor changes their choice.
5. Use conditional required-answer rules only for fields on the active path. If using page jumps, put the rule on the page where the jump should happen; jumps occur when the visitor proceeds.
6. Write a confirmation explaining the next step. Promise only a response time you can maintain.

The check most worth doing: change an answer

A form can work on a straight run and fail when someone goes back. Complete each path with fictional details. Then choose website redesign, enter an answer, and switch to social media support. Inspect both the visible questions and the submitted record.

• Can someone finish without answering hidden questions?
• Do stale answers remain from an earlier branch? Can the reviewer identify the current request?
• Can the “Not sure yet” visitor receive a useful confirmation?
• Does the form work on a phone and with keyboard navigation?
• Does the recipient have enough context to reply without guessing?

These are acceptance checks, not claims about Tally’s behavior. Keep the paths small enough to repeat the checks after edits. The signup form design note explains why visible fields and a clear next action matter before advanced logic.

When should you pay?

You do not need an upgrade for this branching example. Consider Pro for requirements such as removing Tally branding, a custom domain, or collaboration. Business adds controls including submission retention. Check billing terms on the pricing page; this guide does not assume every displayed monthly equivalent is a month-to-month charge.

The strongest reason to upgrade is a requirement you can name. A paid plan will not fix unnecessary questions. Compare the subscription with the work it removes, including reviewing and routing inquiries. If no one owns the follow-up, better intake alone will not solve the delay.

Tally, another builder, or email?

Keep your existing builder if it supports the paths you need and sends usable records to your team. Include Typeform or Google Forms in a future comparison if you already use them, but check current branching and plan limits. For a handful of complex inquiries, a short email exchange may be more considerate.

When inquiries become meetings, the Granola discovery guide helps distinguish tentative requests from commitments. When they become proposals, the Gamma guide offers a five-slide outline. Start by writing only the questions needed to choose that next step.