Custom Software for Auto Repair Shops: Work Orders, Parts Pricing, and Customer History

An independent auto repair shop is a high-velocity operation running on thin margins. A car rolls in for an oil change, the tech finds a leaking valve cover gasket and rear brakes at three millimeters, the service writer has to price the work, get the customer's approval before lunch, source the parts from a jobber that will deliver in two hours, schedule the bay, run the labor, hand the keys back, and have the invoice paid before the end of the day. Multiply that by twenty cars on the schedule and three techs on the floor, and the difference between a profitable week and a busted one comes down to whether the system in the office can keep up with the floor.

Most shops start with Shop-Ware, Tekmetric, Mitchell 1, ShopBoss, AutoLeap, or one of the older platforms like Protractor. For a single-location general-repair shop with two or three bays, one of these will cover the workflow. The cracks tend to show up later, when the shop grows past one location, picks up a fleet account that bills on net-30 with a custom rate sheet, runs a specialty line — diesel, European, performance, fleet service — alongside general repair, or builds out a digital inspection process that the platform's template cannot really model.

This post covers what custom software for an auto repair shop actually looks like, where the off-the-shelf options stop short, and the type of shop that benefits most from building rather than renting.

Why an auto repair shop is different from generic field service

Auto repair shares some surface with field service — work orders, technician time, parts on a job, invoicing — but the operation is structurally different. The car comes to the shop, not the other way around. The customer is rarely on site when the work is being done. The scope of the job usually grows after the vehicle is up on the lift and the tech finds something the customer did not know about. The differences that matter:

• The estimate is a moving target. A customer drops the car off for a brake job. The tech finds a torn CV boot, a weeping rear main, and a wheel bearing that is about to go. The service writer has to add three line items, reprice the work, get the customer’s approval, and reschedule the bay — sometimes twice before lunch. The system has to handle estimate revisions, customer-approved work, and the gap between what was promised and what was authorized.
• Parts pricing is a matrix, not a markup. Shops do not put a flat percentage on every part. They run a tiered matrix — small parts at one margin, mid-range parts at another, big-ticket items at a third — with rules for fleet accounts, internal use, and warranty work that vary by customer. A platform that only supports a single markup percentage is leaving real money on the table.
• Technician efficiency is the labor model. Most shops bill labor against a flat-rate book — a published hour count per job — and pay the tech against either the same book or actual hours. The difference between billed hours and clocked hours per tech per week is the labor productivity number, and it is the number that decides whether the shop made money. The system has to clock time at the job level, not at the day level, and surface tech efficiency against the flat-rate book every week.
• Digital inspections are how scope grows. A tablet-based vehicle inspection with photo and video evidence, sent to the customer by text, with line-item approve/decline buttons, is now standard equipment for any shop that wants its average repair order to grow. The platforms that started before this workflow existed have bolted it on; the platforms that started after still treat it as a discrete module rather than the center of the shop’s estimating process.
• Customer history is the differentiator. A returning customer who has been to the shop five times over four years should have every recommendation, every declined repair, every brake measurement, every fluid service, and every photo on file when they call. That history is also the input to a service reminder program and a maintenance schedule that drives the average customer lifetime value of the shop. Most platforms store the history but cannot surface it in a way that drives the next conversation.
• Fleet billing is a separate animal. A fleet account is not a retail customer. It is a net-30 commercial relationship with a custom labor rate, a custom parts matrix, a purchase order number on every ticket, an authorized signer at the fleet manager’s office, and a consolidated monthly invoice across every vehicle in the fleet. The system has to model the fleet as a separate entity with separate terms — not as a retail customer with a coupon code.

What the off-the-shelf platforms get right — and where they stop

There are real options in this space. Tekmetric, Shop-Ware, and AutoLeap are the most popular cloud-native shop management platforms and cover work orders, digital inspections, parts catalogs, and basic reporting for a standard general-repair shop. Mitchell 1 and Identifix are the older industry standards and integrate deeply with the technical reference data techs use to look up procedures and torque specs. ShopBoss and Protractor sit in between.

For a single-location shop with two or three bays running a standard general-repair book, one of these will cover most of the workflow. The cracks tend to show up in three patterns:

Multiple lines of business under one roof. Many independent shops run general repair alongside a specialty line — diesel, European, performance, transmission, collision, fleet service — each with its own labor rate, its own parts matrix, its own technician skill set, and sometimes its own customer base. The off-the-shelf platforms force everything into a single shop model. The workaround is usually a second system, a second QuickBooks file, or a spreadsheet that the office reconciles by hand every week.

Multi-location roll-up reporting. Per-seat or per-location SaaS pricing makes multi-shop roll-ups expensive, and the reporting still does not show the owner what they actually want — labor productivity per tech per location, parts margin per matrix tier across the group, fleet account profitability across locations, and a comparable scorecard for each shop. Owners end up exporting data to spreadsheets and rebuilding the report themselves.

Reporting that does not match how an owner runs the shop. Owners want gross profit per repair order, average repair order trend, sold-hours per tech against clocked hours, parts margin against the matrix, and a same-day-payment rate — sliced by service writer, by tech, by customer type, and by month. The platforms ship reports against the ticket; the owner wants reports against the business.

What custom software for an auto repair shop typically includes

Most builds we scope cluster around the same core set of modules. The exact mix depends on the balance of retail vs. fleet vs. specialty, the number of locations, and the adjacent programs the shop runs. The recurring pieces:

