Dispatch and Scheduling in BastionGlass: Real-Time Job Management

The Dispatch Problem for Mobile Services

Mobile auto glass repair has a scheduling problem that shop-based businesses do not face. When a customer comes to your shop, you control the timing — you schedule them into available slots on your calendar. When you go to the customer, geography enters the equation. A technician cannot be in McKinney at 9 AM and Mesquite at 9:30 AM because those cities are 45 minutes apart. Drive time between jobs is not optional overhead — it is a hard constraint on how many jobs a technician can complete in a day.

Chris was managing dispatch through text messages and mental math. For a single-technician operation, this worked — he knew where he was and could estimate whether he could make the next job on time. But as the business grew and the plan to add technicians materialized, text-message dispatch would not scale. BastionGlass needed a scheduling system that understood geography.

Calendar-Based Scheduling With Geographic Constraints

The scheduling system in BastionGlass is built around a calendar view that displays jobs as time blocks on each technician's daily schedule. This is familiar territory — every scheduling system uses a calendar. The difference is how jobs get placed on that calendar.

When a dispatcher creates a new job, the system does not simply check whether the time slot is open. It checks whether the time slot is reachable given the technician's prior job location and the estimated travel time between them. A job in Frisco at 2 PM is only valid if the technician's 12 PM job in Plano will be complete — including the estimated job duration and the drive time from Plano to Frisco.

Travel time estimation uses the Google Maps Distance Matrix API. When a job is being scheduled, the system queries the estimated drive time from the technician's preceding job to the new job's location. If the gap between the end of the previous job (including drive time) and the start of the proposed job is negative, the system flags a scheduling conflict.

This is not full route optimization — we are not solving the traveling salesman problem. That level of optimization is valuable for businesses with fleets of twenty technicians covering large territories, but it is over-engineered for a shop with two to five technicians in a single metro area. What we needed was conflict detection: do not let the dispatcher create a schedule that is physically impossible.

Job State Machine

Each job in BastionGlass follows a state machine with defined transitions. The states are: Quoted, Scheduled, En Route, In Progress, Completed, and Invoiced. Each transition triggers specific actions.

When a job moves from Quoted to Scheduled, the system assigns a technician and time slot, checks for geographic conflicts, and sends a confirmation to the customer. When the technician marks a job as En Route, the customer receives an ETA notification. When the job moves to In Progress, a timer starts for labor tracking. When it moves to Completed, the system generates an invoice based on the approved quote and collects the customer's signature on a digital work order.

The state machine enforces business rules that would otherwise depend on the technician remembering the process. You cannot complete a job without uploading before-and-after photos. You cannot invoice a job that was not completed. You cannot schedule a job that does not have an approved quote. These constraints keep the data clean and the workflow consistent, even when the technician is standing in a parking lot rushing between jobs.

State transitions are logged as an audit trail. Every transition records who triggered it, when, and from what state. This audit trail is essential for insurance claim disputes — when an insurance company questions whether a job was completed on a certain date, the timestamped state transitions provide evidence.

Real-Time Visibility

For the shop owner or office manager, the dispatch board provides a real-time view of all technicians and their current job status. The board shows each technician as a column with their day's schedule as a timeline. Color coding indicates job status — blue for scheduled, yellow for en route, green for in progress, gray for completed.

The board updates in real-time using server-sent events. When a technician updates a job status from their mobile device, the change propagates to the dispatch board within seconds. This allows the dispatcher to monitor field operations without calling each technician for status updates — a significant time savings when managing multiple technicians.

We considered WebSockets for real-time updates but chose server-sent events for simplicity. The communication is unidirectional — the server pushes updates to the dashboard client. The technician's mobile interface communicates through standard API calls. SSE is simpler to implement, works through most firewalls and proxies without configuration, and reconnects automatically if the connection drops. For this use case, the simplicity was worth the trade-off of not having bidirectional communication.

Lessons From Field Service Scheduling

The biggest lesson from building dispatch and scheduling was that the system's value is proportional to how easy it is to use in the field. Technicians are not sitting at desks — they are in parking lots with greasy hands using their phones. Every interaction needs to be achievable in two taps. If updating a job status requires navigating three menus and filling in a form, it will not happen consistently.

We optimized the technician's mobile interface ruthlessly. The home screen shows the next job with a single button to mark it as en route. The job detail screen has large, obvious buttons for each state transition. Photo uploads use the camera directly rather than a file picker. The interface assumes the user has five seconds of attention between tasks, and it respects that constraint.

The payment processing integration follows the same principle — collecting payment should be one tap from the job completion screen, not a separate workflow that requires logging into a different system.