Case study · Computer vision and machine learning
AI vehicle damage estimation in five minutes
A US vehicle repair estimating software company needed commercial vehicle damage estimates that stopped consuming an hour of estimator attention. Brainy Neurals built an AI pipeline that reads the photographs, verifies each damage line, and predicts body and paint hours. A verified first draft now takes about five minutes per job.
- Minutes to a first draft5
- Cut in estimator time per job~90%
- AI checks on every damage line2
Ronak and Arsh, Brainy Neurals engineering. They built the detection and verification pipeline for this project and tuned the estimating rules against the judgment of a working estimator.
· · 12 min read
- 01AI vehicle damage estimation in five minutes
- 02At a glance
- 03Why did every estimate take an hour?
- 04What do estimating teams try first?
- 05How we designed the estimation pipeline
- 06The technology stack we used
- 07How does one job get estimated?
- 08Three problems nearly stopped the build
- 09How each one got fixed
- 10What changed once it went live?
- 11What runs in production now
- 12What we would change next time
- 13Where else does photo estimation fit?
- 14The questions buyers keep asking
- 15The services behind this build
- 16More builds with this shape
At a glance
Q. What problem did this solve?
Commercial vehicle damage estimation ran on manual photo review. Each job took 45 to 60 minutes of estimator time, and results varied between estimators.
Q. What did Brainy Neurals build?
Brainy Neurals built an AI vehicle damage estimation pipeline for a US vehicle repair estimating software company. The pipeline detects the damage, verifies each finding, and then predicts the labor hours.
Q. What changed after it went live?
A verified first-draft estimate now arrives in about five minutes of pipeline time per job. Unclear findings route to a human reviewer instead of into the total.
Q. Who else could use this?
Photo-based damage estimation fits insurers, fleet operators, rental companies, and repair networks. It suits any business that assesses condition from photographs and prices the labor.
- Industry
- Automotive claims technology
- Sub-vertical
- Commercial vehicle estimating
- Client
- US estimating software company
- Engagement
- AI estimation pipeline
- Timeline
- Not disclosed
- Capabilities
- Computer vision, machine learning
- Delivery
- Project-based delivery
Why did every estimate take an hour?
A US vehicle repair estimating software company serves the shops and fleets that keep commercial vehicles working. Its users price collision repairs from photographs, view by view, job after job. The company asked Brainy Neurals whether computer vision development could carry that reading instead.
Where the hour went
- Reviewing one job’s photographs burned five to ten minutes before the first damage line even existed.
- Two estimators pricing the same truck produced two different totals, and neither could prove the other wrong.
- A dent photographed from four angles became four line items, each carrying its own labor charge.
- A replaced hood sometimes shipped without the related operations that replacement drags in.
- Body and paint hours came down to whichever estimator happened to be working that day.
- Printed collision estimating guides once shipped as annual books, thick enough to prop a shop door.
None of this was unusual. A 2025 systematic review called manual vehicle inspection labor-intensive, time-consuming, and error-prone, which is the polite version [1].
What do estimating teams try first?
Four routes come up in every scoping call, and each one is defensible.
| Approach | What it gets right | Where it stops | Who it suits |
|---|---|---|---|
| Keep it manual | Expert eyes on every photo | An hour, plus drift | Low volumes, unusual builds |
| Generic damage AI APIs | Fast to wire in | Trained on cars, lost on trucks | Quick triage |
| Estimating templates | Faster data entry | Judgment stays in someone’s head | Shops with one senior |
| Our route | Verified lines and hours in minutes | Labeled photos and rule work | Platforms estimating in volume |
Part of that is training data. The first large open public car damage dataset arrived only in 2023, built around passenger cars [2].
Tried one of these and stalled? Tell us where it stopped.
Tell us where it stopped →How we designed the estimation pipeline
Brainy Neurals built the pipeline as a sequence of checks, where every damage line earns its place in the estimate. A detection model reads each photograph and proposes findings, with a type, a location, a side, and a confidence score. No damage line reaches the estimate until a second model has read the same damage twice.
The first decision was where the judgment in an estimate would live. We rejected a single-pass design that priced whatever the detector found, because dirt on a truck reads as damage.
So every finding passes a second model, which sees the full photograph and a close crop, before anything is priced. Whatever that check cannot settle goes straight to a person.
The second decision split the rules from the models. Related operations are written rules an estimator can read and argue with. Only the labor hours are learned, from historical estimates, and a guardrail caps any prediction that runs high.
The result is workflow automation with a spine of checks, and the checks are what make the output billable.
“No damage line reaches the estimate until a second model has read the same damage twice.”
The technology stack we used
Every layer below exists to make one damage line defensible in front of a customer. The export layer writes the estimate the way document AI systems read it.
Seeing the damage
Photo intake
Uploads organized by vehicle view
Six views per job, so nothing gets read out of context.
A loose photo dump
Damage detection
A detector trained on vehicle damage
Reads part, type, side, and material from each frame.
Generic vision APIs
Verification
A second model on frame and crop
Rejects glare and grime before anything is priced.
One opinion
Findings into lines
Duplicate merge
Cross-photo matching on part and location
One damage becomes one line, however many photos caught it.
Per-photograph line items
Estimating rules
Written rules for related operations
Auditable by an estimator who can argue with them.
Learned end-to-end estimates
Hour prediction
Regression models with a guardrail cap
Body and paint hours per line, capped when they run high.
Flat averages
Out the door
Review queue
A human lane for unclear findings
Doubt costs a reviewer minutes, never credibility.
Silent auto-approval
Export
Spreadsheet, CSV, JSON, with evidence
Ingested downstream without anyone retyping a line.
A PDF no system parses
Want this walked through for your estimating workflow?
No pitch. If it is not a fit, you will know in five minutes.
How does one job get estimated?
One job, start to finish, in exactly the order the pipeline runs it every time.
- An estimator opens a job number and uploads the photographs by vehicle view, front bumper through interior.
- The detection model marks every damaged part it finds in each photograph, with type, location, side, material, and confidence.
- The pipeline then drops the weak findings and merges the same damage seen across several photographs into a single line.
- A verification model then re-reads each surviving line against the full photograph and a close crop of the damage.
- Estimating rules add the related operations a repair drags in, and trained models then predict body and paint hours.
- The job exports as spreadsheet, CSV, and JSON files, with every line carrying the photographic evidence behind it.
Six steps, and a person appears in exactly one of them, where step four leaves doubt.
Three problems nearly stopped the build
Three problems arrived during the build, in the order they hit.
The better the detection model got, the worse the finished estimates read. One cracked fender photographed from four angles came back as four billable lines, and the duplicate labor inflated every draft. Multi-view damage turns out to be a live research problem, and most published methods still assume one photograph [3].
Work trucks lie to a camera all day, and road grime and panel glare kept scoring as fresh damage. So did old repairs that predated the claim entirely.
The hour prediction models behaved right up until they didn’t. Rare damage on rare panels occasionally produced an absurd labor prediction, and one absurd line discredits an entire estimate.
These are the weeks when a platform team starts asking about specialist engineers instead of learning it the slow way.
Raking light on a worn panel shows why glare and grime kept scoring as fresh damage.
How each one got fixed
Each of the three fixes reads simpler than it was to find.
Duplicates
We merge findings across photographs before anything is priced, keyed on the part, the side, and the location zone. One damage becomes one line, whether it shows up in two photographs or ten. The double-billed labor disappeared from the drafts along with the duplicate lines.
False damage
We stopped letting any single model’s opinion price a repair on its own. The verification model sees what the detector saw plus the whole scene. Findings the two disagree on go to a person, so doubt costs a reviewer minutes instead of costing credibility.
Runaway hours
We capped the hour models against typical bands for each repair operation. A prediction that breaks its band gets flagged for review instead of printed. And the proof of concept is where all three of these surfaced, before anything had been promised.
What changed once it went live?
| What | Before | After |
|---|---|---|
| Time to a first estimate | 45 to 60 minutes of estimator work | About five minutes of pipeline time |
| Reading the photographs | An estimator, one by one | The models, with people on the unclear tail |
| Duplicate damage lines | Found by eye, when found | Merged before pricing |
| Related operations | Remembered, or missed | Added by written rules |
| Body and paint hours | One estimator’s judgment | Predicted and capped |
A first-draft commercial vehicle damage estimate now takes about five minutes, against the client’s reported 45 to 60 estimator minutes. That comparison is the roughly 90 percent cut in estimator time this page claims.
We have not published production accuracy or correction figures, and the client’s modeled monthly savings stay off the page too. The client set targets for both, and a target is not a result.
Day to day, an estimator now opens a finished draft instead of a folder of photographs.
What does your team estimate by hand?
Send the one workflow that eats the most time. It goes straight to the person who would architect the fix, not a queue.
Thanks — that is with us.
One reply is coming from the person who would architect it. No sequence, no queue.
