Automotive services
Automotive service business website
A service business website where the work is making an unfamiliar price list legible enough that a customer will pick a service and call.
Interface built in code for this case study — not a client screen capture.
01Business problem
Vehicle care is sold in terms customers do not know. Someone wanting their car to look new again does not know whether that is polishing, ceramic coating or paint correction, and a price list organised by treatment name does not tell them.
Who feels it
The vocabulary gap is the whole problem. A detailing business has genuinely distinct services with different processes, durations and prices. A customer has an outcome in mind and a rough budget. Between those two sits a list of terms — buffing, correction, coating, sealant — that all sound like the same thing to anyone outside the trade, which means the customer either asks for the cheapest thing or asks nothing.
What actually happens is a phone call that starts with the owner explaining the difference between three services. That is a fine conversation to have once; having it before every booking is the business paying for its own website not doing its job.
There is also a trust question that a service business cannot avoid. Somebody is leaving a vehicle worth several months of income with a stranger. Photographs of finished work, visible location, a real phone number and an actual name matter more here than any amount of design polish, and a site full of stock images of other people’s cars actively undermines it.
02Product overview
Services grouped by the outcome a customer is after rather than by treatment name, each with what is included, how long it takes and a price basis — then one tap to call.
Engineering notes
The catalogue is organised by intent first. A customer picks the outcome — restore the paint, protect it, deal with the interior, get it cleaned regularly — and inside each of those sits the actual named services with the differences spelled out. The trade term is still there, because it is what the invoice will say, but it is no longer the thing a customer has to navigate by.
Each service entry states what is included, roughly how long the vehicle will be there, and a price basis rather than a single figure. Duration is the field customers were calling to ask about most, and it never appears on sites like this. Where price depends on vehicle size or condition, that is said outright with the factors listed, because a precise number that turns out to be wrong on arrival costs more trust than a range.
Comparison between services in the same group is a side-by-side view of what differs — inclusions, duration, how long the result lasts. This is what the phone conversation consists of, so putting it on the page was the highest-value thing in the build.
The enquiry path is a call button that is always reachable, with a booking-request form as the secondary route. Contacting from a service page carries the service and the vehicle details across, so the owner picks up already knowing what is being asked about. There is no booking calendar: the business schedules around bay availability and job length in a way that a naive slot picker would misrepresent, and a booking system that confirms a time the business cannot honour is worse than a phone call.
All photography is the client’s own work. Before-and-after pairs are presented as a slider on the same vehicle from the same angle rather than as two separately flattering shots, because for this trade the comparison is the credibility. Every image is generated at layout size and deferred until it is on screen, which is what keeps a photograph-heavy site fast on a phone.
03Key features
8 capabilities, described by what they let someone do rather than by the technology underneath.
A customer navigates by what they want done. The trade term is present but it is not the entry point, which is where the vocabulary gap was costing enquiries.
How long the vehicle will be there. The most common phone question, and almost never on a site in this category.
Where cost depends on vehicle size or paint condition, the factors are listed. A precise figure that changes on arrival costs more than a stated range.
Inclusions, duration and how long the result lasts, compared across the services a customer is actually choosing between. This is the phone conversation, on the page.
A persistent tap-to-call on mobile. For this business the phone is the conversion, and the form is the fallback.
Requests from a service page arrive with the service and vehicle details attached, so the first reply can be an answer.
A comparison slider rather than two separately chosen photographs. For detailing work the honesty of the pairing is the credibility.
Actual address with a maps handoff, real phone number, the owner named. Trust for a service business is built from specifics.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
The customer’s mental model is an outcome. Making them navigate by treatment name was the specific reason the site was not converting into calls.
Trade-off
Some services legitimately sit in two outcome groups, so a small amount of cross-listing was needed — and cross-listing has to be deliberate or it reads as padding.
Why
Both were the questions being asked by phone. A range with its factors named is more useful and more defensible than a figure that needs revising in person.
Trade-off
It is less immediately satisfying than a number, and a competitor showing one flat price looks cheaper at a glance even when they are not.
Why
Scheduling depends on bay availability and job length in ways a slot picker cannot represent. A confirmation the business cannot honour damages the trust the rest of the site is building.
Trade-off
Enquiries need a human reply, so the business carries that load. It was the client’s explicit preference and it is the right call at this size.
Why
Stock images of other people’s cars are recognisable as stock, and in a trade sold on visible results they undercut the entire proposition.
Trade-off
Some services had no good photographs, so those entries lead with text until real work is shot. An empty slot is better than a borrowed image.
06Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Set a simple capture convention with the client — same position, same time of day, no editing — and rebuilt the pairs from work shot afterwards.
Outcome
The comparisons became believable. A pair shot from two angles reads as marketing even when the work is real.
Approach
Added the within-group comparison and reworded inclusions to state the difference explicitly rather than leaving it to be inferred from two lists.
Outcome
The calls shifted from "what is the difference" to "when can you take it", which is the conversation the owner wanted to be having.
Approach
Generated sizes at build time, served modern formats with fallbacks, deferred everything below the fold, and moved the comparison slider to load its second image only on interaction.
Outcome
The gallery kept its quality without being the reason a page took seconds to become useful.
07Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
08Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Outcome groups
The four things a customer might want, with the named services inside each.
Service comparison
Inclusions, duration and durability across the services in one group.
Before and after
The same vehicle and angle, with the slider position visible.
Enquiry
Service and vehicle context travelling with the request, beside the call action.
The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.
09Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
Implementation detail
10Technical preview
This build was delivered to a client, so the source belongs to them and is not republished here in any form — not as excerpts and not as a repository link.
Delivered work
For private client work, contact me for a walkthrough. On a call I can screen-share the build, go through the component structure, the decisions behind the interaction work and the parts that needed rewriting — the same ground a technical preview covers, without republishing a client's property to do it.
Or email directly: surajk86808@gmail.com
What is not published here
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.