How We Cut Fuel Costs by 20% and Nearly Eliminated Mid-Route Breakdowns for a 350-Vehicle Fleet

Client: Under NDA — mid-size B2B logistics company | Industry: Logistics / Fleet Management | Fleet Size: 350+ vehicles across 6 cities | Daily Deliveries: ~4,000 | Timeline: ~10 months | Region: India

---

At a Glance

---

What Was Going Wrong

The company handles B2B deliveries — industrial parts, pharmaceutical supplies, FMCG goods — across six Indian cities. Three hundred and fifty vehicles: a mix of mid-size trucks, delivery vans, and two-wheelers for smaller packages. About 4,000 deliveries a day, most with delivery windows (pharma needs to arrive before 10am, factory parts before shift change at 2pm, that kind of thing). Late deliveries trigger penalty clauses — and their clients enforced them.

The operation ran on experience and phone calls. It had for 15 years, and it worked well enough when they had 80 vehicles in 2 cities. At 350 vehicles across 6 cities, "well enough" was bleeding money.

Routes were planned by gut. Six dispatchers, one per city, each planning routes for 50–70 vehicles every morning. They'd look at the day's delivery list, mentally group deliveries by area, assign them to vehicles, and sequence the stops based on what they knew about traffic and delivery windows. A good dispatcher in Pune could plan routes for 60 vehicles in about 90 minutes. But "good" is relative — we later found that their routes were, on average, 23% longer than optimal. Not because the dispatchers were bad, but because optimizing 60 vehicles × 12 stops each × traffic patterns × delivery windows × vehicle capacity is a combinatorial problem that no human brain can solve optimally. They were doing a remarkable job given the constraints. They were just competing against math.

Nobody knew where anything was. They had GPS trackers on about half the fleet — installed two years ago, connected to a vendor's portal that nobody checked regularly. The trackers on the other half had either stopped working or been disconnected (some drivers didn't love being tracked). When a client called asking "where's my delivery?", the dispatcher would call the driver. If the driver didn't pick up — which happened often while driving — the dispatcher would guess. "Should be there within an hour" was the standard answer, regardless of reality.

Vehicles broke down at the worst times. Twenty-two mid-route breakdowns per month, on average. A truck dies in traffic on the Pune-Mumbai expressway with 14 deliveries still on board. The dispatcher scrambles to send a replacement vehicle — which means pulling it off its own route, delaying those deliveries too. The cascade effect of one breakdown rippled through 3–4 routes. Maintenance was calendar-based: oil change every 10,000 km, brake check every 15,000 km. It didn't account for the fact that a truck doing Mumbai city deliveries (stop-and-go traffic, constant braking) wears differently than one doing highway runs between Pune and Nashik.

Fuel costs were a black hole. Monthly fuel spend: about ₹85 lakh (~$100K). Nobody could tell you how much of that was legitimate route fuel and how much was waste — inefficient routes, excessive idling, detours, or outright theft (siphoning is a known problem in Indian fleet operations and nobody wanted to talk about it, but the CFO had suspicions). They tracked fuel by credit card receipts. Total spend was known; per-vehicle, per-route efficiency was a mystery.

Delivery failures were expensive. About 21% of deliveries missed their window. Some were late by 20 minutes (annoying but manageable). Some were late by half a day (penalty clause). A few per month were outright failures — vehicle broke down, package didn't fit, wrong address, driver couldn't find the location. The penalty costs added up to roughly ₹12 lakh/month (~$14K). Beyond the direct cost, three major clients had put them "on notice" for SLA violations. Losing even one of those accounts would hurt.

Driver management was chaos. 380 drivers across 6 cities. Attendance tracked on paper. Some drivers consistently got easier routes (fewer stops, shorter distances) because they were friends with the dispatcher. Others were overloaded. Overtime was tracked loosely. One driver in Hyderabad had logged 14-hour days for 11 straight days before anyone noticed — a safety and legal liability. There was no performance scoring, no fatigue tracking, no way to know who was a reliable driver and who was regularly making unauthorized stops.

The operations director said it plainly: "We're a logistics company that can't tell you where our trucks are, when they'll arrive, or how much fuel they're burning. We know the answers are in the data somewhere, but we don't have the data."

---

What We Built

