Event registration and event check-in are usually sold as two products. You collect sign-ups in one tool, export a list, import it into a second tool, and hope the two agree on the day. The join between them is a CSV, and the CSV is where the errors live: a name spelled differently, a late registrant who never made it into the second export, a duplicate that shows as two people.
It does not have to work that way. If the sign-up and the arrival both write to the same Google Sheet, there is no export, no import and no reconciliation step — the two facts about each person sit on the same row.
The free route: Google Forms
Start here, because for a lot of events it is genuinely enough and it costs nothing. Google Forms collects the sign-up, writes each response to a linked Google Sheet, and can email a confirmation with Apps Script. If all you need is a list of who intends to come, stop reading and use Forms.
Where it stops is the door. Google Forms has no concept of a per-person code, and no way to record that a specific registrant arrived. To get from a response row to a scannable check-in you have to build three things yourself in Apps Script: generate a unique token per response, render it as a QR image and attach it to the confirmation email, and then build a second surface that reads a scanned token and writes an arrival back to the right row.
That is a real weekend of work, and it is the fragile kind. The Apps Script quota on a consumer account limits how many emails you can send per day. The QR image needs hosting somewhere that will still be up on the morning of the event. And the scanning surface has to work on a phone belonging to a member of staff who has never seen it before, on venue wifi, without you standing next to them.
What the paid route buys you
The honest answer is: the three things above, already built and already tested, plus the thing nobody thinks about until it goes wrong — retries. A confirmation email that fails to send is retried automatically rather than silently lost, which matters when the email is the only copy of the QR code the registrant has.
| Capability | Google Forms / Apps Script (DIY) | QR to Sheets |
|---|---|---|
| Collect sign-ups to a Google Sheet | Yes, and it is free | Yes |
| Unique QR code per registrant | Apps Script build: generate a token, render an image, host it | One toggle; the code appears on screen and in the email |
| Record who actually arrived | Not supported; needs a second Apps Script surface | Scan the code with any phone camera |
| Design the form in your own colours | Limited themes | Full colour control, or one of eight ready palettes |
| Embed on your own landing page | Yes, iframe | Yes, iframe or an auto-height snippet |
| Change fields after sign-ups have started | Yes, but old responses keep the old columns | Yes; each response stores the fields as they were at the time |
| Trigger Zapier or Make on each sign-up | Apps Script trigger | Paste a webhook URL |
| Cost | Free, plus your build time and Apps Script quotas | 7 USD per scanning device per month; free for 1 form and 10 submissions |
Disclosure: this guide is published by QR to Sheets, so treat the right-hand column as a vendor claim and the left-hand one as the honest free alternative. If Google Forms covers your event, use Google Forms.
Designing a form people finish on a phone
Almost every registration is completed on a phone, often in a few seconds of spare attention. Two practical consequences. First, every optional field measurably costs you completions, so ask for what you will actually use at the door and nothing else. Second, put the email field early: it is the field that carries the QR code, so a form abandoned after the email is still recoverable, while one abandoned before it is not.
If you need a session, a ticket type or a dietary requirement, a dropdown beats free text every time. A dropdown gives you values you can filter on; free text gives you forty spellings of the same thing.
The four details that catch people out
Set the timezone to the venue
If you are organising from another city, set the workspace timezone to where the event actually is. Otherwise the arrival timestamps read in your time, and the 9am rush looks like it happened at 5am.
Count phones, not staff
Scanning is licensed per phone that scans, not per person on your team. Two hostesses sharing one phone is one licence. One hostess with a work phone and a personal phone is two, if she scans on both.
Send one test registration before you publish
Register yourself, receive the email, and scan your own QR code at the door you will actually use. It takes two minutes and it is the only rehearsal available. Do it from the phone the staff will use, on the venue wifi if you can.
Decide what a second scan means
Someone will present the same code twice — they stepped out for a call, or a colleague scanned them already. Scanning again reports the original arrival time rather than overwriting it, so your record of when they actually got there survives an honest mistake at the door.
Reconciling registered against arrived
This is the part worth setting up before the event rather than after. With both facts in one sheet, the questions you will be asked afterwards are single formulas: how many registered, how many came, who registered and did not come, and the no-show rate you will use to plan the next one.
Neither route keeps a live currently-inside count for you. If you need that, it is a COUNTIF over your own arrival column, and it belongs in your spreadsheet where you can see how it is calculated.
When this is the wrong tool
If you are selling tickets, you want a ticketing platform: payment, refunds, seat allocation and transfers are a different problem, and per-ticket fees buy you real infrastructure. If your event is free and your question is simply who signed up and who turned up, a form plus a QR code plus your own spreadsheet is the whole job.
Step by step
- 1
Decide what you need at the door
A name on a list is enough if you only need a headcount. If you need to know who actually turned up, and when, then every registrant needs something unique to present — which is what the QR code is for.
- 2
Build the registration form
Start with name, email and phone, then add only what you will genuinely use on the day. Every field you add is a field a person fills in on a phone, often while standing up.
- 3
Point the form at your Google Sheet
Sign-ups should land in a spreadsheet you own, not in a vendor dashboard you have to export from later. One row per registrant, timestamped in your own timezone.
- 4
Turn on the per-submission QR code
Each registrant gets their own code on the confirmation screen and in their confirmation email. Save-to-phone or print both work; there is nothing for them to install.
- 5
Scan arrivals at the door
Any phone camera opens the code. The arrival is written to the same sheet as the sign-up, so the registration row and the attendance row live together.
- 6
Reconcile registered against arrived
Two columns in one sheet answers the only question that matters afterwards: who registered, and who actually came. That is a COUNTIF, not a report you have to buy.
Frequently asked questions
Can each sign-up go straight into my CRM instead of just a spreadsheet?+
Yes, and this is usually the reason a business outgrows a free form builder. Every submission fires an HTTPS webhook the moment it is submitted, so the registration reaches your CRM, Slack or email tool in real time rather than after an export. Paste a Zapier, Make or n8n catch hook and route it to HubSpot, Salesforce, Pipedrive or anything those tools reach. Each field arrives keyed by both its id and its visible label, dropdown answers included, so the automation shows readable names rather than raw ids. A delivery that fails is retried with backoff, so a brief outage on your side delays the lead rather than losing it. Google Forms can do something similar with an Apps Script trigger, but you are writing and maintaining the script yourself.
Can I use Google Forms for the sign-up and something else for check-in?+
Yes, and it is a reasonable split. The friction is the join: you export the Forms responses and import them into the check-in tool, and anyone who registers after that export is missing at the door. If sign-ups close well before the event, this works fine. If people register on the day, you will feel it.
Does each registrant need an app to show their QR code?+
No. The code appears on the confirmation screen and in the confirmation email, so a screenshot, the email itself or a printout all work. The staff scanning it use a phone camera, not an app.
What if a registrant never receives the confirmation email?+
The QR code is also shown on screen immediately after they submit, so most people already have it. A failed send is retried automatically rather than dropped, and you can see which submissions have not been delivered.
Can two people check in with the same QR code?+
The code records one arrival. Scanning it a second time reports that this person already arrived, and shows the original arrival time rather than replacing it, so a duplicate scan at a busy door cannot corrupt the record.
Can I add a field after people have started registering?+
Yes. Add, reorder, hide or delete fields at any time; responses already collected keep the fields as they were when they were submitted, so your history stays readable rather than being reinterpreted by the new layout.
How much does this cost for a 200-person event?+
Cost is driven by scanning phones, not attendees. Two phones on the door is 14 USD for the month regardless of whether 200 or 2,000 people register. There is no per-attendee or per-ticket fee.