Search for form submission tracking and almost everything returned is about analytics: a tag manager, a trigger that fires when the form is submitted, an event sent to a reporting tool, a conversion counted in an advertising account. That material is well written and it answers a real question.
It is not always the question being asked. A team handling submissions day to day usually wants to know something different: which of the things that came in have been dealt with, which are still waiting, and who is holding the ones that are waiting. Both jobs get called tracking, they need different tools, and treating one as the other is why some teams have a perfect conversion dashboard and no idea that eleven enquiries have gone unanswered since Friday.
Two questions wearing the same name
| Counting submissions | Tracking submissions | |
|---|---|---|
| The question | How many came in, from where, at what cost | Which ones are still owed a reply |
| Who asks it | Marketing, whoever owns the ad spend | Whoever answers the enquiries, and their manager |
| Where the answer lives | Analytics and advertising platforms | Wherever the responses are worked on |
| Unit of measurement | An event, aggregated | A single response, with a state |
| When it is wrong | The number is off by a percentage | One named person did not get a reply |
| What it cannot do | Tell you whether anyone replied | Tell you which campaign the person came from |
The distinction is not academic. Analytics is built around aggregation: events are counted, grouped and reported. That design is right for its purpose and structurally unable to answer a question about one submission, which is the only question that matters when somebody calls to ask why nobody got back to them.
Setting up the counting side without fooling yourself
Two methods dominate, and the choice is dictated by how the form behaves.
If submitting the form sends the visitor to a separate confirmation page, count views of that page. It is the most reliable method available, because a page view is a hard signal that the server actually accepted the submission. The failure mode is that confirmation page views can be reached in other ways, by a bookmark or a shared link, so the page should not be publicly linked anywhere.
If the form submits without a page change, which covers most embedded forms and every single page form, the submit has to be detected in the browser and reported as an event. This is the approach the tag manager guides describe. It works, and it has three traps worth knowing before trusting the number.
A submit attempt is not a successful submission. Detecting the button press or the submit event fires whether or not the server accepted the data. Validation errors, network failures and spam rejections all count as conversions unless the event is tied to the confirmation state rather than the click.
Double firing is normal. A form that can be submitted by both a click and the enter key, or that is re-rendered by the page, often produces two events for one submission. Compare the event count against the number of records the form tool actually holds before publishing the number to anyone.
Bots submit forms. Automated traffic will inflate a browser side event count more than it inflates the record count, because many bots never complete the submission.
The check that settles all three is dull and effective: pick a single day, count the events, count the stored responses, and explain the difference. If the difference cannot be explained, the tracking is not yet trustworthy, no matter how good the dashboard looks.
Why the two numbers never quite agree
Even correctly configured, the counted number and the stored number differ, and the gap has legitimate causes. Blocked scripts and privacy tools suppress events without affecting submissions. Duplicate submissions from the same person are one lead and two records. Spam is filtered in one place and not the other.
Deciding in advance which number is authoritative saves a recurring argument. For anything to do with spend, the analytics number is the one that lines up with the platforms doing the spending. For anything to do with work owed, the stored responses are the only number that matters, because a reply is owed to a person and not to an event.
What the operational side actually requires
The tracking that stops enquiries being dropped is simpler than the analytics side. Four things, and none of them need a tag.
A state per response. Not a label in a subject line or a colour on a spreadsheet row, but a field with a small set of possible values that the whole team uses the same way.
An owner per response. A named person, not a team. Anything owned by a group is owned by nobody, which is the mechanism by which a shared mailbox loses messages.
A timestamp on every change. Arrived at, first replied to, closed at. Without these, no question about speed can be answered, and every discussion about response time turns into anecdotes.
A history that stays with the response. Stage changes, owner changes, notes and the replies that were sent, in one ordered list on the same screen as the answers. The equivalent information scattered across a mailbox, a chat thread and a spreadsheet is not a record, because nobody will reassemble it. The tooling for what happens after submission is a different category from form building, and this is the part that distinguishes them.
Choosing states people will actually maintain
The temptation is to model every nuance of the process. The result is a dozen states, most of them unused, and a team that leaves everything in the first one.
Start with four. Something like new, in progress, waiting on the other party, and done. The third is the one most teams omit and the one that removes the most confusion, because a response waiting on somebody outside the team looks identical to a neglected one. Add a fifth only when a real question cannot be answered without it.
Two rules keep the states honest. Every state must have a defined owner, and there must be exactly one state that means no action is needed. When two states both quietly mean finished, the count of open items becomes a matter of opinion.
Tags are the right place for the nuance that states cannot carry. Enquiry type, product, region, source. States describe where the work has got to, and tags describe what the work is about. Mixing the two produces the twelve state design. Different intake types settle at different shapes, which is what makes these worked examples more useful than a generic template.
Where the record should not live
Three places attract the record and cannot hold it.
A mailbox. Read and unread is not a workflow, it is one bit of information per person, and it resets the moment somebody opens a message to see what it says. Shared mailboxes make this worse rather than better, since one person reading marks it read for everyone.
A spreadsheet updated by hand. It works exactly as long as the person who set it up maintains it. Data that has to be copied from one system to another is data that stops being copied during the week when copying it matters most.
A workflow platform's run history. This one looks authoritative and is time limited. Power Automate retains run history for 30 days from the start of the run, and a single run has a maximum duration of 30 days, with pending steps timing out at that point. As a record of what was handled and when, it expires on a schedule.
If the responses must also appear in a spreadsheet, because that is where a report is assembled, the export should be automatic and one directional. A form tool that appends each new response to a sheet as a row and updates that same row when the stage changes keeps the sheet current without making it the place where the state is edited.
Joining the two sides together
The two kinds of tracking can be connected, and the connection runs in one direction only. Analytics cannot tell you what happened to a particular submission, but the submission can be made to carry where it came from.
The method is a hidden field on the form, filled in at the moment the page loads from whatever the page already knows: the campaign parameters in the address, the referring page, the page the form was embedded on. That value is stored with the response, so every record arrives with its origin attached. From then on, the questions that were previously impossible become ordinary filters. Which source produces enquiries that get answered and go nowhere. Which landing page sends people who ask a question nobody on the team can answer. Which campaign fills the queue on a Friday afternoon.
Keep the field simple and keep it stable. One field holding a short source label is worth more than five fields holding every parameter, because the five will be inconsistently populated and nobody will agree on which one to group by. If the detail is needed later, store the full address in a second field and leave it out of the reporting.
Two cautions. A hidden field is visible to anyone who looks at the page source, so it should never hold anything that is not already public. And the value reflects the last click that brought the person to the form, not their whole path, which is the same limitation every attribution model lives with and is worth stating out loud before anybody treats the field as the truth about how a customer was won.
What this buys is the ability to answer a question about spend using the responses themselves rather than an event count, and that number comes with a reply attached.
Measuring the queue, not the funnel
Once responses carry states, owners and timestamps, a small set of numbers replaces the arguments.
The age of the oldest unanswered response. One number, checked daily. It catches everything the averages hide.
The share of responses first replied to within a working day. A median hides the long tail, which is the part people complain about.
The count of open responses by owner. Reveals the imbalance that nobody mentions until somebody leaves.
The count reopened after being marked done. The honest measure of whether the first reply actually answered the question.
None of these come from analytics. All of them come from the responses themselves, which is why the operational side has to exist as a record and not as a dashboard of events.
What to change first
Take yesterday's submissions, count them in your analytics, count them in whatever holds the actual responses, and check how many have a reply. The first two numbers being close means the counting works. The third number being unknown means the tracking that matters does not exist yet, and putting the responses on one screen with an owner and a state, which is what Halict does, is the shortest way to find out.
Q1. Why does my analytics tool report more submissions than the form tool stored?
Usually because the event fires on the submit attempt rather than on a confirmed submission, so validation failures, double firing and bot traffic all get counted. Tie the event to the confirmation state and compare a single day's event count against the stored record count until the difference can be explained.
Q2. Can a shared mailbox be used to track which submissions are answered?
It can hold the messages, but read and unread is not a status, and one person opening a message marks it read for everyone. There is also no owner and no timestamp for when a reply went out, so the two questions that get asked most cannot be answered.
Q3. How many statuses should a response have?
Four is usually right: new, in progress, waiting on the other party, and done. The waiting state is the one most teams leave out and the one that stops a response that is genuinely blocked from looking neglected.
Q4. Is a spreadsheet good enough for tracking form submissions?
For a low volume of submissions handled by one person, yes. It fails when two people edit at once, when the copying from the form tool has to be done by hand, and when someone asks how long the oldest open item has been waiting, since nothing records when each change happened.
Q5. What single number is worth reporting weekly?
The age of the oldest response with no reply. Averages and totals both improve while a handful of items rot at the bottom of the list, and this number does not.