Building control-tower visibility into a restoration dispatch desk.

Most mid-sized restoration companies route jobs through a whiteboard, a dispatcher's memory and one shared Encircle login. The dispatch desk works because the dispatcher has been there for nine years and holds the whole operation in their head. The day they take vacation, the operation runs at 60% of its normal throughput. This is the standard state of dispatch in a $5-25M restoration company, and it is the largest single point of operational risk in the business.

Building control-tower visibility into dispatch is the move that lets the operation scale beyond the dispatcher's memory. It is also the move that lets the operator take a vacation.

The whiteboard model

The whiteboard model of restoration dispatch is built around three artifacts: a magnetic schedule board on the office wall, a shared phone line, and a dispatcher who can quote the current location of any crew from memory. The board shows the day's jobs. The phone takes the inbound calls. The dispatcher patches the two together by knowing who is where.

This model has worked for two decades because the alternatives were worse. Software for restoration dispatch lagged the operational reality, and most tools either added overhead without adding visibility or required so much data entry that the dispatcher abandoned them within a quarter. The whiteboard was honest. It showed the truth and updated in real time. It just did not survive the dispatcher's day off.

Three visibility gaps in dispatch

Three visibility gaps cost a restoration company measurable revenue. The first is real-time crew status. The dispatcher knows the morning schedule but loses track of crew status by mid-afternoon. A crew that finishes a Cat 1 job at 1pm and could pick up an emergency call at 1:15pm is invisible to the desk until they get back to the yard. The company misses the job because the dispatcher does not know the crew is free.

The second is the job pipeline view. Dispatchers can see today's schedule. They struggle to see the three-day or five-day outlook in a way that surfaces capacity tightness early. An operator who knows on Tuesday that Thursday's schedule is going to overflow can pre-position subs or call in part-time techs. An operator who finds out at 7am Thursday eats overtime, declines jobs or misses ETAs.

The third is intake-to-dispatch latency. A call comes into intake. The intake person captures the data. The data sits in a queue until the dispatcher walks over and reads it. The gap between intake completion and dispatch action is somewhere between three and twenty minutes in most operations. Closing that gap is worth two or three percentage points of capture rate.

How control-tower visibility runs

The dispatch desk that has solved this problem has four screens worth of information running at once. The first is a live crew status view: each tech and crew with current location, current job and projected free time. The second is a job pipeline view: open intakes, dispatched but not yet started, in progress, complete but not yet documented. The third is a geographic view: a map of current crew positions overlaid with open jobs awaiting dispatch. The fourth is a queue of inbound intakes with countdown timers showing how long each has been waiting.

None of this requires expensive software. It requires the operator to build the data discipline that feeds these views and the tooling that surfaces them. The companies that have done it have either built it on top of Encircle's API, used a workforce management tool like ServiceTitan, or stitched together a custom view in a tool like Retool sitting on top of their existing systems.

Where humans still belong in dispatch

Even with full visibility, dispatch is not an automation target end to end. Judgment calls remain in three places. The first is how to handle a job that is going to run long: pull a crew off another job, escalate to a sub, or move the next job to tomorrow. The system can present the options. The dispatcher decides. The second is the homeowner conversation when a window slips. This is a relationship conversation that should not be automated. The third is the call to the on-call partner when a crew runs into a situation beyond their scope: a structural concern, a hazardous material question, a refused-entry situation. The dispatcher's instinct here is the actual product.

The control-tower view does not replace the dispatcher. It frees the dispatcher from being the only place the data lives. The dispatcher who used to spend 70% of their day answering "where is crew B" can spend that time on the judgment calls that actually need a human.

The bar for replacing the whiteboard

An operator replacing the whiteboard with software needs to clear three bars. The new view must be more accurate than the whiteboard, not less. The data has to come from systems the field actually updates, not from a separate data-entry workflow. The view must be at least as fast to read as the whiteboard, ideally faster, and the dispatcher should not have to click into anything during a normal day.

Most software products in this space fail one of these bars. The ones that clear all three have been built either by operators-turned-founders or by software teams that embedded with dispatch desks for months before writing a line of code. The companies that find the right tool see dispatch capacity climb 30% to 50% in a quarter without hiring.

The case for moving now

The operators who move on dispatch visibility before they need to are the operators who survive the next storm cycle without quality slipping. The whiteboard model breaks under load. By the time it breaks, the operator is in the storm trying to fix the tool while running the response. Building the control tower in a quiet month is the cheap path. Building it during a storm is not.