Form Response Status Management -- How to Design New, In Progress, Done, and Excluded

Last updated: May 13, 2026

A form submission is not finished when it arrives.

It may appear in email. It may post to Slack. It may create a row in Google Sheets. Those are arrival signals. They tell the team that something happened.

The operational questions come after that.

Who owns this response? Has anyone looked at it? Is it being handled? Are we waiting for the sender? Is it done? Should this sales pitch, spam entry, duplicate, or test submission be excluded from normal reporting?

If those questions live only in memory, form work becomes fragile. If they are represented as response status, the submission can move into action.

This article explains form response status management as an operational design problem. It is not just a label feature. It is the layer that turns a submitted form into a trackable piece of work.

The Short Answer

Response status should answer one question:

What should happen next?

For most teams, the first model can stay small.

You do not need every status on day one. A small form may only need New, In progress, and Done.

But while building FORMLOVA, I have become convinced that Excluded deserves a place earlier than many teams expect. Real forms attract noise: sales pitches, test submissions, duplicates, and out-of-scope messages. If those stay in New, the backlog looks worse than it is. If they move to Done, the team overstates handled work.

Excluded is not a trash can. It is a way to keep normal work and normal reporting honest.

How This Page Fits the Cluster

Several FORMLOVA articles touch response operations, so the boundary matters.

This page owns the model. The linked pages own the implementation details.

Google Forms Collects Responses, but Status Is a Separate Layer

Google's help page for Forms explains how to view responses in the form UI, view them in Google Sheets, download responses as CSV, receive email notifications for new responses, and send responders a copy of their response when email collection is enabled.

Those are important capabilities.

They do not, by themselves, define who owns each response, what stage it is in, or whether it should be excluded from normal work.

You can add status columns to a Google Sheet. That is often a good starting point. But the moment you do that, the Sheet is no longer just a response export. It has become a small operations table.

That distinction matters.

Google Forms is not the problem. Submission collection and response status are different jobs.

A Slack Notification Is Not a Status

One common mistake is to treat a Slack notification as if it solves response management.

Slack is useful for awareness. It can tell the team a response arrived. It can route a submission to the right channel faster than email.

But a Slack message does not reliably answer:

• who owns the response
• whether anyone has started handling it
• whether the sender is waiting for a reply
• whether the team is waiting for the sender
• whether the response should be excluded from reporting

Slack reactions can work for very small teams. They are quick human signals.

But if you care about missed follow-up or duplicate handling, keep the signal and the response record separate. A reaction can be a cue. The response status should live on the response record or in the system that owns response operations.

The Slack setup itself belongs in How to Send Form Responses to Slack. This article focuses on what happens after the notification.

Owner and Status Are Different Fields

Another frequent source of confusion is ownership.

Owner means: who is responsible for this response?

Status means: what stage is this response in?

If those two ideas are collapsed into one field, the workflow gets blurry.

An owner is not proof of progress. A status without an owner may mean nobody is actually responsible.

This is one of the design choices I care about in FORMLOVA. It is not enough to search responses. The product has to help the operator see which responses are actually moving.

Why Excluded Should Be Explicit

You can start with New, In progress, and Done.

For contact forms, lead forms, event forms, and resource request forms, I recommend adding Excluded early.

Real submissions include noise:

• sales pitches
• spam
• internal test submissions
• out-of-scope messages
• duplicates

If noisy entries remain New, the backlog becomes misleading. If they are marked Done, handled counts become misleading.

Excluded keeps a response visible without treating it as normal work.

This matters for later reporting. If you want to know how many real inquiries came in, how many went unanswered, or which channel produced useful responses, you need a way to separate actual work from noise.

If You Stay in Google Sheets, Keep the Columns Boring

If your Google Forms responses already flow into Google Sheets, a simple status layer can work well.

Start with five columns.

This is enough for many small workflows.

The danger is slow column creep.