A platform that sees the entire fleet in real time and makes decisions that no human dispatcher can make — not because the dispatchers aren't smart, but because the math is too complex and the data moves too fast. Five connected systems: route optimization, real-time tracking and dispatch, predictive maintenance, fuel intelligence, and demand forecasting.

Step 1: Getting Eyes on the Fleet

Before we could optimize anything, we needed to know where everything was. This was the unglamorous foundation — and it took almost 7 weeks.

We standardized on one telematics hardware provider and installed GPS + OBD-II dongles on every vehicle in the fleet. The OBD-II port gives us engine data — RPM, coolant temperature, engine load, fuel consumption rate, diagnostic trouble codes. The GPS gives location, speed, heading, and stop/idle detection.

The devices push data over cellular (4G with 2G fallback for rural areas) to an MQTT broker. Position updates every 15 seconds when moving, every 5 minutes when stationary. Engine metrics every 30 seconds. That's roughly 2.5 million data points per day across the fleet.

The installation itself was a project. Two-wheelers don't have OBD ports — we used simpler GPS-only devices for those. Some older trucks had non-standard OBD implementations that reported garbled data. Twelve vehicles had OBD ports that were physically damaged. Three drivers "accidentally" disconnected their devices in the first week — management had a conversation about that.

The live tracking dashboard went up at week 5. First time the ops team could see every vehicle on a map, moving in real time. The operations director stood in front of the screen for ten minutes without saying anything. Then: "That truck in Bangalore — it's been parked for 40 minutes. It's supposed to be delivering right now." One phone call later: the driver was taking an extended lunch break. The fleet visibility alone, before any AI, changed behavior. Drivers who knew they were being watched started sticking to routes.

Step 2: Route Optimization Engine

This is the core of the system. Every morning at 4:30am, the day's delivery manifest comes in from the order management system. The optimizer takes it from there.

Inputs:

• •Today's deliveries: pickup/drop locations, delivery windows, package dimensions and weight, priority levels
• •Available vehicles: type (truck/van/two-wheeler), capacity (weight and volume), current location, fuel level
• •Available drivers: who's on shift, certifications (some routes require hazmat handling, some clients require ID-verified drivers), fatigue score (based on hours worked in the last 7 days)
• •Road network: distance and estimated travel time between every pair of delivery points, adjusted for time-of-day traffic patterns
• •Historical data: which routes tend to run late, which client locations have long loading/unloading times, which areas have parking issues

The optimization: This isn't Google Maps "fastest route." It's a vehicle routing problem with time windows, capacity constraints, driver constraints, and multiple objectives. We use Google OR-Tools as the solver, with custom constraints layered on top. The system is solving: minimize total distance driven while hitting every delivery window while not exceeding vehicle capacity while respecting driver hour limits while keeping the number of vehicles used as low as possible.

For a typical city with 60 vehicles and 700 deliveries, the solver runs for about 3 minutes and produces routes that are, on average, 19% shorter than what the dispatchers were planning manually. That 19% is pure fuel savings, pure time savings, and more deliveries per vehicle per day.

The output: Each driver gets a route on their phone app — a sequenced list of stops with ETAs, delivery details, and navigation. The dispatcher sees all routes on a map, color-coded by status.

One thing we learned the hard way: the optimizer's "optimal" route isn't always practical. Early on, it routed a truck through a narrow lane in old Ahmedabad that was technically a road on Google Maps but physically impassable for anything wider than an auto-rickshaw. The driver called the dispatcher furious. We added a "road suitability" layer — certain road segments are flagged as unsuitable for certain vehicle types, based on driver feedback. It's a living dataset that improves every week. By month 4, routing complaints dropped from a few per day to about two per week.

Step 3: Real-Time Dispatch and Rerouting

The morning route is a plan. Reality is different. Traffic jams, client not available, vehicle issue, urgent pickup request at 11am that wasn't in the morning manifest. The system handles all of this in real time.

Live monitoring: Every vehicle's position and status is tracked continuously. The system computes, every 2 minutes, whether each vehicle is on schedule, ahead, or behind. If a truck is falling behind by more than 15 minutes, the dispatcher gets an alert with options: "Vehicle 147 is 22 minutes behind schedule. Two remaining deliveries will miss their windows. Options: (1) Reroute delivery #8 to Vehicle 152, which is nearby and has capacity. (2) Notify client of delay. (3) No action."

