Scheduling the Crew, and What They See on Site

A calendar tells you what is already booked. It will not tell you whether the foam crew has room on the 9th, and it will not tell you that you moved a job on Tuesday and never told the guys who are driving to the old address on Wednesday. Those are the two failures worth fixing.

What you actually do

1. 1
   Put the job on a crewDrag it onto the board, or assign it from the job. The bar covers the days it takes.
2. 2
   Tell themOne button. It sends the plan and records what you sent, so the schedule and the crew agree.
3. 3
   They see their weekOn their own phone: the address, the scope, and directions in one tap.
4. 4
   They work itPhotos, checklists, and a way to report a problem that reaches the office as a record.
5. 5
   Anything moves, tell them againThe job flags itself as stale until you do. That is the one that costs a day.

The dispatch board

Every crew, every day, with jobs drawn as bars spanning the days they actually take. A three-day pour looks like three days, not like a dot on a Tuesday.

That is the difference between this and a calendar, and it is the reason a calendar cannot answer a scheduling question. A calendar shows a job as an event on the day it starts. A board shows it taking up the days it is going to take, which is what you need to see before you promise somebody the 9th.

Double bookings show in red rather than being blocked, because a dispatcher sometimes means it: a half-day punch list on top of a small job is a real thing people do. The software’s job is to make sure nobody does it by accident. And the open-slot finder answers "can we take this on the 9th" without anybody counting squares.

Telling the crew is a button, and it records what you told them. Move the dates afterward and the job reads as stale on the worklist until somebody tells them again.

That is the failure worth designing for. Almost nobody forgets to dispatch a job in the first place. It is the change three days later that never reaches the truck, and the crew that shows up on the wrong day to a lot with nothing on it.

The crew’s own week

The crew screen shows the work and nothing else: today, then the rest of the week, with the address, the scope, and tap-to-navigate straight into their maps app.

A crew member needs a name and a cell number to be on a crew. A login is optional, because most of them will never want one, and a system that requires one before it will schedule anybody is a system that stops matching who is actually on the truck.

For the crew seat it defaults to Spanish. Most field crews in this market read Spanish first, and everything else in this product is written for the office. Anybody can switch their own phone to English in two taps: the person reading it outranks the setting somebody else picked for them.

On site

Photos are captured against the job in one tap. The app files them by GPS when it is confident, and asks when it is not, because two houses fifteen feet apart on the same street is not a guess worth making silently.

Checklists can require a photo count, and that requirement is real: the item does not close without the shots. When something is wrong, the crew standing on the problem files a report. It reaches the office as a record instead of as a text message at 6:40am, and the office can price it into a change order with the crew’s own words carried into it.

Photos taken with no signal do not disappear. They are written to the phone before anything is sent, and they upload when the phone finds a bar. A basement in a new build has no service, and that is not an edge case. It is Tuesday.

Every screen on this page is the software running, captured from a demo workspace. The builders, addresses and contacts in it are invented; the plan is one we drew. More at Opulence Built.