Which booking changes should festival ticket buyers make themselves?

You're getting ready for your festival, and your inbox is filling up with questions that sound easy. Someone misspelled their name. Someone wants to add parking. Someone bought four tickets and needs to give one to a friend. Each request takes a few minutes, until those few minutes become someone's entire afternoon.

Let buyers handle ordinary changes when your ticketing system can check permission, complete the action and show everyone the correct result. Keep changes involving restricted admission, scarce stock, disputed ownership or money outside the published rules with your team. The sensible dividing line is what a change affects, rather than how small the request sounds.

A name correction might leave everything else untouched. Changing the email address that controls an order could give another person access to every ticket in it. Both look like editing a field, but they deserve different checks.

This guide explains how to decide what buyers can change, when each option should close, and what your team needs to know afterwards. You'll also find sample buyer wording and a practical way to test the whole process before selling tickets. The aim is fewer avoidable support conversations without creating problems at the gate.

Start with the actual booking changes

The first thing you want to do is read the requests you already receive. Use the last comparable festival, or your current support inbox, and group requests by the action people need. Don't start by asking which buttons your supplier offers. Start with what your customers are trying to finish.

Separate finding a ticket from changing it. Downloading another copy should not need the same approval as replacing the attendee. Separate correcting contact information from changing the person who controls the order. Separate adding a parking pass from moving an existing parking pass to a different day.

Write down what each action changes in the booking, payment record and arrival instructions. A camping amendment can affect a supplier's list even when the admission ticket stays exactly the same. A ticket upgrade can change the entrance the buyer should use. That consequence determines the checks you need.

Then identify which requests are common enough to justify a supported customer action. An unusual accommodation arrangement may deserve a conversation. Resending an available ticket usually doesn't. You can still provide a clear support route for the unusual case without requiring every buyer to explain an ordinary correction.

Use this exercise to remove unnecessary restrictions too. If someone needs approval to correct a harmless typo, ask what that approval protects. If the answer is simply that this is how the team has always worked, you have found a reasonable place to improve the process.

Let buyers correct details without rewriting ownership

For ordinary attendee details, allow corrections that don't change admission eligibility or booking control, where your system supports them. Explain which fields are editable and what happens when the buyer saves. The customer should know whether they have corrected the attendee record, their account profile or both.

Be especially clear with names. Correcting spelling and substituting another person are different actions. If your event checks named eligibility, a field labelled "name" shouldn't become an unrestricted way to replace the attendee. Use the proper transfer route when another person is taking the ticket.

For Australian businesses covered by the Privacy Act, the OAIC's guidance on correcting personal information explains the obligation to take reasonable steps to correct inaccurate information. It also says covered entities must not charge for making or handling that correction. Don't automatically apply a commercial ticket amendment fee to a privacy correction request.

That does not mean every festival must offer an editable account page, or that every request must receive the change requested. Check which rules apply to your business. Keep an accessible way to ask for a correction even if the ordinary online amendment deadline has passed.

For contact details, decide whether the information is only used for event updates or also controls account access. Correcting a phone number can be straightforward in one setup and sensitive in another. Your policy should follow what the field actually does, rather than assuming that every contact detail has the same risk.

Treat an order email change as an access decision

Someone writes, "I used the wrong email. Can you send everything here instead?" That might be an honest mistake. It might also be someone trying to obtain tickets they didn't buy. Knowing an order number, event name and buyer name isn't enough on its own to settle that question.

Ask your ticketing provider how it verifies a change to the address controlling an order. Find out what happens if the customer cannot access the original inbox, and whether the old address receives a notification. Your support team needs the approved recovery process before the first urgent request arrives.

The OWASP guidance on account authentication recommends renewed identity checks before sensitive account changes such as changing an email address. For a festival operator, the practical lesson is to require the provider's supported verification process instead of treating an inbox request as proof of ownership.

Also check what the new address would reveal. A group order may contain other people's tickets and details. Moving control of the entire order can expose considerably more than the one admission the person says they need. Where the request is really a ticket transfer, direct them to that narrower action.

Don't ask customers to email passwords or complete card details. If the provider's normal recovery process doesn't resolve the case, escalate it to the person responsible for booking disputes. Tell the customer what evidence can be accepted and where to provide it safely, without improvising a different identity test for every agent.

Use the official transfer process for another attendee

A buyer who can't attend should have a clear answer about whether someone else can use the ticket. Publish eligibility, any cost and the completion deadline before purchase. Then point customers to the actual transfer process, rather than inviting them to edit a PDF or forward a screenshot.

