Custom vs. off-the-shelf scheduling software: your margin lives in the constraints the template can't express

Two things happened in field service software in the second week of July, and read together they say more than either does alone. On July 16, Housecall Pro launched separate, trade-specific packages for HVAC, plumbing, and electrical contractors — different onboarding, templates, workflows, and default settings for each trade. Six days earlier, Valsoft’s Manos Software Group acquired Dispatch, the Boston platform that coordinates work across third-party contractor networks. One vendor is splitting the generic product into verticals. Another is buying its way into a niche the generic product never covered. If you’re weighing custom vs. off-the-shelf scheduling software, that’s the signal worth reading.

TL;DR: The build-or-buy question is the wrong one. Off-the-shelf field service scheduling software has gotten genuinely good, and vendors are now shipping trade-specific versions because the generic workflow didn’t fit. But a template — even a well-researched vertical one — is somebody else’s constraint model, tuned for the median contractor. Write your own constraints down first. Most shops find 80–90% are standard and every serious platform handles them. The few that aren’t are usually the rules that decide margin, and no vendor will ever ship them. Decide after you have the list, not before.

The vertical package is an admission

Housecall Pro didn’t ship trade packages on a hunch. Per Contractor Magazine’s July 16 report, the company analyzed more than 100 million completed service jobs, consulted over 200,000 home service professionals, and evaluated more than 40 platform features to build them. Co-founder and Chief AI Officer Roland Ligtenberg framed it plainly: HVAC, plumbing, and electrical pros want software built for how they work.

That’s a vendor with an enormous dataset concluding that one workflow can’t serve three trades. Which is correct, and also the beginning of the argument rather than the end of it. Because if the gap between HVAC and plumbing is wide enough to justify separate products, the gap between two HVAC contractors in different markets — one doing residential service contracts, one doing commercial retrofit — is not zero either.

The Valsoft deal points at the same thing from the opposite direction. Dispatch, founded in 2013, exists because enterprise service brands running work through independent contractor networks needed something the standard FSM platform didn’t do: centralize scheduling, job information, contractor activity, and customer communication across a network of companies you don’t employ. That’s not a feature gap. That’s a different constraint model — you can’t assign labor you don’t control the same way you assign your own crew.

Verticalization is the market discovering that the last mile is where the work is.

Scheduling stopped being administration

There’s a reason this is surfacing now, and it isn’t software.

JLL’s skilled trades research, published April 21, put the numbers on it. By 2030, an estimated 2.1 million skilled trades positions could go unfilled — electricians, HVAC technicians, plumbers, pipefitters, equipment operators. The U.S. Department of Education puts the potential economic loss at $1 trillion annually. The replacement math is worse than the headline: for every five workers retiring out of construction, manufacturing, and the trades, only two enter. Last year roughly 600,000 jobs were posted across the major trades while about 150,000 new workers came through apprenticeship programs.

When you can hire, scheduling is administration — a way to keep the board tidy. When you can’t, scheduling is the margin lever. The same crew, sequenced better, is the only capacity you’re going to get. That shift is what moves scheduling software from a back-office purchase to a decision about how the business makes money, and it’s why “which package” is suddenly the wrong framing.

A template is somebody else’s constraint model

Here’s the assertion that matters: every scheduling product ships with a constraint model already inside it. You just don’t see it, because it arrives as defaults.

A constraint model is the set of rules a schedule has to satisfy, split into two kinds. Hard constraints can’t be violated — a tech must hold the license for the work, nobody is in two places at once, the permit inspection happens inside the window the municipality gave you. Soft constraints carry a cost when broken — arriving late in a window, sending a second truck, paying overtime. And underneath both sits the objective: the thing you’re actually optimizing. Most platforms optimize drive time, because drive time is measurable and universal. Almost no contractor’s real objective is drive time. It’s margin per truck-day, and those two answers diverge the moment a high-value job sits at the end of a long drive.

The rules that don’t fit are rarely exotic. They’re conditional. A crew can take a particular job type only when a licensed supervisor is on shift. A two-hour buffer after a boiler swap because the truck has to restock. This customer never gets that technician again. A commercial account whose SLA outranks three residential calls on the same street, except in the last week of the quarter. Every one of those is ordinary. Almost none of them are expressible as a checkbox, because they’re conditions on other conditions, and template configuration is mostly flat.

