Pickup Date From

Pickup Date To

Booking Date From

Booking Date To

Location

Compare bookings made on

Location

All locations

All classes

All rate codes

All agencies

AI Demand Forecast

Time-series forecast powered by NavCastiq — trained on your historical pickup actuals

AI Revenue Forecast

T&M Revenue, RPD, Rental Days & LOR — trained on historical actuals

Fleet & Utilization Forecast

Units on rent, utilization & fleet efficiency — trained on daily activity history

Fleet Valuation

Unit-level fleet composition, disposition pipeline & AI fleet health analysis

Fleet Intelligence

Disposition priority · timing · market optimizer · rebalancing — AI-powered

Fleet Planning

Per-location demand & fleet plan, built from historical actuals

Methodology: Avg Daily Demand = trailing 3-month average of (Closed Rev Days ÷ days in month), i.e. average vehicles on rent per day. Demand Target = Avg Daily Demand ÷ Target Utilization. Target Fleet = max(Demand Target, Facility Min) — Facility Min is a manual per-location input for cases like a consolidated airport facility's Minimum Annual Guarantee, where the contractual fleet floor can exceed what demand alone would justify; edit it directly in the table and it's saved for next time. Class-level Target Units allocate each location's Target Fleet in proportion to that class's share of rental-day demand from bookings history. $ Impact uses a placeholder holding cost of $12/unit/day for over-fleeted units and an estimated average daily rate for under-fleeted (lost-opportunity) units — both are adjustable assumptions, not final figures.

This page is built from two different snapshots, each timestamped independently: the Location table and Idle Units Trend come from the Daily Activity report (a midnight read, refreshed daily); the Fleet Status Mix and Class Availability charts come from the FleetCast file (also a daily snapshot, loaded separately in Fleet Valuation). Neither is real-time within the day — both reflect the most recent load. Class charts group unit-level Status as On Rent / AVAILABLE / everything else (maintenance, hold for sale, at auction, etc.) as Down/Other.

Matching: each deficit location is filled from the nearest surplus location that still has units to give, falling back to the largest available surplus when distance can't be determined. A location only offers units above its own target, so Facility Min floors are respected automatically — a location held up by a contractual minimum will never be asked to give those units away. Positions within 2 units of target are treated as on target and left alone. Distance is great-circle mileage between recognized airport codes; other location codes show "—" and are matched by surplus size instead. Real driving distance will be somewhat higher. Transfer cost follows the costing mode. Drive-away is linear — distance × $/mile × cars, since each car needs its own driver. Transporter is a step function — cars are packed into loads, and each load costs (distance × $/mile per load) + the flat fee, whether it's full or not. That's why the $/Unit column matters: a partial load carries the same truck cost as a full one, so a move of 9 cars on 8-car carriers is far more expensive per unit than a move of 8 or 16. Partial loads are flagged. Monthly Gain is the receiving location's average revenue per day × target utilization × 30, i.e. what an additional unit there could reasonably earn. Holding cost isn't credited, since the unit incurs it at either location. Payback is the months to recover the transfer cost. These are planning estimates, not carrier quotes.

