Better questions, clearer handoffs

Form & Intake Planner

Plan the questions and what happens after Send. Arrange conditional steps, map answers to their destination, assign follow-up and share a complete form brief.

Plan before you build

Shape the questions. Plan what follows.

Arrange fields, try the visitor flow and map delivery through follow-up. Your plan stays in this tab; download JSON to keep an editable copy.

Your form plan

1/30 fields

Form title

Introduction

Confirmation message

Changing the plan resets test answers. Required means a visitor must complete the field; a required checkbox must be checked.

Section 1

Section 1 title

Section 1 description

Show section 1Conditions use a Select or Checkbox from an earlier section. Hidden follow-up answers are cleared.

Field label

Field type

Help text

Destination field for Your nameWhere this answer belongs, such as “CRM contact.email” or “Inquiry email: project summary.” Use a field name or description, not credentials.

Required field

After someone submits

Delivery and follow-up

Name the destination, owner and recovery steps a builder needs. Leave undecided details blank. Use system names and roles; keep passwords, API keys and real submission records out of the plan.

Routing and follow-up

Intended recipientName the person or role that should receive a request. Use role names or fictional details; no credentials are needed.

Submission destinationDescribe the inbox, tracker, CRM or other system that should receive accepted requests. This planner does not connect to it.

Follow-up ownerIdentify the role responsible for reviewing requests and the backup when that person is unavailable.

Follow-up timingSet the intended response time and who checks requests that become overdue.

Storage and repeated requests

Storage and accessDescribe where answers may be stored, including notification copies, and which roles may access them. Do not enter secrets or real submissions.

Retention and deletionDecide how long each copy is kept, who removes it and how deletion is checked. Record unresolved decisions rather than assuming a standard period.

Duplicate handlingDecide how double clicks, repeated requests and retries after an uncertain result are recognized and reviewed.

Success and failure behavior

Successful submission behaviorDescribe what counts as accepted, what happens next and when the visitor sees the confirmation message.

Visitor failure messageWrite the proposed message when a request cannot be accepted, including a useful next step. Do not claim delivery if the outcome is uncertain.

Failure and retry handlingPlan what happens to the visitor's answers, how a retry works and who is notified when delivery is delayed or fails.

Check the implemented form

Delivery-test checklist

Record results from testing the working form yourself. The planner does not perform these checks; previewing a message never marks a check passed. Use notes to record the test date, observed result and any remaining work.

Destination and recipient

Send an authorized test through the implemented form and confirm the intended destination, recipient and follow-up owner receive it.

Destination and recipient: status

Destination and recipient: notes

Field mapping

Compare every accepted answer with its intended destination field, including optional and empty values.

Field mapping: status

Field mapping: notes

Conditional paths

Test each conditional path and confirm hidden follow-up answers are cleared and excluded from delivery and storage.

Conditional paths: status

Conditional paths: notes

Validation and accessible errors

Test required and invalid answers, accessible error recovery and server-side validation on the implemented form.

Validation and accessible errors: status

Validation and accessible errors: notes

Success confirmation

Verify when the request is accepted and when confirmation appears. Check the next-step wording against the actual follow-up process.

Success confirmation: status

Success confirmation: notes

Failure and retry

Test an authorized failure scenario, retained answers, visitor message, retry behavior and the owner's alert or review process.

Failure and retry: status

Failure and retry: notes

Duplicate requests

Check repeated clicks and retries after an uncertain response; confirm duplicate handling without silently discarding a new request.

Duplicate requests: status

Duplicate requests: notes

Storage, access and deletion

Check authorized access and the agreed retention/deletion process across stored answers, notifications and other copies.

Storage, access and deletion: status

Storage, access and deletion: notes

Ready for a handoff

Keep the plan. Share the brief.

Both formats include fields, conditions, destination mapping, handoff decisions and your recorded delivery checks. JSON reopens here for editing, including older saved plans. Preview answers are excluded. Review the plan itself before sharing.

Export format

