Used-Vehicle Store Operating System

A commitment date lives in a chat message. The loan is waiting for approval, the registration is in a queue, the reconditioning job is waiting for a part — three segments, three days each, three different people. Nobody can say which segment the vehicle is stuck in, so the customer calls every day.

The buy-in price, the reconditioning spend and the capital tied up sit in three spreadsheets. At month end the store knows it made money; it cannot say which vehicle made it and which one lost it.

A reversal arrives after delivery, after commission is paid, after insurance is issued. Is the returned vehicle sellable or awaiting repair, which payment flow does the refund follow, how is commission reversed — all remembered by people, and one missed entry breaks the books.

This is one technical problem wearing three faces: there is no place where a vehicle is the primary key and where money, order and documents are written against that key. A spreadsheet records amounts, a chat records progress, a contract records terms — and the three never meet.

What this line builds is that anchor. One file per vehicle, opened the day a lead arrives, and buy-in, reconditioning, stock, sale, delivery, collection and reversal all hang from it. The file does not replace the contract or the ledger; it makes them reconcilable.

The boundary matters too: this line does not produce export documents and does not keep the statutory books. It covers the in-store life of a vehicle from intake to sale; if the vehicle is exported, it is handed to the used-vehicle export line.

The three checkpoints differ in kind. Title pre-check decides whether the vehicle may be bought; purchase approval decides whether it may be bought at that price; the title re-check before delivery decides whether it may be transferred.

The last one is the one stores skip, because the vehicle is sold and the money is in. It is also the one where a lien that was never released is discovered by a customer at the registration desk.

Once split, the overdue alert has an addressee: a loan hold notifies the loan officer, a reconditioning hold notifies the workshop. An alert sent to the wrong person is an alert people learn to ignore.

And the promise date, once written into the order, changes only with a trail: when, why, who confirmed. Rescheduling is not the problem; rescheduling without a record is, because the customer remembers the old date and the system remembers the new one.

On the cost side: the buy-in price including direct costs of acquiring the vehicle; reconditioning, posted from job cards so the number is a total of work actually done rather than an estimate; overhead allocated for the period; and capital cost, the days in stock times the store's funding rate.

On the revenue side, the deal price net of rebates and gifts, recorded on the order, so margin per vehicle is revenue minus those four costs — computed per vehicle rather than allocated at month end.

1. Ageing and capital cost belong to the same dimension. Allocating capital at month end loses the one fact worth having: which vehicle sat longest. That vehicle is usually the one whose pricing needs to move.
2. Reconditioning must post per job card. A single 'reconditioning' line hides rework, and rework is where a cheap buy-in quietly stops being cheap.
3. Delay reason is a data field, not a note. Eight overdue orders with the reason 'overdue' produce eight next month; eight split into loan, registration, parts and customer rescheduling produce a fix.

The store-level parameters — target margin, funding rate, approval threshold, ageing alert, default credit terms — are configurable per store, because two stores in the same city rarely run the same numbers.

The floor price deserves one sentence: a salesperson who can see cost and floor will concede margin when the customer pushes, and the concession leaves no trace. Removing the field on the server makes the concession need an approval instead of a reflex.

1. Keeping the promise date in a message. If it is not a required field on the order, no alert, no days-left figure and no overdue analysis can exist.
2. Allocating capital cost monthly. The one number that identifies the overpriced vehicle disappears.
3. Treating the title check as a checkbox. A checkbox proves someone clicked; it does not prove what was checked, when, or whether it is still true.
4. Reversing at document level only. If commission, insurance and the vehicle's sale status are not rolled back together, the books and the yard disagree within a week.
5. Letting sales see cost. Margin is conceded where it cannot be seen.
6. Doing the dashboard before the fields. Skip the fields and the wallboard shows totals that cannot point at a vehicle, so nobody looks at it twice.

Take the last month of delivered vehicles and try to answer, per vehicle, four numbers: buy-in, reconditioning, overhead and capital. Where the answer requires opening a chat history, that is the field that has to exist first.

1. Put the promise date on the order as a required field and split delivery into four stages.
2. Post reconditioning from job cards, and keep rework visible.
3. Record the delay reason as a category, not as free text.
4. Check whether the title status carries a status and an expiry rather than a tick.
5. Walk steps 2 to 6 in the demo tenant with one real vehicle in mind.

• Used-vehicle export management
• Vehicle sourcing & procurement
• Country packs & overseas delivery