Loopyah's ticket transfer instructions explain the supported route when an organizer enables transfers. The holder selects the ticket in My Tickets and chooses Transfer. An email recipient follows the invitation, signs in and accepts. The ticket transfers once the recipient accepts, which matters when you're explaining a deadline.

This is a useful example of letting the product handle an ordinary action. Your team decides whether transfers are enabled and which event conditions apply. Buyers use the supported process. Support handles the cases that fail or require a decision beyond those published conditions.

Keep the purchaser's payment history separate from the current attendee. A friend accepting admission hasn't necessarily paid the organizer, and a holder change doesn't settle money exchanged privately. If the event is cancelled later, your team still needs to understand the original payment and the refund arrangement.

Our guide to fair ticket transfer rules covers that policy in more detail. For this broader booking policy, the essential decision is whether an eligible replacement can complete the transfer without intervention. If they can, don't turn the same action into a separate email approval exercise.

Let additions depend on real availability

Adding a parking pass sounds like an easy way to increase order value. It is, provided there is actually a space available and the buyer receives usable arrival instructions. The confirmation has to match the inventory and the supplier's booking record, rather than merely collecting another payment.

The same applies to camping, workshops, lockers and other extras. Decide which stock belongs to each day, location or admission type. A Saturday camping arrival may require a different entitlement from Friday arrival. Spare stock somewhere in the festival isn't enough if the buyer cannot use it with their booking.

For each addition, check whether the ticketing system can sell it after the original purchase and keep it connected to the right customer. If it cannot, use a supported separate purchase with clear instructions or keep the request with support. Don't advertise an integrated booking change that your setup cannot complete.

Paid upgrades need another check. The buyer should see the new entitlement, the total additional amount and the effect on their original admission before agreeing. Make clear whether the old admission is replaced or whether the purchase is an extra that only works alongside it.

Watch for accidental double selling too. A buyer might already hold a parking pass under another order, or misunderstand which campsite their ticket includes. Clear product descriptions and an accurate booking summary can prevent that confusion. A support team processing mistaken purchases afterwards hasn't saved time simply because the first payment was automatic.

Keep supplier changes and accessibility requests connected

A meal preference or vehicle registration may be editable until the relevant supplier needs its final list. Let the operational reason set the deadline. Don't close every field when one caterer needs numbers, and don't leave every field open because the admission ticket can still change.

Ask each supplier which information they need, when they need it and how later changes reach them. If a customer saves a registration plate after the parking list was sent, who updates that list? Unless someone can answer, the screen is offering a change your operation may never fulfil.

Accessibility arrangements need particular care. A customer may need to update a companion arrangement, arrival plan or equipment detail without changing admission. Keep a named support route available, explain response times, and avoid making the public booking form the only way to ask for help.

Don't invite people to disclose detailed medical information in an ordinary amendment box. Ask for the information needed to arrange support and route it to the people handling that arrangement. The scanner at the gate usually needs the agreed access instruction, rather than the customer's entire explanation.

This is also where automatic approval can be inappropriate even when the request is genuine. An accessible parking space may be limited, or a companion arrangement may need confirmation. Let customers submit the request conveniently, but distinguish "received" from "confirmed" so they can plan their visit with an honest understanding of what is arranged.

Make refunds follow their own rules

A refund is a financial action. Decide the voluntary refund conditions first, then configure the supported customer process to match them. A buyer should understand whether they qualify, what amount returns and what happens to the affected ticket before they confirm the request.

Loopyah's ticketing page describes a refund window measured after purchase. The refund setup instructions specify a period up to seven days and closure three days before the event starts. Explain both conditions so a buyer purchasing close to the festival doesn't expect the full configured period. Verify your settings before publishing the policy.

Keep that voluntary option separate from rights arising when your event changes. The ACCC's guidance on selling event tickets explains that organizer cancellation or major changes can entitle consumers to refunds in Australia. A closed voluntary window doesn't answer every later refund question.

Your support wording should reflect that distinction. "Online refunds are no longer available under our change of mind policy" is more precise than "You have no refund rights." Give customers a route to raise a cancellation, major change or other issue that needs assessment under the applicable rules.

For group bookings, test whether a buyer can refund one eligible ticket without affecting the rest. Check associated extras and any package conditions. Don't promise a partial refund simply because a full order refund works. A refund button should produce an understandable financial result and leave every remaining admission in a state your team can explain.

Set a separate cutoff for each operational need

One universal booking deadline is easy to write and often awkward to run. Your printer might need names before your parking provider needs plates. Transfers may remain workable after both lists close. Customers shouldn't lose useful options merely because one supplier has started production.

Use exact dates, times and time zones in customer instructions. State whether the action must be started or completed by that point. A submitted request waiting for approval isn't a confirmed change. An invitation waiting for acceptance isn't necessarily a completed transfer. Those distinctions matter when the deadline arrives.