Dynamic rerouting: When things change — a new pickup request, a vehicle breakdown, a road closure — the system re-optimizes affected routes in real time. Not from scratch (that would take too long mid-day), but incrementally — it adjusts 2–3 routes to absorb the change while minimizing impact on delivery windows. This runs in under 30 seconds.

Breakdown response: When a vehicle reports a breakdown (driver taps "vehicle issue" on the app, or the OBD data shows an engine fault code), the system immediately: (1) identifies the remaining deliveries on that vehicle, (2) finds the nearest available vehicles with enough capacity, (3) proposes a redistribution plan, (4) alerts the maintenance team with the vehicle location and fault code. What used to be a 45-minute scramble of phone calls is now a 3-minute process.

The dispatcher's role changed. Before, dispatchers planned routes and managed chaos all day. Now, the system plans routes and handles routine changes autonomously. Dispatchers handle exceptions — client disputes, unusual requests, situations the system flags but can't resolve. The Pune dispatcher told us, halfway through the pilot: "I used to make 60–70 phone calls a day to drivers. Now I make maybe 15. And half of those are because the driver doesn't trust the app yet." That trust issue resolved itself within a couple of months.

Step 4: Predictive Maintenance

Calendar-based maintenance doesn't work. A truck that does 200 km/day of highway driving doesn't wear the same as one doing 80 km/day in Mumbai stop-and-go traffic. The first one needs brake work less often; the second one needs it more often. Calendar-based schedules either miss problems or waste money on unnecessary service.

The system uses OBD-II data to predict failures before they happen.

What it monitors:

• •Engine coolant temperature trends (gradual increase = cooling system degradation)
• •Battery voltage patterns (dropping voltage under load = battery aging)
• •Fuel consumption rate vs. expected rate (increasing gap = engine efficiency loss)
• •Brake response patterns (from accelerometer data — longer stopping distances = brake wear)
• •Idle RPM stability (fluctuating idle = potential ignition or fuel system issue)
• •Diagnostic trouble codes (even intermittent ones that clear themselves)

The model: A gradient-boosted model trained on 18 months of historical maintenance records matched against the OBD data from the same period. For each vehicle, it outputs a health score (0–100) and a risk assessment for specific systems (engine, brakes, battery, transmission, cooling). When the score drops below a threshold, or when a specific system shows a concerning trend, the maintenance team gets an alert: "Vehicle 203 — brake system health declining. Current score: 42. Recommend inspection within 5 days. Pattern matches pre-failure data from 3 previous brake incidents across fleet."

Results: Mid-route breakdowns went from 22/month to about 8/month — a 65% drop. The remaining 8 are mostly things the model can't predict: tire punctures, electrical shorts from water damage during monsoon, and one incident where a driver hit a pothole hard enough to crack the oil pan. We also reduced over-maintenance — vehicles that were being serviced too frequently (costing money for unnecessary work) now get serviced based on actual condition. Maintenance costs dropped about 12% even as breakdown prevention improved.

Honest limitation: The model works well on vehicles with 6+ months of OBD data. New vehicles or recently installed dongles don't have enough history — the model defaults to manufacturer-recommended schedules for those. Also, the OBD data quality varies by vehicle make. Tata trucks give excellent data. Some older Ashok Leyland models report fewer parameters. The model is only as good as the data coming in.

Step 5: Fuel Intelligence

Fuel is the single largest operating cost — about 35% of total expenses. We built a system that tracks fuel consumption at the individual vehicle and route level, flags anomalies, and identifies waste.

Per-vehicle fuel efficiency: The system knows (from OBD data) exactly how much fuel each vehicle consumed on each route. It compares actual consumption against expected consumption for that route (based on distance, traffic conditions, vehicle type, and load weight). If Vehicle 78 used 15% more fuel than expected on its route today, it gets flagged.

Common anomalies the system catches:

