> For the complete documentation index, see [llms.txt](https://docs.podplay.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podplay.app/owners-playbook/build-your-club/company-settings/require-on-signup.md).

# Require on Signup

### Overview

The fields you can require Customers complete during Profile creation flow are:

1. First and Last Name (mandatory)
2. Birthday (optional)
3. Gender (optional)
4. Phone Number (optional during signup)
5. Location selection (optional)

#### Before you require it...

Every required field at Profile creation adds friction, and phone number is one of the highest-friction fields (alongside password, captcha, and address). 

At signup a Customer has low commitment, so a required phone field can feel unnecessary and raise privacy or spam concerns. That shows up in the numbers: forms that require a phone number see roughly 55% completion versus roughly 62% for forms that don't, a 7-point drop, and a required phone field can account for up to 37% of all form abandonments. In one signup flow with 9 fields, overall abandonment was 68%, and most of that drop-off happened at the phone field. 

Reducing upfront fields, including deferring phone, cut abandonment to 18% and increased signups 2.5x. Baymard Institute finds that unexplained or early requests for personal data like phone are a major source of abandonment in registration flows. 

Requesting a phone number later, right before a Customer completes a Reservation, costs less. By then they have intent and momentum, so tolerance is higher. Surprise or unexplained requests still cause drop-off: about 14% of shoppers abandon checkout when a phone field is simply required without explanation, and step-level drop-off for a required phone at final stages typically runs 10 to 20%, higher on mobile.

#### Account creation vs. late booking flow

| Where phone is required                        | Impact                                                                                        | Why                                                                               |
| ---------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| During account creation (early)                | \~55% completion vs. \~62% without (7-point drop); can drive up to 37% of form abandonments   | Low commitment, feels unnecessary, privacy and spam concerns                      |
| Late in booking flow (right before completion) | \~10–20% step-level drop-off, higher on mobile; \~14% abandon if required without explanation | Higher intent and sunk-cost momentum, though surprise requests still cost signups |

#### Recommendation

Avoid requiring phone during account creation. If you need it, defer to the booking flow and keep it optional with a clear explanation of why you're asking. The best practice for most Clubs is to collect it optionally later, at Profile completion or after a booking, for SMS reminders and confirmations. That maximizes new-account acquisition while still covering operational needs.

<details>

<summary>What sources were used for the above information?</summary>

<table><thead><tr><th width="151.404296875">Industry / context</th><th width="158.7314453125">Study / source</th><th width="126.5986328125">Basis of research</th><th>Key findings (drop-off / completion)</th></tr></thead><tbody><tr><td>General / multi-industry</td><td><a href="https://paperform.co/blog/insights-from-7k-forms/">Paperform</a> (7,193 forms)</td><td>Analysis of 7,193 real forms</td><td>Single-page 62% completion; 2 pages 49.7%; 5+ pages 41.9%. More fields and pages means higher drop-off. Phone required: -7% completion.</td></tr><tr><td>General forms</td><td><a href="https://owlclaw.com/benchmarks/form-fill-rate-benchmarks/">OwlClaw / Typeform / HubSpo</a>t (2026 benchmarks)</td><td>Aggregated benchmarks</td><td>Completion by field count: 1–2 fields 28%; 3–4 22%; 5–6 18%; 7–9 15%; 10+ 11%. Average form completion ~21.5%.</td></tr><tr><td>General / lead gen &#x26; registration</td><td><a href="https://www.zuko.io/blog/which-form-fields-cause-the-biggest-ux-problems">Zuko</a> (large dataset)</td><td>93M+ form sessions across industries</td><td>Password field 10.5% mean abandonment (highest). Starter-to-completion ~66%; view-to-completion ~45%. Field count not the primary driver in their data.</td></tr><tr><td>E-commerce / checkout &#x26; account creation</td><td><a href="https://baymard.com/blog/explain-phone-number-field">Baymard Institute</a> (ongoing)</td><td>Large-scale usability testing and benchmarks</td><td>Average checkout 11.3 fields (ideal ~8). Forced account creation adds significant abandonment. Multi-field friction is a bigger issue than number of steps.</td></tr><tr><td>SaaS / signup flows</td><td><a href="https://medium.com/@shijas.ux/how-we-increased-signups-by-2-5x-68b72e02155a">Medium case study</a> (one company)</td><td>A/B test before and after</td><td>9 fields: 67% abandonment (68% of it at the phone field). Reduced to 2 upfront fields: 18% abandonment, 2.5x signups.</td></tr><tr><td>Digital banking / onboarding</td><td><a href="https://oradian.com/">Oradian</a></td><td>Industry reports and observations</td><td>68% abandon mid-onboarding when it's too long or complex. KYC and verification steps are major drop points.</td></tr><tr><td>Wikipedia / account creation</td><td><a href="https://phabricator.wikimedia.org/">Wikimedia</a> (Phabricator)</td><td>Real traffic analysis (hundreds of thousands)</td><td>Overall ~80% abandonment. Desktop worse with captcha. Mobile drops heavily at username and password.</td></tr><tr><td>General / multi-step vs. single</td><td><a href="https://antforms.com/">HubSpot, Venture Harbour, others</a></td><td>Aggregated A/B tests</td><td>Multi-step forms (6+ fields) convert ~86% higher than single-page. Crossover benefit around 5–6 fields.</td></tr><tr><td>B2C / lead gen &#x26; contact</td><td><a href="https://mailmunch.com/">Mailmunch</a>, MarketingExperiments, others</td><td>Multiple studies</td><td>Each extra field: 8–50% potential drop. 3 fields best for B2C (~25% completion). Phone -5%, address -4%.</td></tr><tr><td>Various (industry benchmarks)</td><td><a href="https://zuko.io/benchmarking">Zuko industry data</a> (2025–2026)</td><td>93M+ sessions</td><td>Completion varies by industry: financial services ~58%, e-commerce ~51%, property ~35%. Mobile consistently lower.</td></tr></tbody></table>

</details>

### Require Phone Number

When this feature is enabled, Customers must verify a working phone number before their Profile is created. Every new account is tied to a real, reachable number, which cuts down on fraudulent and duplicate accounts. Requiring more information at signup also adds friction, so this page covers both how to turn the feature on and the tradeoff to weigh before you do.

#### How to enable this feature

1. Open Company Settings.
2. Go to the Feature Flags tab.
3. Scroll to the Login / Sign Up section.
4. Toggle Require Phone Number on Signup on.

<figure><img src="/files/ti6iET3sDnaAl0upwwk4" alt=""><figcaption></figcaption></figure>

Once enabled, the phone verification step is added to the Customer signup flow automatically. No other configuration is required.

#### What Customers experience during signup

When a Customer creates a new Profile, they see an added step to verify their phone number:

1. Enter their phone number.
2. Receive a one-time verification code by SMS.
3. Enter the code to confirm the number.

<figure><img src="/files/20LmLefzSpDD8RZcWH9I" alt=""><figcaption></figcaption></figure>

Once the code is verified, the Customer continues and completes account creation. Signup is blocked until a valid phone number is confirmed.


---

# 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.podplay.app/owners-playbook/build-your-club/company-settings/require-on-signup.md?ask=<question>&goal=<endgoal>
```

`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.