Check how the deadline is enforced. If your policy says an option closes but the button remains available, buyers will reasonably expect it to work. If the system cannot close that action as required, choose another supported process and explain it accurately. A sentence in the FAQ won't prevent an incompatible booking from being created.

Have an exception process for genuine operational problems. A customer who started correctly but encountered a service failure needs someone who can investigate. Decide who has authority to approve a late change and what must happen before they confirm it, especially if a supplier already has the earlier information.

Keep statutory correction requests and other applicable rights separate from these commercial deadlines. Your deadline may stop an automatic ticket amendment, but it doesn't necessarily remove obligations to handle inaccurate personal information or a valid complaint. Train support to recognise when the customer is asking a different question from the one the closed button answers.

Record changes so the next person can act

When a change goes wrong, your team needs to answer what happened without reconstructing a conversation across several inboxes. The useful record identifies the booking or ticket, the action, who made it, when it happened and whether it completed. It should also show the information necessary to resolve the consequence.

For example, a supervisor investigating a disputed camping amendment needs to know which arrival entitlement is currently valid and whether the camping team received the update. They do not need unlimited access to every unrelated field in the customer's profile. Keep the record useful for the job it supports.

The FTC's guidance on protecting personal information recommends keeping sensitive information only while there is a business reason and limiting access to staff who need it. Apply that principle when deciding what your booking change records contain and who can read them.

Ask your provider what history is available before promising a complete audit record. Does it show the action and time? Can support tell whether a transfer is pending or accepted? Can you identify the current admission after an upgrade? Write your operating procedure around the records you can actually inspect.

For manual exceptions, record the approval and resulting entitlement through the supported workflow. Don't leave the only evidence in a staff member's private messages. The next shift needs to recognise the same decision, while your retention policy should determine how long the supporting information remains necessary.

Make completion obvious on a phone

Most customers won't study the process before using it. They'll open a confirmation message while travelling, follow a link and try to fix the booking. They need to see the right ticket, the change they're making and the result without guessing which screen contains the final answer.

Use specific action labels. "Update attendee phone number" is clearer than "Manage details" when that is all the screen changes. Before a consequential action, show the affected admission and any payment. After completion, show the new status and tell the customer where to find the ticket or confirmation they need.

The W3C's guidance on form notifications recommends clear feedback about successful submissions and errors, including instructions for resolving problems. Apply that advice to booking changes. "Something went wrong" leaves customers unable to tell whether to retry, wait or contact support.

Distinguish a request from an approval in both the screen and the email. "We've received your camping change request" should explain what happens next and whether the existing booking remains valid. It shouldn't look like confirmation of a new campsite when a person still needs to check availability.

Test keyboard use, screen reader feedback and small screens with your provider's supported flow. Also test an expired link and a customer who no longer has access to the original device. A self service option that only works for the simplest successful attempt will still send plenty of ordinary customers back to your inbox.

Write the policy around decisions buyers recognise

Your public explanation doesn't need your entire internal procedure. It needs to answer the customer's immediate question and direct them to an action that works. Group the instructions around correcting details, giving a ticket to someone else, buying extras and asking for a refund. Explain unusual ticket restrictions where they matter.

Here is illustrative wording to adapt only after testing your own setup. "You can download your tickets through the link in your confirmation. For eligible tickets, use the official transfer option when someone else will attend. The transfer must be completed by the deadline shown in our ticket information. Contact our booking team if you cannot access your order."

Follow that with your actual rules for corrections and extras. For example, explain which details buyers can edit directly, which additions remain on sale and when supplier changes close. Replace general promises such as "change your booking anytime" with the actions and deadlines your event can honour.

Put the short version before purchase, then repeat the relevant instructions in confirmation messages and your FAQ. Someone deciding whether to buy should know about a material restriction before paying. Someone who already paid should be able to find the process without searching your social posts or sending a direct message.

Keep operational messages separate from permission to send marketing. A booking correction isn't automatically a request to join another mailing list. Our guide to an event privacy notice explains how to describe the information you collect and its purposes. Make the booking instructions agree with that explanation.

Tell seasonal staff where to find the policy version customers bought under. If you revise conditions between ticket releases, an older booking may have different terms. Check the original agreement before applying a newer restriction, and record which conditions informed the decision so another agent can understand it without asking the customer to repeat the whole conversation again.

Test a real group booking before launch

Use test customers and sample information to run through an order containing several tickets and at least one extra. Make one ordinary correction, transfer one admission through the supported process and try an addition. Then check what the purchaser, recipient, support team and gate team can each see.