• •Excessive idling: Vehicle stationary with engine running for more than 10 minutes (not at a client site). Fuel burned for nothing. Average fleet-wide idle waste before the system: about 8% of total fuel. After alerts and driver coaching: about 3%.
• •Route deviation: Vehicle deviates significantly from the assigned route. Sometimes legitimate (road closure, client request). Sometimes not (personal errand). The system flags deviations over 2 km and asks the driver to log a reason.
• •Fuel fill anomalies: The OBD data shows the fuel tank level. If a driver fills ₹2,000 of diesel and the tank level only increases by ₹1,400 worth — either the pump is cheating or fuel is being diverted. The system flagged 4 such incidents in the first 3 months. Two were pump measurement errors. Two were... not.
• •Driving behaviour: Hard acceleration, harsh braking, and high-speed driving all burn more fuel. The system scores each driver on fuel-efficient driving habits. The worst 10% of drivers by driving behaviour were using 18% more fuel per km than the best 10%. Driver coaching based on these scores improved overall fleet efficiency by about 6%.

The CFO's reaction when we showed him the first fuel analytics dashboard: "So you're telling me that idling alone was costing us ₹6 lakh a month and nobody knew?" Yes. That's exactly what we were telling him.

Step 6: Demand Forecasting and Capacity Planning

The delivery volume isn't constant — it fluctuates by day of week, time of month, season, and specific client patterns. Mondays and Fridays are heaviest. End-of-month spikes because clients push orders before month-close. Festival seasons (Diwali, year-end) bring 30–40% volume surges.

The system forecasts delivery volume 7, 14, and 30 days out, per city. Inputs: historical volumes, client order patterns, seasonal curves, known events (sales, promotions), and even weather (monsoon reduces two-wheeler deliveries significantly — some packages get rerouted to vans).

Why it matters: Without forecasting, the company either had too many vehicles on slow days (paying drivers and fuel for nothing) or too few on peak days (missed deliveries, frantic calls to hire temp vehicles at premium rates). They were renting temp vehicles about 25 days per month across all cities. With forecasting, they reallocated fleet positioning between cities a week in advance and cut temp vehicle rentals to about 8 days per month. Savings: roughly ₹4 lakh/month.

The model is a Prophet-based forecasting pipeline with city-level and client-level decomposition. Accuracy: within 10% for 7-day forecasts, within 18% for 30-day forecasts. Good enough for capacity planning. Not good enough for exact vehicle counts — we still build in a 10% buffer.

Data flows from vehicles and orders into the AI layer. Route optimization runs at 4:30am; everything else runs continuously. The dispatcher dashboard is the single pane of glass for the ops team.

Technical stack (for the engineering-minded)▾

• •Telematics hardware: GPS + OBD-II combo devices (Teltonika FMB920 for trucks/vans, Queclink GV55 for two-wheelers — GPS only). Cellular connectivity: 4G primary, 2G fallback. Data protocol: MQTT to AWS IoT Core. Battery backup on devices for 4 hours (captures data even if vehicle power is cut — intentionally or otherwise).
• •Data ingestion: AWS IoT Core → Kinesis Data Streams → Lambda for real-time processing. ~2.5M data points/day across 350 vehicles. Position data stored in TimescaleDB (PostgreSQL extension for time-series). Engine metrics in the same TimescaleDB instance, partitioned by vehicle and time. Raw data retained for 12 months; aggregated data retained indefinitely.
• •Route optimization: Google OR-Tools (CP-SAT solver) with custom constraint programming. Constraints: vehicle capacity (weight + volume), delivery time windows (hard and soft), driver shift hours, vehicle-road compatibility, client-specific requirements (some clients need tailgate lift, some need temperature control). Objective function: minimize total distance with penalty weights for late deliveries and driver overtime. Solver runs in a dedicated container with 8 vCPUs — typical city solve (60 vehicles, 700 stops) completes in 2–4 minutes.
• •Real-time dispatch: Custom event-driven service on FastAPI. Consumes live GPS positions from Kinesis. Computes ETA updates every 2 minutes using a pre-computed travel time matrix (updated hourly from historical traffic data). Incremental re-optimization for mid-day changes uses a greedy insertion heuristic — faster than the full solver, good enough for single-delivery reassignments.
• •Predictive maintenance: Gradient-boosted model (XGBoost) trained on 18 months of OBD data + maintenance records. Features: rolling averages of engine temperature, RPM distributions, fuel efficiency trends, brake event frequency, cumulative mileage since last service. Separate models per vehicle category (heavy trucks, light vans, two-wheelers). Predictions run nightly as a batch job. AUC on holdout: 0.87 for "needs service within 7 days." Major limitation: ignores external damage (road damage, weather) — those failures remain unpredictable.
• •Fuel analytics: Rule-based anomaly detection on fuel consumption vs. expected consumption (computed from route distance, vehicle fuel efficiency curve, and load weight). Fuel fill reconciliation compares fuel card transaction amounts against OBD-reported tank level changes. Idling detection: GPS speed = 0 + engine RPM > 0 for > 10 minutes. Driving behaviour score: composite of harsh braking events (accelerometer > 0.4g deceleration), hard acceleration, speeding (above road speed limits from map data).
• •Demand forecasting: Facebook Prophet with custom regressors: day-of-week, week-of-month, festival calendar (Indian holidays are complex — different states, different festivals), weather forecast (OpenWeather API), and client-level order patterns. Trained per-city. Retrained weekly.
• •Driver app: React Native. Shows optimized route with turn-by-turn (MapMyIndia for Indian roads — better coverage than Google Maps in tier-2 cities). Delivery confirmation with e-signature and photo proof-of-delivery. Vehicle issue reporting with fault category selection.
• •Backend: FastAPI (Python 3.11), async everywhere. PostgreSQL for transactional data (orders, vehicles, drivers, routes). TimescaleDB extension for time-series (GPS, OBD). Redis for real-time vehicle state cache. Celery for background jobs (route optimization, maintenance predictions, report generation).
• •Infrastructure: AWS — IoT Core for device connectivity, Kinesis for streaming, ECS for services, RDS for PostgreSQL/TimescaleDB, ElastiCache for Redis, S3 for proof-of-delivery photos and reports. Total infra cost: ~$2,800/month. The IoT data pipeline is the biggest cost driver.
• •Dashboard: React 18 + TypeScript. Live fleet map using MapMyIndia SDK. Vehicle status overlays. Route visualization. Anomaly alerts with one-click acknowledge. Maintenance calendar. Fuel analytics with drill-down by vehicle, driver, route, or time period.

