Most residential field service companies of any size end up working with crews they do not employ. Seasonal peaks, a trade you do not carry in house, a territory at the edge of the radius where sending your own truck makes no sense.
The work itself is usually fine. The scheduling is where it falls apart, and it falls apart in a predictable way: the subcontractor exists in the business but not in the system. They are a phone number in someone's head, called when the board is full.
That arrangement has a specific cost. You are carrying the overhead of the relationship — vetting, onboarding, rates, paperwork — and getting only the fraction of the capacity benefit that your scheduler happens to remember to use.
Three problems, and only one is about trust
Problem 1: Their availability is not visible
An employed technician has a shift. A subcontractor has some availability, which varies, which they know and you do not.
If that availability is not represented anywhere, the scheduling system cannot evaluate them. A slot that a sub could cover perfectly gets declined or pushed, because at the moment of booking the sub does not exist as an option.
Problem 2: Their starting position is unknown
Assigning work sensibly depends on knowing where the crew will be coming from. For your own trucks, the schedule knows. For a subcontractor, it frequently does not — which means either you assign blind, or you fall back on "closest to their home address," which stops being true by mid-morning.
Problem 3: They should not see everything
This is the one people raise first and it is the most tractable. A subcontractor needs the jobs assigned to them, the addresses, the scope, and the customer contact for those jobs. They do not need your full customer list, your pricing, or what your other crews are doing.
That is a permissions problem, not a trust problem, and it should be solved with roles rather than with restraint.
Treating subs as schedulable capacity
The change that fixes most of this is conceptual: stop treating subcontractors as an overflow list and start treating them as crews with constraints.
Practically, that means capturing four things for each one:
Availability windows. Which days, which hours, and how far ahead they are willing to commit. Update it on a rhythm — a standing Friday message asking for next week is low effort and dramatically more useful than calling around on Tuesday morning.
Service capabilities. What work they are qualified and authorized to perform. This is what lets the system consider them for the right jobs and exclude them from the wrong ones automatically.
Working territory. Where they will travel, and from where they start the day. Without a starting position, drive time to the first job is a guess.
Commercial terms. Rate, and whether their cost changes the economics of a given job. Some work is worth subbing and some is not, and that is a decision the person building the board should be able to see.
With those four in place, a subcontractor becomes something the scheduling engine can evaluate on the same footing as an employed crew: qualified, available, and able to physically reach the address in time.
Role-scoped visibility, concretely
Getting permissions right is mostly about being specific rather than clever. A workable default:
| Role | Sees | Does not see |
|---|---|---|
| Office / dispatch | Full board, all crews, customer records | — |
| Employed technician | Own schedule, job details, customer contact for their jobs | Pricing, other crews' schedules |
| Subcontract crew | Only jobs assigned to them, scope, address, contact for those jobs | Full customer list, pricing, other crews, unassigned pipeline |
| Field manager | Their team's schedule and job detail | Company-wide financials |
Two details that matter more than they look:
Scope information has to be complete. The temptation when restricting visibility is to restrict too much, and a sub who arrives without knowing the full scope produces a second visit. Restrict commercial and cross-crew information; never restrict what is needed to do the job right the first time.
Assignment history should be retained. Who did what, when, and how it went. If a sub relationship ends, the record of the work stays with the customer where it belongs.
A note on scope. Everything here concerns crews working for you — your jobs, your customers, your board, with permissions scoped per role. Sharing capacity between independent companies is a genuinely harder problem, because it requires exposing availability to a business that may bid against you. That is a real unsolved problem in this industry and not something to treat as a solved feature.
Scheduling them well
Once subs are represented as capacity, a few practices separate companies that get value from the relationship from those that just have one.
Offer subbed work the same way you offer employed work. If the check at booking is "can a qualified crew physically reach this address by this time," subs participate in that check automatically. No separate process, no remembering.
Confirm commitments explicitly. Employed crews are scheduled. Subs are asked. Build the acknowledgement into the flow so an unacknowledged assignment is visible well before the day of service.
Give them a realistic drive. A sub given an infeasible sequence will either be late or decline future work. The former costs you a customer, the latter costs you the capacity. Compute their travel from their actual starting position, not from your shop.
Track first-time fix and adherence per crew. Not as a stick. As information about what work to send where — most companies find some subs are excellent for particular job types and unsuited to others, and that is worth knowing deliberately rather than anecdotally.
What to take away
- A subcontractor who exists only as a phone number is overhead without the capacity benefit.
- Capture four things to make them schedulable: availability, capabilities, territory and starting position, and commercial terms.
- Visibility is a permissions problem — scope by role, but never restrict information needed to complete the job correctly.
- Run subs through the same feasibility check as employed crews, computing travel from where they actually start.
- Build explicit acknowledgement into assignment; subs are asked, not scheduled.
- Sharing capacity between independent companies is a much harder, unsolved problem — do not conflate it with scheduling your own subcontractors.
Common questions
How do you schedule subcontractors in field service?
Treat them as schedulable capacity with their own availability, service capabilities and working territory, rather than as an overflow list to phone when you are stuck. That means capturing when they are available, what work they are qualified for, and where they are starting from, so the system can evaluate them the same way it evaluates employed crews.
Should subcontractors see the full schedule?
No. Subcontractors should see the jobs assigned to them and the information required to perform them. Role-scoped visibility keeps customer lists, pricing and other crews' work out of view, which matters commercially and is straightforward to enforce with proper permissions.
What is the biggest mistake companies make scheduling 1099 crews?
Treating them as a phone call rather than as capacity. If a subcontractor's availability is not in the system, the scheduler cannot offer their slots, which means the company is carrying the cost of the relationship without getting the capacity benefit.