Michigan GPT

Train the estimator before you train the model

Before a Michigan shop trains a quoting model, estimators need a shared method and clean history the team trusts.

Most Michigan shops that struggle with AI quoting do not have a model problem. They have an estimator problem that the model is about to inherit.

That sounds harsh. It is not meant as a judgment of the people. Estimators in West Michigan machine shops, Tier Two suppliers around Grand Rapids, and stamping plants along I-94 carry a lot of the business in their heads. Setup times that never made it into the traveler. Secondary ops that get negotiated on the phone. Material yield assumptions that only show up when the job runs hot. When those people leave, or when a new hire quotes the same family three different ways in two weeks, the shop feels it in margin long before anyone mentions artificial intelligence.

So when a vendor arrives with a quoting model and a clean demo, the temptation is to treat the software as the fix. Feed it the ERP history. Point it at the drawing archive. Let it learn. That sequence is backwards. If the estimators have never been trained to a shared method, the model will learn the mess with great confidence.

What "trained" actually means

Training an estimator is not a one-day software walkthrough. It is agreement on how the shop prices work, written down well enough that two competent people would land near the same number on the same RFQ.

That agreement covers boring things that decide whether a quote lives or dies. How you treat setup on a fifty-piece run versus a five-hundred-piece run. When you add risk for an incomplete drawing. How you handle a customer who always revises after award. What you do when the nearest historical job used a different material, a tighter tolerance stack, or an outside process that is now in-house. None of that belongs only in one senior person's memory.

A practical shop in Holland or Troy that does this well usually ends up with a short estimating playbook, not a binder nobody opens. Part families get named. Default assumptions get listed. Exceptions get flagged with a reason. New estimators shadow a few dozen quotes with a named reviewer before they send anything customer-facing. The senior estimator's private spreadsheet either becomes shop property or it stops being the real system of record.

Until that exists, an AI project is mostly an expensive way to amplify inconsistency. The model will match whatever it finds. If Job 4417 was quoted soft because the customer was strategic, and Job 4622 was quoted hard because capacity was tight, and nobody labeled either case, the model will average those politics into a number that looks technical.

The data problem is a people problem first

Shops often say their ERP is too dirty for AI. Sometimes that is true. More often the dirt is a record of how estimating actually worked.

Travelers missing secondary ops. Quotes closed without a link to the job that ran. Change orders that never updated the original estimate. Notes sitting in email instead of the quote record. Part numbers that mean three different things depending on who entered them in 2019. Cleaning that is not a weekend IT task. It is estimators deciding, with ops and quality, what a good historical example looks like and which jobs should never train anything.

We have seen mid-sized manufacturers around Metro Detroit spend six figures on a quoting assistant that sounded sharp in the pilot and then quietly drifted. The pilot used a curated set of clean jobs. Production used everything. The estimators had never agreed on how to mark a "do not use for comparison" job. The model kept recommending past prices that were political, incomplete, or tied to a process route the shop no longer runs.

The fix was not a better algorithm. The fix was three weeks of estimator workshops: define the part families that matter, tag the historical jobs that are honest comparisons, write the rules for incomplete packages, and assign one reviewer who owns exceptions. Only after that did retraining the model make sense.

If your estimators cannot explain, in plain language, why last month's quote for a housing family came out the way it did, the model will not invent that explanation for you. It will guess.

A sequence that holds up on the floor

A workable order looks like this.

First, pick one part family with enough history to argue about. Stamped brackets with many variants. Machined housings that return every quarter with a small revision. Welded frames sold in a few standard sizes. Do not start with the exotic one-off that only the plant manager understands.

Second, put two or three estimators in a room with the last twenty closed jobs for that family. Have them re-quote from the original RFQ package without looking at the winning number. Compare the spreads. Where they disagree, write the rule. Where the rule depends on customer behavior, write that too. This exercise is uncomfortable and useful. It surfaces the tribal knowledge that AI vendors assume already lives in the database.

Third, fix the records for that family only. Link quotes to jobs. Fill missing ops. Mark bad history. You are building a training set the humans trust, not boiling the ocean across every SKU since the company bought its first laser.

Fourth, train the people on the playbook you just wrote. New hires get it on day one. Veterans get a short refresher and a chance to object. If a veteran objects and wins the argument, update the playbook. Do not leave the disagreement as a hallway rumor.

Fifth, introduce the model as a junior assistant against that same family. Same review rules you already use for a person. Same expectation that a price without a trail of reasoning is not a price. The model inherits a method instead of inventing one.

Shops that skip to step five because the demo was impressive usually spend the next year arguing with the software. Shops that take the slower path tend to find that the model is almost boring. Boring is the goal. Quoting should be repeatable, not theatrical.

What this costs in calendar time

Owners ask how long the human work takes before the model work starts. For one part family in a mid-sized shop, plan on a few weeks of part-time attention from the estimating lead, not a six-month transformation program. Two workshop mornings. A stretch of record cleanup between quotes. A written playbook that fits in a handful of pages. A review cadence for the first month of live use.

That is slower than a vendor's implementation checklist. It is faster than a year of quoting fights and a team that has stopped opening the tool. The patience is the point. Michigan manufacturers did not get good at making parts by installing software first and defining the process later. Estimating is a manufacturing process. Treat it like one.

There is also a hiring angle. A shop that can train estimators to a shared method can bring on a second or third estimator without betting the book of business on one person's memory. The AI then has someone competent to supervise it. A shop that never trained the humans ends up asking the model to be the senior estimator. That is a role the model cannot hold, no matter how polished the interface looks.

The test before you buy

Before you sign for a quoting model, run a simple test with no software involved. Take five RFQs from the last quarter. Have two estimators price them independently with your current method. If the spreads are wide and nobody can say which answer was right without appealing to instinct, you are not ready to train a model. You are ready to train estimators.

If the spreads are tight and the reasoning matches, you have something worth encoding. That is the moment the vendor conversation becomes useful. You can ask how the tool captures your playbook, how it handles exceptions, and how human overrides feed back into the next recommendation. Those are concrete questions. They beat a generic pitch about transformation.

AI can help a Michigan manufacturer quote faster and more consistently. It cannot replace the work of teaching people how your shop thinks about risk, setup, and history. Do that teaching first. Then train the model on a practice the team already trusts. The other order looks modern in a slide deck and feels careless on Monday morning when the RFQ queue is real.