What used tire shop software needs to track
Why generic auto shop software misses used tires: no tread field, no grade, no lot id, and no way to match singles into sellable pairs.
Four fields decide whether a used tire sells. Tread depth. Condition grade. Source. Lot. Most software built for auto shops tracks none of them.
That's not a knock on those tools, most of which are genuinely good at what they were built for. They were built for oil changes, brake jobs and new-tire sales. In that world a tire is a SKU with a price, not an object with a history. Used tires don't work that way, and pretending they do is how a shop ends up running two systems at once: the software on the counter and the notebook actually keeping track.
Where generic software breaks
A part number and a price cover a new tire fine. A used tire needs more. How deep is the tread today? What grade did someone assign it? Where did it come from, and which lot does it belong to if something turns out wrong with the batch? Ask a generic shop system to hold a tread reading. Most have nowhere to put it. Ask it to flag two used singles that happen to match within a fraction of an inch, and it doesn't know that's a question worth asking.
The result is a workaround: a sticky note on the tire, a note in a spreadsheet cell, a mental tally the owner keeps in his head. Workarounds hold up fine until the owner takes a day off. Then the new hire is standing there staring at a used 225/65R17 with no idea what it's graded, what it cost, or whether it's part of a pair sitting three racks over.
The fields that actually matter
Lot ids matter most, even though they're the field most systems skip entirely.
| Field | Why it matters |
|---|---|
| Tread depth | Sets the price band and the sell or don't-sell line |
| Condition grade | Quick read on cosmetic and structural condition |
| Source | Take-off, trade-in, batch lot or walk-in: affects cost and trust |
| Lot id | Traces a bad tire back to the batch it came from |
| Rack location | Where it actually sits, not where it should be |
| DOT | Age, for the refusal conversation and the receipt |
Miss any one of these and the record stops answering the question a customer actually asks, some version of "is this tire any good." A price alone never answers that question by itself. The fields around it do.
From take-off delivery to receipt
A used-tire workflow has a shape generic software was never asked to support:
- A batch lot or take-off delivery arrives and gets a lot id before anything goes on a rack.
- Each tire gets inspected, graded and measured for tread on the spot.
- It's logged with size, DOT, grade, tread and source, then assigned a rack position.
- Singles get checked against existing stock for a matching pair within a small tread window.
- When it sells, the record updates in the same motion as the sale, not as a separate step someone forgets.
- The receipt carries the used-tire lines: DOT, tread at sale, and the shop's warranty statement.
That's the whole cycle. Skip step four and pairs sit as unmatched singles for months, half sellable at full price and half not. Skip step five and the count on the shelf stops matching the count in the system within a week, which is usually when someone starts doing a physical recount just to figure out what's actually true.
Pair logic is the part most tools skip entirely
Most software, even some built for tire shops specifically, treats every tire as its own record with no relationship to the others. That misses the most common used-tire sale there is: a customer who needs two, not one. A system that can group used singles within a small tread gap into a sellable pair automatically turns dead inventory into a matched set without anyone digging through the rack by hand. Without that, matching pairs by eye across a full rack of used stock is slow, and it's easy to miss a match sitting two rows away from its mate.
DuroBay's pair finder does exactly that. It scans used singles within 1/32" of each other and surfaces them as a pair or a set before a customer even asks. It's one feature in a longer list, but it's the one most general software never builds, because it never comes up outside a used-tire shop.
Getting the fields right matters less if the rest of the shop isn't set up to use them. A tread number typed into a great system still means nothing if the tire it describes is sitting on the wrong rack. A rack system built around size and used-versus-new and a plain checklist for evaluating any software tool both make the fields above worth entering in the first place.
Common questions
Why can't I just use a spreadsheet for this?
You can, for a while. A spreadsheet has no built-in way to flag matching pairs, no photo field, and no automatic record when a tire sells, so it drifts out of date the busier the shop gets.
What's the most commonly missing field in generic software?
Lot id. Most tools track a tire as a standalone item with no link back to the batch it arrived in, which matters the moment one tire in a lot turns out to be bad.
Does grading need to be a formal A/B/C system?
It doesn't have to be fancy, but it does need to be consistent and written down somewhere every tech can see, not just in one person's head.
How is pair logic different from just sorting by size?
Sorting by size groups tires that are close. Pair logic checks the actual tread gap between two specific singles, usually within a small fraction of an inch, before calling them a matched set.
Should the receipt pull from the same record as inventory?
Yes. A receipt built from a separate step is a second place for the numbers to disagree, and a used-tire sale has more fields, tread and DOT among them, that need to match exactly.