Proposal · For discussion

Travel Day Pay

A standard for compensating teams on far-away jobs — August 2026

The problem: teams based in West Valley regularly work jobs in Logan or Santaquin. Today they absorb that drive themselves. We want a standard that compensates mileage primarily and time modestly, that teams can see is fair, and that nobody can game — in either direction.

The core recommendation

Pay per team-vehicle-day, anchored to home base, banded into zones.

One travel payment per team, per vehicle, per day worked — set by how far the job's zone is from the team's home base. Not per job, and never based on self-reported location.

Each design choice earns its place by killing a specific failure mode:

Per day, not per job — a 3-day Logan job pays three travel days (they drive it three times); two Santaquin jobs in one day pay once, at the farthest job's zone. Batching far jobs becomes a win for the team and for us.
Home base, not last known location — last-known is self-reported, goes stale over weekends, and reflects the previous job rather than where the commute actually starts. Home base is set once per team, verified once, and argues with nobody.
Zones, not exact miles — a small banded rate table is transparent, predictable before the team accepts the job, and absorbs the difference between straight-line and drive miles.

The rate formula (illustrative numbers)

Rates derive from a formula anyone can check: round-trip miles × ~$0.70/mi, minus a free-commute allowance of ~25 mi each way (everyone commutes somewhere — we pay the excess), plus a time kicker for drive time beyond ~30 min each way at a reduced rate, since commuting isn't working.

Zone	One-way from home base	Example from West Valley	Per vehicle-day
0	under ~30 mi	Salt Lake valley	$0
1	30–55 mi	Ogden, Provo	~$40
2	55–75 mi	Santaquin	~$60
3	75+ mi	Logan	~$115

Vehicles: pay per vehicle, capped by crew size (1 vehicle per 3 workers, rounded up) so extra trucks aren't a profit center. Days: count days with actual reported work, sanity-capped at expected days from estimated man-hours ÷ (crew × 8) + 1.

What TrackVia can already do

Travis audited the schema: nearly everything exists. Jobs are geocoded (Actual Location), estimated labor hours and crew headcount are live fields, working straight-line-distance math already runs in our production scripts, and team pay has an additive rail (Task Pay Amount) a travel line can ride on with no new pay plumbing. The one missing input is a geocoded team home-base location — a single new field, set once per team.

Build ladder

Tier 1

Minimal standard — ships the policy

Add Home Base Location to Task Teams; extend the existing task script to compute zone from straight-line distance (× road factor) and write a Travel Pay Amount; add it to the pay formula; a small config table for zone thresholds and rates. Accepts slight overpay on batched days in v1 — errs in the teams' favor.

Tier 2

Accuracy and dedup

Same-day, same-team dedup (pay only the max-zone task per day); true drive-miles and drive-time via a distance API through Workato; a structured vehicle count on teams; lodging per-diem option for 3+ day far jobs — beyond ~$115/day/vehicle, a motel is cheaper, so let the team choose.

Tier 3

Travel-aware operations

Use the same distance data upstream: travel-cost-aware team assignment (the assignment preview already computes miles), scheduling that batches far jobs into shared travel days, and travel cost forecast at job-pricing time so far jobs are bid with the stipend built in.

Open decisions

Floor interaction: does travel pay count toward a task's minimum pay, or sit on top? (Recommend on top — otherwise small far tasks eat the stipend, recreating the unfairness.)
Vehicle basis: a real vehicle-count field per team, or derive as crew ÷ 3?
The numbers: free-commute allowance, per-mile rate, time rate, and zone boundaries are all policy dials — the table above is a starting point, not a position.