Double bookings often begin with a reasonable local decision. A colleague accepts a phone booking, a guide agrees to an extra guest or a sales channel still shows yesterday's allocation. Each person sees enough room in their own view. The conflict becomes visible only when the departure list is assembled.
Preventing this requires more than lowering the maximum passenger number. You need a clear capacity model, a rule for temporary commitments and a way to reconcile channels. The framework below is intended for a small tour business using either a booking system or a carefully maintained manual register. It does not assume any particular integration exists.
Define what one sale consumes
List the resources used by each product option. A walking tour may depend on a guide and a maximum group size. A tour with pickup may also depend on vehicle seats and a driver. An activity can require equipment in particular sizes, while a private booking may reserve a whole resource regardless of how many guests attend.
Make those differences explicit before entering numbers into software. One booking is not one passenger, and one passenger is not always one equipment unit. A family booking can contain several people with different requirements. A private group of two might occupy the same departure resource as a group of six.
Booking tools reflect these distinctions in different ways. Bókun's resource-management documentation describes allocation rules for assigning resources. Checkfront's Classic Products terminology distinguishes quantities, capacities and shared resources. These are examples of concepts to investigate in the relevant software version, not a claim that Tripnatic connects to either system.
Separate the product promise from the operational limit
The advertised maximum group size tells guests what experience to expect. The operational capacity determines how many places can actually be sold for a particular departure. A tour described as limited to twelve should not carry more simply because a larger vehicle becomes available. Conversely, a twelve-person product may have only ten usable places on a particular date.
Keep three numbers distinct: the product maximum, the resource capacity for that departure and the remaining sellable places. Decide which person can change each. A sales assistant should not increase the product maximum to solve a last-minute resource problem without reviewing the customer promise.
GetYourGuide's maximum-group-size guidance states that the total includes customers booked outside its channel and highlights consistency between related settings. That principle is useful beyond one marketplace. The guest experiences the entire group, not just the passengers whose bookings came through a particular website.
Work through the tightest-resource calculation
Consider a hypothetical departure advertised for a maximum of twelve guests. The assigned guide can serve that planned group, but the available transport provides ten usable guest places. For this example, no alternative transport has been approved. The departure's operational capacity is therefore ten, even if twelve equipment sets are ready.
Suppose eight places are confirmed and one place is held under a documented policy. Only one place remains available to sell. A new request for three cannot be accepted on the assumption that the hold will probably expire or another vehicle might appear. It needs a different departure or an approved resource change.
If the held place is released, two places become available, still fewer than the requested three. Writing the quantities down prevents a surprisingly common arithmetic error: treating a released hold as an entirely new block of capacity. Keep the worked example beside your procedure and replace its assumptions with those relevant to each product. It illustrates operational arithmetic, not a recommended group size.
Give shared resources their own timetable
A guide, vehicle or equipment set may appear in several product listings. Selling one option can therefore affect another option at the same time. A private morning excursion and a shared morning excursion cannot both rely on the same exclusive resource unless their arrangement genuinely permits sharing.
Record when the resource becomes occupied and when it is available again. Include preparation, travel between meeting points and turnaround where required. Two tour descriptions ending and beginning at the same clock time do not establish that the guide or vehicle can move between them instantly.
Make resource conflicts visible before the guest-facing product is confirmed. In a manual system, a resource calendar can sit beside the departure register, with one person responsible for reconciling them. In software, test how shared resources are allocated and released. Do not infer that the system handles your particular conflict simply because it has a feature called availability.
Create a controlled path for manual bookings
Phone, hotel, walk-in and owner-arranged bookings must consume capacity through the same operating rules as online bookings. Record the quantity and resource impact before promising the guest a place. If staff cannot access the record while away from the office, give them a defined way to request confirmation from the person who can.
Set a rule for when a manual booking becomes confirmed and who communicates that decision. Avoid an informal chain in which a hotel tells a guest yes, a driver mentions it later and the office finally enters it after selling the remaining seats. The person making the commitment needs access to an authoritative decision.
Do not create a second independent seat pool in a notebook. If an outage requires a temporary offline record, label it as such, limit who can accept new bookings and reconcile every entry when access returns. The temporary procedure should explain what happens to online sales during the outage rather than assuming they have stopped.
Make holds real or stop calling them holds
A hold should identify the departure, quantity, reason, owner and expiry. It must reduce the sellable quantity if staff tell a customer the places are reserved. An unrecorded verbal hold has all the inconvenience of a commitment and none of the controls needed to honor it.
Decide whether holds are permitted for each product and channel. A private group needing a short decision window may justify a hold, while a high-demand scheduled departure may remain subject to availability until booking. State the rule clearly instead of allowing each staff member to invent a courtesy period.
Review holds at a defined frequency and release them through the same record that created them. Before extending one, check competing enquiries and the remaining preparation time. If a quote does not hold capacity, say so: “This quote is valid until [time], and availability will be checked again when you confirm.” Price validity and reserved inventory are separate decisions.
Set cutoffs around the work needed to deliver
The booking cutoff should reflect the last point at which you can accept and prepare a guest responsibly under your operating arrangements. Work backward from tasks such as assigning transport, issuing pickup instructions, preparing equipment and briefing the guide. A late sale is useful only when the team can still deliver it.
Bókun's availability guidance includes booking-cutoff settings and points out that connected product settings need alignment. If you use several channels, check each one's cutoff and what happens after it. Do not assume changing the office calendar automatically updates every external listing.
Document an exception process for late requests. Name who may approve them and what must be checked again. A cutoff exception should not silently bypass transport capacity or guest instructions. If approval is declined, offer the next workable departure without suggesting that staff are merely unwilling to help. The constraint is delivery, not the desire to make a sale.
Reconcile channels instead of trusting labels
Decide whether each channel sells from shared live inventory, a separate allocation or a request process. Write that beside the channel name. Where a connection is supported, verify the mapping for product, option, departure, participant categories and time zone. A working connection for one option does not establish correctness for every option.
Where updates are manual, allocate conservatively and set a reconciliation routine appropriate to booking speed. This might require checking after each sale near capacity rather than only at the end of the day. Any example frequency is an operating choice; test it against how quickly your departures can fill.
Tripnatic's operator tools include schedules, capacity and cutoffs, but this guide does not promise a native channel-manager connection or synchronization with other booking systems. Use the actual controls available in your account and verify your separate channels. The booking workflow guide explains how those decisions connect to confirmation and guest communication.
Build checks that count places correctly
If your register has one row per booking, counting rows will not tell you how many passengers are booked. Sum the resource-consuming quantity for the relevant departure and status. Keep canceled records identifiable so they can be excluded deliberately rather than deleting them and losing the change history.
Google Sheets SUMIFS supports summing values against several criteria. That can help calculate confirmed places by date and departure in a manual register. The formula still depends on consistent inputs and correct ranges. A neatly formatted total can be wrong when a booking uses an unexpected status or a new row falls outside the calculation.
Test your setup with hypothetical cases: two passengers in one booking, one canceled booking, one live hold and a booking moved between departures. Check both the old and new departure after a move. Have someone other than the formula author explain the result before the register becomes the basis for live selling.
A manual check should also compare units. A departure total of nine people cannot be subtracted directly from a pool of three vehicles without a rule describing each vehicle's usable capacity and exclusivity. Similarly, an equipment pool may have enough items overall but insufficient items in the sizes the group requires. Write the conversion rule beside the resource rather than leaving it in the owner's memory.
Keep resource changes dated. If a vehicle becomes unavailable for maintenance next week, record the affected period and review departures already sold during it. Closing future sales does not solve commitments made before the closure. The review needs an owner who checks those existing bookings, identifies workable replacements and communicates any material change through the normal booking process. That distinction prevents a technically correct availability calendar from hiding an unresolved delivery problem.
Respond to conflicts with one decision owner
When a conflict appears, pause new commitments to the affected departure through the relevant controls. Confirm the facts before offering solutions: which bookings are confirmed, what resources are committed and what alternatives can actually be delivered. Do not let several team members independently promise different fixes.
Assign one person to coordinate the decision and guest updates. Possible operational options include an approved extra resource, a different departure or the applicable cancellation process, but each needs confirmation. Never assume a substitute experience is equivalent merely because it has a similar duration or price. Give the guest clear information about any proposed change.
After resolving the immediate case, identify how it entered the system. Was a manual booking omitted, a hold invisible or a shared resource modeled incorrectly? Correct that cause and test it. Reducing all future capacity without understanding the failure can hide the problem while making the business less efficient.
Keep a short daily capacity check: upcoming tight departures, unresolved resource assignments, expiring holds, manual entries and any channel not yet reconciled. Record who completed it and what remains open. This is a practical handover, not a guarantee that mistakes can never happen.
If you are considering Tripnatic, review the operator workflow and use the account's current capacity settings within this wider process. The final test is whether the next person can explain why a departure has a particular number left to sell. A defensible answer connects the customer promise, the resource plan and every accepted booking.
