Pooled inventory and commissary scheduling for small truck fleets

Once you cross from one truck to three, your inventory problem quietly changes shape. With a single truck, you buy for one calendar, load it, and whatever's left at night is your problem alone. The moment you're running multiple trucks out of a shared commissary, you're no longer managing inventory — you're managing contention. Two trucks want the same 40 lbs of chicken thigh for the same Saturday. One is heading to a festival that'll do $4k in sales, the other to a slow brewery lot that'll do maybe $900. Who gets the protein when the delivery comes up short?

That question — who gets what, when, and based on what rule — is the whole game with fleet pooled inventory for food trucks. Most small operators never actually answer it. They improvise. And improvising works right up until the week it doesn't, usually during your highest-revenue stretch of the season when every truck is booked and every mistake costs real money.

This is a systems article, not a tips article. We're going to walk through how pooled inventory, priority rules, purchase-order timing, and exception handling connect — and where each piece tends to snap under load.

Why pooling makes sense (and why it quietly breaks)

Pooling is attractive for obvious reasons. Buying 300 lbs of onions across four trucks lands you better pricing and fewer delivery minimums than four separate 75-lb orders. A shared walk-in means you carry less total safety stock because demand across trucks partially cancels out — when one truck under-sells, another over-sells, and the pooled buffer absorbs both. On paper, pooling reduces waste, improves purchasing leverage, and simplifies receiving.

In practice, pooling removes the natural guardrail that separate inventories provide. When each truck owns its own cambros, scarcity is visible and personal — the lead knows exactly what they have. Pool everything, and that visibility disappears. Nobody feels ownership of the shared 50 lbs of brisket, so everybody over-draws "just in case." By the time the third truck loads, the pool is gutted, and the fourth truck's operator finds out at 7am that there's half of what the manifest promised.

The failure isn't the pool. It's pooling without an allocation rule. A pool is just a shared resource, and shared resources without priority logic always get consumed by whoever shows up first or shouts loudest. That's not a food-truck problem — that's a physics-of-shared-resources problem.

The allocation rule is the backbone

The core of a working pooled system is a written allocation rule that decides, in advance, how scarce stock gets split. Not a vibe. A rule your commissary lead can execute at 6am without calling you.

What works across small fleets is a tiered allocation that blends two things: committed demand (what a stop is contractually or realistically expected to sell) and stop priority (the strategic value of that stop). You don't want pure demand-based allocation, because your biggest-volume stop isn't always your most important one — a new recurring venue you're trying to lock down might deserve protection even if it's low-volume this week.

1. 1
   Tier 1 — Protected commitments. Catering contracts, private events with deposits, and high-stakes recurring venues. These get allocated first and in full. They have penalties or relationship risk attached.
2. 2
   Tier 2 — Core revenue stops. Your reliable high-volume lots and festivals. Allocated to forecasted demand after Tier 1 is covered.
3. 3
   Tier 3 — Flex stops. Slow lots, experimental locations, soft bookings. These absorb the shortfall. If the pool runs short, Tier 3 gets a reduced menu, not a cancelled day.

The important design choice: shortfall flows downhill. When a delivery comes up short or demand spikes, Tier 3 takes the hit first, deliberately, by rule. Nobody has to negotiate at 6am. The lead pulls up the allocation sheet and executes.

Sample allocation worksheet

Here's a stripped-down version of the kind of sheet a commissary lead can run per high-contention item. Say it's a Saturday and you've got 120 lbs of marinated chicken in the pool across four trucks:

Pool total available: 120. Forecasted need: 155. The 35-lb gap doesn't trigger a panic — it triggers the rule. Tier 1 is whole, Tier 2's anchor stop is whole, and the two lower-priority stops absorb the shortage in a planned way. Truck D's operator knows in advance to lean on a different protein for the day.

This is the difference between a shortage that costs you a catering contract and a shortage that costs you three chicken tacos at a test lot.

Priority assignment by stop and event

Allocation rules are only as good as the priorities feeding them. The mistake that comes up constantly is treating all stops as equal volume targets when they're not equal in risk or strategic value.

A stop's priority should be set when it's booked, not improvised on allocation morning. Three factors drive it:

1. 1
   Downside risk. What happens if you under-deliver? A catering client with a deposit and a contract rider has real downside. A walk-up lot has almost none — you just sell out early and go home.
2. 2
   Strategic value. Is this a venue you're trying to convert into a recurring weekly? Protecting it this week, even at low volume, can be worth more than squeezing extra margin from an established lot.
3. 3
   Expected contribution. Raw forecasted profit, which matters most for tie-breaking between stops of similar risk.

In real operations, this usually breaks when priority lives only in the owner's head. You know the catering gig is sacred and the brewery lot is flexible — but the person loading trucks at dawn doesn't, not reliably, not every time. Write the tier directly onto the booking record so priority travels with the stop into the allocation sheet automatically.

One pattern worth flagging: don't let a single mega-event silently drain every truck. A festival that eats 80% of your pooled protein can leave every other stop starving. Cap how much any single Tier 2 stop can pull from the shared pool, and flag overruns as exceptions rather than just honoring them. Otherwise your "priority system" is just first-come-first-served wearing a tie.

Aligning PO cadence to your route calendar

Most fleets get this piece backwards. They order on supplier convenience — "we always order Tuesday and Friday" — instead of ordering backward from when trucks actually roll.