---

How We Rolled It Out

Months 1–2: Hardware and data. Installing telematics devices on 350 vehicles across 6 cities. Coordinating with 6 city managers, each with their own opinions about whether this was a good idea. The Ahmedabad manager was enthusiastic. The Mumbai manager thought it was surveillance and pushed back until the operations director intervened. The actual installation took 4 weeks (a two-person team per city). The remaining 4 weeks were spent fixing data quality issues — devices reporting incorrect fuel levels, GPS drift in covered parking areas, OBD data inconsistencies across vehicle makes.

We ran data collection passively for the last 3 weeks of this phase — no optimization, just watching. This gave us the baseline: average route efficiency, fuel consumption patterns, idle times, driving behaviour profiles. The baseline was worse than anyone expected. Average vehicle utilization: 62%. Average idle time: 47 minutes per vehicle per day. Average route deviation from optimal: 23%.

Months 3–4: Route optimization (one city). Built and deployed the route optimizer in Pune first — their most organized city, best data quality, most cooperative city manager. First week: the optimizer's routes were 21% shorter on average. But three drivers refused to follow them ("I've been driving this area for 8 years, I know a better way"). The city manager told them to follow the optimized routes for two weeks and compare. Two of the three came around. The third one still does his own thing on about 30% of stops — his routes are 7% longer than optimal, which is still better than the old average. We decided that was good enough.

The dispatcher's reaction was mixed. He was relieved to not spend 90 minutes every morning planning routes. But he felt like his expertise was being replaced. We repositioned his role — he handles exceptions, client relationships, and driver management. The system handles the math. By month 4, he told us: "It's actually better. I was doing the boring part before. Now I do the interesting part."

Months 5–6: Predictive maintenance and fuel intelligence. The maintenance model needed historical data to train on. We had 18 months of maintenance records (paper logs that we digitized — painful) and 3 months of OBD data by this point. The first model was mediocre — AUC of 0.74. It improved to 0.87 after we added driving behaviour features (harsh braking correlates strongly with brake wear — obvious in retrospect).

Fuel intelligence went live with immediate impact. The first anomaly report showed that 6 vehicles were consistently consuming 20%+ more fuel than expected. Investigation: two had mechanical issues (fuel injector problems), one had a driving behaviour issue (constant hard acceleration), and three had no explanation. The operations director had a quiet conversation with those three drivers. Fuel consumption normalized within a week. Nobody asked what that conversation involved.

