Five items, four of them a standard export
Nothing here touches a truck, a driver, or a live system. The one item that usually needs a conversation rather than an export is the fuel purchase file, since it sits with your card provider.
Trip history
Origin, destination, any intermediate stops, departure date and time, and the unit that ran each trip.
Vehicle specification
Tank capacity, reserve threshold, fuel economy, vehicle class, and how far off route a stop may sit.
Fuel purchase history
Where each truck actually fueled, how many gallons, and at what price.
Fuel prices for the period
What stations along those routes were charging on the days those trips ran, including your contract, cost-plus or network discount basis.
GPS traces
Position history for those units across the same 3-month window.
Where FuelGuru sits in your stack
Useful context for your IT team, though none of it is needed for the study above. FuelGuru sits where a fuel optimization layer sits today, between the TMS that creates the load and the in-cab workflow the driver follows. Dispatch data comes out, the engine prices the trip, and the fuel plan goes into the workflow the driver already uses. Nothing about how your drivers work has to change. The fuel stop simply becomes the right one.
Load created in your TMS
Stops, appointment windows, unit and trailer assignment. No change to your dispatch process.
Dispatch data reaches our API
The only new plumbing in the whole picture. Your IT team can own it, or we build and operate it for you. One short call and we show them what to send.
Priced in seconds
Route and an ordered fuel plan: which stop, how many gallons, at what price, against your tank rules, out of route limits and card network.
Into the driver workflow
The stop appears in the workflow the driver already follows, and navigation takes them there. A fuel stop looks like any other stop.
Two points worth stating plainly. Dispatchers and planners get the full economic picture in a single dashboard: plan, alternatives, cost, adherence. The driver sees only a stop and a gallon count, and company drivers are not shown dollar amounts, though owner operators can be.
Second, the plan keeps updating mid trip: if price moves or a stop is missed, the next best in-network stop is prescribed rather than the plan going stale at dispatch.
We re-run your own trips and show you the difference
We rebuild each trip as if FuelGuru had planned it, price both versions against the fuel prices that applied on those days, and rank the lanes by how much money was on the table.
The comparison, in one picture. Same lane, same load, same delivery window. Only the fuel decisions change. The study runs this for every trip in the window, then puts a dollar figure on the difference, per trip and per lane. Illustrative: the shape of a finding, not a result.
The optimization engine
Every trip re-planned against your tank rules, out-of-route limits, network preferences and card pricing, then priced on real-day fuel rates.
How lanes get picked
- Ranked by total dollar exposure, not raw trip count
- A long lane run ten times often beats a short one run thirty
- Both rankings shown, so you can sanity check the picks
- Tell us the book of business you care about and we report it separately
What each trip shows
- Actual stops against prescribed stops
- Gallons and price basis at each
- Detour miles and minutes the plan spent
- Reserve level at every point on the route
- Why each stop won over the alternatives
And you get the tool
- Dashboard access for your team during the study
- Run any origin and destination pair yourself
- Change tank rules or detour limits and re-run
- No commitment attached to the access
The headline metric: net fuel cost per lane, with purchase price, detour miles and added stop time in one number. If the number is not there, we will tell you it is not there.
one number, per laneThe data specification, with the reason for each field
For whoever pulls the export. Each row carries a short Why note so nobody has to read the whole table to understand a single field. Send what your systems produce, in CSV or Excel, using whatever column names the export gives you. We do the mapping, so please do not clean or reshape anything for us.
| Field | Requirement | Type and unit | Description |
|---|---|---|---|
| 1 · Vehicle data one row per unit in the study | |||
| TankCapacity | Mandatory | Float · gallons | Tank capacity of the truck, for example 250 gallons. Why it sets how much fuel a stop can absorb, and it is the one input we cannot approximate. |
| FuelThreshold | Mandatory | Float · gallons | Minimum fuel to be maintained throughout the journey, your reserve floor. Why a plan that runs a tank lower than your drivers ever would is not a plan you would accept. |
| FuelAtStart | Mandatory | Float · gallons | Fuel in the tank at the start of the trip. Why it decides whether the first stop is needed at all. If it is not held per trip, a fleet typical value is enough. |
| EndOfRouteFuel | Mandatory | Float · gallons | Fuel you want remaining at the destination. Why so the plan does not deliver a truck that cannot start its next load. |
| MaxOutOfRouteMiles | Mandatory | Float · miles | How far off the route a fuel stop may be discovered. Why it sets the search boundary. Too generous, and the recommendation is one your drivers would refuse. |
| OutOfRouteCostPerMile | Mandatory | Float · $/mile | Cost added per mile driven out of route. Why so a cheap station 20 miles away is priced honestly instead of looking free. |
| VehicleType | Mandatory | Varchar | Vehicle classification, for example 5AxlesTruck or 3AxlesTruck. Why it drives truck legal routing, and the toll class if you want the toll view as well. |
| Fuel economy | Mandatory | Float · mpg | How far the truck gets between stops. Why without it the whole plan is guesswork. Fleet average per vehicle class is fine if per unit figures are not handy. |
| PartialFillPenalty | Optional | Float · $ | Penalty applied when fuel is filled partially at a stop. Why it captures the real cost of an extra pull-in. |
| FullFill | Optional | Boolean | When true, always fill to tank capacity. Why tell us if that is your standing policy, so the plan matches it. |
| GPS traces | OptionalRecommended | lat, lon, time | Position history for those units. Why it reconstructs the path actually driven rather than assuming the direct route. Dead head legs, detours and idle time all become visible, and it is how we confirm a stop was a fuel stop and not a break. |
| 2 · Trip data one row per dispatched trip, three months | |||
| Origin | Mandatory | Varchar | Start location of the trip, as an address or coordinates. Why a trip cannot be re-planned without both ends. City and state is enough to begin. |
| Destination | Mandatory | Varchar | End location of the trip. Why together with origin it defines the lane we rank and report on. |
| DepartureTime | Mandatory | Date | Start date and time for the trip. Why it anchors each trip to the right day's fuel prices, which matters more than it looks. |
| Waypoints | Optional | Varchar | Intermediate stops along the trip, in order. Why multi stop trips price very differently from point to point. Without them we would understate the real route's cost and flatter our own plan. |
| TripId | Optional | Varchar | Unique trip identifier. Why it joins trips to fuel transactions and GPS traces cleanly instead of us inferring the match. |
| TotalTripCost | Optional | Float · $ | Total cost incurred on the trip, including fuel, detours and other expenses. Why it gives us a second reference point to sanity check our own figures against. |
| 3 · Fuel data from your fuel card provider, the baseline we measure against | |||
| Fuel purchase data | Mandatory | transaction file | Historical purchases for the same window. Useful columns are date and time, unit, station name and location, gallons, price per gallon, and total amount. Driver ID matters only for slip seat operations, and a DEF or product line flag keeps the diesel math clean. Why it is the baseline. Without it, any savings figure would be our own arithmetic marking its own homework. |
| Fuel price data | Mandatory | $/gal by date | Prices along those routes on the days those trips ran, and critically the basis you actually buy on, whether contract, cost-plus or network discount. Why optimizing on retail when you buy at a discount understates your real savings, sometimes badly. |
On the fuel card provider: the purchase file usually comes from the card program rather than from you directly, and in our experience the request moves considerably faster when it comes from the carrier. We are glad to draft that request, join the call, or speak to their technical team, but the authorization has to be yours.
On price history: we can source a meaningful amount of station level pricing ourselves. What we cannot reconstruct is your discount structure, so if the purchase file carries the price you actually paid, that alone closes most of the gap.
If a piece is missing, we still deliver
We would rather say this now than at the readout. Here is what each gap actually costs you in the report. Only one row genuinely stops the work.
| If we do not get | Impact | What the report becomes |
|---|---|---|
| GPS traces | Minor | We re-plan from dispatched origin and destination instead of the driven path. Dead head legs and unplanned detours become invisible, so the actual cost baseline is slightly understated, which works against our own numbers rather than for them. The full study still runs. |
| Waypoints | Minor | Multi stop trips get treated as point to point. We flag those trips in the report rather than quietly folding them in. |
| Fuel price history | Moderate | We fall back to the pricing we can source ourselves plus whatever the purchase file carries. Directionally sound, and we state the price basis on every line so you can see exactly where each number came from. |
| Fuel purchase file | Moderate | The comparison shifts from what you actually paid to a modeled baseline, typically the average and the worst case stop available on each route against our plan. Still a real range, but it is a model rather than your ledger, and a skeptical CFO will say so. |
| Vehicle specification | Blocking | This one we cannot work around. Without tank capacity and fuel economy there is no defensible fuel plan to compare anything against. It is also the easiest item on the list to produce. |
Format, transfer, and how the data is handled
None of this is prescriptive. Send what your systems produce and we will take it from there.
Effort on your side
- Trip history export: 1 to 2 hours
- Vehicle specification list: under an hour
- Fuel card authorization: one email
- GPS export request: one request
- During the study: none, we run the replay
Format and transfer
- CSV or Excel, one file per group
- Your own column names, mapped on our side
- A 20-row sample first is welcome
- Secure upload link, or your preferred SFTP
- NDA in place first if you would rather
How the data is handled
- Used only for this study
- Anonymized in any aggregate analysis
- Never resold; we make nothing off data as such
- Unit numbers can be pseudonymized
- Deleted on request at the end
What usually moves the date: the fuel card file, because it depends on a third party rather than on either of us. It is worth starting that request first and running the trip and vehicle exports in parallel.
Three months is the ask, enough to cover seasonal price movement and give each major lane a meaningful trip count.
What happens next
Send the export list to whoever owns your TMS reporting, and the authorization to your fuel card provider. We are glad to draft that request and join the call with their technical team. We handle the replay, the ranking and the report. Roughly two weeks after a complete data drop you get a number for your top lanes, along with dashboard access to check it yourself. If any item on the list is difficult, tell us which one and we will tell you exactly what the report loses.