Documenting Your Pay Structure So It's Consistent and Defensible

Why this matters

If pay decisions live only in your head, they drift. A raise here, an off-the-cuff spiff there, a rate negotiated a little higher for the hire you really wanted to land, and three years later two techs doing the same work for the same tenure are paid noticeably differently with no reason you could actually state out loud if asked. Undocumented pay is not just an unfairness risk, it is a legal one: pay differences unmoored from any documented, job-based reason are exactly what wage-and-hour and equal-pay claims are built on. A written pay structure protects your crew's trust and protects you.

Step 1: Define your roles and tiers before you write a single rate

Before documenting numbers, document the structure the numbers will live inside. List every distinct role and experience tier in your shop: apprentice, journeyman, senior tech, lead tech, whatever your shop actually uses. For each tier, write down the objective criteria that qualify someone for it, such as years of experience, specific certifications held, or a demonstrated skill checklist, not vague language like "seasoned" or "proven." Objective criteria are what let you explain a pay difference later as "this person met these stated requirements," rather than a judgment call nobody can retrace.

Step 2: Document the pay mechanic for each role, not just the number

For every role and tier, write down the actual formula, in plain language a tech could calculate themselves:

• The base, hourly rate, flat-rate percentage, or salary, and which tier it applies to.
• Any commission, bonus, or spiff layered on top, the percentage or trigger, and what it is calculated against (billed revenue, collected revenue, jobs closed, whichever you actually use).
• Any quality gate that affects the incentive portion, such as a callback-rate threshold that must be met before a productivity bonus pays out.
• How travel time, drive time, and any required training time are paid, since these are common sources of dispute if left ambiguous.

The test for whether this step is done: hand the written formula to a tech with no other explanation, and see if they can calculate their own expected pay for a sample week. If they cannot, the document is not specific enough yet.

Step 3: Set the pay band range for each tier, not a single fixed number

A single fixed rate per tier is brittle, since real people within the same tier have real variation in tenure and specific skill. Instead, document a range, a floor and ceiling, for each tier, and write down what moves someone from the floor toward the ceiling within that band: additional certifications, longer tenure at that tier, a documented performance history. This lets you place two techs at different points within the same tier's band, for reasons you can name, rather than either forcing false equality or drifting into unexplainable gaps.

Step 4: Write the review-cycle rule into the document itself

State plainly, in the same document, how often pay is reviewed, what triggers an off-cycle review, and what data feeds the decision (performance metrics, market check, business capacity). This closes the most common source of undocumented pay drift: raises that happen only when someone asks, on no fixed schedule, for reasons nobody wrote down at the time.

Step 5: Get every current tech's actual pay onto the documented structure

Once the bands and formulas exist, go through your current crew, honestly, and map each person's actual pay against where the document says they should sit. You will likely find some mismatches: someone paid above their tier's ceiling for historical reasons, someone below their tier's floor who has simply never asked. Do not silently correct these downward. Handle each mismatch deliberately.

• Below-band pay should generally be corrected upward on a stated timeline, since a documented structure that leaves your own team below its own floor undermines the whole point of having one.
• Above-band pay is not corrected downward retroactively. Either grandfather it explicitly with a note in the document explaining why, or plan a gradual approach over future review cycles, never a same-week cut on work already priced in.

Step 6: Put it in writing and have each tech acknowledge it

A pay structure that exists only as an internal spreadsheet you never share does not build the trust you are after. Share the relevant parts with each tech, at minimum their own tier's formula, band, and what would move them to the next tier, and have them sign or otherwise acknowledge they have seen it. This single step converts pay from something that feels like it happens to a tech into something they can see, understand, and work toward.

Step 7: Revisit the whole document on a fixed schedule, not just individual pay

Separately from individual reviews, revisit the structure itself once a year: are the bands still competitive against the market, does the formula still make sense given how the business has changed, has a tier's criteria become outdated. A document that never gets revisited becomes exactly as stale and indefensible as no document at all, just with more paperwork.

Common mistakes to avoid

• Writing criteria vague enough that they justify any decision after the fact. If a criterion could not have predicted the outcome before you knew the outcome, it is not a real criterion.
• Documenting the structure but never checking current pay against it. The document only protects you if actual pay matches what it says.
• Treating the document as legal armor instead of an honest tool. A pay structure that is documented but not actually followed is arguably worse than no document, since it shows you knew the standard and did not apply it.

References

• U.S. Department of Labor, Wage and Hour Division, recordkeeping and pay-transparency guidance
• Society for Human Resource Management (SHRM), pay-band and compensation-structure design guidance
• See related: The Review Cycle That Should Drive a Pay Change
• See related: Equal Pay for Unequal Output Decision Tree