Planning Profiles: How to Run Different Dispatch Rules for Different Hubs, Days, or Order Types

Most delivery platforms let you set delivery planning rules once. Service time per stop, vehicle capacity, how strictly to respect time windows, when the order cutoff falls. That works for a single hub running a single kind of order. It stops working the day you open a second hub with a different product mix, or the day a Shipper with tighter windows signs on.

Planning Profiles, found under Settings, Planning and Automation in Geofleet, solve this by turning the rule set into a reusable object. You define a profile, attach it to the hubs, days, order types, or Shippers it should govern, and Smart Planner picks the right one when it builds routes. This post explains what a profile contains, how attachment and precedence work, how Smart Planner and Auto Allocation consume the profile, and a worked example with three profiles running side by side in one city.

Why One Global Rule Set Breaks at the Second Hub

Consider an operator running three hubs in the same metro. The grocery hub runs two-hour windows, 30 to 40 stops per van, and a 90-second service time because most drops are doorstep. The pharmacy hub runs signature-required drops with ID checks, so service time is closer to four minutes, capacity is measured in totes rather than volume, and cold-chain orders cannot sit in a vehicle for more than a fixed number of hours. The B2B hub delivers pallets to loading docks with appointment slots, eight to twelve stops per truck, and a cutoff at 4 pm the previous day.

With one global rule set, whichever hub you tune for wins and the other two lose. Set service time for pharmacy and the grocery routes come back with a third of the stops they could carry. Set it for grocery and pharmacy Captains run 40 minutes behind by lunch. Set strict time windows for B2B appointments and the grocery planner refuses to build routes on a busy Saturday because it cannot satisfy every window. The usual workaround is a dispatcher who knows the exceptions and adjusts by hand, which is exactly the manual work the platform was meant to remove.

What a Planning Profile Contains

A planning profile is a named bundle of the parameters Smart Planner uses to construct and score routes. The exact fields vary with how your tenant is configured, but a profile typically defines the following. Treat the table as a description of the kinds of rules a profile carries rather than an exact form layout.

Service time and capacity are the two that matter most

If you only tune two parameters per profile, tune these. Service time is the multiplier on everything else: a 30-stop route with the wrong service time is off by an hour before the vehicle leaves the hub. Capacity model errors are the other silent killer. A planner that counts parcels when the real constraint is chilled totes will overload a reefer van and force a mid-route return.

Time-window strictness is a business decision, not a technical one

Hard windows protect appointment-based customers and cost you route density. Soft windows with a lateness penalty keep density high and let the planner trade a few minutes of lateness for a whole extra route saved. The right answer differs by order type, which is precisely why it belongs in a profile rather than a global toggle.

How Profiles Attach to Hubs, Days, Order Types, and Shippers

A profile does nothing until it is attached to a scope. Geofleet supports attaching profiles at several levels, and the practical value comes from combining them. The following scopes are the ones most operators use.

• Hub: the default profile for every order dispatched from that hub. This is where most operators start.
• Day of week or date: an override for Saturdays, public holidays, or a promotional weekend when volume and staffing look different.
• Order type or service level: express, scheduled, cold-chain, returns pickup, or bulky. The order type carries the profile regardless of hub.
• Shipper: a client with contractual rules, such as a pharmacy chain that requires signature and a two-hour window on every drop.

Precedence when scopes overlap

Overlaps are normal. A cold-chain order from a pharmacy Shipper on a Saturday at the north hub matches four scopes. Geofleet resolves this with a precedence order, and a sensible default is the most specific scope wins: Shipper or order-type rules override day rules, which override the hub default. For example, a profile attached to the "cold-chain" order type might set a hard four-hour vehicle dwell limit that applies no matter which hub the order leaves from, while the hub profile still supplies capacity and cutoff.

The important discipline is to keep the number of overriding scopes small. Two or three layers are readable. Six layers with conflicting values become the same undocumented tribal knowledge you were trying to eliminate.

"We used to re-plan the pharmacy runs by hand every morning because the planner did not know about ID checks. Now the pharmacy profile carries a four-minute service time and a signature requirement, and the routes come out right the first time."

— Operations lead, regional pharmacy and grocery delivery network

How Smart Planner Uses the Profile to Build Routes

Smart Planner is the route construction engine. When a planning run starts, whether on a schedule, at a cutoff, or manually, it gathers the unplanned orders in scope, resolves the profile for each order, and groups orders that share a profile into planning sets. Each set is then routed using that profile as its constraint model.

1. Collect orders that have passed their cutoff and are not yet on a route.
2. Resolve the effective profile per order using hub, day, order type, and Shipper attachments.
3. Apply batching rules to form waves, for example a 10:00 wave and a 14:00 wave for grocery.
4. Filter eligible vehicles and Captains by the profile’s vehicle and skill requirements.
5. Build routes that respect capacity, max stops, max duration, and window strictness, then sequence stops using priority weighting.
6. Score the plan on distance, lateness risk, and utilisation, and present it for release or auto-release.

Because the profile is resolved per order rather than per run, a mixed pool of orders at one hub can still produce correctly constrained routes for each order type. The planner does not need a human to pre-sort them. For the underlying optimisation approach, see the guide to AI route optimization for delivery linked at the end of this post.

Worked Example: Three Profiles, One City

Here is how an operator with the three hubs described earlier might set this up. The numbers are illustrative; yours will come from your own dwell-time and load data.

On a normal weekday, the grocery hub default plans two waves of dense van routes. Pharmacy orders, wherever they originate, pick up the Shipper override and are routed only onto reefer vehicles with certified Captains, in hard two-hour windows. The B2B hub plans the next day at 16:00 with appointment slots as hard constraints. Add a Saturday override for the grocery hub that drops max stops to 32 and moves the second wave to 13:00, and the weekend takes care of itself.

How Planning Profiles Interact with Auto Allocation

Planning Profiles govern batch route construction. Auto Allocation governs live assignment of individual orders to Captains. They share the same rule source. When an express order arrives after the morning wave has left, Auto Allocation resolves the same profile the planner would have used, so it only considers Captains with the required vehicle and skills, respects the same window strictness, and honours the same priority weighting. This is what keeps a live-assigned order from being handed to a Captain who cannot legally or physically fulfil it.

If you are moving from static daily routes to a mix of planned waves and live dispatch, the profile is the object that keeps both modes consistent. The 30-day transition plan linked below walks through that migration in detail, and the companion post on auto allocation explains the live side.

Rolling Out Profiles Without Breaking Live Dispatch

1. Export a week of actual stop dwell times and route durations per hub and order type. This is your evidence for what each profile should contain.
2. Create one profile that matches your current global settings and attach it to every hub. Nothing changes yet, but every route is now tagged with a profile.
3. Clone it for the single case that hurts most, adjust only the parameters your data supports, and attach it to that hub, day, or order type.
4. Run for one week. Compare planned versus actual duration, stops per route, and on-time rate for routes under the new profile.
5. Add further profiles only where the numbers show a real difference. Retire any profile that produces the same plan as its parent.
6. Document precedence in plain language somewhere your dispatchers will read it.

Profiles are not a one-time setup. Review them quarterly, or whenever a hub changes its product mix, a Shipper changes its contract, or a new vehicle class joins the fleet. The cost of a stale profile is the same as the cost of no profile: routes that do not match how the day actually runs.