The most common question a service advisor answers is whether a car is ready, and the most common reason it gets asked is that nobody told the owner. The client's dealer network held job status in its workshop system and shared it only when someone called. ELIVTECH built a Flutter app over that existing CodeIgniter platform so owners see job progress, approve additional work and book service without the phone call being the interface.
The client operates a nationwide dealer network running sales and aftersales on a CodeIgniter platform built over many years. Service was booked by telephone against paper diaries that differed by dealership, so availability could not be seen and double bookings were routine. Once a vehicle was in the workshop the owner had no visibility, and any additional work discovered during inspection required a phone conversation that often delayed the job for hours. Service history followed the dealership rather than the vehicle. ELIVTECH delivered a Flutter application for owners covering booking, live job status, additional work approval, service history and roadside assistance, built against a versioned API over the existing platform rather than a parallel system.
At a glance
The challenge
A network holding all the information owners wanted, and no way to give it to them.
Booking by telephone against paper diaries
Owners called during working hours and an advisor checked a diary that only that dealership held. Availability could not be seen, slots were double booked when two advisors wrote at once, and anyone whose own working hours matched the dealership's had no practical way to arrange a service.
No visibility once the car was in
The workshop knew where a job had reached and the owner did not. People called for updates, advisors left the counter to check, and the interruption slowed the technicians being asked. The information existed and was simply never routed to the person waiting for it.
Additional work waiting on a phone call
When inspection found work beyond the booked service, the job stopped until an advisor reached the owner and explained it verbally. Approval was recorded as a note, the vehicle sat on a ramp meanwhile, and disputes about what had been agreed had nothing but recollection to settle them.
Service history tied to the dealership
Each dealership held the records for work it had performed. An owner who moved, or who used a different dealership while travelling, arrived without history, and the network could not present a single view of a vehicle's maintenance even though every record sat on the same platform.
Service reminders sent on a fixed schedule
Reminders went out at set intervals regardless of how much the vehicle had actually been driven. Owners covering high mileage were reminded too late and those driving rarely were reminded too often, so the messages were widely ignored and the network lost contact between visits.
Warranty claims assembled by hand
Establishing whether a repair fell under warranty meant checking purchase date, mileage, service adherence and previous claims across separate screens. The work was repeated for every claim, and inconsistent judgements caused rework when submissions were later challenged.
Our solution
Expose what the workshop already knows, at the moment it becomes true, to the person waiting on it.
Journey Mapping and Status Modelling
Three weeks in dealerships following a service from booking to handover, establishing which internal job-card states are meaningful to an owner and which are workshop detail. Exposing every state would have produced noise, so eight owner-facing states were defined and mapped onto the platform's existing job card without changing how technicians work.
Versioned API Over the Existing Platform
Rather than a parallel service system, a versioned API was built over the existing CodeIgniter platform, with characterisation tests written around the job-card logic before it was extended. Bookings, approvals and status all read and write the same records dealership staff already use, so there is one source of truth and no reconciliation between systems.
Flutter App with Booking and Live Job Status
One Flutter codebase serves both platforms. Owners see real availability across the network rather than one dealership's diary, book against a capacity model that accounts for bay and technician availability, and follow job progress as the workshop updates it. Push notifications carry the milestones that matter instead of every internal transition, so an owner learns that a vehicle is ready or that a decision is needed without being told each time a technician updates a line on the job card.
In-App Approval, History and Warranty
Additional work is sent to the owner with photographs, an itemised description and a revised completion estimate, and approval is recorded against the job card with a timestamp. Service history follows the vehicle across the network, mileage-aware reminders replace the fixed schedule, and warranty eligibility is evaluated from platform data rather than assembled manually. Advisors raise approval requests from the same job card they already work in, so the app adds a channel to their workflow rather than a second place to keep updated.
Technology stack
Results
Measured once the app was live across the dealer network.
Before and after: platform engineering measures
- Service booked by telephone against a dealership paper diary
- Availability invisible, with double bookings a routine occurrence
- No owner visibility once the vehicle entered the workshop
- Additional work stalled until an advisor reached the owner
- Approvals recorded as a written note on the job card
- Service history held by the dealership that performed the work
- Reminders sent on fixed intervals regardless of mileage
- Booking against real network-wide availability at any hour
- Capacity model accounting for bay and technician availability
- Eight owner-facing job states visible as the workshop updates them
- Additional work sent with photographs and an itemised description
- Approval timestamped against the job card as a durable record
- Service history following the vehicle across the whole network
- Mileage-aware reminders replacing the fixed schedule
Project timeline
Journey Mapping and Status Modelling
Dealership observation from booking to handover, owner-facing state definition against internal job-card states, service capacity modelling, and the API contract over the existing CodeIgniter platform.
API Layer and Platform Extension
Characterisation tests around existing job-card logic, versioned REST API, network-wide capacity and booking model, vehicle-centric history consolidation, AWS infrastructure in Terraform, and the release pipeline.
Owner Application
Flutter booking flow against live availability, live job status with milestone push notifications, additional work approval with photographs and itemised detail, service history, and roadside assistance request handling.
Warranty, Reminders and Dealer Tools
Warranty eligibility evaluation from platform data, mileage-aware reminder scheduling, advisor tooling for raising approval requests, consent and retention handling for owner data, and accessibility work on the booking journey.
Pilot and Network Rollout
Pilot at a representative dealership group, device range testing, load testing on morning booking peaks, monitoring on status propagation and approval turnaround, then rollout by region with telephone booking retained throughout.
Key takeaways
What shaped the engineering decisions
- Extend the platform, do not build beside it: A separate service booking system was rejected because it would have created a second diary to reconcile. Building a versioned API over the existing job card kept one source of truth for dealership staff and owners alike.
- Translate internal states, do not expose them: Showing every workshop transition would have been noise, and showing too few would have recreated the phone call. Defining eight owner-facing states preserved meaningful visibility without altering how technicians record work.
- Make approval a record, not a conversation: Verbal approval noted on a job card leaves disputes unresolvable. Sending photographs and itemised detail, then timestamping the response, gave both the owner and the dealership the same durable evidence.
- Model capacity, not slots: A booking system offering fixed slots would repeat the diary's failure. Accounting for bay availability, technician skill and job duration meant an offered appointment is one the workshop can genuinely deliver.
- Attach history to the vehicle: Records held per dealership fragmented something the network already owned collectively. Consolidating history against the vehicle made it useful to any dealership the owner visits and to warranty assessment.
- Pin legacy behaviour with tests first: Characterisation tests around existing job-card logic were written before extending it, so behaviour the dealer network depended on was captured before anything new was layered on top.
Want results like these?
Let's discuss how ELIVTECH can drive measurable outcomes for your business.
Start your project