Repeat the important cases near the relevant deadline. Try a pending action that completes late, an unavailable extra and a restricted ticket. Check that a failed payment doesn't leave the customer believing an upgrade is confirmed. Verify that a completed refund doesn't leave the refunded admission apparently valid in the entry process.

You should also test overlapping actions. A customer might start a transfer and ask support for a correction before the recipient accepts. Another might open the same order on two devices. Ask the provider what happens in those cases and make sure support checks the current booking before approving anything further.

Run the exercise with the person handling customer support and the person managing admission. Let them use the records and instructions they will actually have during the festival. If they need the event owner to explain every screen, the procedure needs more work before customers start relying on it.

The test should end with a usable admission record and a customer who understands what changed. If one action updates the ticket but leaves an essential supplier working from old information, keep that action under review until the handoff works. A successful screen message alone doesn't establish that the festival can deliver the change.

Work through a festival booking together

Consider a fictional weekend festival where one customer buys admission for a group, a camping booking and parking. The group is travelling together, but the purchaser won't arrive at the same time as everyone else. Now a friend drops out, another changes vehicle, and someone wants to upgrade admission.

Start with the friend who drops out. Identify the specific admission they held and check whether the replacement meets its conditions. If a supported transfer can move that admission independently, the rest of the order should follow its existing arrangements. The parking and camping permissions still need checking against their own terms.

Next, the vehicle changes. If your parking provider uses registration plates for admission, updating the buyer's account profile isn't enough. Confirm that the replacement plate reaches the parking record used on arrival. If the supplier has already received a final list, support needs to check the amendment before telling the customer it is settled.

The upgrade affects a different part of the operation. The buyer needs to understand which ticket changes, whether the upgrade is available and what additional amount they will pay. Once complete, entry staff need to recognise the new admission. The booking summary must not leave the customer wondering whether to present the original ticket as well.

Finally, consider who receives the practical messages. The purchaser may still handle the camping booking, while the replacement attendee needs their own admission instructions. Sending every update only to the original purchaser could leave the replacement unaware of an arrival change. Test the messages alongside the ticket changes, rather than assuming the right people will forward them.

This example is why a single "edit booking" promise can be misleading. The group has several connected purchases, but each amendment changes a different entitlement or operational record. Your policy should make the easy actions convenient while checking the consequences that matter for each one.

Give support a usable exception process

When a customer needs help, begin by identifying the current booking and the action they want. Check whether an online attempt is already pending. Otherwise a helpful agent might approve a second action while the first is still completing, leaving the buyer with conflicting instructions.

Write down who can approve each exception. An ordinary correction may belong with booking support. A change affecting campsite allocation may need the camping manager. A disputed payment needs the person authorised to investigate it. The customer shouldn't have to work out your organisation chart, so keep one clear contact route and direct the request internally.

Before confirming an exception, check the affected supplier and admission record. Explain whether anything remains outstanding, what the customer should use on arrival and when they should expect the final answer. If approval depends on another person, acknowledge receipt without promising the outcome.

Keep a process for service outages too. If buyers cannot complete a permitted action because your provider is unavailable, decide how requests will be recorded and assessed when service returns. Don't advise people to share account access or alter ticket files as a temporary workaround. Your fallback still needs to preserve a valid booking.

After resolving the request, close the conversation with the actual result. "Your request has been handled" tells the customer very little. Say which admission or extra changed and where they can find its current confirmation. If the request was refused, explain the relevant condition and the practical alternatives available under the event's rules.

Review whether the changes reduced work

After launch, look at the requests that still reach support. Are customers unable to find the action? Do they start it and abandon it? Are they asking for a permission you deliberately withheld? Those are different problems, and each needs a different response.

Compare completed actions with follow up contacts and errors at admission. A higher number of online changes is only useful if customers finish correctly and the team can honour the result. Avoid celebrating fewer emails while supervisors at the gate spend longer resolving bookings that appeared settled online.

Ask support to note the reason for repeated contact in a simple, consistent way. You don't need a complicated reporting project to discover that a confirmation email hides the booking link or that buyers think a transfer invitation is already complete. Fix the explanation when the rule itself is working.

If the rule creates repeated exceptions, reconsider the rule. A cutoff may be earlier than your suppliers actually need. A whole order restriction may be blocking ordinary changes to one ticket. Keep the restrictions that protect a real requirement and revise the ones that create work without improving delivery.

Before your next ticket release, choose one common request and follow it through purchase, amendment and arrival. Let buyers complete it themselves when the verified process handles every consequence. Where it doesn't, make the support route clear and give the responsible person enough authority to resolve it. That is a booking policy your team can run when the festival gets busy.