Dispatch Software for Commercial Kitchen Service Companies

Dispatch is today and scheduling is next week, and products are usually strong at 1 of the 2. A dispatch board is judged on 1 thing: how fast a competent person can rebuild a disrupted afternoon on it, which is not what any demo shows you.

The short version

Scheduling software plans ahead. Dispatch software runs the day, and the day in this trade is interrupted constantly by kitchens going down.

Which means the board is not a calendar. It is an operating surface somebody works on continuously, and the qualities that matter are how much it shows at once and how quickly it can be changed.

Most evaluations judge a board on how it looks when the day is complete. The honest test is how it behaves at 10am when an emergency arrives and three appointments have to move.

3 board designs each hide something different

Design	Strength	Weakness
Timeline by technician	Shows who has room, and gaps are obvious	Geography is invisible
Map with jobs plotted	Shows clustering and who is facing which way	Time and capacity are hard to read
List with filters	Fastest for triage and for finding one job	No sense of the shape of the day

A dispatcher in this trade needs all three during a normal morning, which is why the useful question is not which design a product uses but how quickly it switches between them.

What a commercial kitchen board has to show

Six things, and the first three are records rather than dispatch features.

• The equipment, by manufacturer, model and serial, rather than a symptom at an address
• Its history, so the assignment can favor whoever has seen it
• Where the likely part is, across vans and the store
• The account's response window and any spending limit
• Site service hours, so nobody schedules a fryer job at 12:30
• Real drive times at the hour being assigned

Roopairs holds equipment records with history alongside parts inventory and the dispatch board, which is what puts the first three in front of a dispatcher rather than in somebody's memory.

Most boards show the last two adequately and the first three not at all, which is where a well-reviewed product still produces the wrong assignment most mornings.

The rebuild is the test, not the build

Anybody can arrange a clean morning. The work starts when it breaks.

A kitchen goes down at 10am. Something has to move, a customer has to be told, and the choice is between the nearest technician and the one who knows the equipment.

What a board has to make fast: seeing who can absorb the insertion with least disruption, moving several jobs without re-entering anything, and notifying the affected customers without leaving the screen.

Ask a vendor to do exactly that in a demo. Insert an emergency into a full day, rebuild it, and notify the displaced customers, while you watch. Most demonstrations show a clean build because it is easier, and the rebuild is where products differ.

Awaiting parts is a state, not a gap

The board behavior that separates products built for parts-heavy work.

A job diagnosed and waiting on a special-order compressor is neither open nor finished. On many boards it either sits as active for three weeks or disappears from view entirely.

What it needs: a distinct state, a link to the purchase order so the office can see what is outstanding, and a way for the job to return to the board when the part arrives rather than when somebody remembers.

Roopairs holds purchase orders attached to work orders with parts inventory alongside, which is what makes the waiting state answerable rather than a promise to check with a supplier.

Portal work has to land on the same board

Otherwise you are running two dispatch operations with one set of technicians.

A service company with chain accounts receives work through facilities platforms with their own references, response windows and closeout requirements.

Those jobs use the same vans and the same people as direct work, so splitting them across two boards splits capacity planning and hides the real picture of the day.

What to test: a portal ticket becoming a job carrying its work order number, purchase order number and not-to-exceed limit, appearing alongside direct work rather than in a separate view.

3 problems a better board does not fix

Worth stating, because it is frequently bought to solve these.

Second visits caused by the wrong part or an unfamiliar piece of equipment. Those are records failures presenting at the board, and a better board without better records assigns the wrong person faster.

Not enough technicians. A board makes capacity visible and does not create it, and a service company consistently unable to meet its windows has a staffing decision rather than a software one.

And undefined priority rules. When a portal ticket and a direct customer need the same slot, that is a business decision that should be written down rather than settled by whoever is loudest at 10am.

4 requests test what a demo will not show

1. "Insert an emergency into this full day and rebuild it." The actual job, done in front of you
2. "Show me the equipment, its history and where the likely part is, from the board." Without opening four screens
3. "Show me a job waiting on a part and how it comes back." A state, or a gap
4. "Show me a portal ticket arriving as a job with its references." One board or two

Request one is worth insisting on. It is the only part of the demonstration that resembles a real morning.

At three or four technicians the board becomes the memory

The pain starts around your third or fourth technician.

Below that a dispatcher holds the day in their head and a simple board is enough. Everyone knows the sites, one person knows the parts, and the schedule is rebuilt from memory when it breaks.

Past three or four, that stops working and the board becomes the memory. Which is also the point at which the first three requirements above stop being nice and start deciding whether the assignment is right.

Roopairs runs a product tour where you can see the dispatch board with equipment records, history, parts inventory and portal work on it.

What a kitchen operator says

“My service vendor looks everything up on Roopairs, lets me know the issues, what's already been taken care of and what I need to get taken care of, so I can get my kitchen back up and running in a timely fashion.” — a kitchen operator whose service company runs Roopairs

Also worth reading

• A Dispatch Board When Every Call Is Urgent
• Field Service Scheduling for Commercial Work
• Should I use OEM or non OEM commercial kitchen parts

Frequently asked questions

What is the difference between dispatch and scheduling software?

Scheduling plans ahead and dispatch runs today. Products are usually strong at one of the two, and in this trade the day is interrupted constantly, which makes the dispatch half the one that gets used hardest.

What should a dispatch board show?

The equipment by manufacturer, model and serial, its history, where the likely part is, the account's window and limit, site service hours, and real drive times. Most boards show the last two and not the first three.

How should you test a board in a demo?

Ask the vendor to insert an emergency into a full day, rebuild it, and notify the displaced customers while you watch. Demonstrations show a clean build because it is easier, and the rebuild is where products differ.

Why does awaiting parts need its own state?

Because a job diagnosed and waiting on a special-order component is neither open nor finished. Without a state it either sits active for three weeks or vanishes, and it should return to the board when the part arrives.

Should portal work be on the same board?

Yes. It uses the same vans and people as direct work, so a separate view splits capacity planning and hides the real shape of the day.

What can a better board not fix?

Second visits caused by the wrong part or an unfamiliar piece of equipment, a genuine shortage of technicians, and undefined priority rules. The first is a records problem presenting at the board.