If the Sheet starts holding routing rules, notification conditions, email templates, send logs, retry errors, exclusion reasons, priority scores, owner teams, and weekly report logic, the spreadsheet has become an application. That may be acceptable for a while, but it should be an explicit choice.

The broader boundary is covered in Google Forms + Sheets + Apps Script Operations.

Status Is Not a Reply Feature

Public help for response-status features in form products also separates status management from replying to the submitter. That distinction is worth keeping.

Status does not send a message to the respondent.

It records where the response stands on the team's side.

Auto-reply emails, manual replies, Slack notifications, owner notifications, CRM creation, and reporting are different jobs. Status is the operational state that helps those jobs stay coherent.

If you are working on the respondent-facing email, use How to Set Up Form Auto-Reply Emails. If you are working on internal movement after a response arrives, keep reading about status.

How FORMLOVA Treats This Workflow

The product walkthrough is separate: View, Filter, and Update Response Status with FORMLOVA.

The underlying model is simple:

1. View the response list
2. Filter the responses that matter now
3. Inspect the target responses
4. Update their status
5. Connect the result to CSV, Google Sheets, notifications, email, analytics, or workflows when needed

I care about that order because viewing a response is not the end of the job.

The work is:

See the response. Decide what it means. Move it forward.

When those steps are connected, a form is no longer just an inbox. It becomes the start of an operation.

Three Weekly Checks Are Enough at First

Once you have response status, you do not need a heavy dashboard immediately.

Start with three weekly checks.

• Responses still New after three days
• Responses with no owner
• Forms where Excluded is rising quickly

These three checks reveal most early operational problems.

If New responses sit untouched, notification or ownership is weak. If owner is blank, routing is weak. If Excluded rises, the form entry path, field design, spam controls, or sales-message handling may need attention.

Form improvement does not have to start with a polished analytics page. It can start by finding where the workflow stops.

Related Workflows You Can Use

After the status model is clear, Inquiry Owner Assignment is the closest first workflow. It routes new responses to owners so the status column does not become a passive label.

For recurring checks, use Unhandled Response Reminder. If the team needs a weekly or monthly summary, AI Response Report turns response content into an internal report.

FAQ

How many response statuses should a form have?

Start with New, In progress, and Done. Add Waiting when follow-up timing matters. Add Excluded when sales pitches, spam, duplicates, or test submissions would otherwise distort the work queue.

Can Slack reactions be used as response status?

They can work for a small, informal team. For reliable response management, treat Slack reactions as human cues and keep status on the response record or operations system.

Is a status column in Google Sheets enough?

For a low-volume form with a small team, yes. If the Sheet begins to hold routing, notification, reply history, exclusion logic, and reports, you should reconsider whether the spreadsheet has become an operations system.

Is status management the same as an auto-reply?

No. An auto-reply is a message sent to the respondent. Status management is the internal state of the response. Both matter, but they solve different problems.

What should contact forms do first?

Use New, In progress, Done, and Excluded. Then add owner assignment. After that, add category routing, Slack notification, and sales-message handling only where they reduce real operational risk.

Summary

A form response is not complete just because it arrived.

Notifications create awareness. Spreadsheets create visibility. Auto-replies reassure the respondent.

Status management moves the response into action.

New, In progress, Waiting, Done, and Excluded are enough for most teams. The point is not to create a complex taxonomy. The point is to make sure everyone knows what a status means and what should happen next.

If you want the concrete FORMLOVA flow, continue with View, Filter, and Update Response Status with FORMLOVA.

Disclosure and Verification

I wrote this as the developer of FORMLOVA, based on the product decisions behind FORMLOVA's post-submission workflow. Claims about viewing Google Forms responses, opening responses in Google Sheets, CSV downloads, new-response email notifications, and response receipts were checked against Google Docs Editors Help on May 13, 2026. The distinction between response-data status and replying to the submitter was checked against FormMailer public help on May 13, 2026.

References:

• Google Docs Editors Help: View & manage form responses
• FormMailer Help Center: Response data status settings
• FormMailer: Response aggregation and management features