Parts Fitment: The Question This Cannot Answer
The question every parts customer asks — "will this fit my car?" — is the one no general operations system answers. What you can build around the gap with searchable fields, what you cannot, and how to decide whether that settles your buying decision.
A customer walks into a parts shop on Kirinyaga Road and says "Probox, 2014, front brake pads". That sentence is a database query against a fitment table, and in most Kenyan parts businesses it is executed by a man who has been doing this for eleven years. He is fast, he is usually right, and he is a single point of failure that no software at this price replaces.
This post is about being precise about that, because it is the one place where an honest answer might cost us a sale and a dishonest one would cost you a year.
What fitment actually requires
A real fitment capability is three things, and the third is the expensive one.
-
A vehicle model
Make, model, year range, engine code, body variant, sometimes market and trim. Not a text field — a structured record, because "Probox 2014" is four different vehicles depending on engine and market.
-
A many-to-many relationship between parts and vehicles
One pad set fits thirty vehicles; one vehicle takes four alternative pad sets at different price points. Neither side is a single value, which is why a "compatible with" text field breaks down within a week.
-
The data itself, maintained by somebody
This is the actual product. Commercial catalogues exist and are licensed per year, and the reason they cost money is that a team keeps them current as manufacturers change part numbers. No software vendor generates this; they license it or they do without.
The third point is why fitment is not a feature that gets added in a sprint. A vendor who tells you they can build fitment is offering you the first two things and a data-entry project.
The honest position here
What AWRA OpsHub does today
- Items with a barcode field, plus custom fields you define, so OEM numbers, aftermarket cross-references, box numbers and shorthand all sit on one record and are all searchable.
- Full-text search across those fields, so typing a code someone read off a box finds the record whichever naming system it came from.
- Categories and item grouping, so "brake pads" is a navigable set rather than a search term.
- Custom fields on customers and on jobs, so you can record the vehicle you are dealing with today.
What it does not do
- No vehicle entity. No make, model, year, engine code or VIN as structured records.
- No part-to-vehicle relationship. Compatibility cannot be expressed as data, only as text on a part.
- No fitment lookup. Nothing accepts a vehicle and returns the parts that fit it.
- No catalogue data of any kind. Every code and cross-reference is one you typed.
- No interchange or supersession chain — nothing knows that part A was replaced by part B in 2019.
That is a complete answer rather than a hedged one. The system holds your stock, your money, your suppliers and your customers accurately; it does not answer the fitment question, and it will not by configuration.
What you can genuinely build around it
The workaround is real and worth doing, because it converts one man's memory into something searchable by anybody — which addresses the risk even though it does not address the capability.
The searchable-fields approach
Seventy per cent, not a hundred. It works when the customer gives you a chassis code or a part number, and fails when they give you "a 2014 Probox" and there are four of those. It also degrades over time unless somebody maintains the "fits" field, and nobody maintains a free-text field without being asked to.
The three-question test
Ask these of your own business, honestly
How do customers identify what they want?
If the answer is
"They bring the old part, or a number."
Then
The searchable-fields approach covers you well. A part number or a chassis code is a search, and search is built. This is the majority of counter trade in wholesale and trade-focused shops.
How do customers identify what they want?
If the answer is
"They tell us the car."
Then
You are running a lookup service. Weigh this gap above every other consideration, and consider a dedicated parts catalogue product alongside a general operations system rather than instead of one.
What proportion of your enquiries does one person answer?
If the answer is
"Most of them."
Then
Regardless of the software decision, write the mapping down. That is a business-continuity problem with or without a system, and the searchable-fields exercise is the cheapest way to do it.
The two-system answer, which is often right
For a parts business whose trade genuinely runs on fitment lookup, the workable architecture is two systems with a clear boundary: a catalogue product for the lookup, and an operations system for the stock, the money and the customers. It sounds inelegant and it is how a good many parts businesses in this market actually operate.
Where the boundary sits
A catalogue or lookup source
Answers "what fits"
- Vehicle identification from registration, VIN or chassis code.
- The parts that fit, with alternatives at different price points.
- Supersession — what replaced what, and when.
- Maintained by somebody whose business that is.
The operations system
Answers everything after that
- Do we have it, how many, and in which bin.
- What it cost us, landed, and what we should sell it for.
- Serial and warranty, on the categories that need it.
- The customer's account, credit limit and what they owe.
- What we need to reorder, and from whom.
What crosses
- A part number, typed or pasted. That is the entire integration, and it needs no software.
- Nothing automated. Which is fine — a counter man reading a number off one screen and typing it into another is two seconds.
Resist the urge to integrate these. A part number typed by a human is a two-second operation and a robust one; a synchronisation between a licensed catalogue and your item list is a project with a maintenance burden and a licensing question attached.
If fitment is a condition, say so early
A vehicle entity and a part-to-vehicle relationship are a real build rather than a configuration, and they are the kind of thing that gets scoped for a client who asks in writing. What they are not is something to hope for. Ask in the first conversation and get a plain answer — from us and from anybody else.
Our take
There is no fitment capability here and there will not be one by configuration. The searchable-fields workaround genuinely converts one person's memory into something anybody can query, and it answers about seventy per cent of counter enquiries — which is worth doing regardless, because that memory is a continuity risk. If your customers identify parts by naming their car rather than by producing a number, run a catalogue alongside and let the boundary be a typed part number.
Make the mapping searchable, at least
Custom fields for OEM, aftermarket, box numbers and supersessions, all searchable from one box — so the knowledge in one person's head becomes something any member of staff can find.
See plans & pricingFrequently asked questions
Can the system look up which parts fit a vehicle?
No. There is no vehicle entity, no part-to-vehicle relationship and no fitment lookup, and none of that arrives by configuration. Compatibility can only be expressed as searchable text on a part record. It is the clearest limitation in this cluster and worth settling before any other consideration if your trade runs on lookup.
Why is fitment hard to build?
Three parts, and the third is the product. You need a structured vehicle record — make, model, year range, engine code, variant, because "Probox 2014" is several different vehicles. You need a many-to-many relationship, since one pad set fits thirty vehicles and one vehicle takes four alternatives. And you need the data itself, maintained continuously as manufacturers change numbers. Commercial catalogues are licensed annually for exactly that reason.
What is the best workaround?
Put every naming system on one item record in searchable fields: the box number in the barcode field, and custom fields for the OEM reference, a free-text "fits" list of chassis codes, and what the part supersedes. A search for a chassis code then returns everything carrying it. That answers roughly seventy per cent of counter enquiries and, more importantly, moves the mapping out of one person's head.
When is the workaround enough?
When customers identify what they want by bringing the old part or quoting a number — which describes most wholesale and trade-focused counter business. It is not enough when they identify what they want by naming their car, because then you are running a lookup service and the missing vehicle record is the core of the product rather than a detail.
Should we run a separate catalogue product alongside?
For a fitment-driven business, yes, and it is how a good many parts dealers in this market already operate. The catalogue answers what fits; the operations system answers do we have it, what did it cost, what does the customer owe and what should we reorder. Let the boundary be a part number typed by a human — do not build a synchronisation, which adds a maintenance burden and a licensing question to save two seconds.
