§03 / THE WORK

1. 01

   Regional Workflow Mapping and Dispatch Pattern Analysis

   Spent four weeks embedded across seven regional offices observing actual dispatch workflows before committing to any data model or workflow engine design. The most significant finding was that job priority in practice was not a static field set at work order creation — it was continuously renegotiated by dispatchers throughout the day as new urgent jobs arrived, technician availability shifted, and client escalations came in. Any system that treated priority as a set-once attribute would immediately be worked around. The dispatch model was designed around dynamic priority re-evaluation as a first-class operation, not an edge case.

2. 02

   Work Order Lifecycle and SLA Monitoring Engine

   Designed a work order service that models each job as a state machine — raised, triaged, assigned, in-progress, pending-parts, completed, verified — with SLA deadline metadata attached at creation and evaluated continuously by a monitoring service that consumes state transition events. The SLA monitor calculates time-to-breach for every open work order in real time and emits escalation events at configurable threshold intervals before the deadline — allowing dispatchers to act before a breach occurs rather than discovering it afterward. SLA breach events, when they do occur, are written to the audit log with the full assignment history of the work order, enabling root cause attribution to be produced immediately rather than reconstructed days later.

3. 03

   Parts Reservation and Inventory Lifecycle

   Parts inventory is modelled as an event stream rather than a mutable quantity record. When a work order is dispatched, the required parts are reserved against the work order record, reducing available stock immediately — before the technician physically collects them. Reservations that are not fulfilled within a configurable window (technician did not collect; job was cancelled) are automatically released back to available stock and surfaced as an exception. Parts collection and consumption are recorded as events by the technician through the mobile application at the moment of collection and use, making the inventory position accurate to within minutes rather than hours. Low-stock alerts are derived from the event stream and routed to the regional parts coordinator role with a lead time calculated from the average procurement cycle for that part.

4. 04

   Asset Service History and Preventive Maintenance Scheduling

   A canonical asset registry was designed to accumulate every work order — reactive and preventive — against a persistent asset identifier that survives technician and dispatcher turnover. Each asset record holds a complete event-sourced service history: every job raised against it, every part replaced, every fault category recorded, and every technician who worked on it. Preventive maintenance schedules are defined per asset class and per contract, generating scheduled work orders automatically at the configured interval. The maintenance schedule engine tracks whether scheduled jobs are completed within their service window and flags overdue preventive maintenance as a compliance exception before it becomes a client-reportable failure.

5. 05

   Technician Mobile Application with Offline Job Management

   Field technicians operate in environments with inconsistent connectivity — plant rooms, basement plant spaces, and remote sites regularly have no signal. The technician mobile application runs a local job state cache that holds the technician's assigned jobs, asset details, required parts list, and job history access for the current shift. Job status updates, parts consumption records, fault categorizations, and completion sign-offs are written to a local queue and synchronized to the central platform on reconnection. The synchronization is idempotent: if a technician's device submits the same completion event twice due to a partial sync, the second submission is deduplicated at the ingestion layer without creating a duplicate job record.

6. 06

   Client-Facing SLA Reporting and Contract Visibility

   Client SLA reports were previously assembled manually from regional exports once a month, delivered as PDF attachments with no self-service access for clients. The proposed reporting layer maintains per-contract SLA performance models updated continuously from the work order event stream, enabling client-facing report generation at any cadence — daily, weekly, or on-demand — without manual assembly. Reports cover response time compliance, resolution time compliance, first-time fix rate, repeat fault rate by asset, and open work order aging. The reporting layer is physically separated from the transactional path, ensuring that client reporting queries do not affect dispatch performance during operational hours.

§06 / ARCHITECTURAL DECISIONS

1. 01

   Why Kafka for the Event Bus

   Field service operations produce events from three independent sources at different frequencies and latency tolerances: dispatcher-initiated work order transitions (low frequency, moderate latency tolerance), technician mobile app events (moderate frequency, low latency tolerance during sync windows), and SLA monitoring heartbeats (high frequency, must not affect transactional path). Kafka's consumer group isolation allows these workloads to consume from the same event stream at their own pace without coupling. The durable log enables the SLA monitor to replay the full work order history for any contract when recalculating compliance figures, and allows the analytical store to be rebuilt from scratch without re-ingestion from source systems.

