Use case · Operator field guide

A production rate card is an operating control, not a spreadsheet tab

The goal is not one perfect list of prices. The goal is a controlled source of truth that tells producers which rate to use, when it applies, and who can change it.

Trace 01 · Signal → cause → consequence

Diagnose the operating failure before buying a tool

Visible signal

Two producers price the same role differently, old bids are copied forward, and nobody knows whether a package includes labor, expendables, mileage, or overtime.

Underlying cause

Rates live inside historical estimates instead of a governed card with units, markets, notes, effective dates, and an accountable owner.

Business consequence

The shop underprices quietly, looks inconsistent to repeat clients, and cannot learn whether margin loss came from selling, production, or stale inputs.

Control 02 · Operating principles

Three controls that survive the software

A rate without a unit is not a rate

Day, hour, week, item, package, percentage, and allowance are different economic objects. Store the unit explicitly and reject ambiguous entries.

Market context beats fake precision

A Dallas crew day rate and a Los Angeles crew day rate may both be correct. Record market and source context instead of forcing one universal number.

Overrides need a reason

A producer should be able to depart from the card for a relationship, package, or unusual scope. Capture why, who approved it, and whether it should update the card later.

Runbook 03 · Smallest useful workflow

Run this on one real job

Do not begin with a company-wide migration. Prove the control on representative work, record the exceptions, and expand only when the operator can trust the new state.

01

Start with the rates that move gross margin

Do not begin by cataloging every expendable. Load the 30 to 60 labor roles, equipment packages, post services, and percentage rules that appear most often or carry the most risk.

  • Top roles are grouped by department
  • Owned-equipment billing rates are separate from replacement cost
  • Production fee, insurance, and contingency rules are documented
02

Assign a review cadence

Review volatile labor and rental inputs quarterly and the full card at least twice a year. A named owner should approve changes and publish a short change note.

  • Every entry has a last-reviewed date
  • Superseded rates stay available for historical estimates
  • Producers know when the new card takes effect
03

Measure overrides

The override rate is a signal. Frequent overrides may mean the card is wrong, a seller is discounting, or the business has distinct client tiers that deserve explicit rules.

  • Override reason is required
  • Recurring exceptions are reviewed monthly
  • Client-specific pricing is not mistaken for a market rate
04

Close the learning loop

Compare sold rates with committed costs and final actuals. Update the card only when the evidence is repeatable; one strange job should not reset company pricing.

  • Sold rate, cost expectation, and actual cost remain separate
  • Margin variance is reviewed by category
  • The next estimate sees approved changes

Instrument 04 · Evidence

Measure whether the control is earning its place

  1. Rate-card coverage across estimate line items
  2. Override frequency and override value by producer
  3. Age of the oldest actively used rate
  4. Margin variance by role, package, and department

Boundary 05 · Product truth

Where Production Engine fits today

The current build is strongest from company rate card through estimate, option approval, and initial budget creation. The design-partner program exists to test the next control on live work without pretending the whole production stack is finished.

Present in the current repo

  • Stores tenant-specific rate cards with category, role, unit, market, and integer-cent rates
  • Injects the active card into authenticated estimate generation
  • Falls back to baseline rates for missing entries and keeps the tenant card as the primary source when matched

Design-partner scope

  • Translate the shop's current rates into a clean first card
  • Define override rules and missing-rate review
  • Use live estimates to identify the next card-management controls worth building

Honest boundary: The current product has rate-card mechanisms, not a complete rate-card administration suite. Design partners should expect guided setup and direct feedback on the management surface.

Paid design-partner program

Put one live workflow under control in 90 days.

Implementation, rate-card and workflow mapping, access for five operators, and direct product-team collaboration.

$2,500 implementation + $499/month for five operators · 90-day commitment

FAQ 06 · Buying questions

Questions to resolve before implementation

Should clients see the internal rate card?

Usually no. Clients should see the estimate they are approving. Internal cost expectations, negotiated crew rates, and pricing logic should remain controlled while client-facing line items stay explainable.

How many rates should we load first?

Load the smallest set that can price one real, representative job without copying an old estimate. For many small commercial shops, that is dozens of entries, not thousands.

What should happen when a rate is missing?

Flag the fallback, let a producer choose a reviewed temporary value, and queue the gap for the card owner. Silent guesses turn a data-quality problem into a margin problem.

Index 07 · Internal route

Continue the operating system

Paid design-partner program

If this failure costs real producer time or margin, test it on a live job.

Implementation, rate-card and workflow mapping, access for five operators, and direct product-team collaboration.

$2,500 implementation + $499/month for five operators · 90-day commitment