Itinerary Planning Feedback and Enhancements (August 2025)

This document summarizes comprehensive feedback gathered from customers (primarily Dropoff), in August 2025. The aim is to capture identified pain points and desired enhancements to guide future development.

Key Areas for Improvement and Enhancements

Driver Allocation and Workload Balancing

Currently, the system prioritizes using the fewest drivers needed to complete a task. This often leads to situations where users want to plan for a specific number of drivers (e.g., five or six), but the system provides a solution using fewer drivers (e.g., four or five), requiring manual adjustments and "trial and error".

Requested Enhancements:

• Implement a "Use All Drivers" / "Use Fewest Drivers" toggle. This would allow users to assign work to all available drivers for a more balanced workload, even if a solution is possible with fewer drivers.

• Introduce a "Mileage Balancing" feature to ensure fair distribution of work among drivers. This would prevent situations where one driver travels significantly farther (e.g., an extra 30-40 miles) than peers without an apparent reason.

• Allow for balancing by other parameters such as amount of time everybody's driving, amount of stops everybody has, or distance, especially as driver pay can be based on these factors. This would help in making driver assignments fairer.

• Ability to include or exclude driver’s "deadhead drive" mileage, allowing for calculation of only the mileage from the first pickup to the last drop. This provides flexibility, as some routes may require this inclusion while others do not. This is important for accurate driver payment calculations

• Ability to "lock the sequence". The ability to take the placeholder route and then assign it to a driver without it reoptimizing based on the driver location. This enhancement provides dispatchers with more control over the final route plan and preventing unexpected changes

Future Planning and Modeling

The current system's timeline view only shows shipments for the selected date, and multi-day planning is not yet available.

Requested Enhancements:

• Enable the system to allow for the division and preparation of future orders.

• Implement a new calendar-style feature where users can select a future date and build an IP plan specifically for that day. This is crucial for clients who send large quantities of orders in advance, allowing dispatchers to plan routes and set drivers the night before, especially for high-volume periods like holidays.

• The ability to plan for future orders would also be beneficial for sales modeling. For example, during holiday seasons, users could model routes for large customer orders (e.g., 100+ orders) to determine driver needs and pricing.

• Allow users to save route plans without immediately assigning them, providing flexibility to pull the triggers later.

• Provide a virtual business unit or a simulation environment to model routes and scenarios. This would allow plugging in "fake orders" to model out potential new business and assess density, then potentially transferring these plans to live orders.

Route Time Inaccuracy and Traffic Consideration

Routes are consistently off by 1 to 1.5 hours, particularly those scheduled between 11:30 a.m. and 5:00 p.m. in locations like Las Vegas. The system appears to be underestimating travel time. While the system is supposed to account for historical traffic data, users experience significant discrepancies, suggesting it might be calculating based on "midnight" traffic or traffic at the time of route building rather than running.

Requested Enhancements:

• Implement a feature that considers anticipated traffic, similar to Beans Route's manual traffic setting (light, heavy, or moderate). This would give users control to adjust for rush hour or different times of day in various markets (e.g., Seattle).

• The system should accurately factor in dwell time and service time at pickups but needs improvement in traffic calculations.

Solution Recommendations:

Routing Styles

The current routing often leaves drivers in remote locations without a clear return plan, which is frustrating, especially if returns are required.

Requested Enhancements:

• Add more routing styles, including a Roundtrip Function. This would ensure drivers are brought back towards their origin location by the end of their route, making trips more efficient and predictable. This is particularly relevant for pharmaceutical deliveries that often require paperwork returns to the origin.

• A "furthest first" option is desired, where drivers go to the furthest stop and then work their way back towards the origin.

Driver App Functionality & Integration (NOT specific to Itinerary Planning)

Users report the driver app becomes "unmanageable" with more than 10 stops. The current workflow for pickups and deliveries, which includes multiple steps like photos and scans for each stop, is cumbersome.

Requested Enhancements:

• Implement a "Is This Package Mine?" functionality, similar to a competitor. This would allow drivers to open their app and rapidly scan packages to immediately see if a package belongs to their route or not, mapping the scan to the correct pickup without needing to navigate individual stops. This feature consolidates driver workflow.

• Address the issue where consolidated pickup photos are applied to all delivery events, which confuses customers. While individual photos for each pickup are desired for high-value items (like pharmaceuticals, $13,000-$15,000 medications) to prove package condition at pickup, the current consolidated photo feature causes issues.

• Provide a toggle for including or excluding the driver's starting point ("deadhead drive") in the total route mileage calculation. Users want the option to calculate just the route mileage from the first pickup to the last drop.

• A toggle to lock the sequence or disregard the driver's starting position is desired, as the system currently slightly rearranges stops when a placeholder driver is replaced by a real driver.

Current System Limitations and Comparison to Competitors

• Order Volume: The current IP is limited, effectively "gatekeeping" its use to under 50 orders a day, or about 10 orders per driver on the app, due to driver app manageability issues. For larger volumes (100+ orders), users revert to other solutions like "Gross Scale".

• Modeling/Simulation Limitations: While users can set up test accounts and business units for planning, there is currently no easy way to transition modeled orders from a test environment to live, actual work. Manual steps are required to move each order. The ability to "fake orders" for modeling is desired.

• Beans Route Comparison: Beans Route offers specific features that IP currently lacks:

  • Traffic lever (light, moderate, heavy).

  • Roundtrip function and the ability to go from one location out.

  • Ability to specify the exact number of drivers (e.g., "six drivers") and balance across different metrics.

Desired Future State

The ultimate goal is to enable users to go "all in" on Itinerary Planning and eliminate the need for third-party routing providers like Beans Route.

Key aspects of the desired future state include:

• IP needs to be capable of handling larger order volumes without limitations.

• The system should be trusted to provide accurate route times and balanced workloads, reducing the need for manual manipulation or guessing.

• The IP should be able to be a forecasting/ planning/ sales tool by allowing easy modeling and simulation of potential new business opportunities.