Fleet Workshop Stores: No Invoice to Discipline You
An internal workshop has no invoice to discipline it, which is why fleet stores leak more than commercial ones. Cost per vehicle without a vehicle record, tool custody that actually works, and the honest position on service scheduling.
A commercial garage has a customer who queries the bill. An internal workshop servicing your own fleet has nobody in that role — the cost goes to a maintenance budget, the budget is annual, and nobody reconciles a specific repair against a specific vehicle. That absence is why fleet stores in Kenya routinely leak at a rate that would close a commercial workshop.
The leak is rarely theft in the dramatic sense. It is a filter issued and not recorded, a set of pads taken for one vehicle and fitted to another, a tool that left with a mechanic who resigned, and oil drawn in litres nobody counted. Individually trivial, collectively a substantial line in an annual budget nobody examines.
The three controls that matter, in order
-
Nothing leaves the store without a job to leave for
The single highest-value control. Every issue names the job it is for, which means every part has a destination and an unattributed issue becomes visible. Without this, the workshop store is a shelf people take from.
-
Tools are custody records, not stock
A torque wrench is not consumed and should not be issued as stock. It is an asset with a custodian, and the custody record is what makes "who has it" answerable. This is the control that recovers the most value in the first year, because tools walk quietly.
-
Consumables get a standard issue, not a recorded one
Asking a mechanic to record 1.8 litres of oil produces either a fiction or nothing. Set a standard consumable issue per service type and correct it when a job is genuinely different. An approximation that happens beats a precision that does not.
Cost per vehicle, without a vehicle record
There is no vehicle entity here — no vehicle, trip, route, odometer or fuel log. So cost per vehicle has to be assembled from two things that do exist, and it works better than it sounds.
Two ways to represent a vehicle, and when each is right
Approach What you get and what you lose
The vehicle as an asset A register entry with custody, movements, purchase cost, barcode
Right for tracking that you own it, who has it, and where it is. Wrong for accumulating running cost — an asset carries no cost roll-up, no service interval, no meter reading and no depreciation.
Each service as a project Parts issued at stamped cost, labour hours, a budget, and a margin
Right for costing an individual job properly. Wrong for lifetime cost, because nothing joins the projects for one vehicle into a history.
Both, joined by a naming convention The workable answer
Registration number as the project name prefix — "KDA 123A — 60,000km service". Then a project search on the registration returns every job on that vehicle. Crude, and it is the only join available.
The naming convention is doing real work here and it has to be enforced from day one. Retrofitting a registration prefix onto two years of projects named "Toyota service" is an afternoon of guessing, and half of it will be wrong.
Annual cost on one lorry, assembled
Maintenance and tyres, yes. Fuel and per-vehicle overheads, no — there is no fuel or trip entity and expenses code to a category or project — and carry no department at all — rather than to a vehicle. So the honest claim is maintenance cost per vehicle rather than total cost of ownership per vehicle, and if somebody promises you the second one from a general operations system, ask them which table holds the odometer reading.
Service scheduling: the gap to plan around
What AWRA OpsHub does today
- An asset register with custody, movements, verification, warranty expiry, barcodes and GPS capture.
- Condition recorded before and after every movement, so deterioration is traceable across hand-offs.
- Retirement as a first-class event, with the date, who authorised it and why.
- Serial-level tracking with warranty expiry on the components where it matters — tyres, batteries, rotating electrics.
- Projects for costing a service or repair, with parts issued at stamped cost and labour as time entries.
- Stock issued to a job, tenant-verified so a mistyped job cannot charge another organisation's project.
More we can add to your workspace
- A preventive maintenance scheduler: a service interval, a last-service date and a calibration due date, with the next service raised for you.
- Meter and hours tracking: an odometer and engine hours, so distance-based and hours-based servicing can be driven by the system.
- A maintenance event on the asset. A service or repair cannot be logged against a vehicle. The asset has a status somebody can edit to "maintenance" and edit back, but each edit overwrites the last and leaves no dated trail, so the asset itself never shows that a service happened. The project is what carries the evidence.
- Work orders. Maintenance is a project you cost, not a managed work order lifecycle attached to the machine.
- A fuel, trip, route or vehicle entity, so fuel per kilometre and route cost are outside this.
- A cost roll-up on an asset. A vehicle asset does not accumulate what has been spent on it.
- A downtime record and an availability percentage. Both follow from the maintenance event above; today days off the road come from the dates on the project you raised.
The first two together are the important pair: an internal workshop's core discipline is servicing on schedule, and this system neither schedules a service nor records that one occurred against the machine. Whatever you use for that today — a wall chart, a spreadsheet, a reminder — keeps doing it. What changes is that the cost of each service becomes a real number instead of an estimate, because the project holds the parts and the labour even though the asset does not.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsA workable scheduling substitute
Since nothing will raise the next service, the schedule lives outside and needs to be somewhere that is looked at. Two approaches work and both are unglamorous.
Pick one and stick to it
- A wall chart in the workshop, one row per vehicle, next service due by date and by distance. Visible, physical, and updated by whoever closes a job. In a fleet under about twenty vehicles this beats anything digital because it is in the room where the decision happens.
- A spreadsheet with a reminder, one row per vehicle, next-due date, checked weekly by a named person. Necessary above twenty vehicles, and it fails the moment nobody owns the weekly check.
- Either way: the odometer reading is captured on the job. Put it in a custom field on the project so that when a service is costed, the distance is recorded alongside. It will not drive a schedule and it will let you reconstruct one.
- And a monthly reconciliation: vehicles serviced this month against vehicles due. Ten minutes, and it is the only thing that catches a vehicle quietly missing two services.
Tool custody is where the fast money is
Most fleet workshops have never counted their tools. Putting them in the asset register with a named custodian each, then verifying once a quarter, typically finds a surprising quantity missing in the first pass and then stops the bleed — because the mechanism is not the record, it is that everybody now knows the tools are counted.
Our take
Make every issue name a job, put tools in the asset register with a custodian, and use a registration-number prefix on project names from day one so a vehicle's job history is at least searchable. Then be clear that scheduling stays on your wall chart, because there is no service interval, no odometer and no preventive scheduler — what you gain is that the cost of each service becomes real, and what you keep doing by hand is deciding when the next one is due.
Stop the store leaking, then cost the fleet
Issues that name a job, tools as custody records with a named holder, serial and warranty tracking on tyres and batteries, and service costs as real numbers — with the scheduling gap stated up front.
See plans & pricingFrequently asked questions
Why do internal fleet workshops leak more than commercial garages?
Because there is no customer querying the bill. Cost goes to an annual maintenance budget that nobody reconciles against specific vehicles, so a filter issued and unrecorded, pads taken for one vehicle and fitted to another, and a tool that left with a resigning mechanic all pass unnoticed. Individually trivial, collectively a substantial line in a budget nobody examines.
Can we track cost per vehicle?
Maintenance cost per vehicle, yes — by putting the registration number as a prefix on every service project name so a search returns that vehicle's job history, with parts at stamped cost and labour as time entries. Total cost of ownership per vehicle, no: there is no fuel, trip or odometer entity, and expenses code to a category or project — and carry no department at all — rather than to a vehicle.
Does the system schedule preventive maintenance?
No. There is no preventive maintenance scheduler, no service interval field, no last-service date and no meter or hours tracking, so nothing raises the next service and distance-based servicing cannot be driven from here. Maintenance exists as movements on an asset — sent to maintenance, returned — plus a project for the cost. Your wall chart or spreadsheet keeps doing the scheduling.
How should we handle tools?
As assets with a named custodian, not as stock. A torque wrench is not consumed, so issuing it as stock loses track of it — a custody record makes "who has it" answerable. Verify once a quarter. Most fleet workshops have never counted their tools, the first pass usually finds a surprising quantity missing, and the bleed stops mainly because everybody now knows they are counted.
What is the single most valuable control?
Every issue names the job it is for. That gives every part a destination and makes an unattributed issue visible, which is the difference between a store and a shelf people take from. Second is tool custody. Third is a standard consumable issue per service type rather than asking a mechanic to record 1.8 litres of oil, which produces either a fiction or nothing.
Can we record odometer readings?
Only as a custom field on the job. It will not drive a service schedule, since nothing reads it, and it does let you reconstruct distance between services later. Capture it from day one — retrofitting readings onto two years of past jobs is an afternoon of guessing and half of it will be wrong.