• Repair order with revision history — a work order that captures every state change from estimate to authorized to in-progress to ready for pickup to invoiced, with the timestamp, the user, and the customer-facing description preserved for every revision so there is a clean audit trail of what was sold and when.
• Digital vehicle inspection — tablet-first inspection with photo and video capture per line item, color-coded by severity, with a customer link sent by text for line-item approve or decline, automatic work-order update on approval, and a timestamped record of the authorization.
• Parts pricing matrix — tiered markup rules by part cost, by category, by supplier, by customer type, with overrides for fleet contracts and internal use, and a live margin number on every line item so the service writer can see what the job is worth before they quote it.
• Labor and flat-rate book — labor priced against a published flat-rate book (Motor, Mitchell, AllData) with override rules for in-house pricing on common jobs, and labor billed by repair order with the option to bill multiple labor lines on a single job.
• Technician time tracking — clock in and out at the job level, not the day level, against the flat-rate hours the job was sold on, with a daily efficiency number per tech and a weekly rollup against the labor budget.
• Customer and vehicle history — every visit, every recommendation, every declined repair, every measurement, every photo, every fluid service, attached to the vehicle and to the customer, surfaced in front of the service writer when the customer calls.
• Service reminder and maintenance program — automated reminders by text and email for mileage-based services, time-based services, declined-repair follow-up, and seasonal maintenance, with a measurable return rate that drives lifetime value.
• Fleet billing — separate fleet customer entities with custom labor rates, custom parts matrix, PO requirements, authorized signers, and consolidated monthly invoicing across every vehicle in the fleet, with net-30 terms and aging follow-up.
• Parts ordering integration — live availability and pricing from WorldPac, NAPA PROLink, AutoZone Commercial, and O’Reilly First Call, with PO generation, receiving, and core charge tracking, so the service writer is not flipping between four supplier portals to source a job.
• Multi-location roll-up — labor productivity, parts margin, average repair order, gross profit per RO, and same-day-payment rate by location, by service writer, by tech, with a comparable scorecard the owner can manage to without exporting to Excel.
• QuickBooks sync — repair orders, fleet invoices, vendor bills, parts purchases, and aging follow-up flow to QuickBooks Online or Desktop without double entry.
• Customer-facing service history portal — a web portal where the customer (and especially a fleet manager) can see every past visit, every recommendation, every approval, every invoice, and the upcoming maintenance schedule, without calling the shop.

None of these features is unique to custom software in the abstract. The point of building custom is that all of them work the way your shop runs, in the same system, without the manual reconciliation that comes with stitching three or four off-the-shelf tools together.

Parts margin is where the money quietly goes

The single most underused number in an independent shop is actual parts margin per ticket against the matrix the shop thinks it is running. Owners have a number in their head — usually a blended percentage from the P&L — and they assume their service writers are pricing against it. They are usually wrong on a meaningful share of the tickets, and they cannot see which ones until the month is closed and the math is already cooked.

A real parts margin system enforces the matrix at the line level, shows the service writer the live margin number as they build the estimate, flags tickets that fall below a target floor before they go out the door, and reports margin by service writer, by category, by supplier, and by customer type every week. A service writer who is quoting a brake job at retail-with-a-fleet-discount because they forgot to switch the customer profile is a margin leak that nobody will catch in a generic platform. Custom software catches it before the job is sold.

Technician efficiency is the productivity dashboard

Labor is the other half of the shop's P&L, and the number that matters is sold hours against clocked hours per tech per week. A tech who clocks forty hours and sells forty-five against the flat-rate book is running at a 112 percent efficiency rate — that is the profitable bay. A tech who clocks forty and sells thirty is either undertrained, underutilized, or working on jobs that were priced wrong. Either way, the owner needs to know it this week, not at the end of the quarter.

Generic platforms surface a daily timecard. They do not run a labor productivity program. Custom software can clock time at the job level, compare it to the flat-rate hours the job was sold on, calculate efficiency per tech per day and per week, and surface the techs and the job categories where the labor model is breaking. The same data drives pay decisions, training plans, and the labor rate the shop charges next year.

Who benefits most from a custom build

Not every auto repair shop needs custom software. The ones that benefit most have at least two of the following:

• More than one location, where roll-up reporting and a comparable scorecard across shops would change how the owner manages the group.
• A real fleet book of business — five or more commercial accounts with custom rates, PO requirements, and net-30 invoicing — running alongside retail repair.
• A specialty line (diesel, European, performance, transmission, collision) running alongside general repair, with its own labor rate and parts matrix.
• A meaningful digital inspection program where the average repair order depends on the customer approving recommended work from a tablet-driven walkaround.
• A parts pricing matrix that the current platform cannot model cleanly — tiered margins, customer-type rules, supplier-specific overrides — and the gap is showing up in monthly P&L.
• A labor productivity problem the owner can feel but cannot quantify, because the platform does not clock time at the job level against the flat-rate book.

If a shop is brand new or running a single bay as a side-of-the-house operation, an off-the-shelf platform is almost always the right answer. Custom software is most useful when the ticket count, the technician count, and the workflow complexity are real enough that the workarounds in a generic tool start costing real money every week.

What a build looks like in practice

We start with the workflow, not the screens. Before any code is written, we map the actual operation: how a vehicle gets checked in, how the inspection gets run on the tablet, how the estimate gets built and sent for approval, how parts get sourced and received, how the tech clocks time against the job, how the invoice gets paid, and where the office spends time fixing problems after the fact. The custom software is built around that map.

Most shop builds ship the core operation first — repair orders with revision history, digital inspections with text approval, parts pricing matrix, technician time tracking, and QuickBooks-synced invoicing — and add fleet billing, multi-location reporting, parts ordering integrations, and the customer-facing service history portal in later phases. That sequencing keeps the project tight and gets the business value into the bays early.

Fixed price. No hourly billing. The scope and cost are agreed before any code is written, and we build against that scope.

Frequently asked questions

If your shop has outgrown the platform you started on, start with a conversation. We will scope the workflow before talking about a build.