Before you replace the dispatch whiteboard, write down everything it does.
Magnets for technicians, columns for the day, a red marker for anything urgent. It looks old-fashioned, and the plan is to replace it with scheduling software. Spend a week noticing what that board quietly does first, or the new system will drop it.
A dispatch whiteboard does more than show the schedule. It gives everyone the day at a glance, holds the dispatcher's knowledge of who suits which job and customer, makes changes take seconds, and is the place the office and the field meet when plans change. Before replacing it with field service scheduling software, spend a week recording what the board does, photographing it through the day and noting every change and why. Then require the new system to keep those jobs (glanceable, fast to change, dispatcher can override) and add what the board can't: customer updates, job history, and status from the field.
The board on the wall
In the office of a small heating and plumbing company, the dispatch board covers most of one wall. Each technician has a column and a magnet with their name. Jobs are written on cards and stuck in time slots. A red marker means urgent. A blue dot means "call the customer first." A card turned sideways means waiting for a part. There's a coffee ring on Wednesday that nobody has cleaned off in months.
The owner wants to replace it. It doesn't work when the dispatcher is out sick, nobody can see it from a van, customers keep calling to ask when the technician will arrive, and there's no record of what happened last month. All fair. Scheduling software would fix every one of those.
But the board is doing more than it looks like. It's been shaped by years of real days, and a lot of what it does isn't written anywhere. The board isn't the schedule. It's where the schedule gets argued about.
So before choosing software, we'd spend a week writing down every job the board quietly does. Here's what that list usually contains.
It shows everyone the whole day at a glance
Stand in the doorway and you can see the day. Who's overloaded, who has a gap after lunch, which jobs are still unassigned, which are urgent. Nobody has to log in, filter, or scroll.
That glance does real work. The office manager notices a gap and fills it with a callback. A technician who drops in for parts sees they're about to get a job across town and says something. The owner walks past and spots a problem in two seconds.
Software that replaces this needs a single view that shows the whole day for everyone, readable from across the room on a big screen. A calendar where you click into each technician one at a time loses something the wall gave you for free.
Decision guide
What the board does, and what the software must do
| Consideration | The whiteboard | What the new system must do |
|---|---|---|
| Whole day at a glance | Visible from the doorway. | One view of everyone, readable on a wall screen. |
| Dispatcher's knowledge | Applied silently while moving cards. | Skills, preferences and notes recorded; overrides in seconds. |
| Changes | Pick up a card and move it. | Drag and drop, as fast, visible to all. |
| Odd conventions | Sideways cards, colored dots. | Statuses and tags, or dropped on purpose. |
| Field updates | Phone calls to the office. | Status from the technician's phone; customer told. |
The board isn't the schedule. It's where the schedule gets argued about.
It holds what the dispatcher knows
The dispatcher doesn't just put jobs into gaps. She knows that one technician is the person to send for old boilers, that another shouldn't go to a particular customer after a disagreement last year, that the new hire needs easier jobs this month, and that a certain office building wants the same person every time because they know the access codes.
None of that is on the board. It's in her head, and the board is where she applies it.
The risk with new software is that it "optimizes" around all of that, assigning by distance and free time alone, and the dispatcher spends her day undoing it. Ask what the system lets you record: skills, preferences, customer notes, who to avoid. And make sure the dispatcher can override any suggestion in seconds without a fight.
This is also the honest answer to "it doesn't work when the dispatcher is out sick." The board works fine. What's missing is her knowledge. Software helps only if some of that knowledge gets written down along the way, in customer notes and technician skills, so the person covering for her on a Monday has more to go on than the magnets.
Our note on riding along for a shift before you design the field app makes the same point from the van's side: watch the work first.
It makes changes take seconds, and handles the odd ones
A job runs long. Someone calls in sick. An emergency comes in at ten. On the board, the dispatcher picks up three cards and moves them. Done in fifteen seconds, and everyone can see what changed.
The odd cases are handled just as fast. The sideways card for "waiting on a part" isn't a feature anyone designed. Someone needed it once, and now everyone understands it. Boards are full of little conventions like that, and each one is a status the business needs.
When you write your list, capture every one of these conventions: colors, dots, sideways cards, sticky notes in the margin. Each needs a home in the new system, as a status, a tag or a note, or someone needs to decide on purpose that it's no longer needed. The same thinking is behind treating the spreadsheet as software that already exists.
It's where the office and the field meet
When a technician calls in, "finished early," "need to come back tomorrow," "customer wants a quote for a new system," the dispatcher updates the board. That makes the board the meeting point between the field and the office.
It's also the board's weakest job, and the place software can help most. Technicians can update status from their phones. Customers can get a message when the technician's on the way. The office can see what happened on each job without a phone call. Job history, photos and parts used can follow the customer.
So the list has two columns: what the board does well and must be kept, and what the board can't do and the new system should add.
How the work moves
A week of noticing
- Photograph the board
A few times a day, every day for a week.
- Narrate the changes
One line per move: what and why.
- Collect the conventions
Every color, symbol and odd placement.
- Log the calls
Who needed what, and whether the board answered it.
- Sort into keep, add, drop
Becomes the requirements and the demo script.
Spend a week noticing
Here's how we'd make the list:
- Photograph the board a few times a day for a week: first thing, mid-morning, after lunch, end of day.
- Ask the dispatcher to narrate changes. Every time something moves, a one-line note of what and why.
- Collect the conventions: every color, symbol and odd placement, with what it means.
- Note the phone calls: who called, what they needed, and whether the board answered it.
- Sit with the result and sort it into "keep," "add," and "drop on purpose."
That list becomes your requirements for any scheduling software you look at, and a script for the demo: show us how we'd do this, and this, and this.
Keep the dispatcher at the center of the choice. She's the person who'll use the new system most, and the person whose day gets worse if it's wrong. If she can run a normal Tuesday in the demo, including the emergency at ten and the sick call, it's worth a trial. If she can't, no feature list will make up for it.
We build business process automation and mobile tools around the way field work actually runs, keeping the judgment of the people who coordinate it. If you're about to take the board down, let's look at it together first.
Related work: WorkStep.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.