Scheduling when you don't know who is showing up

Crew availability is harder to plan around than it used to be. Hiring takes longer, and a crew you expected on Tuesday is not always the crew that arrives.

The interesting part is where that costs money, because it is almost never the labor. A morning without a crew costs you a customer who took the day off, material sitting on a driveway, an inspection booked around a date that has moved and four phone calls that only one person in the office can make. That is the bill, and most of it is communication.

What a schedule assumes

A week laid out on a board assumes two things that nobody says out loud.

It assumes crews are interchangeable, so if one does not arrive another can take the work. In practice a tear-off on a steep cut-up roof is not work you hand to whoever is free, and the person who knows that is usually the one who is not in the office when the call comes.

It assumes jobs are equally movable. They are not, and the differences are knowable in advance. Material delivered yesterday makes a job expensive to move. So does an inspection booked for Thursday. A homeowner who arranged to be home costs you in a way no invoice shows and shows up later in a review.

A job with none of those attached can slide a week and cost nothing.

The reshuffle is the product

When a morning goes wrong, what the office does next is the actual work.

Someone has to know which jobs can move without a cost, which cannot, what is already sitting on which driveway, and who has been told what. Then they have to reach a customer, a supplier and a crew lead in whatever order does the least damage.

In a company where that knowledge is spread across a scheduling board, a text thread and one person's memory, this takes a morning. In a company where it is written down against each job, it takes a few minutes and one decision.

The second company is not better managed in some abstract way. It just answered the question earlier, when there was time to answer it.

Make the customer call first

It is the cheapest thing to get right and it is the one that gets delayed, because nobody enjoys making it and because there is always a hope the day recovers.

A homeowner told at seven that the crew is coming Thursday instead is inconvenienced. The same homeowner told at eleven has taken a day off work for nothing, and that is the version that turns into a review and a payment conversation.

Whoever is going to make that call needs two things in front of them: which customers were expecting somebody today, and what they were last told. If assembling that takes fifteen minutes, the call happens at eleven.

Mark the jobs before you need to

The practical move is to record, on each job, what makes it hard to move. Material delivered. Inspection booked. Customer taking time off. Crane or lift scheduled. Any of those and the job is one you protect.

None of that requires new software. It requires a field, or a tag, or a column that somebody fills in when the fact becomes true rather than when it becomes urgent. It does not exist because it costs a few seconds on a good day and saves an hour on a bad one, and the good days outnumber the bad ones right up until they do not.

Where software helps is in making the answer visible to whoever is holding the phone, rather than to whoever built the schedule. Those are frequently different people, and the second one is on a roof.

The version that maintains itself

A tag somebody has to remember to set is a tag that is wrong by the second week of a busy month. That is the honest limit of the paragraph above, and it is worth saying, because the fix is not discipline. It is deriving the flag instead of typing it.

Every fact that makes a job expensive to move already exists somewhere in a system you run. Material delivered is a status on the supplier order. An inspection is an event on a calendar with the job's address on it. A customer arranging to be home is a reply sitting in a thread. A lift is a hire with a date. None of that has to be re-entered by a person, because each of those systems will tell you what it knows if something asks.

So the movability of a job stops being a judgment and becomes a computed property. The job carries a short list of what is attached to it and what each attachment costs to move, and that list updates itself when the supplier marks the order delivered or the inspection is booked. Nobody maintains it. It is right on the worst morning of the year for the same reason it is right on a quiet one.

What that buys is a single screen at seven in the morning: the jobs scheduled today, what is attached to each, when each customer was last contacted and what they were told. The four phone calls become one decision plus one action. The action sends the customer the new date, tells the crew lead, notifies the supplier if material has to follow, and writes onto the job what the customer was told, so the next person to speak to them starts from the truth instead of a text thread.

Two more things become possible once the data is shaped that way. Crews stop being interchangeable in the software as well as in reality, because capability is a field: who can take a steep tear-off becomes a filter, not a phone call to the one person who knows. And the reshuffle produces a record, so at the end of a season you can answer how many jobs moved, what it cost, and which of your dependencies caused it. That is a question no roofing company we have talked to can currently answer, and it is the one that tells you what to fix.

The test

Take a week from this season where something went wrong. Count the phone calls it took to resettle, and ask who made them.

If the number is high, the fragility is in how much has to be reassembled before anyone can act. If it is low but one specific person made all of them, the process is not in your business. It is in them, and it takes a holiday when they do.

Either answer points at the same piece of work: getting what that person knows into the job record, where the phone can reach it.