Complete export

# Untitled form

Form build brief created with Plainview Web’s Form & Intake Planner.

This is a specification, not a functioning submission form. Preview answers are not included.

## Introduction

No introduction specified\.

## 1. Your details

**Show:** always.

### 1.1 Your name

- Identifier: field-name
- Type: text
- Required: Yes
- Destination mapping: Not decided\.

## Confirmation message

Thank you\. Your request has been received\.

## Delivery and handoff decisions

These decisions describe the intended implemented form. No destination is connected, and no request is sent by this planner.

### Intended recipient

Not decided\.

### Submission destination

Not decided\.

### Follow-up owner

Not decided\.

### Follow-up timing

Not decided\.

### Storage and access

Not decided\.

### Retention and deletion

Not decided\.

### Successful submission behavior

Not decided\.

### Visitor failure message

Not decided\.

### Failure and retry handling

Not decided\.

### Duplicate handling

Not decided\.

## Delivery test checklist

Statuses and notes are manually recorded by the plan's author. This planner does not run delivery tests or verify a passed result. Record actual checks on the implemented form; use fictional data and an authorized test destination.

### Destination and recipient

Send an authorized test through the implemented form and confirm the intended destination, recipient and follow-up owner receive it.

- Recorded status: Not checked
- Notes: No test notes recorded\.

### Field mapping

Compare every accepted answer with its intended destination field, including optional and empty values.

- Recorded status: Not checked
- Notes: No test notes recorded\.

### Conditional paths

Test each conditional path and confirm hidden follow-up answers are cleared and excluded from delivery and storage.

- Recorded status: Not checked
- Notes: No test notes recorded\.

### Validation and accessible errors

Test required and invalid answers, accessible error recovery and server-side validation on the implemented form.

- Recorded status: Not checked
- Notes: No test notes recorded\.

### Success confirmation

Verify when the request is accepted and when confirmation appears. Check the next-step wording against the actual follow-up process.

- Recorded status: Not checked
- Notes: No test notes recorded\.

### Failure and retry

Test an authorized failure scenario, retained answers, visitor message, retry behavior and the owner's alert or review process.

- Recorded status: Not checked
- Notes: No test notes recorded\.

### Duplicate requests

Check repeated clicks and retries after an uncertain response; confirm duplicate handling without silently discarding a new request.

- Recorded status: Not checked
- Notes: No test notes recorded\.

### Storage, access and deletion

Check authorized access and the agreed retention/deletion process across stored answers, notifications and other copies.

- Recorded status: Not checked
- Notes: No test notes recorded\.

## Implementation reminders

- Resolve unfinished recipient, field mapping, storage and retention decisions before collecting answers.
- Build server-side validation, spam protection and accessible error messages.
- Clear and exclude answers when their conditional section becomes hidden.
- Decide any additional format, length, range, consent or delivery requirements.
- Test the finished form’s delivery and confirmation behavior; a local preview does not establish that a request reaches its destination.

How to use the result

Plan the flow before the build.

Add the fields you need, group related questions and decide which answers are required. Conditional sections can depend on a select or checkbox field in an earlier section. The preview lets you try those paths without collecting real submissions.

Map each answer to its destination field. Under Delivery and follow-up, describe who receives the submission, who responds, what is stored and what happens when something fails. Preview success and failure wording, then record manual delivery-test results after the real form is built. A successful preview does not establish that a request was delivered.

Download a Markdown brief to share with a builder, or save a JSON plan to reopen here later. Both include delivery decisions and your recorded checklist; preview answers are excluded. Older saved plans still open, with the new delivery details left undecided. The planner does not create a hosted form, send email, connect to a database or apply a retention policy.

Processing stays in this browser tab. Plans and preview answers are not uploaded or saved by the tool. Download the JSON plan before closing the page. Limits are 10 sections, 30 fields and 20 options per choice field.

Markdown & HTML Converter · HTML Accessibility Checker

W3C: accessible forms ↗ · How these tools work