Somewhere in almost every service trades operation I've walked into, there's a spreadsheet.
It's usually named something like "tech pay" or "commission calc" or "payroll Q3 FINAL FINAL." It was built by the owner two or three years ago. It's been modified so many times the original logic is buried three layers deep in conditional formatting. One person understands it fully. That person is usually the owner.
Every pay period, someone pulls job data from the FSM, enters it manually into the spreadsheet, runs the formulas, fixes the errors that show up because someone's job didn't sync correctly, and sends the output to whoever processes payroll. This takes two to three hours, minimum. On a bad week, a callback dispute, a holiday adjustment, an on-call premium that doesn't fit the formula, it takes longer.
This is the standard. Not the exception.
The obvious problem
The spreadsheet is a single point of failure. If the person who built it leaves, nobody fully understands it. If you hire a new tech with a different commission structure, someone has to add a column and hope they get the formula right. If there's a calculation error that goes unnoticed (and there will be, eventually), the shop is paying techs incorrectly. Overpayment is embarrassing. Underpayment is a wage claim.
Department of Labor exposure is real in trade shops. Overtime rules for emergency calls, on-call weekends, and holiday coverage are complex. Commission structures that interact with hourly overtime calculations require careful handling. Most spreadsheets don't handle this correctly. Most shop owners don't know they don't.
The problem nobody talks about
There's a second problem that's less visible and more expensive: the commission spreadsheet and the estimating process are completely disconnected.
When a tech runs on commission, percentage of ticket, flat spiffs, performance bonuses, that commission is a real job cost. It needs to be factored into the estimate the same way materials and labor are. If it's not, the bid is wrong.
Most shops don't factor it in. The estimating process accounts for labor hours and materials. It doesn't automatically include the commission that will be paid on the job if it closes. The result: the shop bids a job, wins it, does the work, pays the tech their commission, and then wonders why the margin on that job was lower than expected.
At 5–15% of ticket value going to commission on many jobs, the unbaked commission is not a rounding error. It's a consistent margin leak across every commissioned job in the business. The shop that does 400 jobs a year and underestimates commission on each one is working harder than the numbers justify. The answer is sitting in a spreadsheet that never touches the estimating process.
What the automated version looks like
Payroll platforms built for field service (Gusto integrated with an FSM, ServiceTitan's native tech pay module, or a proper payroll service configured for variable comp) pull timesheet and job data directly. Commission calculates automatically based on rules defined in the system. The output is reviewable, not manually constructed.
When that's connected to the estimating workflow, either natively in ServiceTitan or through a configured integration, commission becomes a line item in every estimate. The bid accounts for the cost before the job is sold.
That's not complicated to build. It requires getting the commission rules out of the spreadsheet and into a system that can apply them automatically and consistently. The spreadsheet can stay as a reference. It shouldn't stay as the source of truth.
The question worth asking
If the person who runs payroll was unavailable next Friday, sick, out of town, unreachable, could payroll still run correctly and on time?
If the answer is no, the payroll process depends on a person, not a system. That's a risk the business is carrying every two weeks.
[The Service Trades Assessment][LINK: quick survey] covers your payroll and compensation setup, including how commission is calculated and whether it connects to your estimating process.
—- All posts / Onizuka Studio Automation Files Series Internal use: swap [LINK: quick survey] for the live Service Trades Quick Survey URL before publishing Internal use: swap [LINK: assessment] for the full audit URL where relevant
Michelle Onizuka is co-founder and Systems Architect at Onizuka Studio. She builds automation and AI systems for small businesses — including service trades operations across Tampa Bay and beyond.