Optimiciti

Resort & hospitality shuttles

Plan resort shuttles that pool guests without long detours

You set the pickup windows, the vehicle sizes and how far out of the way a guest may be taken. Optimiciti works out who rides with whom and in what order, and flags anything it cannot fit.

Where the difficulty is

Everyone wants the first lift.

You know your properties, your lift times and what a guest will tolerate. The difficulty is that pooling is a trade: every rider you add to a shuttle shortens the fleet's total driving and lengthens somebody's journey. Finding the split that keeps both acceptable, across a whole morning of pickups, is a search problem rather than a judgement call — and it changes completely when one flight lands late.

What makes it tricky

What you can hold the solver to

You define these; the solver treats them as hard constraints rather than preferences. If a run cannot satisfy one, the ride is returned unassigned rather than quietly pooled into a two-hour trip.

  • A cap on detours

    Set the most extra time any one rider may absorb from pooling. The solver will not exceed it to save a mile elsewhere.

  • Boarding windows

    Each party boards inside its own window. A pickup is never scheduled outside it.

  • Seats are finite

    An 8-seat electric shuttle and a 16-seat minibus are different constraints. A run never carries more than the vehicle holds.

  • Runs that cross midnight

    An evening arrival and the next morning's first-tracks run solve as one plan, not two disconnected ones.

  • Fixed anchors

    A lift opening, a flight time, a tour rendezvous — times you do not control become bounds the plan works around.

  • Shifts and bases

    Drivers start and end where their shift does, from one base or several.

What you get

Every guest inside their window, nobody taken far out of their way. Fewer vehicles doing it.

Detour caps are hard, not weighted.
A rider's maximum excess time is a constraint the solver will not trade away for a shorter fleet distance.
Pooling is the objective, not a side effect.
The solver looks for the fewest vehicle-minutes that still satisfy every window and cap you set.
Vehicle size gates the work.
Party sizes and seat counts decide which shuttle can take which booking; the plan is built around that, not corrected afterwards.
Re-solving is cheap.
A late flight or an added booking is a new solve, not a rebuild — and it runs in the background while you carry on.

Try it with your own runs

Open one of the examples above and change it, or enter your own pickup points, windows and shuttles. No account needed.