So the software does what it can and hands the rest back. The tell is the override rate. If your dispatcher is routinely dragging jobs after the auto-schedule runs, that isn’t a training problem or a data problem. Those overrides are your constraint model — the part the template couldn’t hold, being reapplied by hand every morning by the one person who knows it.

Which means it isn’t written down anywhere. It’s in a senior dispatcher’s head, and it retires when they do.

Constraint type	Example	Off-the-shelf handling	Where it breaks
Simple hard rules	License, certification, skill tag	Solid — every serious platform	Rarely
Spatial / temporal	Drive time, arrival windows, shift hours	Solid, usually the core optimizer	Rarely
Resource state	Parts on the truck, tool availability	Partial	Needs live inventory the platform may not own
Conditional rules	Job type allowed only if a supervisor is on shift	Weak	Conditions on conditions don’t fit flat config
Priority inversion	Soft rule must outrank a hard one on certain days	Weak	Fixed precedence, no per-context override
Objective function	Optimize margin per truck-day, not drive time	Rarely exposed	The default objective is the vendor’s, not yours
Cross-company labor	Assigning third-party contractor networks	Specialist products only	Different model — you don’t control the labor

The agentic version doesn’t change the answer

The current pitch is that AI agents will absorb this. They won’t, and the reason is structural rather than temporary: assigning technicians to jobs under competing constraints is combinatorial optimization. That’s a solver problem. Language models are extraordinary at language and mediocre at combinatorics, and pointing one at a dispatch board produces a fast, fluent, confidently suboptimal schedule.

The adoption data reflects the gap. Gartner’s 2026 Hype Cycle for Agentic AI places agentic AI at the Peak of Inflated Expectations, with 17% of organizations having deployed agents and more than 60% expecting to within two years. Gartner’s own June 2025 forecast — that more than 40% of agentic AI projects will be canceled by the end of 2027 on escalating costs, unclear business value, and inadequate risk controls — has aged well. So has its finding on “agent washing”: of the thousands of vendors claiming agentic capability, Gartner estimated roughly 130 were genuinely building agents.

None of which makes agents useless here. They’re good at the edges of scheduling — reading the inbound call and turning it into a structured job, explaining to a customer why the window moved, summarizing what the tech found so the next visit starts informed, handling the exception conversation a dispatcher would otherwise take. That’s real time back. It’s just not the assignment. The assignment wants a solver, and a solver still needs the constraint model somebody has to write.

The working version

Write the constraints down before you shortlist anything.

Sit with whoever actually builds the board and get every rule out of their head and onto paper. Mark each one hard or soft. Then ask the question nobody asks: what are we optimizing? If the honest answer is margin per truck-day and the software optimizes drive time, you’ve found the mismatch before you’ve paid for it.

Most operations are pleasantly surprised at this point. The list comes back 80–90% standard, which means off-the-shelf is the right call and the evaluation is now a real evaluation instead of a feature-grid comparison. Take the list to the demo and make the vendor schedule a genuinely bad week from your own history — the one with the emergency callout, the tech out sick, the permit that landed late. Clean sample weeks prove nothing.

For the remainder, the choice is narrower than build-or-buy. Sometimes the rule is a bad habit and deleting it is the fix. Sometimes it belongs in a thin layer beside the platform — the schedule comes out of the product, and a small service reorders it against the rules the product can’t hold. Sometimes, when scheduling genuinely is the business, the optimizer itself is worth owning. I’ve built that last one: a constraint-programming engine for a utility’s crews that landed at 96% workday efficiency, which was only possible because the constraints were specified properly first. The solver was the short part. Getting agreement on what the rules actually were took longer than writing the code.

And whichever path you take, the layer under it is the same one that decides whether any of this works: the platform has to agree with your CRM and your billing system about what a job, a customer, and a technician are. That’s a data contract, and it’s the thing that quietly sinks scheduling rollouts that were otherwise fine. Getting that right is the project; the scheduling engine is the last step.

The operator read

The vendors verticalizing this month are telling you the truth about their own products: the generic template didn’t fit, so they built three. That’s an improvement, and it’s still a template. A trade-specific package is a better guess at your rules made by someone who has never seen your board — informed by 100 million jobs, and still a guess about the median contractor.

Nobody makes money being the median contractor. The margin is in the handful of rules that are specifically yours, and those are exactly the ones no package ships with. You can’t evaluate software against constraints you’ve never written down — and if the only copy lives in one dispatcher’s head, the software decision isn’t the urgent one.