Method: seasonal-naive with trend. Each future week is forecast as last year's actual demand for the SAME ISO week, multiplied by a trend factor measured as this year's last 8 matched weeks ÷ the same 8 weeks last year (clamped to 0.5–2.0 so one anomalous week can't distort the whole horizon). Weeks with no prior-year match fall back to a trailing 4-week average, and the Basis column says which rule produced each row. Accuracy: the headline figure is a real backtest — the most recent complete weeks are held out, forecast using only data that predates them, and compared against what actually happened. It is measured on your data, not a generic claim. This forecast is intentionally transparent and instant rather than AI-driven; the AI Fleet & Utilization Forecast page under AI Forecasts remains the richer model-based view.

Load a Fleet file on the Fleet Valuation tab to build a replacement schedule.

This is the capital layer, not the disposition queue. Fleet Intelligence scores individual units for "should this car go now". This one answers the planning question instead — how many units cross a threshold, in which months, and what that costs — so it stays aggregate and forward-looking rather than per-unit. Method: each unit's months-to-replacement is the sooner of two paths — miles remaining ÷ the monthly accrual rate, and age limit minus months already on fleet. Units past either threshold are Overdue and shown in month zero. Where the numbers come from: odometer and model year are read from the fleet file. Months on fleet uses Days on Fleet where the file provides it and falls back to model year otherwise, which is coarser — a unit bought used looks younger than it is. The monthly mileage rate is measured from your own fleet when Days on Fleet is available, and is an editable assumption when it isn't; the note above the schedule says which is in play. Replacement cost is always your input, since no feed carries it.

Served demand is capped at fleet size. That single constraint is what makes this more than arithmetic: cut the fleet far enough and demand stops being fully servable, so revenue falls even though your cost base shrank. The Unserved column is where that shows up — it's demand you'd have to turn away. A scenario that looks profitable while stacking up unserved demand is usually one that's quietly shrinking the business. Two ways to drive fleet. "Fleet size change" nudges it by a percentage. "Target utilization" works backwards — you name the utilization you want to run at and the model solves for the fleet that delivers it against the scenario's demand, then reports what that implies in units. The second is usually the more useful question. Note that in target-utilization mode nothing is ever turned away — the fleet is sized to exactly meet demand, so Unserved is zero by construction. The constraint that binds there is the Facility Min: a high target can size a location below a contractual floor, which is what the warning banner is for. Unserved demand only appears when you drive fleet by percentage and cut past what demand needs. RPU is monthly revenue ÷ fleet units — the fleet-productivity read. A fleet cut that holds revenue raises RPU, which is precisely the efficiency claim such a cut is making; if RPU rises while unserved demand also rises, you're not getting more efficient, you're getting smaller. The portfolio RPU in the KPI strip is total revenue over total fleet, not an average of per-location RPUs, so a 20-unit site doesn't count the same as a 400-unit one. Baseline is each location's trailing 3-month average fleet, average daily demand and revenue per day, all reported. Costs use the same three assumptions as the Cost & Profitability tab, so changing them there changes these results too. Demand and fleet levers scale the baseline directly; the rate lever moves revenue per day only, and deliberately does not feed back into demand — real price elasticity isn't in this data, and inventing an elasticity curve would make the output look more authoritative than it deserves. Read a rate change here as "if we held volume", and treat the volume response as your judgement call.

The core limitation: the Daily Activity report publishes Non-Useable as a single blended total — incoming fleet, disposal units and service units all land in the same number, with no breakdown by reason. Splitting it requires cross-referencing the FleetCast report's unit-level statuses, and only the current FleetCast snapshot is retained. So the composition above is today's, and it cannot be reconstructed for a past month. That's why an elevated reading in June can't be attributed to a cause from this data alone. Retaining a dated FleetCast copy each day would fix this going forward. Categories: Incoming is Non-Active (fleet type 40) — units entered in the system but not yet delivered, so they're excluded from idle fleet by default; they aren't yours to earn on yet. Disposal (hold for sale, auction, turnback) IS counted as idle, since that's capital sitting still regardless of the reason. Service covers maintenance, cleaning, claims and damage. Revenue impact is discounted by utilization on purpose. Lost rental days = avg units idle × 30 × that location's utilization, then valued at its revenue per day. An idle unit at a location running 90% was almost certainly a lost rental; the same unit at 55% mostly wasn't. Multiplying every idle unit by a full day's rate would produce a much larger and much less defensible number. Treat this as the recoverable opportunity, not a headline loss.

Reported (from your data): Revenue, Rental Days, RPD, Utilization and RevPAC all come straight from the Daily Activity report and bookings history — no modeling. Estimated (from the assumptions above): Est. Cost = (avg fleet × depreciation × months) + (fleet days × fixed holding) + (rental days × variable). Contribution and Margin follow from that. TSD sends no cost or depreciation feed, so these three inputs are the entire cost model — change them and every estimated figure updates. Treat contribution as directionally useful for comparing locations against each other, not as a substitute for the general ledger.

Fleet Size alerts use a fixed 85% target (independent of the what-if slider on the Optimization tab) so this feed stays stable as a monitoring baseline. Utilization Trend alerts compare the most recent week with data against the same ISO week last year, flagging swings of 10+ percentage points. Fleet Age/Mileage alerts flag locations where 30%+ of the loaded fleet snapshot is at 30k+ miles.

Rate Evolution

Your rates vs competitor rates over time — AI-powered pricing position analysis

All competitors ✦ AI Rate Analysis