Squarespace Attendee Management: How to Collect Information from Every Attendee
The short answer: Squarespace Commerce is built around the order — not the individual attendee. That's the right design for most things it handles. For events where individual guest details matter, it means you get one name, one email, and one set of details for the buyer. The other guests are invisible until you build a system to find them.
If someone purchases four seats for their team, you get one name, one email, and one set of details. The other three guests are invisible to you until you build a separate system to find them. This guide explains why that happens, what it costs you in practice, and what your real options are for collecting the information you actually need from every person walking through your door.
The Midnight Before the Event
I want to tell you about a printer.
When my company, Week of the Website, was doing professional event production alongside website design, we took real pride in running the best check-in experience our clients had ever seen. For galas, nonprofit fundraisers, summits, and food festivals, hospitality wasn't a nice-to-have — it was a core part of what clients hired us for. Guests should feel welcomed from the moment they arrived. Names should be known. Dietary needs should be handled gracefully. Nobody should be standing in a slow line while a volunteer squints at a laptop.
What guests didn't see was what it took to make that happen.
Because we often built event sites on Squarespace, we'd run into the same wall every time: Squarespace only captures the buyer's information at checkout. Not each attendee's. So if someone bought a table of eight for a gala, we had one person's details and seven unknowns. To collect what we actually needed — dietary restrictions, accessibility needs, meal selections, organizational affiliation — we'd send a follow-up email after purchase with a link to a third-party form. Then we'd wait. Then we'd chase. Then we'd manually reconcile whatever came back against the order list and build a check-in document by hand.
That document got built at midnight. Because that's when the last stragglers sent in their forms. And then, inevitably, someone would email at 7am: "My guest Maggie is actually bringing her brother now instead of her husband, and he's allergic to dairy."
I own a WiFi-enabled printer — an HP OfficeJet 250 mobile all-in-one, to be specific — because we had to reprint check-in lists so close to event kick-off that a regular printer tethered to a desk wasn't going to cut it. We needed to print from wherever we were, whenever the last change came in.
I tell you this not to complain, but because I think a lot of event coordinators reading this have their own version of this story. The frantic spreadsheet. The late-night reconciliation. The morning-of reprint. The volunteer at the door working off a list that was already out of date.
This is what attendee management looks like when your ticketing platform wasn't built for it. And if you're using Squarespace, that's exactly what you're working with — unless you build something around it.
What Squarespace Actually Captures at Checkout
When someone completes a purchase through Squarespace Commerce, here's what you get:
The buyer's name
The buyer's email address
Billing address (if required)
Any custom form fields you've added to the product or checkout
That last one sounds promising — and it is, with an important limitation. Squarespace does allow you to add custom fields to a product or checkout form. You can ask for dietary restrictions, t-shirt size, accessibility needs, whatever you need. The problem is those fields apply once per order, not once per ticket.
So when someone buys a single ticket, you're fine. You get their name, email, meal preference, and any other fields you set up. But when someone buys four tickets — which happens constantly at galas, corporate events, team workshops, and any event where group purchases are common — you get one set of answers for the entire order. One meal choice. One dietary note. One accessibility request. For four people.
Which four people? You don't know. You have the buyer. The other three are a mystery until you go find them.
For a 20-person workshop, this is manageable if annoying. For a 200-person fundraising gala where half the guests were brought by corporate table sponsors, it's a logistical problem that has to be solved before anyone walks in the door.
The Cascade: How One Gap Becomes Three Problems
The missing per-attendee data isn't just one inconvenience. It creates a cascade of downstream problems that compound as your event gets closer.
Problem 1: You Don't Know Who's Coming
Your guest list is incomplete. You have buyers, not attendees. For any event where individual identity matters — where you need to greet people by name, match guests to seats, or ensure the right people get the right meal — you're working with a partial picture from the moment tickets are sold.
The workaround is almost always a follow-up email with a separate form. Which means you're asking guests to do something after they've already completed a transaction. Response rates on those forms are rarely 100%. Some people miss the email. Some ignore it. Some fill it out for themselves but not their plus-ones. And every response that comes in is a manual reconciliation task.
Problem 2: Your Data Lives in Five Different Places
Even if you get good form completion rates, you now have attendee information scattered across:
Squarespace order confirmations (buyer info)
Your follow-up form responses (attendee info, in a separate system)
Email threads from people who replied directly instead of filling out the form
Last-minute change requests sent via email or text
The spreadsheet you built by hand trying to reconcile all of the above
None of these talk to each other. If someone cancels a ticket, the cancellation is in Squarespace but the form response is still in your Google Sheet. If someone updates their dietary restriction at the last minute, that update is in an email you have to manually find and apply.
This is the data fragmentation problem, and it's not abstract. It's the midnight spreadsheet. It's the reprint. It's the volunteer at check-in asking "what's your last name?" while a line forms behind the guest.
Problem 3: Check-In Has No Foundation
Check-in is where all of this comes to a head. A smooth check-in experience requires one thing above all else: a single, accurate, up-to-date list of who is supposed to be there and what you need to know about them.
When your attendee data is scattered, that list doesn't exist until you build it manually. And because you're building it manually from multiple sources, it's already slightly wrong before the event starts. And because guests make last-minute changes, it gets more wrong as the day approaches.
The result is a check-in experience that puts unnecessary pressure on your staff, slows down entry, and occasionally leads to the exact hospitality failure you were trying to prevent — a guest with a dairy allergy handed the wrong meal because the update came in after the list was printed.
The Workarounds People Actually Use (And Their Honest Tradeoffs)
If you're managing events on Squarespace right now, you're probably using one of these approaches. They all work, to a degree. They all have real costs.
The Follow-Up Form
Send a post-purchase email with a link to a Google Form, Typeform, or JotForm asking for attendee details. Collect the responses. Reconcile manually.
What works: Flexible. You can ask for anything. Works with any ticketing setup.
What breaks: Requires a second action from buyers after purchase. Response rates are inconsistent. Each response is a manual reconciliation task. Changes come in via email and have to be tracked separately. The form doesn't know about cancellations.
Custom Checkout Fields (Per Order)
Add custom fields to your Squarespace product or checkout asking for dietary restrictions, accessibility needs, and other information. Capture it at the point of purchase.
What works: Zero friction — guests answer at checkout, no follow-up needed. Data lives in Squarespace orders.
What breaks: Fields apply once per order, not per ticket. If someone buys multiple tickets, you get one answer for all of them. For events where group purchases are common, this doesn't solve the per-attendee problem.
Separate Registration Form for Each Event
Skip the Squarespace ticketing entirely for attendee data. Use a dedicated event registration platform (RSVPify, Eventbrite, etc.) that handles per-attendee data collection natively.
What works: These platforms are built for this. Per-attendee fields, attendee management dashboards, check-in tools — it all exists.
What breaks: Now you're off Squarespace entirely. The checkout happens on another platform. Your brand consistency breaks. For nonprofit clients especially, you're adding per-ticket fees back into the equation. You've traded the attendee data problem for the brand fragmentation problem.
Manual Spreadsheet Reconciliation
Export your Squarespace orders, combine with form responses and email updates, build a master check-in document. Repeat for every event
What works: Total control. You know exactly what's in the document because you built it.
What breaks: It's midnight. You're printing from a WiFi-enabled mobile printer because the last change came in an hour before doors open. This is not a system. This is survival.
What Good Squarespace Attendee Management Actually Looks Like
The goal isn't to patch the gaps. The goal is to have a single system that handles attendee data from purchase through check-in, without asking guests to do extra work or asking you to reconcile data from five different places the night before your event.
Here's what that actually requires:
Per-Attendee Registration Fields
When someone buys multiple tickets, each ticket should trigger its own set of required fields. Not per order — per ticket. The buyer fills out their own information plus prompts for each additional attendee. You end up with individual records for everyone, not one record for the group.
This matters most for events where individual details are operationally significant: dietary restrictions that affect catering, accessibility needs that require advance preparation, meal selections for plated dinners, organizational affiliation for networking or badging purposes.
A Single Attendee Dashboard
All attendee information in one place, connected to the original order, updated in real time. If someone cancels, their record updates. If someone changes their meal preference, that change is reflected in the same system you're using for check-in. No reconciliation. No spreadsheet. No reprint.
Searchable, Exportable Guest Lists
On event day, your check-in team needs to find names quickly. A searchable attendee list — filterable by ticket type, checked-in status, or any custom field — means the line moves. Exportable to CSV means you can print a backup, generate a badge list, or hand off to a caterer without rebuilding the data from scratch.
Check-In Tools That Connect to Your Actual Data
Check-in should be an action taken against your attendee list, not a separate process running off a printed document. When you check someone in, their status updates. When a last-minute cancellation happens, it's reflected. The check-in tool and the attendee management system are the same system.
Automated Confirmations That Set Expectations
For events where you need attendee information from group purchases, the confirmation email is your best chance to collect it while purchase intent is highest. An automated email that goes out immediately after purchase — with clear instructions and a link to complete attendee details — will get better response rates than a follow-up email sent hours or days later.
What Eventually Does Differently
Eventually is a Squarespace extension built by Week of the Website that adds native event ticketing and attendee management to Squarespace Commerce. The attendee data problem is one of the core reasons we built it — because we lived it, and because it's solvable if you design for it from the start.
Here's how Eventually handles per-attendee data collection:
Events in Eventually are created as Squarespace Commerce service products, so checkout still happens natively through your Squarespace store using Squarespace Payments. But when a buyer purchases multiple tickets, Eventually prompts for individual attendee details for each one — not just for the order. Dietary restrictions, accessibility needs, meal selections, organizational affiliation, whatever fields you've set up for that event — collected per ticket, at or shortly after purchase.
Those responses feed into a single attendee management dashboard. Searchable. Exportable to CSV. Connected to check-in tools that update in real time. If someone cancels a ticket, their record reflects that. If an attendee updates their information, it's in the same place your check-in team is working from.
For nonprofit and community organizations, Eventually's free tier covers free events and RSVPs — because not everything is a paid ticket, and data collection for a free community gathering shouldn't require a workaround any more than a paid gala should.
Eventually is pre-launch and building a waitlist. If you want early access and founder pricing, you can join the waitlist at eventuallyticketing.com.
What to Do Right Now If You're on Squarespace
If you have an event coming up and need to collect per-attendee information before Eventually launches, here's the most functional version of the workaround:
Add custom checkout fields to your Squarespace product for the buyer's own details — dietary restriction, meal choice, accessibility needs. This gets you clean data for single-ticket purchases.
In your order confirmation email, include a clearly worded prompt for group purchasers: "Bought tickets for others? Please complete their details here" — with a link to a Google Form or Typeform. Make this the very first thing in the email, not buried below order details.
Build your form to ask for the order number, each attendee's name and email, and the specific fields you need per person. Requiring the order number helps with reconciliation.
Set a firm deadline for form submissions — something like 48 hours before the event — and send one reminder to anyone who purchased a multi-ticket order and hasn't submitted the form.
Build your check-in document from a merged export of Squarespace orders and form responses. Keep it in Google Sheets so you can update it from any device and print the final version as late as you need to.
Is this ideal? No. It's the midnight spreadsheet, slightly optimized. But it's the most reliable version of the workaround, and if you're running an event next month, it'll get you through.
Just maybe invest in a WiFi printer.
The Bottom Line
Squarespace's attendee data gap is real, it's documented, and it affects everyone running events where individual attendee information matters — which is most serious events. The per-order limitation isn't a bug or a setting you can change. It's how the commerce system is built.
The workarounds work, with real costs in time, data quality, and the kind of late-night labor that nobody accounts for in their event budget. The right solution is a ticketing system designed to collect per-attendee data at the point of purchase, feed it into a single dashboard, and connect it directly to check-in — so that the list you're working from on event day is accurate, complete, and current.
That's what we're building with Eventually. Because nobody should be reprinting their check-in list at midnight.
─────────────────────────────
Keep reading:
→ How to Sell Event Tickets on Squarespace
→ Recurring Events on Squarespace: Why It's So Hard and What to Do About It
─────────────────────────────
Ready to stop reconciling spreadsheets at midnight?
Eventually is building native attendee management for Squarespace Commerce. Join the waitlist at eventuallyticketing.com for early access and founder pricing.
