Dispatch with your eyes open: crew, asset and job state in one view.
GA Applications designs fleet and field operations dashboards from approved job, crew, asset, inspection and location data. Dispatch, readiness and response are visible together, scheduled state is never confused with reported or confirmed state, location is proportionate and permission-aware, and every exception has an event-to-field action path.
Field operations live or die on the gap between what the schedule says and what is actually happening. This direction closes that gap visibly — without turning a coordination tool into a surveillance system.
Demonstration uses fictional crews, jobs and locations. Real builds show only data your policies approve.
Dispatch board — today
Interface demonstration — fictional data| Crew | Job | Window | State | Readiness |
|---|---|---|---|---|
| Crew A | Winery pump install | 07:30–12:00 | CNF | ●Ready |
| Crew B | Depot lighting refit | 08:00–15:00 | RPT | ▲1 item short |
| Crew C | School hall AV rigging | 13:00–17:00 | SCH | ■Vehicle check overdue |
| Crew D | Farm workshop wiring | — | BLK | ◐Parts 3d late |
- Location resolution
- CNF means
- RPT means
Built for the gap between the schedule and the truth
This direction serves dispatchers, field-service leaders, fleet coordinators and the operations managers above them. Its decisions are minute-by-minute: Can Crew C take the afternoon job given their vehicle check is overdue? Do we tell the school we are unconfirmed for 13:00? Is Crew B's 'started' a phone call or a verified arrival? Each answer depends on keeping three states — scheduled, reported, confirmed — visibly separate, because a dispatch board that blurs them manufactures confidence nobody has.
The target operating outcome: coordinators who act from verified state at 9am instead of discovering the plan-versus-actual gap at the afternoon debrief — with privacy boundaries that make the tool defensible to the crews it coordinates.
State honesty and readiness, side by side
Scheduled ≠ reported ≠ confirmed
Scheduled is the plan. Reported is a signal from the field — a phone update, a form, a device sync. Confirmed means a second signal or a responsible person has verified it. The board draws these as different cells with different labels (SCH / RPT / CNF), and nothing promotes itself silently: a phone call stays RPT until a verification rule is met. When a crew's coverage drops out, their state freezes at last-known and ages visibly — a stale cell, not a guessed one.
Readiness is a gate, not a vibe
Readiness combines the approved inputs you define: vehicle and asset checks current, required competencies held, parts picked, access confirmed. A crew can be scheduled and keen and still not ready — the board says which item blocks them and who is chasing it. GA Applications designs the software and integration layer here; inspection competence and any statutory sign-off remain with the qualified people who do that work.
Event-to-field action
Every exception opens an action path with context attached: reassign the job, reschedule the window, order the part, notify the customer — executed in the systems you already use, by a person. The dashboard routes; it does not command. Safety-critical control of vehicles or equipment is out of scope for a visibility layer and belongs in engineered control systems with their own assurance.
Privacy-aware location module
Interface demonstration — fictional data- What is shown
- What is not shown
- Who can see traces
- Retention
- Worker notice
Location earns its place by answering a coordination question — "did they arrive?" — not by enabling surveillance. Proportionality is a design requirement, not a setting.
Definitions this view typically carries
Confirmed arrival
Field-app sync within the job window plus geo-proximity to the job site, or manual verification by the dispatcher. A phone call alone is 'reported', not confirmed.
Crew readiness
All gate items current: vehicle/asset checks, competencies, parts, access. One expired item = not ready, with the blocking item named.
Response time (exception)
Minutes from exception raised to a recorded dispatcher response. Measures the coordination loop, not the crew — crews are never ranked on visibility data.
Check currency
Days until next due inspection or service per vehicle/asset. Overdue items are alert-styled and block readiness; unknown dates are shown as unknown, never as current.
Approved inputs only — and honest gaps when coverage drops
Approved sources
- Job system: windows, sites, status
- Field app: syncs, forms, photos
- Asset register: checks, faults
- Roster: crews, competencies
Governed layer
- State rules: SCH → RPT → CNF
- Location policy P-04: resolution, retention, access
- Readiness gates v1.0
- Refresh: 5 min ops sources, hourly register
Views
- Dispatcher board
- Field worker: own day queue
- Manager: exceptions & response
- Customer comms context (manual)
Field connectivity is treated as unreliable by design. The capture side queues updates offline and syncs with original timestamps; the board shows the gap as a stale period rather than backfilling it with guesses. If the field app feed stops entirely, affected crews drop to unknown state with an alert to the dispatcher — a quiet map is treated as a failure, not as calm. Only data your policies approve enters this pipeline: the source profile step documents each input, its authority, its resolution and its retention before anything is built.
What we need from you, and how delivery runs
Inputs
- Read access to job, roster and asset systems, subject to interface review
- Your readiness gate list and your state-verification rules
- Your location policy — resolution, retention, who sees what — or help drafting one
- The dispatcher and field-service leader who will pilot the board
Delivery & acceptance
- Decision workshop → source profile (including privacy review of location inputs)
- Prototype against one real week's dispatch
- Reconcile state rules against what actually happened — SCH/RPT/CNF verified by the dispatcher
- Pilot with one region or crew group alongside current practice
- Acceptance: states never blur; offline gaps shown honestly; location resolution matches policy; readiness gates verified; exception response path tested; table equivalents and keyboard access pass
Right fit
- Crews, vehicles and jobs are coordinated daily by a dispatcher
- Plan-versus-actual gaps are discovered late and expensively
- You want coordination visibility with defensible privacy boundaries
Wrong fit
- You want continuous movement tracking of staff (we do not build that)
- You want automated control of vehicles or plant from a dashboard
- There is no field capture habit or device workflow to build on yet
Related directions and services
Frequently asked questions
Does this track our people?
It shows what your approved policies allow — no more. Location can be presented at job-site, region or last-known level rather than continuous traces, retention is limited, and workers should know what is collected and why. Monitoring visibility, recommendation and control are deliberately different things, and the design keeps them separate.
What is the difference between scheduled, reported and confirmed?
Scheduled is what the plan says. Reported is what someone or something has sent back — a crew update, a form, a device ping. Confirmed means a second signal or a responsible person has verified it. A dashboard that blurs these three invents certainty; this design keeps them visually distinct at all times.
Can the dashboard trigger actions in the field?
It can route an exception to a coordinator with the context to act — reassign a crew, order a part, notify a customer — through the systems you already use. Safety-critical control commands are out of scope for a visibility layer and belong in engineered control systems with their own assurance.
What asset and inspection data can be included?
Anything your systems authoritatively hold: registration and inspection due dates, reported faults, readiness flags, custody assignments. Each item shows its source and age, and overdue or unknown states are styled so they cannot be overlooked or mistaken for compliant.
What happens when coverage drops out in the field?
Updates queue on the device or gateway and sync when connectivity returns; the dashboard shows the gap honestly as a stale period rather than filling it with guesses. Offline behaviour of the capture side is designed as part of the field workflow, not assumed away.
What did your schedule say at 7am — and what was true by 9?
Describe how dispatch reaches your crews today and where the plan-versus-actual gap hurts most. We will scope a view that shows state honestly, respects your privacy obligations and gives coordinators a clear action path for every exception.