Note
Who Owns the Screen: The One Person a System Needs
A new operations system has a high-risk period that runs for about sixty days after it goes live. During that time, the team is still learning the tool, the processes are being settled, and nobody is certain which jobs the system covers versus which ones still go through the old channels. What determines whether the system survives this period is usually not the software. It is whether there is a named system owner: one person whose daily job includes reviewing what the board shows and acting on it.
Without that person, the system moves from active management tool to passive reporting log in a matter of weeks.
What does a system owner actually do each day?
The role is not administrative. It does not mean entering data or managing user accounts. It means:
- Looking at the board each morning and confirming that every job with a start date in the next three days has a technician assigned
- Identifying jobs that closed yesterday but have not moved to the billing queue, and finding out why
- Flagging sites whose inspection dates fall in the current month and confirming the jobs exist in the schedule
- Raising unassigned or overdue items to whoever makes scheduling decisions, before they become problems
This takes less than thirty minutes a day on a typical operation of ten to twenty-five technicians. The time is not the constraint. What makes the role function is that it belongs to a specific person, on a recurring schedule, with clear authority to raise what they find.
Why does the owner have to be one person and not several?
Shared ownership tends toward zero ownership. If three people can see the board and any of them can raise a problem, the implicit logic is that someone else will probably catch it. Unassigned jobs stay unassigned because the coordinator assumed the foreman noticed. Closed-but-unbilled jobs sit for a week because nobody is sure whose job it is to follow up, and what those weeks cost while the jobs wait rarely appears on any report.
One named person removes the coordination overhead. When a job sits unassigned for two days, the reason is visible: the owner missed it, or they saw it and made a decision. Either way, there is one conversation to have.
The same logic applies to frequency. “Check the board when you have time” does not produce a daily review. A fixed daily task, on the calendar, does.
Is this the business owner’s role or the coordinator’s?
Almost always the coordinator’s, not the business owner’s.
The MD typically carries too many other responsibilities to sustain a daily review of operational detail. They also tend to respond to what they are told rather than what they see. When the MD is the de facto board monitor, the board gets checked during periods of pressure and ignored during periods of calm. The review becomes reactive rather than routine.
The coordinator, whose job already involves scheduling and follow-up, is the natural fit. They are close enough to the day-to-day to act on what they see. They understand which jobs are time-sensitive. They know who to call when a technician is not yet assigned to a job that starts tomorrow.
A practical marker for whether this is working: when a job arrives in an unassigned state on a Monday morning, does the system owner find it before the foreman does? If the answer is yes, the daily review is functioning. If the system owner is consistently reacting to problems the field team has already discovered, the review is not happening.
What happens when there is no named owner?
The pattern is predictable. In the first few weeks after a system goes live, the novelty keeps people checking. Jobs get logged, the board fills in, and the data looks good. As the novelty fades, the check-in frequency drops. A week passes where nobody formally reviews the board. Unassigned jobs accumulate. Billing delays happen. The team starts routing exceptions through the old channels because those channels have faster responses.
Within two months, the system is being used as a record of what happened rather than a tool for managing what is happening. The other half of the same failure is a system the work does not have to pass through at all. At that point, getting it back to an active management role requires retraining, re-establishing habits, and dealing with backlogged data that accumulated during the drift.
Naming the owner before go-live, and building the daily review into their routine from day one, is easier than correcting the drift after six weeks.
Consider a contractor with fifteen technicians running eight to ten jobs a month. If three jobs per month sit unassigned for two extra days each because nobody caught them on the board, that is six technician-days of delayed scheduling across a year. If two closed jobs per month miss their billing cycle because nobody flagged the gap, that is two months of deferred cash flow per job, or potentially twenty-four delayed invoices in a year. Neither number is catastrophic on its own. Combined, and sustained across twelve months, they represent a drain that would not exist if one person reviewed the board for twenty minutes each morning.
FAQ
What if the coordinator already has no spare time in their day?
The daily board review replaces some of the informal check-ins the coordinator is already doing. If they are currently discovering scheduling gaps through phone calls, WhatsApp messages, and foreman conversations, the board review makes those gaps visible earlier and in one place. In most operations, this reduces total coordination time rather than adding to it. If the coordinator’s role is genuinely full, the question is which tasks need to move before a new system is added, not whether the system should skip the owner role.
Can the system owner role change as the team grows?
Yes, and naming an owner does not prevent that. It just means that when ownership shifts, the new owner is explicitly identified, briefed on the review routine, and has a handover from the previous owner before the gap appears. Systems that drift usually do so during exactly this transition: a coordinator left, the incoming person did not know the daily review was expected, and three weeks passed before anyone noticed the board was no longer being checked.
How much board access does the system owner need?
Enough to see everything in the current schedule, reassign jobs between technicians, and flag status changes. Administrative access to system settings or billing configuration is a separate question. Giving the system owner the minimum access that lets them do the daily review well reduces risk if the role turns over. A system owner who cannot reassign a job or change a status is not able to act on what they see, which makes the review pointless.
If you are putting a new operations system in place and want to understand how the coordinator role connects to the daily review routine, the program page explains how TRACE 30 structures this across its five install sessions. You can also schedule a call to work through how it maps to your current team.