2. 02

   Why Event Sourcing for Work Orders and Inventory

   Both work orders and parts inventory have the same fundamental auditability requirement: it is not sufficient to know the current state; the full history of how that state was reached must be reconstructible for client dispute resolution, SLA root cause analysis, and regulatory inspection. A mutable record with update-in-place semantics cannot answer the question 'what was the inventory position at 14:23 on the day Job X was dispatched?' An event-sourced model answers it directly by replaying events to that timestamp.

3. 03

   Why Regional Dispatcher Nodes Rather Than Centralized Only

   Dispatch operations cannot tolerate the latency and availability risk of a WAN dependency on the critical path. A dispatcher assigning a technician to an urgent job must receive confirmation in under a second; a central data centre round-trip under variable WAN conditions cannot guarantee this. Regional nodes handle read and write operations against a local store, with asynchronous propagation to the central broker. The dispatch experience is always fast and always available; central visibility is eventually consistent with a bounded, observable lag.

4. 04

   Why Parts Reservation Before Physical Collection

   Reserving parts at dispatch time rather than at physical collection time shifts the inventory commitment from an untracked informal act to a system-recorded event tied to a specific work order. This enables the inventory position to reflect committed stock before it physically moves, preventing the concurrent collection conflict that caused stockouts. It also enables the parts coordinator to see which reservations are pending collection and which have been outstanding long enough to suspect cancellation — information that was entirely invisible in the spreadsheet model.

5. 05

   Why Continuous SLA Monitoring Rather Than Deadline Checking

   A system that checks whether a deadline has been breached after the fact produces a compliance record. A system that continuously evaluates time-to-breach for every open work order and emits threshold alerts before the deadline produces operational interventions. The difference is not a feature distinction — it is an architectural choice about when the system acts. Continuous monitoring requires the SLA service to maintain a live computation over all open work orders, which drove the decision to project work order state into a Redis-backed deadline priority queue rather than scanning the PostgreSQL work order table on a polling interval.

§08 / IMPACT

1. 01

   SLA Breaches Detectable Before They Occur

   SLA compliance monitoring previously produced a historical record of failures discovered during monthly reporting. Continuous SLA monitoring targeting pre-breach alerts at configurable thresholds — 75% and 90% of deadline elapsed — converts breach detection from a retrospective audit into a real-time dispatch signal. Dispatchers are notified in time to act; the breach class that was previously undetectable until after its contractual consequence becomes operationally preventable.

2. 02

   Parts Stockouts During Active Jobs Eliminated

   Parts stockouts mid-job were a direct consequence of the absence of a reservation mechanism — available stock was visible, but committed stock was not. Structural parts reservation at dispatch time, before physical collection, makes the committed inventory position visible and prevents concurrent allocation of the same stock to two jobs. The stockout class caused by concurrent untracked collection is architecturally eliminated rather than operationally managed.

3. 03

   Asset Service History Becomes a Canonical Operational Record

   Previously, an asset's maintenance history was distributed across whichever regional spreadsheets had managed jobs against that site, inaccessible to technicians in the field and unqueryable for trend analysis. A canonical per-asset event log accumulating every job, fault category, and parts replacement produces a service history that technicians can access before arriving on site, that clients can receive in contract reports, and that the organization can mine for repeat fault patterns indicating assets approaching replacement threshold.

4. 04

   Client SLA Reporting Converted from Manual Assembly to On-Demand

   Monthly SLA reports previously required two days of manual data assembly from regional exports. The continuously updated analytical SLA models enable on-demand report generation at any granularity — per contract, per site, per asset class, per time period — without manual intervention. Clients can receive weekly reports at no additional operational cost. The reporting lag that allowed contractual consequences to accumulate undetected is removed.

5. 05

   FSM Licensing Eliminated at Scale

   Per-technician licensing made the cost trajectory to 60 regions economically indefensible. The purpose-built platform eliminates per-technician and per-region licensing entirely, with infrastructure costs scaling sub-linearly with operational volume. The compounding licensing savings at 60-region scale represent a material financial outcome of the transformation program, independent of the operational improvements.

§10/ SECURITY & GOVERNANCE