Save-and-resume on long forms

A scholarship application form on a client site had a 28% completion rate. Users started, got three sections in, left, never came back.

We added save-and-resume. Completion went to 65%. Same form, same fields, same audience.

Save-and-resume is the highest-leverage UX feature on long forms. Here’s when to wire it, and how Core Forms does it.

The completion-rate research

For forms with:

• 1-5 fields: save-and-resume is irrelevant. The form is done in 30 seconds.
• 6-12 fields: marginal. Most users finish in one sitting; save-and-resume helps the long tail.
• 13-20 fields: meaningful. Save-and-resume usually adds 10-20% completion.
• 21+ fields: massive. Save-and-resume can double completion rate.

The bigger the form, the bigger the win. The reason: large forms get filled across multiple sessions. Phone in the elevator, laptop in the evening, desktop the next morning. Without save-and-resume, each context switch is a lost lead.

How Core Forms does it

Toggle one setting in the form’s Settings → Save & resume. Once on:

• After the user fills out at least one step (or one field, configurable), Core Forms saves a draft.
• The user gets a unique resume URL emailed to them: https://yoursite.com/your-form/?resume=abc123xyz.
• The user can leave the form, close the browser, switch devices, anything. They click the resume link, the form reopens with all their data prefilled.
• Drafts auto-expire after 30 days (configurable). Cleanup runs in the background.

The setup is one toggle. No middleware, no third-party storage. Drafts live in WordPress.

What “draft” actually stores

A draft is a row in the wp_cf_submissions table with status = 'draft' and a unique draft_token. The form data is JSON, same shape as a final submission.

Two implications:

1. File uploads work. A user uploads a resume in step 2, leaves, comes back three days later. The file is still there, attached to the draft.

2. The draft is searchable. From the WordPress admin, you can see all drafts (filtered by status: draft). Useful for “who started but didn’t finish” reporting. Email them a nudge.

When to NOT use save-and-resume

Three cases:

1. High-volume short forms. A newsletter signup with save-and-resume is overkill. The user types the email and submits in 5 seconds. Adding save-and-resume infrastructure for that is a maintenance cost without a corresponding gain.

2. Forms with sensitive financial data. If the form collects credit card info, payment details, or other secrets, save-and-resume means storing those in the database. Don’t. PCI compliance gets thorny.

3. Forms that need real-time validation against external data. “Apply for this lottery” with availability that changes minute-to-minute. The user resumes their draft hours later, the availability is stale, the submit fails. Either don’t use save-and-resume here, or rebuild the validation step on resume.

For typical long-form use cases (job applications, scholarship apps, multi-step intake), none of these matter.

The email subject that wins

The “resume your form” email is its own conversion problem. The subject line decides whether the user clicks back in.

Three patterns I’ve tested:

• “Continue your application” — basic. ~30% click rate.
• “Your saved progress is ready (60% done)” — adds progress context. ~45% click rate.
• “You’re 60% done with your application — want to finish?” — same info, friendlier tone. ~55% click rate.

The numbers vary by audience but the pattern is consistent: progress context beats generic.

In Core Forms, the resume email body uses data variables. Customize the subject and body in the form’s Messages tab.

The “save-then-prompt” pattern

A subtle UX choice: when does Core Forms save the draft?

Three options:

1. Save on every field blur. Maximum recovery if the user closes the tab unexpectedly. Highest server load (lots of small writes).

2. Save on every step transition. Save when the user clicks “Next.” Lower server load. Less recovery if the user closes mid-step.

3. Save on explicit “Save and continue later” button. The user opts in. Cleanest UX, but users have to remember to click it.

Core Forms defaults to option 2 (save on step transition). For most use cases, that’s the right balance.

The resume URL security model

The draft token is a 32-character random string. Cryptographically random, not guessable. Anyone with the URL can resume the draft.

This is the right tradeoff for most forms. The user knows the URL is sensitive (it’s emailed to them). Sharing it is their call.

For sensitive forms, you can require email verification on resume: clicking the URL emails a one-time code to the user’s email, the code unlocks the draft. Toggle in the form’s settings.

What this looks like in practice

A real example. A coaching client’s intake form: 22 fields across 4 steps. File upload (resume PDF) in step 2. Long textareas in steps 3 and 4.

Before save-and-resume: 31% completion.

After save-and-resume + step 2 progress email: 64% completion. Same audience, same campaign budget.

That’s roughly 2x the effective lead volume from the same traffic. The form change paid for itself in a week.

The next step

Identify your longest form. If it’s 13+ fields, turn on save-and-resume. Watch completion for two weeks.

For agencies running long client forms, save-and-resume is the feature you should set up by default on any form with more than 10 fields. It’s a 30-second toggle that doubles output.

Bundled in Core Forms.