When one customer returns a bike at 1:00 PM and the next picks it up at 1:00 PM, you can't realistically clean and inspect the bike in zero minutes. The turnaround buffer prevents this scheduling collision.
Where to set it
/dashboard/shop-rentals/inventory → Turnaround Buffer card.
The card shows:
- Average buffer minutes across your fleet
- Total vehicle count
- Per-model breakdown (with min/max if values vary across vehicles in the same model)
To change it:
- Pick a scope (All vehicles, or a specific model)
- Enter minutes (e.g., 30)
- Click Apply
The change updates reservation_buffer_minutes on every vehicle in
scope. The next availability check picks it up.
How it works
The reservation availability engine subtracts a buffer window from each vehicle's available time. So if a bike is booked 9 AM – 1 PM and the buffer is 30 min:
- New booking starting 1:00 PM → ❌ rejected (within buffer)
- New booking starting 1:30 PM → ✅ allowed
The buffer applies on both sides of an existing booking — meaning back-to-back attempts in either direction get blocked.
Recommended values
| Shop type | Buffer |
|---|---|
| Casual bike shop with simple cleaning | 15 min |
| Standard rental with helmet sanitizing | 30 min |
| Premium with full inspection | 45-60 min |
| E-bike shops needing battery check | 60 min |
For weekly or monthly rentals, the buffer is rounded down to nothing in practical terms — set it tight (5-10 min) for those use cases via a model-scoped override.
Per-model overrides
The same shop might want different buffers per bike type:
- 15 min on cruiser bikes (quick clean)
- 60 min on e-bikes (battery and electronics check)
Use the Apply to dropdown to scope the change to one model. Repeat for each model with custom needs.
Why on the vehicle, not the model
Buffer is stored on vehicles.reservation_buffer_minutes, not on the
model. This lets you override per-vehicle if needed (e.g., one bike in
the fleet has a finicky brake that needs longer inspection). Most shops
keep all vehicles in a model on the same buffer; the apply-to-model
button does the bulk update for you.
What it doesn't do
- Doesn't insert a "blocked" pseudo-reservation. The buffer is computed at availability check time — it's not a stored reservation.
- Doesn't block damage events or service log entries. The buffer is just for back-to-back bookings.
- Doesn't apply between different bikes. A 1:00 PM return on bike A doesn't affect bike B's availability.
Verifying the buffer is working
Test with a sample booking:
- Open the public booking page
- Pick a model that has only 1 unit in stock
- Verify a 9-1 PM booking is allowed
- Try to book 1-3 PM same day — should fail with no availability
- Try 1:30-3 PM (assuming 30 min buffer) — should succeed
If the second test allows 1:00 sharp, your buffer might not be set on that specific vehicle. Check the Per model breakdown.
Common edge cases
Customer wants a back-to-back at the counter
Operator override: cancel the buffer for this specific booking by
manually creating it via the database (reservation_buffer_minutes is
checked at API level, not enforced as a hard constraint in the
database).
In practice: tell the customer "we need 30 minutes to clean the bike between rentals" — most accept this.
Buffer is too long, blocking obviously-fine bookings
Lower it. For high-traffic urban shops, even 15 minutes might be too much in peak season. Adjust based on real operational pace.
New vehicles don't have a buffer set
New vehicles inherit a default of 0 minutes if you don't set one. Either run the bulk update again after adding new vehicles, or set the buffer per-vehicle when adding them in the vehicle creation form.