Auto Repair Shop Software: How to Choose One

Short answer: auto repair shop software is not an appointment book, it is a vehicle history system. The first question to ask when evaluating one is not about the interface: is the record opened against the customer or against the vehicle, is extra work approved by the customer inside the system, and does a fitted part leave stock the moment it is added to the work order? The answers rule out most off-the-shelf packages in the first week.

The record belongs to the vehicle, not the customer

A workshop's real asset is not its customer list, it is vehicle history. If one customer owns three cars, that is three separate service histories, three mileage curves and three warranty states; who the invoice is addressed to does not change that. When a car changes hands, its history goes with it — because "what oil went into this car last time" is a question about the vehicle, not the owner.

That has a clear data modelling consequence: a vehicle is identified by its VIN, not its plate. Plates change, get transferred, get replaced by temporary ones; the VIN does not. Software that makes the plate the primary key either loses the history when a car is sold or merges two different vehicles into one record. This is not something you can bolt on later — the data model is built this way from day one.

If service history is not attached to the vehicle itself, the answer to "when were these brake pads replaced" lives in a mechanic's memory rather than in the system. When that mechanic leaves, the answer leaves with them.

Field service software is not workshop software

The field service management software used for appliances and machinery solves a calendar and routing problem: the technician travels to an address, travel time is scheduled, and the van is managed as a warehouse. In a workshop the flow is reversed — the customer comes to you. The constraint here is not the road but the number of lifts and mechanics: how many cars can be raised at once, and who is qualified to do which job. Software that ignores those two limits is contradicted on day one, when five cars are booked in for nine in the morning.

A general-purpose online booking system falls short for the same reason: a routine service takes forty minutes, bodywork takes three days. The two do not sit in the same calendar in the same way.

The critical module is the approval flow, not the work order

In a workshop, the scope of a job cannot be fully known until the car is opened up. A fault found after disassembly means extra parts and extra labour — and unapproved extra work is usually unbilled extra work. That is why the most critical part of the software is not the work order screen but the flow that lets the work order grow.

• Work orders must be itemised: parts, labour time and amount visible per line.
• Extra work must be added as a new line to the existing order — opening a second work order splits the history of one visit in two.
• Approval must be requested from inside the system and stored with a timestamp: the link sent to the customer, the time it was approved and the amount approved. Verbal approval over the phone is not evidence when a dispute starts.
• Orders waiting for approval need their own queue; a car occupying a lift because "the customer never called back" is the most expensive loss a workshop has.
• Declined lines should stay on record too — so you can say "we recommended this last time" at the next visit.

Sending the approval request over WhatsApp rather than SMS noticeably shortens response time; we covered that infrastructure in WhatsApp Business API integration. Whatever the channel, the rule holds: approval given outside the system does not exist in the system.

Parts, stock and warranty come from one record

A fitted part must leave stock the moment it is added to the work order. Without that link, the stock record drifts away from reality within weeks and a car waits on the lift for a part the system said was there. For the general warehouse logic see stock software or custom development; what is specific to a workshop is that a part record must carry more than a quantity — brand or aftermarket equivalent, part number and warranty period.

Warranty tracking therefore belongs to the work order rather than to stock: a part's warranty starts on the date it was fitted, at that day's mileage. If either is missing, the question that arrives six months later — "wasn't this part under warranty?" — has no answer.

Service reminders are a revenue line, not a feature

The module that brings customers back most reliably is the reminder, and its logic is one simple rule: the next service is due when the time threshold or the mileage threshold is reached, whichever comes first. That calculation should run the moment the work order is closed, not be reconstructed from a report later. Mileage is projected from the daily average between the last two visits:

type Visit = { date: Date; km: number };

/** Next service: whichever threshold — time or mileage — is reached first. */
export function nextServiceDue(
  history: Visit[],
  intervalMonths: number,
  intervalKm: number,
): { dueDate: Date; reason: 'time' | 'mileage' } {
  const last = history[history.length - 1];

  const timeDue = new Date(last.date);
  timeDue.setMonth(timeDue.getMonth() + intervalMonths);

  // Daily average needs two real readings; with a single visit we do not
  // guess mileage at all and let the date decide.
  const previous = history[history.length - 2];
  if (!previous) return { dueDate: timeDue, reason: 'time' };

  const days = (last.date.getTime() - previous.date.getTime()) / 86400000;
  const kmPerDay = days > 0 ? (last.km - previous.km) / days : 0;
  if (kmPerDay <= 0) return { dueDate: timeDue, reason: 'time' };

  const mileageDue = new Date(
    last.date.getTime() + (intervalKm / kmPerDay) * 86400000,
  );

  return mileageDue < timeDue
    ? { dueDate: mileageDue, reason: 'mileage' }
    : { dueDate: timeDue, reason: 'time' };
}

The detail that matters here is refusing to project mileage for a car that has only visited once. A bad projection does something worse than sending an early reminder: it creates a notification channel nobody reads again.

Off-the-shelf or custom?

For a single-site workshop doing standard maintenance and repair, an off-the-shelf package is usually the right call. Decide with three tests; if at least two are a yes, look at custom software:

• Do you have more than one site sharing vehicle history, parts stock or customer balances between them?
• Is there a non-standard flow — insurance assessment, fleet contracts, negotiated corporate discounts? With fleet work the invoice usually goes to the contracting company rather than the driver, and a package that cannot model that will send you back to spreadsheets.
• Does it need to talk to another system, such as accounting, e-invoicing or a parts supplier catalogue? How those links are built is covered in accounting software integration.

Whichever way you go, ask a fourth question while collecting quotes: can the data be exported? If vehicle history, work orders and customer records cannot be taken out in a standard format, changing software becomes impossible a few years down the line.

Five mistakes that break the project

• Identifying a vehicle by its plate — the history breaks when the plate changes.
• Writing extra work into a second work order — one visit then shows up as two in every report.
• Taking approval outside the system, over the phone — no evidence when billing is disputed.
• Separating parts issue from the work order — the warehouse loses touch with reality within a month.
• Designing the mechanic's screen for a desktop — a tablet used with gloves on in the workshop needs three large buttons; a screen nobody uses means data nobody enters.

Conclusion

When choosing workshop software, ignore the feature count and look at three things: is the record opened against the vehicle, does approval happen inside the system, and do parts and stock come from one record. Get those right and reminders and reporting become meaningful on their own. If your workflow falls outside what packages cover, get in touch — we will map your current process and work out which parts an off-the-shelf tool can cover and which need custom development.