The Customer Is Not the Price

Say this morning's ticket reads Ridgeline, 24 tons of base rock, delivered. Every word is true. It's also not enough to price the load, because Ridgeline is running three jobs right now, and each one pays a different number.

The school addition was bid last winter at $11.75 delivered, sharp, because you wanted the tonnage. The Fairview subdivision runs at $12.50, negotiated in the spring when diesel settled down. And the odd repair work Ridgeline calls in, a washed-out culvert approach, a shop pad, bills at list, $14.10. Three prices, all current, all signed off by somebody who had the authority to sign.

So which one does this ticket get?

The account doesn't have a price

The uncomfortable fact underneath the question: on a multi-job account, the customer is not the pricing unit. The job is. The quote that set $11.75 wasn't a quote to Ridgeline. It was a quote to the school addition, with its own tonnage estimate and its own end date. The subdivision got its own deal. The repair work never got a deal at all, which is a deal too, called list.

Now look at what the billing side has to work with. The customer master has one line for Ridgeline and one default rate in it. The ticket, written at the scale with four trucks in line, names the customer because that's what the scale operator knows for certain. Sometimes the driver writes "school" in the corner, because he just came from there. Sometimes he doesn't, because he hauled to all three sites before lunch and the corner of a carbon ticket is small.

The mapping from load to job, the one fact the price actually hangs on, lives in nobody's paperwork. It lives in the dispatcher's memory of who called for rock, and in the billing clerk's sense of what Ridgeline is usually up to.

The usual job

Here is what "usually" does at the keying desk. The clerk handles maybe 60 Ridgeline tickets a month. Most go to Fairview, so Fairview is the default, and the default gets applied wherever the ticket is silent. She isn't careless. She's resolving an ambiguity the paper handed her, sixty times a month, using the only tool she has, which is the pattern.

Dispatch will tell you the default is almost always right. That's the problem, not the defense. A guess that's usually right never generates the phone call that would expose it, so it runs for years. Count the tenth ticket. Twelve repair loads a month keyed to Fairview bill at $12.50 instead of $14.10. On 24-ton loads that's $1.60 a ton, about $460 a month, $5,500 a year, on one account, for rock that was hauled, delivered, and invoiced. The invoice was even paid. It was just priced by a guess, and the guess ran low.

Run it the other direction and it costs you twice. School loads keyed to Fairview overbill the subdivision PM, who checks his job costs and calls. You credit him, fine. But the same loads have now vanished from the school job's history, so the quantity you're tracking against that bid is short. At closeout, your records and the GC's don't agree on how much rock the school took, and yours are the ones built on defaults.

There's a third cost, slower and worse, that never shows on any invoice: your bid history is poisoned. Fairview looks like it ate far more base than the takeoff said, the school looks light, and the estimator pricing next year's school job studies numbers a keying default wrote. You'll trust that history more than any single ticket, and it's the least reliable document in the building.

Don't make the gate answer an office question

The 2010s software answer was to make job number a required field on the ticketing screen, which moved the ambiguity to the worst possible place: a scale window with a line of trucks, where the operator picks whatever clears the screen. The carbon book never needed the rescue. A driver writing "school" in ink when he knows it, and nothing when he doesn't, is honest paper. Keep it. The question just can't be allowed to die there.

flowchart TD
    A["Ticket: Ridgeline, 24 tons base"] --> B{"Which job?"}
    B -- "clerk's default" --> C["Keyed to Fairview at $12.50"]
    C --> D["Repair loads underbilled, school history short"]
    B -- "rule: Ridgeline has 3 open jobs" --> E["Unresolved ticket flagged that day"]
    E --> F["Dispatch still remembers the load"]
    F --> G["Priced by the job's own rate"]

The durable fix is structural, and it's office work, not truck work. The three Ridgeline jobs, each with its own rate and dates, are reference data. "A ticket on a multi-job account must resolve to an open job" is a billing rule, and so is "no open job named means list price," if that's the policy you'd actually defend. Tickets get digitized the day they're written, as written, corner scribbles included. A Ridgeline ticket that can't resolve gets flagged that afternoon, while the dispatcher can still say it was the culvert crew that called, instead of surfacing in March when the school closes out. Invoice totals assemble job by job, from tickets that cleared. That's the slice Termco was built for, and none of it touches the scale house. The book and the pen stay where they are.

What the structure buys you is smaller than it sounds and worth more: the guess becomes a question, asked the same week, answered by someone who knows.

Count your Ridgelines

The audit is one list and one afternoon. Pull every account with more than one active job or rate, and for the last 90 days, count the tickets that name only the customer. Price each one at the gap between the job rates it could have landed in. While you're there, ask your clerk which account she'd hate to key with the dispatcher on vacation. She already knows where the guesses live.

If you want a second set of eyes on the paper itself, send 10-20 sample tickets to hi@termco.ai, favoring accounts that run more than one job, and you'll have findings back within 48 hours.

The customer's name gets the invoice to the right mailbox. It was never supposed to set the price. The day your tickets have to answer to the job instead of the account, the tenth load stops riding at the ninth load's rate.