Roofing Scheduling and Dispatch Software: 6 Gates

The install date is the last decision you make about a roofing job, not the first. Everything upstream of it decides it for you.

That is the difference between roofing and every other trade that buys dispatch software. A plumber dispatches one technician to one address for two hours. You commit a crew of four to eight people to one address for one to three days, and you cannot commit them until the shingles are on the ground, the permit is pulled, the dumpster is scheduled and the sky cooperates.

Most software sold as "roofing scheduling and dispatch software" is a field service calendar with a rain icon bolted on. A calendar records a decision. It does not make one.

The short answer

Roofing scheduling and dispatch software is worth buying when it models a job as a chain of dependencies with a crew and a duration attached, and it is not worth buying when it only gives you a prettier calendar. The test is simple: can the tool tell you, without a phone call, which sold jobs are actually ready to install this week? If it cannot answer that, you have bought a whiteboard with a login screen.

A roofer on r/Roofing put the problem plainly in a 2026 thread asking for production scheduling software: CRMs are "great for scheduling and tracking leads but not for keeping track of production schedules." That gap is the whole subject of this article.

Why roofing breaks general field service software

General field service management was designed around a service call. One technician, one address, one visit, one to three hours, and the main optimisation problem is drive time between stops. That is why almost every dispatch demo you will sit through leads with route optimisation and a map with pins on it.

Roofing has almost none of those properties.

Route optimisation across four stops a day is a real gain for a plumbing shop. For a roofing company running one address per crew per day, it is a rounding error. The value in roofing sits somewhere else entirely: in knowing which jobs are genuinely ready, and in knowing how much your crews can physically absorb.

The six gates that decide the install date

The most useful description of roofing scheduling I found this week came from a contractor answering that r/Roofing thread. Their point was that install schedules break because one detail is stale, and they listed the usual suspects: material delivery, permit or inspection, weather window, crew availability, dumpster, subcontractor, or a job that sold differently than production expected.

Turn that into a gate system. A job does not get a date until all six clear.

Gate 1: Scope confirmed against measurements. The signed scope and the measurement report agree. Squares, pitch, layers, decking allowance, ventilation, and any upgrade the salesperson promised verbally. This gate exists because "sold differently than production expected" is the failure that costs you a full crew day at the address.

Gate 2: Materials ordered. Not "we will call ABC on Monday." An order exists, with a purchase order number attached to the job.

Gate 3: Delivery date confirmed. This is the gate most schedules skip. As one contractor phrased it in the same discussion, key the start date off material delivery so installs never get booked before the shingles land. A confirmed delivery date is a fact you can schedule against. An order without a date is a hope.

Gate 4: Permit and inspection status. Known, and either cleared or with a realistic date. Municipalities are not moved by your schedule.

Gate 5: Dumpster and crew assigned. Both are physical resources with their own availability, and both need to move together if the date moves.

Gate 6: Weather window. Not "it looks clear Tuesday," but a window long enough for the job's actual duration, including the tear-off day where the roof is open.

The point of naming the gates is that it converts scheduling from a judgement call into a status query. Your production board should be able to show you every sold job and which gate it is stuck behind. That single view is worth more than every route optimisation feature in the category.

Schedule squares, not slots

A calendar day is not a unit of capacity. Squares are.

Roofing consultants publishing crew benchmarks put an experienced crew at roughly 1 to 1.25 squares per man-hour measured from setup through cleanup, with anything under 0.8 signalling an operational problem. That maths puts a four-person crew somewhere near 32 to 40 squares in an eight-hour day on a standard pitch, and a steep or cut-up roof can take 50 percent longer for the same footprint.

Operator reports line up with that range. In one widely-read r/Roofing thread, a homeowner documented a 52-square Florida job that took a 12-man crew a day and a half to tear off and dry in, then under a day to shingle. In another, a six or seven-person crew ran a full 10-hour demo and underlayment day, then installed 28 squares in four hours the next morning. A solo roofer in the same subreddit reported around 15 squares a day including stocking the roof.

The practical move is to stop booking jobs into days and start booking squares into weeks. Take each crew's real historical output, multiply by the days you can realistically work, and derate it. The standard capacity planning guidance is to schedule at 70 to 80 percent of theoretical maximum, precisely so that weather days, decking surprises and callbacks have somewhere to land.

A crew that can do 150 squares a week gets booked at 110 to 120. The gap is not slack. It is the only thing standing between one rain day and a schedule that stays broken for a month.

This is the number your software has to hold. If your scheduling tool cannot show a crew's committed squares against their weekly capacity, you are doing capacity planning in your head, and your head is not available to the office at 7am when a delivery slips.

The crew you scheduled is not always the crew you have

Here is the roofing-specific reality that no dispatch product accounts for: a large share of production labour is subcontracted at a per-square rate, which means your crews are participants in a market, not slots on your calendar.

Asphalt shingle labour is commonly quoted around $50 to $90 per square for install and $75 to $125 with tear-off, and labour tends to run 40 to 50 percent of the total job cost. Those rates are not fixed. After Hurricane Beryl, one homeowner documented their contractor's subcontracted crew walking off mid-job because per-square rates in the market had moved from a negotiated $80 to $90 up to $140 to $180. Day one had a five-man crew and 75 percent of the tear-off done. Day two had two guys. The job hit day 12 at 40 percent complete.

That is a scheduling failure no weather API would have caught, and it is the single biggest reason roofing schedules differ from HVAC schedules. Dispatch software built for W2 technicians assumes the resource shows up because it is on payroll. In roofing, after a regional storm event, the resource is being bid against.

Two implications for what you buy and how you run it:

