The Notebook: A Love-Hate Story
Walk into almost any fleet repair shop in the country and ask the parts admin how they track cores. Odds are, they'll reach for a spiral-bound notebook. Once in a while, there is a spreadsheet that the admin has built and only he or she understands. Regardless, in almost every single shop, there will likely be a pile of old cores sitting in the middle of the parts floor, wrapped in plastic, with a simple sharpie message: "Unable to return."
For something that directly touches cash flow every single day, core management is handled with remarkable informality across shops everywhere.
Overview
A core charge is money, held temporarily by a supplier, that you get back when you return a rebuildable part. Sensors, alternators, starters, turbos, fuel injectors, water pumps, reman engines; these parts carry core charges that can run anywhere from $50 to several thousand dollars per unit.
On a busy heavy duty shop floor, teams are usually generating five to fifteen core credits a day. Across a week, this money is sitting in a bin somewhere, theoretically on its way back to a supplier, accruing value. In practice, a large portion of it evaporates due to missed return windows, credits that never get claimed, cores that get lost in the back room in a pile saying “Do not move,” or cores returned in condition that gets them rejected.
Most shops often have no idea how much they're losing because they've never had clean enough data to measure it. Most fleets and service providers describe it simply as “A lot.”
Why the Notebook?
Parts admins are smart, resourceful people who are constantly asked to track complex, moving information with tools not designed for the job.
Core management is a lot of coordination.
When a tech pulls a failed alternator off a truck, the parts admin needs to record that a core was generated, tie it to a specific repair order, know which vendor the replacement came from including which specific purchase order, know what the return deadline is for that vendor, track whether the core was actually pulled from the vehicle and not left in the cab or the yard, assess whether the core is in returnable condition, stage it physically for return, confirm the return shipment, and then follow up to make sure the credit hit the account.
That is an eight-step process for a single part. On a day with forty open ROs, no system in the world makes that seamless, so parts admins do what humans do when technology fails them; they create their own system.
What Breaks Down, and When
The failure modes are predictable, and they compound each other.
The RO disconnect. In most shops, the core return process is entirely separate from the repair order workflow. The RO closes, the invoice goes out, and the core enters a kind of organizational no-man's-land.
The deadline problem. Supplier return windows vary: 30 days, 60 days, sometimes less for certain part categories. Keeping those deadlines in a notebook means the tracking system is as reliable as the person who wrote it down. When that person is out sick, takes a vacation, or leaves the company, the knowledge is not there.
Staging chaos. Even when a core gets noted correctly, the physical part has to actually make it into a return bin, get labeled, and go out with the right paperwork. In a busy shop, cores end up in corners, in the wrong bins, or in technicians' personal vehicles waiting for someone to deal with them. By the time anyone looks for them, they're past the return window or damaged beyond acceptance.
Credit black hole. Even shops with decent core tracking often fall down on the back end. The return goes out, but nobody is systematically reconciling supplier credit memos against what was sent. Credits get under-applied, disputed, or simply missed. Accounts payable doesn't know what parts said, and parts doesn't know what AP received.
The Invisible Cost
In a well-run shop with dedicated attention to cores, recovery rates should be 90% or better. In an average shop, recovery rates of under 50% are the norm. Apply that to a shop doing $3 million in annual parts spend. If 20-25% of that spend involves parts with core charges averaging around $300, you're looking at up to $90,000 in potential core credits per year. Almost $45,000 not recovered from a single location.
Why It's Stayed This Way
Core management is unglamorous. It doesn't show up in uptime metrics, it doesn't affect customer satisfaction scores, and it doesn't appear on the report the GM looks at in the morning. It's a back-office function that is often invisible.
It's also genuinely hard to automate without deep integration into the RO workflow. A bolt-on solution that requires manual data entry is barely better than the notebook. The only way to fix core management is to make it a byproduct of the repair process itself, something that happens automatically when a part is received, when an RO closes, when a return is triggered. That requires the kind of integration that most legacy shop management systems were never designed to provide.
What Good Looks Like
Core tracking done right isn't a separate process. When a reman part is received, the system should automatically recognize that a core is expected. When the tech installs the part, the core should be flagged as generated. As the return deadline approaches, the parts admin should not have to deal with a sticky note they put on their own monitor. When the return ships, the system should log it. When the credit comes back, it should be reconciled against what was expected.
Exceptions should surface automatically rather than getting buried in a pile of invoices.
The parts admin's job doesn't disappear in this model, it gets elevated. Instead of spending their day managing a notebook, they're managing exceptions.
The Bottom Line
Core management looks like a small operational detail when actually it's a daily cash flow function that most shops are running on institutional memory, vibes, and handwritten notes. The real problem is that the tools shops depend on were never built to make core management automatic, auditable, and tied to the work that actually generates the core in the first place. Until that changes, the notebook stays.