Note
When the Schedule Lives in One Person's Head
The difference between a business that can grow and one that cannot is often one question: if the person who holds the schedule is unavailable today, what actually happens?
Most installation businesses do not have a clean answer. Not because nobody has thought about it, but because the schedule has never really existed as a separate thing. It lives as knowledge, and that knowledge lives in one person.
How does technician scheduling actually work?
In a business with ten to thirty technicians, the person running the schedule knows things that are not written down anywhere. They know that two of the crew are still finishing a job in Rayong and will not be back until Wednesday. They know that one technician is the only one with experience on a particular panel brand, and the factory in Bang Na specifically asked for him. They know that two technicians had a disagreement last month and should not be on the same site this week.
That knowledge is real and useful. It is also completely inaccessible to anyone else in the business.
New jobs come in, they make adjustments. A site calls to push back the start date, they rearrange. A technician phones in sick, they call someone else. It works. Until there is a day when it does not.
What does the schedule holder’s absence actually cost?
The risks are not dramatic. Nobody plans to collapse a project by going to hospital. The costs are ordinary.
The schedule holder is sick for two days. Not a week, just two days. Who handles the incoming calls? Who knows that the Chonburi job has to start Tuesday because the factory closes Wednesday for a maintenance round? Nobody calls the wrong person, but nobody calls the right one either, and Tuesday comes and goes with no crew on site.
A project runs long unexpectedly. An Ayutthaya solar job stretches three extra days because a permit from the provincial office is delayed. The schedule holder is managing the rearrangement in their head while also on-site at the Samut Prakan job. Three technicians from a different project wait for instructions that never arrive. That is 24 technician-hours gone, not because anyone made a mistake, but because the information needed to catch the conflict was visible to nobody who had time to act on it.
The person leaves. Not dramatically; they simply decide to move on after four years. During the handover they try to explain how the schedule works, but a mental map cannot really be transferred. The replacement spends three months rebuilding it, and during those three months some of the knowledge is simply lost.
What does a visible schedule actually look like?
The alternative is not a complex piece of software. It is a surface where the schedule can be seen by someone who was not in the room when the decisions were made.
What that surface has to show:
- Which technician is assigned to which site on which day
- Which days have no assignment yet for each technician
- Which jobs are expected to run long, and by how much
Not job tickets. Not status lists. Technician-days: each person, each day, assigned or unassigned. That is the unit that matters for scheduling.
Here is a worked example. A contractor has 14 technicians running three projects simultaneously. On a board showing technician-days, next week looks like this:
- 9 technicians assigned across the three active sites
- 3 technicians completing a closeout on Tuesday, free from Wednesday onward
- 2 technicians unassigned for the full week
That board means anyone in the business can answer the question: can we take a new job starting Thursday? The answer is yes, and they know exactly which six people are available, without calling the person who holds the schedule. Run the same exercise with your own headcount and current projects and see whether you can answer that question without picking up a phone.
Is a whiteboard enough?
Sometimes. The test is specific: can someone who was not in the room on Monday still read the schedule accurately on Wednesday?
A whiteboard that the foreman updates once a week, in shorthand only they understand, is not a visible schedule. It is the same mental map written on a wall.
A board that is updated as jobs are assigned, shows actual technician names against actual dates, and can be read without an interpreter, passes the test. The format does not matter much. What matters is whether the information lives in the board or in someone’s head.
What makes a scheduling board hard to keep current?
The common failure is that updating the board is treated as a second task. The foreman updates it when there is time. Under pressure, there is never time, so the board drifts. Within two weeks it reflects last month’s reality, and nobody trusts it.
The boards that survive are the ones where updating happens as a natural result of dispatching. Assign a technician to a job, they appear on the board. Close a job, those days free up automatically. The update is not a separate act; it is the dispatch itself.
FAQ
Does the foreman need to give up control of the schedule?
No. The goal is that the information is visible, not that someone else makes the decisions. The foreman can own scheduling entirely. What changes is that others can see and verify what was decided, which usually makes the foreman’s own job easier: they field fewer questions that the board already answers.
How far ahead does a schedule need to go?
For installation work, four weeks of visibility is enough for most decisions. Anything beyond six weeks changes too often to be reliable. The goal is not perfect planning; it is catching conflicts before they happen rather than after they have already cost you a day or more.
Is this different from a shared calendar?
A shared calendar tracks events. Installation scheduling needs the reverse view: for each technician, what are they doing each day? A calendar that shows jobs does not immediately tell you which technician is free Thursday. A board organised by technician does.
If making this visible is something you want to put in place, the details of how the TRACE 30 program sets it up are at /program/. If a short conversation first makes more sense, /schedule-a-call/ is there.