Transferring a ticket to someone else

Plans change between buying a ticket and using it. The question is not whether people will pass tickets on — they will — but whether that happens inside your system or outside it. The alternative to a transfer feature is somebody forwarding a PDF and hoping, which leaves your door list quietly wrong.

Enable it per event

Transfers are off by default and enabled per event, because whether a ticket should be transferable is a decision about your event rather than a platform default.

• A conference: usually yes. A company bought three tickets and is sending different people than it planned. Refusing that produces no-shows and an irritated customer, and gains you nothing.
• A workshop with prerequisites: probably not, or not without you approving it. The value depends on who is in the room.
• An age-restricted or heavily allocated event: generally no. Transfers work against the controls you set up on purpose.
• A dinner or anything catered per head: yes, and it is better than a refund — the seat stays sold and the headcount does not move.

How it works

The current holder sends the ticket to an email address. The recipient is notified and can accept it. Once accepted, the ticket is genuinely theirs: a new ticket is issued to the new person and the old one is invalidated.

That last step is what makes it a transfer rather than a note in a file. The code that arrives at the door belongs to the person whose name is on the list, and the previous holder's copy no longer works — so a forwarded screenshot of the old ticket does not admit anybody.

Why not just forward the PDF

Because check-in validates against your records, not against the piece of paper. If a ticket is passed on informally, a chain of consequences follows that all look minor and are not:

• Your door list is wrong. The person in front of your staff is not the person the scanner names, which is either a confusing conversation or an unchecked one.
• Your emergency contact is wrong. For anything physical or licensed, this is the serious one.
• Your per-person limits have been bypassed. Somebody who bought their maximum and passed tickets on has effectively bought more.
• Your attendance data is fiction. Post-event follow-up goes to the buyer, not the attendee, and your list of "people who came" is a list of people who paid.
• Nobody can tell you what happened. If two people arrive with the same PDF, you have no record of who was supposed to have it.

A transfer feature that people actually use is therefore worth more than the feature itself: it pulls an activity that was going to happen anyway back into a place where it is recorded.

If the recipient has no account

They can still accept. Somebody being sent a ticket by a friend should not hit a registration wall before they can take it.

This is where transfer features usually die in practice. If accepting requires signing up first, a meaningful share of recipients will not bother — they will ask for the PDF instead, and you are back to forwarding. The acceptance flow works for somebody who has never heard of the platform, because that is the common case: your attendee has an account, their friend does not.

Transfers as a refund policy

Worth considering deliberately. "Transfers allowed, no refunds" is a legitimate and often better policy than either extreme, particularly where you have committed to per-head costs.

It is generous in the way that matters to the attendee — they are not out of pocket, they can pass the ticket to a colleague or friend — while your headcount, your catering numbers and your revenue stay put. It also removes the awkward middle case where somebody asks for a refund two days out and you have already paid the caterer. Set it out clearly in your refund policy so people know it is an option before they need it.