The fuel logistics data stack, mapped

The map

A mid-market fuel carrier doesn’t have a system. It has a dozen. The recurring cast:

• Supply, orders, and dispatch: Gravitate is the center of gravity for many carriers; it’s where orders live and trucks get told what to haul.
• TMS and trucking ops: TMW Suite and the broader Trimble stack run the trucking side: loads, drivers, settlements, invoicing.
• Telematics and ELD: Samsara knows where every truck is, how it’s being driven, and the GPS truth of every delivery.
• Tolls: Bestpass aggregates toll activity across the fleet.
• Rack and market data: DTN is the authoritative source at the rack, including the bill of lading for every load lifted.
• Customer fuel systems: the c-store chains you deliver to run their own platforms (PDI Telapoint, Titan, Planet 9, and others) for inventory and ordering.
• Back office: accounting, payroll, compliance filings, and the spreadsheets that glue the gaps.

Every one of these is good at its job. None of them was designed to talk to the others, and the carrier’s margin lives in the seams between them.

The two gaps

All the expensive problems in that map reduce to two gaps.

The operational gap: data that should move, doesn’t. Customer orders get re-keyed into Gravitate by hand. Delivery status lives in Samsara and TMW while the customer calls dispatch to ask where their load is. BOLs are in DTN while disputes get argued from paper. Every seam is latency, errors, and phone calls.

The analytical gap: questions that span systems, can’t be answered. Is toll spend inside policy? Which sites keep running dry? Did we hit the delivery windows we promised? Each answer needs three systems joined, so each answer becomes an analyst-week, so the questions mostly go unanswered.

Closing the operational gap

This is an integration layer’s job: two-way sync between your hub and every system your customers and vendors run, speaking whatever each side speaks (modern API, EDI, file drops). The bar is that an order placed in a customer’s TMS lands in yours with no human in the middle, and status flows back the other way in seconds.

That layer is what our product Manifold is, and the proof of the shape is the carrier whose 5,000+ c-stores got live visibility into every fuel load, with orders flowing into Gravitate untouched. Where a system has no integration surface at all, you go in through the UI, properly.

Closing the analytical gap

This is a data platform’s job, and at mid-market scale it’s smaller than it sounds: land the sources in a lake, model them once with tested business logic, serve dashboards on top. One proven shape is S3 and Glue for the lake, Athena for query, dbt for the modeling, Metabase for the dashboards: boring, cheap to run, and sufficient for six unified source systems feeding outage, toll, delivery, and driver views across a 5,000+ site network.

The selection logic matters more than the logos: managed over self-hosted, SQL over exotic, and modeled-once over per-dashboard queries, because the platform’s value is that its joins are trusted.

The order of operations

Carriers ask which to do first. The sequencing that holds up:

1. Integration where the money bleeds. Whatever seam generates the most re-keying, phone calls, or disputes gets closed first. It pays back fastest and it starts accumulating the event data the next step wants.
2. The data platform second. Once data moves, unify it. Every dashboard after the foundation is cheap.
3. AI on top, governed. AI in fuel logistics runs on exactly this substrate: clean flows and trusted joins. Skipping to step three is how companies end up with demos. This is the maturity curve behind the fractional Chief AI Officer seat: by the time a carrier wants to lead its market in AI, steps one and two are either done or they are the roadmap.

None of this requires replacing a system you run today. The stack you have is fine. The seams are the work.

If the map looks like yours, Strategy & Advisory is where the sequencing conversation happens.