What drifting trainer pay looks like
Picture a fitness studio manager closing the month. One trainer taught eighteen group classes and three private sessions. Another sold four ten-packs but taught far fewer classes. Payroll is due tomorrow, and the only shared record is a spreadsheet labeled "sessions" that nobody can agree means taught, sold, or both.
That scene is an illustration, not a TwoQM client. Many fitness studios know the gap: teaching credit and pack sales live in different heads while the payroll export still has to go out. TwoQM builds custom software that encodes your pay rules once so classes taught and packs sold stay separate fields on one shared record.
This article is about trainer payroll and ops — paying from classes taught without confusing that number with packs sold or memberships. It is not class booking intake, and it is not class pack balances and freeze requests, a different member-facing workflow. The salon piece on booth-renter W-2 and commission rules is a different industry, useful only as a reminder that pay rules need one written source of truth. TwoQM builds tooling. It does not give tax, employment, or legal advice. Your studio, its payroll provider, and its counsel decide rates and classifications.
Here is an original example, not a measured result. A Rio Grande Valley studio pays group classes by the session taught, private sessions at another rate, and a small pack-sale credit only when a pack or membership closes. Front desk marks "sold" in the booking app. Trainers text how many classes they taught. At month end both numbers merge into one "sessions" total — and a trainer gets paid for packs sold and for classes someone else taught from those packs.
When it doesn't work, teaching and sales credit collide, a substitute has no named pay owner, make-up notes live only in chat, and nobody can say who signed off on the export. Nobody is careless. Taught and sold simply never lived as separate fields on one record.
One shared record per pay period
Treat each trainer's pay period as one record the front desk, the trainer, and payroll all see. Each record holds:
Sessions taught. Group and private sessions delivered, with date, class type, and substitute flag — pending review or approved for pay.
Packs and memberships sold. Sales credit when your studio pays one, as a separate line from teaching credit, with sold date and product type.
Pay-rule snapshot. The rate table for that period (group, private, substitute, sale credit), stored as your studio already defined it — not invented by software.
Payroll export ownership. The named person who runs or approves the export, and the date, before anything is paid.
Only sessions approved for pay enter the export; open disputes stay visible until a person resolves them.
Keep taught and sold as different fields
The same record should make the split obvious. A pack sold on Monday does not automatically create teaching credit for every session redeemed from it. Teaching credit accrues when the class is taught (or when your written rule says a substitute earns it). Sales credit accrues when your rule says a pack or membership closes. If both apply in the same week, they appear as two lines, not one merged total. That rule belongs in the system, not in memory.
Shared view for trainers, front desk, and payroll
Trainers should see their own taught sessions and disputed lines without editing rates. Front desk confirms attendance and substitutes against the roster. Payroll sees the same approved totals without hunting chat. When a session fails review — wrong trainer, double booking, or a sale attributed to the wrong person — the line goes back to pending with a short note. The export cannot flip to ready while required lines are still open.
Bilingual notes when the Rio Grande Valley team needs them
Many Valley studios serve members and staff in English and Spanish. Keep exception or make-up notes as sibling fields on the same pay record when both languages matter, not as separate chat texts. Staff still write and approve the wording; software only keeps both versions together.
Draft exception summaries a person still owns
AI can help in narrow ways a person reviews: drafting an exception summary for a disputed substitute, proposing bilingual note drafts from fields staff already entered, or flagging a pay period with pending lines before export day. It never runs payroll, never changes rates, never sends pay stubs, and never marks a session approved for pay on its own. Ordinary business automation covers the rest: remind trainers to confirm taught sessions, notify payroll when every required line is approved, and block "export ready" until the named owner confirms.
Connect the roster to the tools you already use
Class attendance may stay in your booking tool. Pack sales may stay in membership. Payroll may stay with your current provider. The pay record can sit on top as the taught-vs-sold and approval layer. Connected systems can pass approved totals into the export your payroll tool already expects. Whether those tools support the connections is confirmed during scoping. Sometimes a disciplined shared sheet, a written rate table, and a named export owner are enough. If that already works, scoping should say so before anything custom is built.
Where to start this week
Pull last month's trainer pay disputes. For each one, note whether the confusion was sessions taught, packs sold, a substitute, or export ownership. Then list who may approve a session for pay and who may run the export. That list is the first draft of your trainer payroll rules.
If you want trainer pay that keeps classes taught separate from packs sold on one shared record, TwoQM can scope the fields, approvals, and connections around tools your studio already uses. Pricing explains how business apps, systems, and custom software are scoped. Nothing here is tax, employment, or legal advice.
Describe Your Trainer Payroll Rules · Explore TwoQM custom software