Reasoning & math
AuraScore 81/100

Last-Mile Delivery Density and Stop-Time Optimization Report

Model parcel drop densities, stem times, and driver shift constraints to optimize last-mile delivery cluster efficiency.

Deploy this template when planning urban parcel dispatch zones to balance route stem times against on-foot delivery density. It provides dispatch engineers with mathematical breakdowns of stop-per-hour trade-offs and capacity limits.

Template

Role: Last-Mile Routing & Dispatch Optimization Systems Engineer

Context

  • Territory Boundary: Optimizing parcel density across {{service_zone_area}}.
  • Stop Target: Modeling delivery workload for {{average_daily_stops}} per vehicle.
  • Linehaul Ingress/Egress: Transit overhead dictated by {{stem_mileage_to_cluster}}.
  • Volume Characteristics: Van pack factor determined by {{package_cube_distribution}}.
  • Labor Envelope: Maximum shift duration restricted to {{driver_shift_limit_hours}}.
  • Urban Impedance: Transit velocity modified by {{traffic_congestion_index}}.

Task

Generate a mathematical last-mile delivery density and route feasibility report that evaluates stops-per-hour thresholds, isolates transit overhead against on-foot service times, and establishes optimal dispatch cluster boundaries.

Method

  1. Calculate total unadjusted transit time for ingress and return using {{stem_mileage_to_cluster}}.
  2. Apply {{traffic_congestion_index}} to transit times to determine effective stem drive time.
  3. Subtract total stem transit time from {{driver_shift_limit_hours}} to establish the net available on-route delivery window.
  4. Calculate delivery stop density per unit area using {{average_daily_stops}} and {{service_zone_area}}.
  5. Model inter-stop drive and walk durations based on stop density and parcel handling requirements from {{package_cube_distribution}}.
  6. Compute the required stops-per-on-route-hour needed to complete {{average_daily_stops}} within the net delivery window.
  7. Evaluate whether required stops-per-hour fall within realistic operational productivity bands (18-28 stops/hr).
  8. Determine parcel cubic capacity bottlenecks against vehicle payload to verify route cube-out risk.

Constraints

  • Route models MUST NOT exceed the total on-duty hours defined in {{driver_shift_limit_hours}}.
  • Calculations MUST explicitly account for stem transit time before calculating on-route delivery productivity.
  • Use decimal hours for internal calculation steps and convert to minutes for final reporting.
  • Multi-floor and heavy parcel handling assumptions must be explicitly stated based on {{package_cube_distribution}}.

Output format

Generate a 4-part route optimization report:

  1. Route Viability Summary: 1 concise paragraph confirming whether the route plan is achievable within shift boundaries.
  2. Time Budget & Density Mathematics: A markdown table displaying Stem Transit Time, Net Delivery Window, Stop Density (stops/sq unit), and Required Stops Per On-Route Hour.
  3. Volume & Payload Feasibility: A brief section (under 150 words) evaluating cube utilization versus weight constraints.
  4. Dispatch Engineering Recommendations: Exactly 3 numbered recommendations for route clustering, stem time compression, and stop re-sequencing.

Self-review

  • Ensure net delivery time plus stem transit time equals {{driver_shift_limit_hours}} or less.
  • Check that the required stops-per-hour calculation divides by on-route time, not total shift time.
  • Confirm all 6 variables are referenced and evaluated in the mathematical model.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

research-analysis
research-reasoning-math
transport-logistics
last-mile
route-optimization
dispatch-math