Manage workshop session transfers without losing a seat

Separate a request from a confirmed transfer

Consider two people moving from a Saturday craft workshop to a Sunday session. Deleting their Saturday booking as soon as the form arrives could leave them without either place when Sunday is full. Keep the original booking and create a separate transfer request. Useful states are received, checking capacity, approved, applied and declined. The first acknowledgement confirms receipt of a request, not a new reservation. This distinction matters because a transfer changes the capacity of two sessions, whereas an ordinary contact-detail correction usually changes only one record.

Match the booking and party size

Collect the existing reference, the contact used at booking, requested session and number of people moving. Names alone are unreliable identifiers. In the internal log, retain original and destination session IDs, party size, reviewer, reviewed time and applied time. A request exceeding the original party size, or moving only part of a group, needs an explicit decision. Required fields and conditional questions can improve the form, but they do not prove that a submitted reference belongs to the person requesting a change. Resolve uncertain matches before modifying either session.

Count confirmed places and active holds

Suppose the destination has twelve places, nine confirmed attendees and two active holds for another request. Only one place remains, so a two-person transfer must not be approved. These are illustrative values, not observed performance. Aggregate by stable session ID, excluding cancelled bookings and expired holds. A single organiser reviewing a small register may be sufficient. If several operators allocate the final seat at the same time, a form and a filtered view are not a concurrency guarantee; assess a booking system that can enforce the required reservation boundary.

Choose an application order and recovery point

Define the application sequence: hold the destination places, record approval against the original booking, attach the new session, release the old places and send the final notice. Keep a request ID and a checkpoint for each completed action. When the booking changed but the email failed, resend the notice rather than moving the booking again. When destination capacity cannot be secured, preserve the original booking. If Airtable automations are involved, identify the trigger and target record carefully, and check whether updating a completion flag can unintentionally qualify the record for another run.

Align deadlines and attendee messages

Write the organiser’s transfer deadline as a date, time and time zone instead of an ambiguous phrase such as the day before. Separate same-day exceptions and any price difference from the ordinary request path. This is a workflow design example, not a statement of contractual refund rights. The final message should state the new session, venue, party size and what happened to the previous booking. Give unresolved contact attempts a review deadline so a destination hold does not remain indefinitely simply because nobody replied to an email.

Start with manual approval where it is sufficient

A handful of transfers each month can be handled with an existing form, a shared register and one reviewer. Before adding Make, fix missing fields, absent ownership and forgotten holds. Costs depend on the notification features, collaboration seats and automation volume you actually need. A restrained first automation records the request and alerts the organiser while leaving the capacity decision to a person. Compare current plan inclusions before paying for additional messaging or automation. Saving a small amount of typing is less useful than preserving the correct booking when something fails.

Test the transfer cases before opening requests

Try available capacity, a full destination, an unchanged session, a late request, an unknown reference, a repeated request and a partial group move. Verify preservation of the original booking and release of abandoned holds, not only the happy path. Use fictional test records and apply an already-completed request again: attendance totals must stay unchanged. Finally reconcile the original session, destination and attendee message. The related workshop, correction and waitlist guides cover adjacent processes; keep those jobs separate so a contact update cannot accidentally acquire the authority to move or release a seat.

• Collect customer change requests with Tally
• Collect workshop applications with Tally
• Manage event registration and a waitlist with Make