A rental company lists the same slide as a dry rental, a wet rental and part of an event package. Three offers appear on the website, but there are still only as many slides as the company physically owns. A booking against one offer must reduce what can be sold through the others.

Inflatable rental shared inventory starts with a simple distinction: customers choose offers; bookings consume resources. Map each offer to its required equipment, then calculate availability across those shared requirements. The worked example below shows how that changes individual bookings, package availability and order amendments.

Map Each Offer to the Equipment It Consumes

Start with equipment approved for the intended use. A wet/dry inventory setup records a permitted configuration; it does not make a dry-only model suitable for water. When adding commercial inflatable water slides, establish the exact model and its permitted configurations before creating alternative sales listings.

For this fictional example, assume a single overlapping booking window, two interchangeable slides called resource A, one compatible wet-use accessory kit H and one game G. Every item is available for that window. Other necessary equipment is already accounted for; H is an illustrative constrained resource, not a complete equipment list or a standard supplier bundle.

The last row creates a rental package availability rule: all three components must be available together. The kit must also be shared between the two offers that use it. Giving each listing its own independent copy of H would invent stock.

This issue appears in real rental systems. Event Rental Systems' package documentation describes dry and wet slide options using one underlying inventory item. InflatableOffice's accessory documentation describes required accessories and availability across linked rentals. Those are examples of software implementations; the resource calculation below is independent of either interface.

Calculate the Limit for Each Offer

For each required resource, divide its available quantity by the quantity needed for one booking, round down to a whole booking, and take the smallest result. Ignore resources the offer does not require.

Offer limit = the minimum of floor(available resource ÷ quantity required per booking).

With A = 2, H = 1 and G = 1, the dry offer has a limit of two. The wet offer is limited to one by H. The wet-slide-and-game package is also limited to one: min(2 ÷ 1, 1 ÷ 1, 1 ÷ 1) = 1.

These limits answer separate questions: how many of each offer could be booked from the current starting position? They are alternative uses of shared stock. Adding 2 + 1 + 1 does not produce four available slides or four simultaneously fulfilable orders.

Pooling also requires genuine interchangeability. Two bounce house combos with different promised themes or model requirements cannot automatically be treated as equivalent. If a particular unit is promised, the resource model must preserve that restriction.

Recalculate After Every Competing Booking

Suppose the first customer books the wet-slide-and-game package. That order consumes A × 1, H × 1 and G × 1. One slide remains, but there is no kit or game left for another overlapping booking.

The second customer can take the remaining slide dry. Selling another wet offer would require a kit that is already committed. Buying another slide alone would not remove that kit constraint.

The order sequence matters because each accepted booking changes the next customer's choices. Website, telephone and office bookings need to affect the same underlying quantities. Our rental booking software guide covers broader system selection; use this calculation as a concrete trial case when checking how a proposed system handles shared resources.

Treat an Amendment as a Change in Requirements

Return to a different starting position: two dry bookings occupy both slides. The recorded commitments are A = 2, H = 0, G = 0. No slides remain available, but the kit and game are unused.

If one customer changes from dry to wet, the amended order still requires one slide. It adds one kit. The combined commitments become A = 2, H = 1, G = 0; a check that demands a third slide would incorrectly reject a feasible amendment.

If that customer then requests the game package, the change adds G × 1 while retaining the same A and H commitments. If another booking has already consumed G, the proposed amendment cannot be confirmed from this pool.

Compare the old and proposed requirements together before committing the change. Avoid releasing the original booking first and hoping its resources remain available while the replacement is entered. Check how the actual system protects that transition, including simultaneous enquiries.

Cancellation releases only the cancelled order's recorded allocation. Cancelling one wet package returns one A, one H and one G; it does not reset every linked listing to its original stock quantity. For separately tracked physical units, the individual inflatable asset-record guide explains the identity record that sits behind an equipment reference.

Test the Resource Model Before Using It for Live Orders

Use test bookings in an isolated trial or a controlled test window. Write down the expected resource balance before examining what the system displays:

1. Book one wet offer. Expect A = 1, H = 0, G = 1 remaining; the wet package must also become unavailable.
2. Add one dry booking. Expect A = 0; every slide offer is now unavailable.
3. Cancel only the wet booking. Expect A = 1, H = 1, G = 1; the dry order must remain allocated.
4. Change the remaining dry order into the wet package. Expect A = 1, H = 0, G = 0 remaining.
5. Cancel that amended order. Expect the starting balance, A = 2, H = 1, G = 1.

Investigate any mismatch at the resource level: an unlinked accessory, a duplicated component, a missing package requirement or an amendment that left the old allocation behind. A correct-looking product calendar alone does not establish that every dependency is working.

This example isolates overlapping, interchangeable stock. Real availability must also respect the actual allocation window, preparation, maintenance, delivery and other business constraints. If the software cannot express a required dependency, use a documented manual confirmation process rather than advertising unrestricted instant availability.

Download the worked inventory test as a CSV and replace the illustrative offers with your own approved configurations. The useful result is a booking model in which each confirmed offer consumes exactly the resources it needs, and every competing offer reflects what remains.