# The tickets are sold — and half your attendees are still a blank — MijnEvent [Home](https://mijnevent.nl/en) / [Blog](https://mijnevent.nl/en/blog) / The tickets are sold — and half your attendees are still a blank attendee details privacy forms dashboard # The tickets are sold — and half your attendees are still a blank Dietary needs, company names, weights: the details you only need after the sale rarely arrive on their own. Here is how to collect them without making eighteen phone calls. MijnEvent · 17 August 2026 · 13 min read In short - Ask for extra details after the sale: during checkout the buyer usually does not have them yet, and every extra question there costs you sales. - The request hangs on the ticket, not on the order: two of ticket A and two of ticket B with different forms produce four forms, not two. - If you cannot explain in one sentence why you are asking for something, do not ask for it — and a short form gets you more answers anyway. - Dietary needs and weight are special category data: encrypted, behind a separate permission, with explicit consent, and kept for seven days after your event instead of thirty. - A deadline works where a friendly reminder gets filed under 'later' — but what happens after that deadline is your call, not the system's. The dinner sold out. A hundred and twenty seats gone in a fortnight, and you have exactly forty-three email addresses — because most people booked for two, four or six at a time. Then the caterer calls: how many gluten-free, how many vegetarian, and how many guests cannot have nuts? By Tuesday, please, or they will not make it. And so the round begins. An email to every buyer with a question in it. A handful of replies. A second email. A few more replies, half of them saying "for my table: two veggie and nothing else out of the ordinary" — but which of those six people at the table had the nut allergy again? By Thursday evening you are on the phone with people you barely know, a spreadsheet open beside you whose columns you no longer entirely trust. This is not a catering problem. The same pattern turns up at a conference that needs invoicing details, at a balloon flight that has to balance the weight per basket, at a starter pack that has to be ordered in the right size, and at a multi-day workshop where everyone still has to pick a session. It all comes down to the same thing: at the moment of selling you did not yet know what you would need at the moment of running the thing. # Why checkout is the wrong place to ask The temptation is obvious: just put those questions in the order form and be done with it. Two reasons not to. The first is practical. The buyer often does not have the answers at that point. Somebody booking four seats at a gala does not know their guests' dietary needs by heart, and somebody giving a balloon flight as a present certainly does not know the recipient's weight. Ask during checkout and you get guesswork — or worse, somebody fills in the same thing four times for convenience. The second is commercial. Every extra field between "I want this" and "paid" costs you sales. A checkout that asks for company registration numbers, dates of birth and phone numbers is not a thorough checkout, it is a leaky one. Paying should be short. The way out is not complicated: sell first, ask afterwards. With the [Attendee details](/en/modules/attendee-details) module the buyer gets a single link straight after payment showing everything still outstanding, and has until your deadline to complete it. # Four tickets means four forms, not two This is where most systems go wrong. The request hangs on the **order**, so somebody who booked four seats gets one form asking "does anyone at your table have dietary requirements?". That answer is useless to a kitchen. A dietary requirement belongs to a person, and a person belongs to a ticket. Which is why in MijnEvent the request hangs on the ticket. Take an order with two of ticket A — the dinner ticket, with a form for dietary needs and an emergency contact — and two of ticket B, the workshop ticket asking which session you want. That is not two forms but **four**: the dinner form twice and the workshop form twice, each tied to one specific seat. Four rows in your overview, four statuses, four times complete or not. That sounds like more work, but it is less. You no longer have to work out at the end which answer belongs to which guest, and your export to the caterer is a list of rows you can forward as it stands. Ticket types that need nothing extra — a plain admission ticket, say — simply get no form attached, and the buyer never notices a thing. # The buyer is almost never the whole table The second half-solution you often see: dump it all on the buyer. They paid, let them sort it out. In practice that means the buyer takes over your round of phone calls — messaging their six guests, collecting the answers and typing them across. That works once, and not twice. So the buyer can forward each form separately. One click from their own overview and the guest attached to *that* ticket gets a link to their own form. No account, no password, and the guest sees only their own questions — not what the rest of the party filled in. The buyer still sees the state of play: what is in, what is outstanding. They only have to keep nudging where nudging is needed, which is exactly as much responsibility as anyone can handle. # Only ask for what you are actually going to use The moment you can build a form, you want to put things in it. Date of birth, could be handy. Phone number, just in case. An open comments box, you never know. That is how a request grows from four fields to fourteen, taking your response rate down with it. There is one rule that reliably stops the slide: **if you cannot explain in one sentence why you are asking for something, do not ask for it.** In MijnEvent that sentence is not advice but a required field. For every form you record the purpose, and a sensitive field needs a separate explanation on top of that — one the attendee literally reads while filling it in. That is the only real brake on "let's just ask for everything", because a field whose purpose you cannot write down tends to delete itself. Walk your own form past that rule: - **Date of birth** — only if you enforce an age limit or your insurer requires it. If all you need to know is whether somebody is an adult, ask *that*, not the full date. - **Phone number** — only if you genuinely need to reach somebody on the day. Otherwise an email address is enough, and you already have one. - **An open comments box** — kindly meant, but it is an invitation to type in medical history you never asked for and are not allowed to keep. Keeping it short pays off twice over: you get more completed forms back, and you have less data to secure, export and erase again. What you never ask for cannot leak. For the fields you only sometimes need there are conditional questions: "which diet?" appears only for people who said they have dietary requirements, and "which workshop on day two?" only for people who bought a two-day ticket. The form stays short without you missing anything. # Dietary needs and weight are not ordinary fields Now the part most organisers underestimate. A dietary requirement and a weight are legally a different animal from a company name. The GDPR has a category of **special category data**: information about health, religion and ethnicity among other things. In principle you are not allowed to process it at all, unless an exception applies — which for an event organiser comes down in practice to the explicit consent of the person concerned. The Dutch data protection authority sets out which data falls into that category on [Bijzondere persoonsgegevens](https://www.autoriteitpersoonsgegevens.nl/themas/basis-avg/soorten-persoonsgegevens/bijzondere-persoonsgegevens) (in Dutch). A weight touches on somebody's health — little argument there. With a dietary requirement there is a catch that is easy to miss: "gluten-free" and "nut allergy" say something about health, but **halal** and **kosher** say something about somebody's religious beliefs. A single dropdown can therefore touch two special categories at once. That does not make it forbidden — you may perfectly well ask what somebody eats if you have to serve them a meal — but it does make it something you handle more carefully than a company name. In MijnEvent you flag such a field as **sensitive**, and from there it takes care of itself: - You are required to write down what you need it for, and the attendee sees that text while filling the form in. - The attendee gives explicit consent, and what they read at that moment is recorded — proof of the text somebody actually saw, not of the text that happens to be there now. - The answers are stored encrypted. (That goes for *all* answers, in fact; encrypting uniformly is safer than deciding field by field.) - Only team members with that specific permission can view them. Your box office staff do not need to know who uses insulin. - They go earlier than the rest: **seven days after your event instead of thirty**, with an entry in the log as proof that it happened. One sensitive field applies the shorter retention period to the whole form. That is deliberate: sorting out which answer landed in which box is exactly the kind of admin where mistakes creep in. So yes, we do store the data — which is more honest than pretending it lives nowhere. Just for exactly as long as your event needs it, and not a day longer. For more on what you are on the hook for as an organiser, see [handling a GDPR request](/en/blog/handling-gdpr-requests). # Why a deadline works where a friendly reminder does not "Would you mind sending over your dietary requirements when you get a chance?" That is a perfectly nice email, and it achieves almost nothing. Not because people are unwilling, but because there is no moment in it at which the answer becomes urgent. Without an end date, every day is an equally good day to do it tomorrow — and by the time it does become urgent, you are the one making the calls. A deadline fixes that by turning "sometime" into a date. Which is why the request in MijnEvent comes with one by default, and why that deadline is not just a date field you forget to update. It is calculated: a set number of hours after purchase, but never later than a chosen margin before your event, and always cut off shortly before the doors open. Somebody buying a ticket three days before the dinner does not get a week's grace that falls after the dinner. Reminders then run by themselves: at the moments you set before the deadline, at most one per day, and they stop the second a form is complete. Nobody gets chased for something they filled in yesterday. # But the deadline should be yours to hold And here is where automated systems most often get it wrong. Automatically cancelling on a missed deadline sounds tidy and consistent — right up to the moment it hits your most loyal visitor, who spent two weeks in hospital. The system does not know that. You might. So the default outcome in MijnEvent is a soft one: the submission is marked *overdue*, the ticket stays valid, and **you** get an alert email. It lists who is missing what, how often they have been reminded and how to reach them. That last part is not a detail: you weigh up calling versus cancelling very differently when you can see somebody ignored four reminders rather than getting their first one yesterday. From there it is your call: - **Call and write it down.** Every attendee has a notes field. What you agreed on the phone then sits with the right person, instead of on a scrap of paper you will not find again next week. - **Extend the deadline.** Sometimes the reason is simply a good one. - **Cancel for good.** One button that cancels the ticket *and* refunds it: the ticket price minus the transaction costs already incurred. Those costs were genuinely charged by your payment provider, and it would be odd for you to carry them because somebody else left a form sitting. Service fees, order costs and any donation are not refunded. If you would rather let it run automatically, you can — it is just off by default, and there is a daily ceiling on it. If it suddenly involves a sizeable share of your submissions at once, the system stops and warns you instead of grinding on. That is the guard rail for the day somebody accidentally sets a deadline in the past. # What you write about an attendee is data about them too You will read this at hardly any provider, and it belongs in the conversation. A notes field is genuinely useful: "called on 12 August, sending dietary needs on Friday" saves you half a conversation next week. But such a note is **personal data in its own right**. It is information about an identifiable person that you are storing, so it falls under the same right of access as their name and their order. If that attendee asks what you hold on them, your note is part of the answer. That is true of any system you keep this in, including a stray spreadsheet — a file on your laptop is no less covered by the GDPR than a database. The practical rule that follows is simple and surprisingly useful: **write every note as though the attendee is reading over your shoulder.** Because they are entitled to. Factual, short and usable, then — "called 12/8, sending Friday" rather than a verdict on somebody's phone manner. That is not only the legally sound choice, it also makes for better notes for whichever colleague picks up the phone next week. In MijnEvent that note is stored encrypted, along with who wrote it and when, and it is erased with everything else. How to handle an access or erasure request from there is covered in [handling a GDPR request](/en/blog/handling-gdpr-requests), and why we mask email addresses in the dashboard in [privacy: masked email addresses](/en/blog/privacy-email-masking). # Export, then tidy up Once everything is in, the last step is dull — which is the point. You export per event or per ticket type, send the file to your caterer, balloon operator or workshop host, and that is that. After which the system tidies up. Thirty days after your event by default, and seven for the sensitive fields. The submission itself stays behind as an empty administrative shell — you can still see *that* a form belonged to that ticket — but the answers are gone, and the erasure leaves a trace in the log. # What it costs A single flat **€50 per event** where you collect details, and your very first event is free. That amount is independent of the number of forms, fields and attendees: a hundred guests with three questions costs the same as a thousand guests with twelve. Never a percentage of your revenue, never a fee per form. Adjustable per organisation, down to €0. # In short Sell first and ask afterwards, because during checkout the buyer does not have the answers yet. Hang the request on the ticket rather than the order, so four tickets really do produce four answers. Let the buyer forward each form to the guest it concerns. Only ask for what you can justify in one sentence, and treat diet and weight as what they are: special category data that is kept for less time and sits behind its own permission. Put a deadline on it, because that is the difference between a request and a reminder that gets ignored. And keep the decision about what happens after that deadline to yourself. Want to know more? Have a look at the [Attendee details module page](/en/modules/attendee-details) — we activate the module for your organisation on request. Frequently asked questions ## Frequently asked questions ## Why not simply ask for attendee details during checkout? Because the buyer usually does not have them yet. Somebody booking four seats at a dinner does not know their guests' dietary needs off the top of their head. And every extra question while paying costs you sales, so checkout stays short and the questions start afterwards. ## What if a ticket is meant for somebody else? The buyer forwards that single form to the guest in one click. The guest fills in only their own form, without an account and without seeing anyone else's answers. The buyer still sees what is outstanding. ## Am I allowed to ask about dietary requirements? Yes, but it is special category data: an allergy says something about someone's health, and halal or kosher says something about their religion. You need explicit consent, you have to state what you need it for, and you keep it for less time than the rest. ## What happens if somebody never fills in their details? Reminders keep running until the deadline. After that you get an alert email listing who is missing what, how often they were reminded and how to reach them. You can call, extend the deadline or cancel for good — automatic cancellation is possible, but off by default. ## Can an attendee ask to see what I noted about them? Yes. A note you write about an attendee is personal data in its own right and falls under their right of access. So write every note as though the attendee is reading over your shoulder. [ Back to blog ](https://mijnevent.nl/en/blog) MijnEvent ## Read more [ ![](https://regify-mijnevent.s3.eu-central-1.amazonaws.com/blog/covers/van-ideal-naar-wero-wat-verandert-er-voor-je-ticketverkoop.webp) payments MijnEvent · 17 August 2026 · 7 min read ## From October your iDEAL payments run on Wero: what organisers need to know In July the Dutch Payments Association announced the next step in the move from iDEAL to Wero. Your visitors will not notice a thing, and you probably will not either — but there are three things worth checking now. ](https://mijnevent.nl/en/blog/ideal-becomes-wero-what-changes-for-ticket-sales) [ ![](https://regify-mijnevent.s3.eu-central-1.amazonaws.com/blog/covers/controleur-worden-app-installeren-en-testen.webp) steward Jasper Koers · 15 August 2026 · 6 min read ## Scanning at the gate: install the app, prepare and test it together You have been asked to scan tickets. Four steps get you ready: install the app, sign in with the code from your e-mail, download the event for offline use and test with a colleague that the same ticket really does turn red on the second phone. ](https://mijnevent.nl/en/blog/steward-at-the-gate-install-prepare-and-test) [ ![](https://regify-mijnevent.s3.eu-central-1.amazonaws.com/blog/covers/rechten-per-teamlid-instellen.webp) management Jasper Koers · 11 August 2026 · 4 min read ## Permissions per team member: decide exactly who can do what Under Management → Team you set per team member what they can see and do: per section, per module, with separate sensitive permissions and — if you want — limited to a single event. Five templates give you a head start. ](https://mijnevent.nl/en/blog/set-permissions-per-team-member) MijnEvent ## Ready to get started? Create a free account and sell your first tickets today. [Start free](https://mijnevent.nl/registreer) [Pricing](https://mijnevent.nl/en/pricing)