Customer & Vehicle Service History in a Garage
The reason customers come back to a garage is that you know their car. That knowledge currently lives in a folder and a mechanic's memory — and this system has no vehicle record, so here is exactly how far a naming convention gets you and where it stops.
Ask a loyal garage customer why they keep coming back and they rarely say the price. They say you know the car — that you remember the gearbox was rebuilt in 2023, that the previous owner neglected the cooling system, that the noise it makes on cold mornings is nothing. That knowledge is the garage's actual asset, and in most Kenyan workshops it is held in a paper folder and one mechanic's head.
Both of those have the same problem: they leave. The folder gets lost and the mechanic gets a better offer, and the asset walks out with them.
The gap, stated first
There is no vehicle entity here. No vehicle, registration, chassis or VIN as a structured record, and therefore nothing for a service history to hang from. This is the central limitation of the automotive cluster and it is worth reading before the workaround, because the workaround is genuinely useful and it is a workaround.
What that means concretely: the system will not show you a page for KDA 123A listing everything you have ever done to it. What it will do is let you find every job you recorded against that registration, if you named them consistently.
How far the naming convention gets you
The registration-prefix approach
The distinction matters in one specific way: nothing aggregates. There is no total spent on that vehicle, no service interval derived from previous jobs, no alert that it is due. You get a chronological list of jobs that a person reads and interprets — which is what the paper folder gave you, made searchable and impossible to lose.
Getting the convention to hold
This is the whole difficulty. A naming convention applied for three months and then abandoned produces a history that covers three months, and nobody trusts a partial record — so the discipline is either total or worthless.
Five rules that make it survive
- Registration first, always, with no exceptions for "just a quick look". The quick looks are half your job volume and they are where a history has gaps.
- One format, decided once. "KDA 123A" not "kda123a" or "KDA-123A". Search is forgiving about case and not about punctuation, and three formats means three histories for one car.
- Mileage captured on every job, in the same custom field. It will not drive anything and it is what lets you tell a customer their last service was 14,000km ago rather than "a while back".
- Photographs before and after, attached. The cheapest trust-builder available in this trade, and the thing that ends disputes about pre-existing damage. Attachments live on the record and are access-logged.
- A note field used properly. "Previous owner neglected cooling system", "customer declined rear pads, advised". This is the actual knowledge — the parts list is the easy half — and it is worth ten seconds at job close.
The declined-work note is the commercially valuable one
Every garage advises work the customer declines. Rear pads at 30%, a weeping shock, a belt that has another few thousand kilometres in it. Recorded, that is a follow-up list and a protection. Unrecorded, it is a liability — because when the pads fail, the conversation is about whether you mentioned it.
This is the single highest-return habit in this post and it costs one line at job close. It also happens to be the thing customers respect most when it resurfaces: telling somebody in March that you flagged this in November, with the job on screen, is worth more than any discount.
What is and is not available
What AWRA OpsHub does today
- Projects as jobs, searchable by name, so a registration prefix makes a vehicle's jobs findable.
- Custom fields on projects and customers, for registration, make, model, year and mileage.
- Parts issued to the job at stamped cost, so what was fitted is a record rather than a memory.
- Attachments on the record — photographs, inspection sheets, the customer's authority — checksummed and access-logged.
- Customer records with contacts, addresses and credit limits, so the owner side is properly held.
- Notes on jobs and tasks, which is where the interpretive knowledge lives.
What it does not do
- No vehicle record, so no vehicle page, no aggregation and nothing to attach a history to structurally.
- No service reminders. Nothing tells you or the customer that a service is due — there is no interval, no last-service date and no scheduler of any kind.
- No mileage-based anything. Mileage is a number you record and nothing reads.
- No customer-facing history. A customer cannot look up their own vehicle.
- No recurring invoice generation, so a service plan billed monthly is manual.
- No ownership change handling — a vehicle sold to a new owner is a new customer with the same registration, and the two histories are joined only by that string.
The absence of service reminders is the one to plan around, because reminding customers is where the commercial value of a service history actually converts. That stays a spreadsheet with dates and a named person who sends the messages — which is not sophisticated and does work.
The reminder process, since the system will not do it
-
One sheet, one row per vehicle, four columns
Registration, customer phone, last service date, next due date. Built from your job records once, then maintained as jobs close. This is a twenty-minute setup, not a project.
-
A named person checks it weekly
Not "someone" — a name. Fifteen minutes on a Monday, pulling the vehicles due in the next fortnight.
-
Message them where they actually read
WhatsApp or SMS, both of which the system can send. A short message with the registration, when the last service was and roughly the mileage since — specifics are what make a reminder read as service rather than marketing.
-
Track what came back
A fifth column. Within two months you will know your reminder conversion rate, which tells you whether this is worth fifteen minutes a week. In most workshops it very clearly is.
What this is really solving
Not efficiency — continuity. The reason to record a service history is that when the mechanic who knows the car leaves, the knowledge stays. Every garage that has lost a senior mechanic knows exactly what that costs, and it is the strongest argument for the ten seconds of note-writing at job close.
Our take
Prefix every job with the registration from day one, in one format, with no exceptions for quick looks — a convention applied to 70% of jobs is worth nothing. Record mileage and, above all, the work the customer declined, which is both a follow-up list and your protection. Then accept that reminders live on a spreadsheet with a named owner, because there is no vehicle record and nothing schedules. What you are buying is continuity when a mechanic leaves, and that is worth the discipline on its own.
Make the folder searchable and unlosable
Jobs findable by registration, mileage and vehicle detail in custom fields, photographs and inspection sheets attached and access-logged, and notes where the real knowledge lives — with the missing vehicle record and reminders stated plainly.
See plans & pricingFrequently asked questions
Can we keep a service history per vehicle?
Not as a vehicle record — there is no vehicle, registration or VIN entity, so nothing structurally holds a history. What works is naming every job with the registration as a prefix, which makes a search return every job on that vehicle in order, with parts, tasks, notes and attachments on each. You get a findable chronological history rather than a vehicle page, and nothing aggregates it.
How do we make the naming convention stick?
Registration first, always, in one agreed format, with no exceptions for quick looks — the quick looks are half your volume and they are where histories develop gaps. A convention applied to seventy per cent of jobs is worth nothing, because nobody trusts a partial record. Decide the format once: search is forgiving about case and unforgiving about punctuation.
What is the most valuable thing to record?
The work the customer declined. Rear pads at 30%, a weeping shock, a belt with a few thousand kilometres left. Recorded, it is a follow-up list and a protection; unrecorded, it is a liability, because when the pads fail the conversation becomes whether you mentioned it. It costs one line at job close and it is the highest-return habit in the whole cluster.
Does the system send service reminders?
No. There is no service interval, no last-service date and no scheduler, and mileage is a number you record that nothing reads. Reminders live on a four-column sheet — registration, phone, last service, next due — checked weekly by a named person, with the message sent by WhatsApp or SMS, both of which the system can send. Add a fifth column for what came back and you will know your conversion rate within two months.
What happens when a vehicle changes owner?
Nothing automatic. The new owner is a new customer, and the two histories are joined only by the registration string in the job names — which does actually work, since a search on the registration returns jobs from both ownerships. There is no ownership-change handling and no way to separate the histories if you need to.
Why bother if the system will not aggregate any of it?
Continuity rather than efficiency. The knowledge that keeps customers loyal currently lives in a folder that gets lost and a mechanic's memory that leaves, and every garage that has lost a senior mechanic knows what that costs. Making the folder searchable and impossible to lose is the whole benefit, and it justifies the ten seconds of note-writing on its own.
