The scheduling system in most small contracting businesses is one person's head, backed up by a group chat and a whiteboard in the shop.
It works. That is the important thing to acknowledge: it genuinely works, up to about two crews. The owner knows where everyone is, reshuffles by text when something moves, and the whole thing runs on shared context that would take an hour to write down and takes ten seconds to say out loud.
Then it stops working, and it stops working suddenly. The usual trigger is a third crew, or the owner taking a week off, or one bad Tuesday where a cancellation cascades. Two people show up at the same job. Nobody shows up at another. A client who booked three weeks ago gets called the night before and moved.
What actually breaks?
It is worth being precise about the failure, because the obvious diagnosis ("we need a scheduling app") leads people to buy something that does not fix it.
The schedule exists in more than one place. The whiteboard says one thing, the group chat's last forty messages say another, and the owner's head holds the version that is actually true. Nobody can tell which is authoritative, so everyone asks the owner, which makes the owner the bottleneck for every question.
Changes do not propagate. A move announced in a group chat at 9 p.m. is seen by whoever was looking at their phone. The crew member who was driving finds out at 7 a.m. when they arrive at the wrong address.
Nobody can see tomorrow. Crews know today because they were told this morning. They cannot plan, cannot tell a client "we'll be back Thursday," and cannot flag that Thursday is a problem until Thursday.
Client commitments are invisible. The schedule tracks where crews go, not what was promised. So "we'll start your kitchen the week of the 14th," said on a phone call a month ago, exists nowhere and surfaces as an angry call on the 15th.
The drive cost calculator shows what the drive to a job costs you, per job and across a year.
One schedule, visible to everyone
The fix is not sophisticated. It is a single schedule that is the source of truth, that every crew member can see on their own phone, and that updates for everyone the moment it changes.
That is genuinely the whole idea, and its value comes almost entirely from the "single" and the "everyone." A beautiful scheduling tool that only the owner looks at reproduces the original problem with better graphics.
Three properties matter more than features:
It has to be readable on a phone in a driveway, in about three seconds. Where am I, what am I doing, who else is there, what is the address. If a crew member has to navigate, they will text the owner instead, and you are back where you started.
Changes have to be visible without being announced. When a job moves, the schedule moves. Nobody should have to also send a message, because the day they forget, someone drives to the wrong place.
It has to include the client-facing promise, not just the crew assignment. The schedule needs to know that this job was promised for the week of the 14th, so that when you move something into that week you can see what you are displacing.
The day board and the week ahead
In practice, small crews need two different views, and conflating them is a common mistake.
The day board is the crew's working document. Today, who is where, in what order, with addresses and access notes. It should be brutally simple and should not require interpretation at 6:45 a.m.
The week ahead is the owner's planning surface. It shows capacity: which crews have space, what is unassigned, what is at risk. It is where you answer "can we take this job?" and it is the thing that lets you stop over-promising.
Crews should not have to look at the planning view to find their day, and the owner should not have to reconstruct capacity from seven day boards. Zeus separates these deliberately: a day board for the crew, and a planner for assigning work across the week, both reading from the same schedule so they cannot disagree.
Building slack in on purpose
The most common scheduling error in small contracting is not disorganization. It is booking to 100% of capacity.
If every crew is fully committed every day, then a single overrun, a sick day, or a delayed inspection has nowhere to go. It cascades, pushing three clients, each of whom then has to be called. One bad day becomes a bad two weeks.
Deliberately leaving gaps feels wasteful and is not. A half-day of unbooked time per crew per week absorbs almost all normal variance. In the weeks nothing goes wrong, it becomes callbacks, snag lists, quoting, or maintenance you have been deferring, none of which were getting done anyway.
The related habit: stop booking specific start dates far in advance for work you cannot control the lead-up to. "The week of the 14th" is a promise you can keep. "Tuesday the 14th at 8 a.m.," made a month out, is a promise that depends on four things going right, and it converts a small slip into a broken commitment.
Subcontractors are part of the schedule
A recurring gap in small-crew scheduling is that subs live outside the system. The drywaller is booked by text, the electrician by phone, and neither appears on the schedule that the rest of the work is planned around.
This causes a specific and expensive failure: your crew finishes rough-in on Wednesday, but the electrician was booked for the following Monday, and nobody noticed the four idle days until Wednesday afternoon.
Subs do not need to use your software. But their committed dates need to be on your schedule, visible alongside your own crews, or you cannot see the dependency chain that actually determines when a job finishes.
What should you do first?
If you are running on a whiteboard and a group chat and it is starting to strain, the sequence that works:
- Get every committed job into one place, including the vague client promises. This is uncomfortable, because you will discover you have over-committed. Better to discover it now.
- Give every crew member read access on their phone. Just this, before any process change, removes most of the daily "where am I?" traffic.
- Stop announcing changes separately. Change the schedule and let people see it. This only works after step 2, and it is what actually retires the group chat as a system of record.
- Add the sub dates.
- Leave a half-day of slack per crew per week and defend it.
Steps 1 and 2 do most of the work. The rest is refinement.
Frequently asked questions
We're only two people. Is this overkill?
At two people, the head-and-text system genuinely is efficient, and formalizing it too early adds overhead for no gain. The signal to change is not headcount: it is when you start having to reconstruct what was promised, or when someone shows up at the wrong place more than once.
How far ahead should we schedule?
Firm assignments about a week or two out; committed weeks, not days, for a month or two beyond that. Scheduling specific days three months out produces false precision that you will spend the intervening months rearranging.
What about jobs that get interrupted and resumed?
They need to appear on the schedule each time they are worked, not once as a block. A kitchen worked over five non-consecutive days is five entries. Treating it as one continuous block hides the gaps, and the gaps are where the capacity actually went.
Should clients see the schedule?
Generally no: the internal schedule contains other clients' information and changes constantly, and exposing it invites negotiation over crew allocation. Tell clients their committed window and update them when it changes.
ZEUS