1. Your production board needs sub crews as first-class resources, with their own rates, capacity and assignment history. If subs live in a spreadsheet and employees live in the software, your capacity number is fiction.
2. Track schedule adherence per crew, meaning the percentage of jobs that started on the originally scheduled date. Over a season that number tells you which crews to give your storm work to, which is a far more valuable output than a map.

What the weather feature actually does

Every vendor in this category leads with weather. It is the most oversold feature in roofing software, and it is worth being precise about why.

Weather is a real constraint, not a marketing invention. Aggregated construction delay research published by EHAB attributes roughly 21 percent of construction delays globally to adverse weather, with building projects in the 10 to 18 percent range, and external finishing trades carrying the highest share of non-working days because rain, wind and temperature all bind at once. Roofing is the most exposed trade in that group, since tear-off deliberately opens the building envelope.

But a forecast is not a reschedule. When Tuesday goes wet, the actual work is:

• Finding the next window long enough for the remaining duration
• Confirming the crew is free in that window, and that they have not been rebooked
• Moving or extending the dumpster rental
• Confirming the material can sit safely on site, or rescheduling the drop
• Telling a homeowner who booked a day off work
• Not cascading the change into the three jobs behind it

A weather integration helps with step one. Steps two through six are dependency management, and that is the capability you should actually be evaluating. The honest test in a demo is to ask the vendor to move a three-day install by four days and watch how many of the attached resources move with it. If the dumpster and the delivery stay put while the job slides, the tool is showing you a calendar event, not a job.

There is also a customer-communication angle worth noting, because roofing weather delays generate the angry calls. Homeowners on r/Roofing regularly post asking whether it is reasonable to demand a postponement when rain or snow is forecast for a tear-off day, and whether shingles sitting on the driveway through a storm is a problem. Those threads are a preview of the calls your office takes. Automated reschedule notifications are not a nice-to-have in this trade, they are the difference between a delay and a review.

Pricing, and why per-seat billing fights your business model

Published pricing across the category, as reported in 2026 roundups and vendor pages, spans a wide range:

Two things matter more than the headline number.

First, structure beats price. A per-user model on a roofing company means your software bill peaks exactly when your headcount peaks, which is the season you are already carrying maximum payroll and material float. Contractors on r/Roofing describing AccuLynx repeatedly land on the same sentence: it is expensive if you have a lot of salespeople. A three-layer model of base plus per-user plus messaging is genuinely hard to forecast before a sales call.

Second, and less obvious: per-seat pricing creates a bad incentive at exactly the wrong point. A production board is only accurate if the foremen, the production manager and ideally the sub crew leads are in it, updating status. If every one of those logins costs $60 to $120 a month, the rational move is to keep them out and have the office rekey their texts. That is how you end up with software that everybody pays for and nobody trusts. As one roofer put it in a thread on production tracking, a CRM is only as good as the information being inputted into it.

If you want the fuller version of this argument, we walked through it for the general case in custom CRM versus off-the-shelf CRM, and the switching costs in how much it costs to switch CRM.

The fields your production board actually needs

Feature lists in this category are long and mostly interchangeable. Here is the short version of what a roofing production record has to hold before anything else matters:

• Job address, squares, pitch and complexity multiplier
• Layers to remove and decking allowance
• Signed scope, plus the measurement report it was priced from
• Material order reference, supplier and confirmed delivery date
• Permit status and inspection dates
• Dumpster vendor, drop date and pickup date
• Assigned crew, whether employee or sub, and the agreed per-square rate
• Estimated crew days, derived from squares and complexity, not typed in by hand
• Scheduled start date, original scheduled start date, and actual start date
• Weather-dependent flag
• Punch list and final invoice status

The two fields most tools omit are the complexity multiplier and the original scheduled start date. The first is what stops a 12/12 pitch Victorian from consuming a slot sized for a ranch. The second is the only way to ever measure whether your scheduling is improving, because without it, every job looks like it started on time.

How to test a platform before you commit

The advice that came up most consistently from roofing operators, including from vendor employees participating honestly in those threads, was to trial on real work rather than to compare feature grids.

1. Run two real jobs end to end in each shortlisted tool. Real photos, real measurements, real material order, real invoice. Feature comparison pages will not tell you what annoys you on day nine.
2. Trial through one bad week. One roofer specifically recommended trialling through a real storm week, because that is when scheduling either holds or does not.
3. Break something on purpose. Slip a delivery by three days and see whether the install date moves on its own or waits for a human to notice.
4. Check the phone, not the desktop. Incomplete onboarding kills adoption faster than missing features, and the mobile experience is where field tools quietly fall apart. Your foreman is standing on a roof in the sun with gloves on.
5. Price it at peak headcount, not today's. Model the July bill, not the January one.
6. Ask about the exit. Roofers repeatedly warn each other that getting data out of some platforms is harder than getting in. Ask what an export contains before you migrate years of job history into it.

If you want the operational version of this rather than the software version, we covered the underlying habits in how to schedule jobs efficiently as a contractor.

The bottom line

Roofing scheduling and dispatch software is worth real money when it holds the dependency chain and the capacity maths. It is worth very little when it is a calendar with a weather widget, because the calendar was never the constraint.

Buy for the six gates. Book capacity in squares against a derated weekly number rather than in job slots. Treat subcontracted crews as real resources with real rates, because in a storm market they behave like one. And weight the pricing structure at least as heavily as the price, since a per-seat model taxes the exact behaviour that makes the schedule true.

The company that knows on Monday morning which jobs are ready to install does not need a better calendar. It already has the only thing the calendar was supposed to give it.