Most comparisons of online form creators stop at the builder. They count question types, show the drag and drop editor, and rank the themes. That comparison is nearly useless once more than one person has to do something with the answers, because every product on the market can put a text box on a page. The part that differs, and the part that decides whether the tool survives contact with a real intake process, is what happens between the moment someone presses submit and the moment a human replies.
If a queue of submissions is already being worked by hand, the shape of the problem is usually the same. Responses land in a spreadsheet. Someone scans the new rows. Someone else replies from a personal mailbox. Nobody can say from the sheet alone whether row 214 has been answered, who answered it, or what was said. The spreadsheet grows columns called Status and Owner because the tool did not supply them, and those columns go stale because nothing enforces them.
Start from the queue, not from the form
A useful way to choose is to write down the path a single submission takes through the organisation, then check which steps the candidate tool covers.
A typical path has six steps. Someone fills in the form. A notification goes somewhere. A person picks the submission up. That person decides what it needs. A reply goes out. The record is marked done and kept for as long as the organisation has to keep it.
Almost every form product on the market covers steps one and two well. Step two is where most of them stop. The notification arrives, and from that point the process runs on human memory and whatever informal convention the team has invented.
This matters more than it sounds. The common failure modes in an intake queue are not lost submissions. They are duplicate replies, where two people answer the same applicant an hour apart, and silent drops, where everyone assumed someone else had it. Both come from the same root cause: the submission has no owner and no state, so there is no shared answer to the question "is this one handled".
Three questions that separate the categories
Ask these of any candidate before looking at the editor.
Can a submission be assigned to a named person, so that the assignment is visible to everyone else looking at the same list. Can a submission carry a state that a human sets, beyond read and unread. Can the reply be sent from inside the record, so that the reply becomes part of the record rather than living in one person's sent folder.
A tool that answers yes to all three is doing case management with a form attached. A tool that answers no to all three is a form builder, and the case management will have to be built on top of it out of spreadsheets, shared mailboxes and habit.
Pricing models decide what happens when the form succeeds
Form products are priced in three broadly different ways, and the difference only shows up once volume arrives.
| Pricing model | Grows with | What happens when volume arrives | Typical fit |
|---|---|---|---|
| Per response, monthly cap | Number of submissions | Cost rises with success, and the form can hit a wall mid month | Campaigns with a known ceiling |
| Per seat | Number of staff using it | Cost is flat regardless of how many people apply | Ongoing intake worked by a small team |
| Free with hard caps | Nothing, until a cap is hit | The cap becomes the constraint on the process | Occasional, low volume collection |
The per response model is the one that produces unpleasant surprises, because the cap applies to the thing you cannot control. Jotform is a clear published example: the free Starter plan allows 100 submissions per month and 500 stored submissions in total, Bronze at $39 per month allows 1,000 per month, Silver at $49 allows 2,500, and Gold at $129 allows 10,000. Jotform documents what happens at the storage ceiling: once total submission storage is exceeded, the system deletes the oldest form response to make room for new ones.
That last detail is the one to read twice. A cap that throttles new submissions is an inconvenience. A cap that removes old ones is a records management problem, and it is the kind of problem that is discovered months later when someone goes looking for an application from the spring.
Per seat pricing inverts the exposure. The bill tracks how many colleagues are in the tool, which is a number the organisation actually controls and can predict a year ahead. A sudden surge of applicants changes the workload but not the invoice. Tools built around this model tend to leave forms and responses uncapped, because the response count is no longer the thing being sold. If that is the shape you want, the pricing page of any candidate should say plainly whether responses are metered.
What the free tiers actually restrict
Free tiers differ in which dimension they squeeze, and the dimension matters more than the word free.
Google Forms does not cap responses. Its published limits are structural: a form can hold up to 300 pieces of content, counting questions, descriptions, images and videos, and up to 75 sections. For collecting answers at volume it is generous. What it does not provide is any notion of a submission belonging to someone, or any state beyond what a linked spreadsheet is made to carry.
Jotform's free tier caps in the other direction. Five forms, 100 submissions a month, 500 stored in total, 100 MB of upload space, 100 fields per form. The builder is full featured and the caps are the product.
A third pattern caps the number of people rather than the work. Unlimited forms and unlimited responses on every tier, with the price set only by how many colleagues need an account, and the free tier set at one person. That shape suits a queue worked by a named team, because the number that grows is the number nobody wants to be surprised by.
None of these is wrong. The mistake is choosing a free tier without knowing which dimension it restricts, then discovering the restriction in the middle of an application window.
Notification is not the same as reply
Every form tool can tell you that something arrived. Almost none of them, on their own, give the reply a home.
Google Forms illustrates the gap precisely. Under Responses, the More menu offers "Get email notifications for new responses". It fires. It tells the subscriber that a response came in. Turning that alert into a reply that contains the applicant's own answers means leaving Forms entirely, usually for Apps Script or a Marketplace add-on.
That route works, and it also has ceilings that are easy to miss. Apps Script sends mail through the account that owns the script, and Google publishes the quota: 100 email recipients per day for consumer accounts, 1,500 per day for Google Workspace accounts. Trigger runtime is capped too, at 90 minutes a day for consumer accounts and 6 hours a day for Workspace. An intake process that grew on a personal Gmail account will hit the 100 recipient ceiling long before it hits anything else.
The deeper problem is not the ceiling. It is that the reply lives in one person's mailbox. Two months later, when a colleague picks up the same applicant, the previous exchange is invisible unless someone thought to forward it. A tool that keeps the send box on the same screen as the answers turns that from a habit into a property of the system. The features worth checking are whether a reply, an internal note and a status change all attach to the same record, and whether the record shows them in order.
Bulk and one at a time are different jobs
An intake queue needs both. Individual replies carry a decision and have to be written. Batch replies carry an announcement, such as a shortlist notice or a schedule change, and have to reach a filtered group without anyone assembling the address list by hand.
Check whether a candidate tool can do both from the same list, and whether variables can drop each person's own answers into the batch message. Doing the batch job through a separate mail merge product is workable, but it splits the record again: the merge tool knows what was sent, and the form tool does not.
Where the data lives and how it leaves
Two questions, both boring, both worth asking before the choice is made rather than after.
The first is export. Every tool exports CSV. The one that matters is whether the columns your team added, the ones that record what happened after the submission, come out alongside the applicant's answers. If internal state lives only in a separate spreadsheet, the export will be a partial record and the reconciliation will be manual.
The second is retention, which is where form choice quietly becomes a compliance question. In the United States, the Equal Employment Opportunity Commission requires employers to keep all personnel or employment records for one year, and for one year from the date of termination where an employee is involuntarily terminated. Under the Age Discrimination in Employment Act, payroll records must be kept for three years. A platform that deletes the oldest submissions when a storage cap is reached is in direct tension with an obligation of that kind, and the tension will not announce itself.
Ask where the data is physically held, whether one workspace can reach another's records, and what happens to the data after cancellation. Most vendors answer all three on their questions people ask page. A vendor that does not answer them in writing is telling you something.
Test it against one real intake, not a demo form
The fastest way to separate candidates is to take a single real process, ideally the one currently causing the most rework, and run it end to end in each tool. Not a sample form. The actual questions, with the actual file uploads, worked by the two or three people who would actually work it.
Running that test surfaces things a feature list never will. Whether two people opening the same submission can see each other. Whether the file an applicant uploaded can be opened without hunting through a drive. Whether marking something done takes one click or a trip to another tab. Whether the CSV at the end is something finance or legal would accept as a record. A tool that offers a live demo with worked examples makes this cheap to do before any account is created.
What to change first
Before comparing builders, write down who owns a submission and what states it can be in. That one page will eliminate most candidates immediately, because most of them have no place to put it. Then check whether the pricing grows with your staff or with your applicants, and try one real intake in whichever tool survives, starting from Halict or any other product that keeps the reply on the same screen as the answer.
Q1. Is a free online form creator good enough for a small team?
It depends on which dimension the free tier caps. A free tier that caps responses will constrain the process itself, and some products delete the oldest stored responses once the storage ceiling is reached. A free tier that caps the number of accounts constrains only how many colleagues can log in, which is easier to plan around. Read the cap before the feature list.
Q2. Can Google Forms send a reply that includes what the person wrote?
Not on its own. The built in setting under Responses notifies subscribers that a response arrived, but composing a reply containing the submitted answers requires Apps Script or a Marketplace add-on. Both send through the owner's Google account and inherit its quota, which Google publishes as 100 email recipients a day for consumer accounts and 1,500 a day for Google Workspace accounts.
Q3. How do you stop two people replying to the same submission?
The only durable fix is an owner field that everyone can see, set on the record itself rather than in a side spreadsheet. Colour coded rows and verbal conventions fail as soon as two people are looking at the list at the same time. If replies are sent from inside the record, the previous reply is visible too, which catches the duplicate before it goes out.
Q4. Should responses be stored in a spreadsheet or in the form tool?
A spreadsheet is a good destination and a poor workspace. It is the right place for analysis, reporting and handing data to another system. It is the wrong place to track who is handling what, because nothing stops two people editing the same cell and nothing records what was sent to whom. Keeping the working state in the form tool and syncing rows to a sheet gives you both.
Q5. What should be tested before committing to a form tool?
One real intake, worked by the people who would actually work it, from submission through reply to export. Check whether two people can see each other's ownership, whether uploaded files open from the record, and whether the CSV export includes the columns your team added rather than only the applicant's answers.