Route optimization software decides which vehicle serves which customer, in what order and at what time, so the same orders get delivered with fewer kilometers, fewer vehicles and less overtime. Inside a fleet management system it works alongside GPS tracking, a driver app and trip costing, and together they show where your delivery money actually goes.
The savings are real, but they are not automatic. They depend on how routes are planned today, how clean your customer addresses are and whether drivers follow the plan. An experienced dispatcher who knows every shortcut in Bekasi can match the software on a quiet day. The same dispatcher struggles when tomorrow brings 300 drops, 14 vehicles of three different sizes and a list of minimarkets that only receive goods in the morning.
This guide covers where delivery costs leak, what the software calculates, which features matter for Indonesian operations and how to prove the savings on one depot before you commit to a full rollout.
Where delivery costs actually leak
Fuel is the cost everyone watches, but it is only one line. Driver wages and overtime, vehicle rental or depreciation, tolls, parking, uang jalan (trip allowances) and repeat visits after failed deliveries all rise or fall with the quality of route planning.
| Cost leak | Typical cause | What the software changes |
|---|---|---|
| Extra kilometers | Routes built from memory or by rough area | Sequences stops by road distance and real travel time |
| Too many vehicles on the road | Loads not consolidated, capacity guessed | Fills each vehicle by weight, volume and drop count |
| Overtime and late returns | Service times and traffic ignored | Uses time-of-day travel times and measured unloading times |
| Failed deliveries | Store closed, wrong location, receiver not ready | Respects receiving hours and sends ETA messages |
| Disputed trip allowances | Uang jalan set per trip without data | Calculates allowances from planned distance and tolls |
| Unauthorized trips | No visibility after the truck leaves | GPS history, geofences and alerts |
Before you compare products, measure four numbers for at least a month: cost per drop, kilometers per drop, drops per vehicle per day and failed delivery rate. Without that baseline, every savings claim, including the one in a vendor's brochure, is guesswork.
What route optimization software actually calculates
Under the hood, the software solves what researchers call the vehicle routing problem: given a set of orders, a fleet and a list of rules, find the routes with the lowest total cost. The number of possible routes explodes as stops increase, so solvers use heuristics that find very good routes in seconds or minutes instead of proving a perfect answer. Open-source solvers such as Google OR-Tools and commercial routing services both work this way.
The constraints that make a route realistic
A route that ignores real rules looks short on screen and fails on the road. Good software lets you model:
- Vehicle capacity in kilograms, cubic meters or crates, per vehicle type
- Customer time windows, such as a minimarket that receives goods only before noon or a restaurant that cannot unload during the lunch rush
- Service time per stop, which differs between a quick warung drop and a supermarket distribution center with a queue at the dock
- Driver shifts, breaks and maximum working hours
- Road rules: some roads and toll sections limit trucks during certain hours, and Jakarta's odd-even (ganjil-genap) plate rules on certain roads can affect vans with private plates
- Priorities, such as chilled goods first or key accounts before noon, plus pickups combined with drops
Travel time matters more than distance
Straight-line distance means little in a city with flyovers, one-way loops and rainy-season flooding. The solver needs a matrix of road travel times, ideally by time of day, from a road network engine such as the open-source OSRM or a commercial maps API. Motorcycles, which carry many last-mile parcels in Indonesian cities, need their own speed profile because they move through traffic very differently from a box truck.
Static plans versus dynamic re-routing
Static planning builds tomorrow's routes tonight from confirmed orders. Dynamic routing adjusts during the day when an urgent order arrives, a vehicle breaks down or a customer cancels. Many distributors get what they need from good static planning plus a simple way to insert urgent orders. Fully dynamic routing matters more for same-day couriers and on-demand services.
Fleet management features that make the plan happen
A route plan is a forecast. Fleet management records what actually happened and what it cost. These modules are worth considering, roughly in the order most operations need them:
- Driver app with electronic proof of delivery (ePOD). Stops in sequence, a handoff to the navigation app, photo and signature capture, reasons for failed drops and cash on delivery (COD) collected. It must work offline, because signal drops in basements, loading docks and rural roads
- GPS tracking and geofences. Live position, trip history and alerts when a vehicle stops too long or leaves its area. A hardware tracker is harder to switch off than a driver's phone
- Customer notifications. An ETA message on WhatsApp lets the receiver prepare space and payment, which cuts wasted visits
- Trip costing and settlement. Planned versus actual kilometers, tolls and fuel per trip, uang jalan settlement and driver incentives per drop or per trip (ritase)
- Fuel and maintenance. Fuel logs compared against distance, service schedules by kilometer, and reminders for STNK renewals and KIR roadworthiness tests
- Reporting. Cost per drop, on-time rate and vehicle utilization by depot, ideally in the same business intelligence dashboard your managers already use
Routing is only as good as the orders feeding it. Orders should flow automatically from your sales system, ERP or marketplace accounts through a proper API integration, and stock should be confirmed by your inventory management system before routes are built. Planning a route for goods that are not in the warehouse is a common and avoidable source of failed drops.
Buy, build or combine?
There is no single right answer. The choice depends on how standard your delivery rules are and how tightly delivery must connect to the rest of your systems.
| Option | Good fit when | Watch out for |
|---|---|---|
| Subscription route planner | Standard drops, one or two depots, need to start quickly | Per-vehicle or per-order fees, limited custom rules, data export limits |
| Custom system on an open-source solver | Unusual rules, many depots, deep ERP integration | Needs engineers who can tune and maintain the optimizer |
| Custom workflow calling a routing service | Custom costing and driver flows with proven optimization underneath | Two parties to manage, usage fees that grow with volume |
A fleet of a dozen vans doing standard drops is usually well served by a subscription tool, at least at first. Custom work starts to pay off when your rules are unusual: canvassing routes where salespeople sell directly from the van, mixed fleets of motorcycles and trucks, consignment pickups, or allowance and incentive schemes that no off-the-shelf product models correctly. It also makes sense when routing must sit inside the wider logistics operations you already run, so that orders, stock, trips and invoices share one record.
How to prove the savings before rolling out
Run a structured pilot instead of trusting a demo. A practical sequence:
- Pick one depot and gather two to four weeks of historical orders, vehicle lists and actual trip records
- Fix addresses first. Indonesian addresses with RT/RW numbers and landmarks such as "behind the mosque" often geocode poorly. Ask drivers to capture a GPS pin at each customer during their next visit and store it permanently
- Measure real service times from GPS stop durations instead of assuming five minutes per stop
- Replay history. Re-plan past days in the software and compare kilometers, vehicles used and driver hours with what actually happened
- Run a live pilot with part of the fleet for three to four weeks and compare planned against actual every day
- Agree on the scorecard up front. Decide with operations and finance how savings are counted, for example cost per drop and on-time rate, before the pilot starts
- Roll out depot by depot, fixing data issues as each one goes live
As a rough planning range, assuming orders already live in a digital system and the depot runs up to 20 vehicles, a pilot like this takes 6 to 10 weeks, and much of that time goes into address and data cleanup rather than software.
Pitfalls that quietly erase the savings
- Drivers ignore the plan. Involve senior drivers early, explain the sequence and let them record reasons for deviations. Their local knowledge often reveals rules the system is missing
- Optimizing kilometers only. The shortest route that misses receiving windows creates repeat visits and unhappy customers
- Unrealistic service times. Plans that assume fast unloading at busy stores overrun every afternoon, and drivers stop trusting them
- No feedback loop. Actual travel and stop times should flow back into the planning parameters every month
- Treating it as an IT project. The dispatcher's job changes from building routes to handling exceptions, and that change needs training and time
How Weaveward can build this for you
We would start by connecting your order source, whether an ERP, a sales app or a spreadsheet export, together with your GPS history, then replay a few weeks of real orders through a routing engine to show the gap in kilometers, vehicles and hours against your current plans. The first delivery would be a dispatcher planning screen and an offline-capable driver app with ePOD for one depot, validated against the cost-per-drop baseline agreed with your operations and finance teams.
When the pilot numbers hold, we would add trip costing, uang jalan settlement and management dashboards, then roll out depot by depot. Learn how we approach custom business systems for operations, or talk to our team about your fleet.