Checking Google Form responses is easy the first week. There are eleven of them, one person is reading them, and the Responses tab is enough. The difficulty starts at the point where a second person begins replying to submissions, because from then on the question is no longer what came in. It is which ones have already been dealt with, and Google Forms has no answer to that.
What follows covers the three places responses can be read and what each one is actually good for, how to get told when something arrives, and the part most guides stop short of: building a handled or not handled state on top of a tool that does not have one.
The three views inside the Responses tab
Open the form and click Responses at the top. Google's documentation describes three views behind that tab, and they answer different questions.
Summary aggregates everything. Charts for the multiple choice questions, a scrolling list for the open text. This is the view for a survey, where the interest is the shape of two hundred answers rather than any single one. It is close to useless for intake, because the one thing it cannot show is a single submission with all its answers together.
Question shows every answer to one question at a time. Useful for scanning a single field across the whole set: all the dates requested, all the departments selected, all the free text on one question read in sequence when coding themes.
Individual shows one submission at a time, with a pair of arrows to move through them. This is the intake view, and it is the one most people want when they say they need to check the responses. Its limitation is that it is strictly sequential. There is no filtering, no sorting and no way to mark one as read, so a reviewer working through ninety submissions has to remember where they stopped.
The counter beside the tab label shows how many responses exist in total. It does not show how many are new, and it does not change when somebody reads one.
Reading responses in the linked spreadsheet
For anything beyond a quick look, the spreadsheet is where the work happens. From Responses, then Summary, the More menu at the top right holds Select destination for responses, with two choices: Create a new spreadsheet, which makes one in Sheets, and Select existing spreadsheet, which points the responses at a spreadsheet that already exists. Google notes that responses stored this way are placed in a table, which gives the data structure rather than leaving it as a loose range.
What the sheet adds is everything the Responses tab lacks: sorting, filtering, a column for notes, conditional formatting, formulas, and more than one person looking at it at once. A submission can be found by name in two seconds instead of by pressing the arrow forty times.
Two cautions that catch people out:
- The sheet is a copy, not a window. Editing a cell corrects the spreadsheet and leaves the response inside Forms unchanged. Where the two disagree, decide which one the team treats as authoritative and stop using the other for reporting.
- Unlinking stops the flow but keeps the data. Google's help states that unlinking a spreadsheet from the form stops new responses arriving in it while the current data remains intact. The form keeps collecting into its own response store regardless.
Downloading is the third route. Under More in the Responses tab, Download responses (.csv) produces a file that is a snapshot at the moment it was taken. Useful for an archive or for handing to someone outside the organisation, actively harmful as a working copy, because within a day it is out of date and nobody can tell by looking at it.
Getting told when a response arrives
Nobody should be refreshing a form to see whether anything came in. Under Manage responses in the Responses tab, the option to Get email notifications for new responses sends a message on each submission.
This works, and it has two limits that show up quickly once a team is involved.
The notification goes to the person who turned it on, individually. Each collaborator who wants alerts has to enable them for themselves, which means the set of people being notified is invisible and drifts over time as people join and leave.
The notification says a response arrived. Acting on it means going to the form or the sheet, finding the row, and then having no way to tell the other notified people that it has been taken. On a form receiving two submissions a week that is fine. On one receiving twenty a day, the notifications become noise that everybody filters into a folder, which is the point at which the form effectively stops being monitored.
For anything with a service expectation attached, a routing rule in the mail client that flags the notifications, plus one named owner for the form, beats shared notifications with no owner.
The part Forms does not do: tracking what has been handled
This is where the honest answer differs from the one most articles give. Google Forms records submissions. It has no concept of a submission being read, assigned, answered or closed. Every method of tracking that state is something built on top by the team using it.
The common approaches, and what each one costs:
| Approach | How it works | Where it fails |
|---|---|---|
| Status column in the sheet | Add columns for status and owner, fill them by hand | Only as current as the last person who remembered; two editors overwrite each other |
| Checkbox column | Tick when handled | Says it is done, not who did it or when |
| Colour by hand | Highlight rows as they are processed | Colour carries no meaning outside the team, and copies lose it |
| Conditional formatting on a status column | Rows colour themselves from the status value | Good, but still depends on the status being typed |
| Filter views per person | Each reviewer works a filtered slice | Breaks when a submission needs two people |
| Copy into a task tracker | Submissions become tasks | Two systems to keep in step, and the answer lives in neither |
The practical minimum is three columns added to the right of the response data: status, owner, and the date the reply went out. Conditional formatting on the status column so that anything not closed stands out. A rule that nobody deletes or reorders the response columns, since new submissions keep writing into the original positions and formulas placed beside them can end up reading the wrong row.
That setup holds up for a single reviewer and starts to strain with three. The failure is not the spreadsheet: it is that the reply itself lives somewhere else. Somebody reads the response in the sheet, writes the reply in their own mail client, and the only record that the reply happened is a date typed into a cell by the person who sent it. Nobody else can see what was said, a colleague answering the same person two days later starts from nothing, and when the respondent replies, the thread sits in one inbox.
A form tool that keeps the response and the reply together removes that split by giving each submission an owner and a state as a property of the record rather than as a column somebody maintains. The intakes where this is worth the change are the recognisable ones: applications, support requests, bookings, anything where a person is waiting for an individual answer rather than being counted in a total.
A routine that survives the volume going up
Most teams do not design a checking routine. They inherit one, which is whatever the first person did when there were nine submissions. The version below takes about twenty minutes to set up and holds at a few hundred responses.
Check at fixed times rather than on every notification. Twice a day for most intakes, hourly for anything with a same-day promise attached. Interrupt-driven checking feels responsive and produces the worst coverage, because the submissions that arrive while somebody is busy are the ones that never get a second look.
Work from the oldest unhandled response, not the newest. The natural instinct is to open the one that just arrived, which quietly pushes the awkward submissions further down until they are weeks old. Sorting by timestamp ascending and filtering to the rows without a status gives a queue that empties instead of a list that grows at both ends.
Separate the two things a response needs. Some need a decision, some need a reply, and many need both but not from the same person. Marking which of the two is outstanding, rather than a single handled flag, is the difference between a tracker that tells you what to do next and one that only tells you what is left.
Reconcile weekly. Count the responses in the form, count the rows with a status filled in, and look at the gap. A count that does not match means somebody processed a submission without recording it, which is worth catching in the same week rather than at the end of the intake.
Record the reason, not just the outcome. A status column reading closed answers nothing three months later when the same applicant writes back asking why.
Checking responses without being the form owner
Two related questions come up often enough to answer directly.
Collaborators. Adding an editor to the form gives that person the Responses tab as well as the questions. That is a blunt instrument: an editor can also change the questions and delete responses. Where somebody only needs to read submissions, sharing the linked spreadsheet with view or comment access is the narrower grant, and it is usually the right one.
Respondents checking their own submission. People who filled in a form and want to see what they sent have no history page in Google Forms to go back to. Their copy exists only if the form was set to collect email addresses and to send responders a copy of their response, in which case the confirmation email is the record. Where that was not set up, the only remaining route is asking the form owner, and the owner can read the response but cannot reissue a copy without a script.
Turning receipts on before publishing a form costs nothing and removes an entire category of incoming questions later. It also gives the respondent something to quote when they write in about a correction, which makes the correction two lines of email rather than an exchange about what they think they submitted.
What to change first
Link the form to a spreadsheet if it is not already, then add status, owner and reply date columns and a conditional format that makes anything unclosed visible. That alone tells the team which submissions are still waiting. When the tracking columns stop matching reality, the cause is almost always that the reply is being written somewhere the record cannot see, which is the problem Halict is built to remove.
Q1. Where are Google Form responses stored if no spreadsheet is linked?
In the form itself, under the Responses tab, and they stay there whether or not a spreadsheet exists. A destination can be chosen at any time through Select destination for responses, so starting without one is not a dead end. Google also notes that unlinking a spreadsheet stops new responses arriving in it while the data already there stays intact, and the form keeps collecting into its own response store either way.
Q2. Can two people work through the same set of responses without colliding?
Not inside Forms, which has no per-response state and no way to claim one. In a linked spreadsheet it is workable with an owner column filled in before anyone starts replying, though two editors can still overwrite the same cell. Once more than two or three people are involved, a tool where each response carries its own owner and status avoids the problem rather than managing it.
Q3. How do you get notified when a Google Form receives a response?
In the Responses tab, under Manage responses, turn on email notifications for new responses. The setting is per person, so every collaborator who wants alerts enables it separately, and the notification only reports that a submission arrived. Acting on it and recording that it was handled are separate steps.
Q4. Is downloading responses as CSV a good way to check them?
For an archive or a hand-off, yes. As a working copy, no: the file is a snapshot, it stops matching the form the moment the next submission arrives, and nothing in the file shows how old it is. Reading in the linked spreadsheet keeps everyone on the same current data.
Q5. Can someone read form responses without being able to edit the form?
Yes, by sharing the linked spreadsheet with view or comment access instead of adding them as a form editor. A form editor can change the questions and delete responses, which is more access than a reviewer usually needs. The spreadsheet route also lets each reader sort and filter without affecting anybody else's view.