Your purchase-order cadence should be anchored to your route calendar, not the other way around. If Saturday is your heaviest multi-truck day, the PO that covers Saturday needs a receiving window early enough to catch substitutions, shortfalls, or a vendor no-show before allocation morning — not the night before, when you have zero recovery room.

1. 1
   Monday PO covers Tue–Wed stops. Light volume, forgiving.
2. 2
   Wednesday PO covers Thu–Fri. This is where catering commitments usually land, so build in a confirmation step.
3. 3
   Thursday PO covers the weekend surge. This one receives Friday morning, giving you a full business day to fix shortfalls before Saturday's pooled allocation.

The logic: the higher the contention and revenue of a route day, the earlier its PO should receive relative to load time. Low-stakes weekdays can run tight. High-stakes weekends need a buffer day baked in. This ties directly into commissary procurement systems that prevent last-minute substitutions — the vendor SLA and PO discipline on the buying side is what makes the allocation side trustworthy. If your receiving is chaos, no allocation rule can save you.

The cadence also has to respect your shared commissary's physical schedule. If three operators are all trying to receive, break down, and portion on the same morning, you get prep collisions regardless of how clean your POs are. That coordination layer is its own discipline, covered in shared commissary scheduling rules to avoid overbooking and prep collisions — worth reading alongside this, because PO cadence and prep-window scheduling have to be designed together or they fight each other.

The exceptions SLA matrix — where real systems earn their keep

Rules handle the normal week. The exceptions matrix handles the week that goes sideways, which is the only week that actually tests whether you have a system.

An exceptions SLA matrix is just a pre-written table that says: when X goes wrong, here's who owns it, here's how fast it must resolve, and here's the fallback. The whole point is to remove decision-making from the moment of panic. At 6am with a short delivery, nobody should be inventing a plan.

A practical matrix for a small fleet looks like this:

The value here isn't the specific rows — it's that every likely failure has a named owner and a clock. What breaks small fleets isn't the problem itself; it's the 45 minutes of "who's supposed to handle this?" while the delivery driver waits and two leads argue over the last case of avocados.

Keep the matrix short. Five to eight rows covering your genuinely common failures beats a 30-row document nobody reads. Exceptions that happen once a year don't need SLAs — they need a phone call to you.

A real scenario

A three-truck operation running a brewery-lot-and-events circuit kept hitting the same Saturday wall. Roughly every third weekend, one truck would load out light on a key protein because an earlier truck over-drew the shared pool. The downstream cost showed up as early sell-outs on stops that should've run full shifts — somewhere in the $600–$900 range in lost Saturday sales on the affected truck, plus one catering near-miss that genuinely rattled a client relationship.

The fix wasn't more inventory. It was a two-page allocation sheet with tiers written onto each booking, a Thursday PO that received Friday morning instead of Saturday dawn, and a six-row exceptions matrix taped inside the walk-in. Nothing fancy.

Over the following couple of months, the light-loadouts basically stopped — not because shortfalls disappeared, but because shortfalls now flowed to the flex stop by rule instead of randomly gutting whichever truck loaded last. The catering tier never got touched again. The owner's description was less "revenue exploded" and more "I stopped getting the 6:45am panic calls." That's usually the real win.

When pooling is the wrong move

Pooled inventory isn't automatically correct, and pushing it too early creates problems it was meant to solve.

1. 1
   If you're running two trucks on wildly different menus, pooling creates overhead without much buffer benefit — there's little shared stock to pool. Separate inventories may be cleaner.
2. 2
   If your commissary space is tight, a pooled walk-in with multiple operators drawing from it can create cold-chain and traceability headaches that outweigh the purchasing savings.
3. 3
   If you don't have reliable demand forecasts per stop, your allocation rule is guessing, and a guessing rule is worse than visible per-truck scarcity.

Pooling pays off when your trucks share meaningful menu overlap, your volumes are large enough that purchasing leverage matters, and you can actually forecast stop-level demand with some confidence. Below that threshold, keep inventories separate and revisit pooling when the math changes.

Making the pieces talk to each other

The reason this works as a system and not four disconnected documents is that each layer feeds the next. Priority gets assigned at booking. Booking priority drives the allocation tiers. The allocation forecast drives PO quantities. PO cadence respects the route calendar and the commissary's prep windows. And the exceptions matrix catches whatever slips through all of it.

Where small fleets lose the thread is the handoff between layers — specifically, getting clean quantity and priority data to flow from the booking calendar all the way to the truck manifest without being retyped three times. Every manual re-entry is a place for a transposed number or a dropped tier. Structuring that data so it moves cleanly from commissary to each truck is exactly the problem addressed in a machine-readable commissary-to-fleet manifest schema for small fleets, and it's the connective tissue that keeps your allocation rules from quietly drifting out of sync with what actually got loaded.

“

Plenty of solid small fleets run the whole thing on three shared spreadsheets — an allocation sheet, a PO-to-route calendar, and an exceptions matrix taped where the lead can see it.

A simple visual can make the handoffs obvious at a glance.

You don't need enterprise software to run this. Plenty of solid small fleets run the whole thing on three shared spreadsheets — an allocation sheet, a PO-to-route calendar, and an exceptions matrix taped where the lead can see it. What matters is that the rules are written, the priorities travel with the booking, and the shortfall logic is decided before the short delivery shows up. The spreadsheet is just the container. The discipline is the product.

Get the allocation rule right first. Everything else — cadence, priorities, exceptions — hangs off it. A fleet that knows exactly who gives up the last case of chicken, and why, before anyone asks, is a fleet that stops bleeding revenue on the exact days it should be making the most.