The data was all there and none of it met in one place. Three systems, three grains, no shared keys:

• The FSM reports invoices, not costs. Job records carry revenue, assigned tech and duration. Labor cost, parts cost and overhead are in two other systems.
• Payroll knows hours, not jobs. Hours arrive as timesheet totals per pay period, so tying a technician hour to the job it was spent on needs the dispatch log as the bridge.
• Drive time was recorded and never costed. The platform tracked it. No report multiplied it by anything.
• The hourly rate used everywhere was the pay stub rate. Payroll taxes, benefits, workers comp, the truck, fuel and the phone were absorbed into overhead and never landed on a job.
• Overhead was spread evenly per job. That single choice systematically flattered long jobs and punished quick high ticket calls, which is the opposite of the truth.

Architecture

The burdened rate is a table, not a constant

Each technician gets a rate per period: wages plus employer taxes, benefits, workers comp, and the vehicle and phone cost from the input sheet, divided by paid hours. It changes when someone gets a raise or a new truck, so it is a per period row rather than a hardcoded number.

-- Burdened hourly rate per technician, per period
VAR DirectPay = SUM( 'Payroll'[Wages] )
                + SUM( 'Payroll'[EmployerTaxes] )
                + SUM( 'Payroll'[Benefits] )
                + SUM( 'Payroll'[WorkersComp] )
VAR Vehicle   = SUM( 'TechCosts'[TruckAndPhone] )
VAR PaidHours = SUM( 'Payroll'[PaidHours] )
RETURN
    DIVIDE( DirectPay + Vehicle, PaidHours )

True job cost

The measure that everything else reads from. Note that onsite and drive hours are summed together before being multiplied by the rate:

-- True job cost = burdened labor + parts + allocated overhead
VAR LaborCost =
    SUMX(
        'Job Labor',
        ( 'Job Labor'[OnsiteHours] + 'Job Labor'[DriveHours] )
        * RELATED( 'Technicians'[BurdenedHourlyRate] )
    )
VAR PartsCost =
    CALCULATE( SUM( 'Job Parts'[Cost] ) )
VAR OverheadAlloc =
    [Billable hours on job] * [Overhead rate per billable hour]
RETURN
    LaborCost + PartsCost + OverheadAlloc

Overhead per billable hour, and why it matters

The overhead rate is total overhead for the period divided by total billable hours in the same period, so it moves with utilization rather than with job count:

-- Overhead rate per billable hour, current period
DIVIDE(
    CALCULATE( SUM( 'Overhead'[Amount] ) ),
    CALCULATE( SUM( 'Job Labor'[OnsiteHours] ) )
)

Margin, and the grain it is computed at

Profit per job and margin are computed at job grain and then aggregated, never the other way round. Aggregating revenue and cost first and dividing at the end hides the losing job types inside a healthy average:

-- Gross profit, computed per job then summed
SUMX(
    VALUES( 'Jobs'[JobId] ),
    [Job revenue] - [True job cost]
)

Missed call exposure

Deliberately a rough estimate, built from the company's own numbers rather than an industry benchmark:

-- Estimated revenue lost on unconverted inbound calls
VAR UnbookedCalls   = [Inbound calls] - [Calls converted to jobs]
VAR AvgJobValue     = DIVIDE( [Total revenue], [Job count] )
VAR HistoricalClose = [Booking rate]
RETURN
    UnbookedCalls * AvgJobValue * HistoricalClose

Presented with the assumptions visible, because the value of the number is the order of magnitude and not the decimals.

Lead source return, on profit rather than revenue

The last measure is one line and it changes marketing budgets. Return per channel is gross profit over spend, not revenue over spend, so a channel that books cheap low margin work stops looking like a winner:

-- Return per dollar of marketing spend
DIVIDE( [Gross profit], SUM( 'Marketing'[Spend] ) )