Months 7–8: All 6 cities + real-time dispatch. Rolled out route optimization and tracking to the remaining 5 cities. Each city took about 10 days — the integration patterns were established, but local road data needed city-specific tuning. The real-time dispatch system went live at month 7. The first mid-day rerouting event: a truck broke down in Hyderabad with 9 remaining deliveries. The system redistributed them across 3 nearby vehicles in under 2 minutes. All 9 deliveries were completed within their original windows. The dispatcher's comment: "That would have taken me 30 minutes and at least 4 phone calls, and I probably would have missed two of the windows."

Months 9–10: Demand forecasting and stabilization. The forecasting model needed enough historical data with the new system's delivery patterns (different from pre-optimization patterns). By month 9, we had 6 months of clean data. The model started producing useful forecasts — accurate enough for weekly capacity planning, not accurate enough for daily precision. The last month was stabilization: fixing edge cases in the optimizer (school zones with restricted truck access during certain hours, seasonal road closures during monsoon), refining the maintenance model with more failure data, and training city managers to actually use the dashboards instead of calling the central ops team.

---

What Changed

Eight months after full deployment across all cities:

The 27% increase in deliveries per vehicle is the number the CFO keeps bringing up. It means they can handle significantly more volume without buying new vehicles. At their growth rate, they would have needed to add 40–50 vehicles this year. Instead, they added 12. The cost avoidance on vehicle acquisition alone is substantial.

The drivers' reaction was the part nobody planned for. Initially, about a third of drivers resisted the system — they felt tracked, managed, and distrusted. Six months later, most of them prefer it. The routes are more efficient (they finish earlier), the navigation app means they don't get lost in unfamiliar areas, and the maintenance alerts mean fewer breakdowns stranding them on the side of a highway. One driver in Bangalore told his city manager: "Tell the computer people that the route today was actually good." High praise.

The dispatchers' roles changed the most. They went from being route planners (manual, repetitive, stressful) to being operations managers (exception handling, client relationships, driver coaching). Two of the six dispatchers struggled with the transition — they were great at route planning and less comfortable with the new role. One adapted with training. One moved to a different department. The other four are happier than before.

One thing we got wrong: the driver app's battery drain. The app runs GPS and sends data continuously. On older phones (and many drivers have older phones), it killed the battery by 2pm. We had to optimize the app's GPS usage, add a battery-saver mode, and the company ended up buying 40 budget smartphones for drivers whose phones couldn't handle it. Should have anticipated that.

"I'll tell you the moment I knew this was worth it. We had a truck break down on the NH-48 outside Pune. Before this system, that's a two-hour crisis — phone calls, scrambling, three clients calling me angry. This time, by the time I got the alert, the system had already reassigned the deliveries. Two of the three clients got their delivery on time. The third was 20 minutes late instead of 4 hours late. I just sat there and watched it happen on the screen. That's when I stopped worrying." — Operations Director (name withheld at client's request)

---

What's Next

The system covers the core delivery operations loop, but there are areas we're working on:

1. •

   Electric vehicle integration — They're adding 30 EVs to the fleet next year. EVs have different constraints: range limits, charging time, charging station availability. The route optimizer needs to factor in battery state-of-charge and plan routes that include charging stops when necessary — without blowing delivery windows. It's a different optimization problem, and we're building it now.

2. •

   Client-facing tracking — Right now, only the ops team sees the live tracking. Their B2B clients want real-time visibility too — "where's my delivery, right now, on a map." We're building a client portal with live ETA updates. The tricky part: how much data to expose. The client should see their delivery status, not the entire route (which includes other clients' deliveries).

3. •

   Multi-day route planning — Currently, the system optimizes one day at a time. For clients with flexible delivery windows ("deliver this week"), optimizing across multiple days could reduce fleet utilization further — batch Tuesday's and Wednesday's deliveries into one efficient Tuesday run instead of two separate trips. The math is harder (the solution space explodes), but the savings could be significant.

4. •

   Weather-adaptive routing — During monsoon season, certain roads flood regularly. Right now, drivers report flooded roads and the dispatcher manually adjusts. We want the system to integrate real-time weather and flood data to proactively reroute around problem areas before drivers get stuck. Mumbai in July is basically a routing nightmare that changes hourly.

---

Built by GammaEdge. If your fleet operations run on gut instinct and phone calls, and you know the data exists but can't get to it — we should talk.