K · 01 / Platform age modernised21 years
2005 → 2025
↗ A two-decade-old operational backbone rebuilt for maintainability and scale.
Case study · field service modernisation
From a 2005 monolith
to a modern field service platform — built for glass replacement in motion.
A on-the-road automotive glass replacement business, where every job depends on the right part, technician, appointment window, insurance status, and live field context. In 2025, its legacy platform was fully overhauled into a modular, API-driven system for inventory, scheduling, insurance verification, GPS-aware dispatch, and end-to-end job management.
case · transformation metrics
legacy vs 2025 platform
K · 02 / Dispatch modelreal time
GPS-aware
↗ Static scheduling replaced by live technician visibility and route-aware decisions.
K · 03 / User experience
Step-by-step
Overloaded legacy forms became guided workflows by role and task.
K · 04 / Workflow state
Automated
Manual checks and handoffs were converted into structured real-time workflow events.
K · 05 / Architecture
API-driven
Fragmented integrations were consolidated into a cleaner platform integration layer.
§ 01 / The problem
The platform had become the operation —
and the operation had outgrown the platform.
The company's legacy system carried the business for years, but it reflected the assumptions of 2005: desktop-first workflows, centralised coordination, limited real-time data, and forms that exposed system complexity instead of guiding users through decisions.
stack · before
▸ legacy constrained
Customer and job records
Auto glass inventory
Appointment scheduling
Insurance checks
Claims workflows
Dispatcher coordination
Limited field visibility
Operational reporting
↳ one monolithic system · overloaded forms · fragmented integrations · manual operational interpretation
P · 01
Complex forms slowed down the front line
Large screens exposed too much at once. Users needed to know which fields mattered, which sequence to follow, and which hidden rules affected downstream work.
P · 02
Scheduling was too static for mobile work
Technician availability, travel time, job duration, cancellations, and emergency changes all affect the day. The old model could schedule appointments, but not respond intelligently to live field conditions.
P · 03
Inventory and scheduling were not connected enough
For glass replacement, the wrong part or unavailable stock can break the appointment. Inventory decisions needed to be tied directly to booking, dispatch, and job readiness.
P · 04
Insurance and claims created operational drag
Coverage verification and claim-related workflows required accuracy and traceability, but too much of the process relied on manual checking, disconnected systems, and exception handling.
§ 02 / The solution
A full platform overhaul.
Modular by design.
Operational by default.
The transformation did not recreate the legacy system screen by screen. It redesigned the operating model around real field service journeys: customer intake, vehicle and glass identification, stock reservation, insurance verification, appointment planning, technician dispatch, live job updates, and claims progression.
Phase 01 / Map the operation
Workflow redesign
The first phase separated true business complexity from accidental system complexity. Every major user journey was mapped around who needed to decide, what data was required, and which workflow state should trigger the next action.
01Customer intake and job creation mapped from first contact to completion.
02Vehicle and glass part selection connected to inventory readiness.
03Insurance and claims steps structured as traceable workflow states.
04Dispatcher and technician journeys redesigned around live field context.
Outcome → process model defined before platform modules were rebuilt
Phase 02 / Rebuild the platform
Modular field service system
The legacy monolith was replaced with a modular architecture where customer jobs, stock, scheduling, dispatch, GPS, insurance, and claims all operate as connected platform domains rather than tightly coupled legacy screens.
Customer/job management
Inventory management
Appointment scheduling
Technician dispatch
GPS tracking
Insurance verification
Claims integration
Unified API layer
Outcome → one connected platform for inventory, scheduling, claims, GPS tracking, and dispatch
↪ The operational lever · dynamic dispatch
Static schedules became a live field view. Dispatchers can now act on what is happening, not only what was planned.
The modern platform gives dispatchers live visibility into technician location, job progress, appointment windows, and operational exceptions. It helps the business match the right technician, the right part, and the right appointment with far less manual coordination.
dispatch · live
TechnicianNorth Dublin · active
Current jobWindscreen replacement · in progress
Next window13:30–15:00 · route feasible
Part statusReserved · van stock confirmed
GPS + stock + appointment state → dispatcher decision support
§ 03 / The results
A field operation with live context.
Not just newer screens.
The 2025 overhaul changed how work moves through the business. Jobs are easier to create, schedule, track, and complete. Dispatch has better live context. Insurance and claims workflows are more structured. Inventory is connected to appointment readiness. Technicians are more visible in the field.
R · 01
Faster, clearer job handling
Step-by-step workflows reduce the mental load on customer service and operations users. The platform now guides the job forward instead of exposing every legacy field at once.
Guided UX
R · 02
Better dispatch decisions
GPS-aware dispatching gives operational teams live visibility into technician movement, job status, and appointment feasibility.
Live field view
R · 03
Stronger inventory control
Stock availability and glass part readiness are connected directly to the appointment and job workflow, reducing avoidable scheduling risk.
Stock-aware
R · 04
Cleaner insurance and claims handling
Coverage verification and claims-related steps are more structured, traceable, and visible inside the operational workflow.
Traceable
R · 05
A platform ready for future change
The modular architecture gives the business a foundation that can evolve without reopening the constraints of the old monolith.
Modular
The goal was not to rebuild the old system screen by screen. The goal was to redesign the operation around real-time field service.
§ 04 / What we shipped
The full systems
inventory.
Each module is a first-class part of the platform, connected by shared job data, role-based access, auditability, and API-driven integrations.
#
Module
Type
What it does
T · 01
Field service core
custom
The central job engine for customer, vehicle, appointment, technician, status, and audit data.
T · 02
Customer and job management
custom
A unified workspace for customer details, vehicle context, service requirement, insurance status, appointment, technician, and job history.
T · 03
Vehicle and glass part matching
custom
Supports accurate selection of the required automotive glass part and connects that choice to stock availability and job readiness.
T · 04
Inventory management
custom
Tracks availability, supports reservation against jobs, and flags stock constraints before appointment confirmation.
T · 05
Appointment scheduling
custom
Manages appointment windows around customer availability, technician capacity, part readiness, and operational constraints.
T · 06
GPS-aware technician dispatch
custom
Shows technician location and job progress so dispatchers can react to delays, cancellations, and route realities.
T · 07
Technician field workflow
custom
Focuses technician interactions on assigned jobs, location, part context, status updates, and completion steps.
T · 08
Insurance coverage verification
integrated
Structures eligibility checks, exception handling, and coverage status inside the job workflow.
T · 09
Claims integration
integrated
Connects job data with claims workflows, reducing duplicate entry and improving traceability.
T · 10
API and integration layer
platform
Standardises data exchange across insurance, claims, inventory, GPS, notifications, and operational events.
T · 11
Operational dashboards
visibility layer
Surfaces job status, scheduling load, exceptions, technician progress, and operational performance for managers and dispatchers.
↪ Eleven platform capabilities, one operational source of truth. The system now reflects how field service actually moves.
§ 05 / The arc
From legacy constraint
to live platform.
M · 00
Legacy assessment
The 2005 system was reviewed across workflows, screens, integrations, data structures, and user roles.
M · 01
Workflow redesign
The operating model was mapped around real field service journeys, from customer intake to claims progression.
M · 02
Platform architecture
The modular architecture was defined around shared job data, API boundaries, role-based access, and audit history.
M · 03
UX and core build
Complex forms were converted into guided flows while core modules were rebuilt around jobs, stock, scheduling, and dispatch.
M · 04
Integrations and rollout
Insurance, claims, GPS, inventory, and operational events were connected through the new integration layer and transitioned into live use.
For field service operations that cannot afford system drag
Still running mobile work
on software from another era?
If your business depends on dispatch, mobile teams, inventory, claims, scheduling, and customer communication, the system underneath matters. A modern field service platform gives the operation a live nervous system: the right part, the right technician, the right appointment, and the right job state — all in one connected workflow.