Using ChatGPT to Read Bid Packages: What Actually Breaks

Atishay Jain · August 10, 2026 · 12 min read

I have been asked the same question in almost every demo I gave this year. It usually comes about fifteen minutes in, and it usually comes from the most technical person in the room. It sounds like this: "How is this different from ChatGPT, which I could just teach myself?"

It is a fair question, and I have stopped being annoyed by it. The honest answer is that a general chat assistant does a lot of this quite well. If you paste ten pages of a specification into one and ask it what the material requirements are, you will get a good answer. Anybody who tells you otherwise is selling you something.

So this article is not going to argue that using ChatGPT to read bid packages is a waste of time. It is about what starts breaking when you go from ten pages to a real package, and about one gap that no chat window can close, no matter how good the models get.

I should say upfront that I build software in this space, so I am not a neutral party. I have tried to be as honest about the parts where a chat assistant wins as about the parts where it does not.

First, What We Mean by a Bid Package

If your company builds engineered-to-order products, your enquiries do not show up as a part number and a quantity. They show up as somebody else's project documents.

A typical one has three parts:

The specifications. Numbered text chapters describing what materials, standards and performance the job needs.
The drawings. Sheets with measurements, details and notes on them.
The commercial documents. The invitation to bid, the bid form, bond requirements, deadlines, and the penalties if you finish late.

Together they usually run somewhere between a hundred and a thousand pages. Most of those pages have nothing to do with you. Buried inside them are maybe thirty or forty statements that actually decide your price.

Somebody has to go and find those.

Right now that somebody is usually your most expensive engineer, and it takes them most of a day.

Where Using ChatGPT to Read Bid Packages Genuinely Works

Let me give credit properly here, because if I skip this part you have no reason to believe the rest.

It reads well. Paste a spec section into a chat window, ask it what the welding standard is, and it will find it and explain it to you. It copes with strange wording, old terminology and bad grammar far better than searching for keywords ever did.

It explains well. A junior estimator can ask what a clause means and get a clear answer in a few seconds. That is genuinely useful and it costs almost nothing.

It drafts well. Clarification emails, submittal lists, a first version of a scope letter. All fine.

If your packages are short, if you quote a handful of jobs a month, and if the same experienced person reads all of them, then a chat window plus your own judgment is a perfectly sensible setup. I would not try to sell you anything else.

Things start to go wrong when the packages get long, the volume goes up, or more than one person starts doing the reading. That is where using ChatGPT to read bid packages stops being enough, and the next five sections are the specific places it comes apart.

Break One: It Cannot Hold the Whole Book

A chat window can only handle so much text at once. You can paste a section into it. You cannot paste six hundred pages and expect every line to get equal attention.

What happens in practice is that you decide which parts to paste. And the moment you do that, you have already made the decision you wanted the software to make for you.

Here is the uncomfortable part. The section you decide to skip is usually the one that costs you money. We recently ran a six hundred and sixty eight page public specification book through our own software. It picked out fourteen sections that mattered for process equipment, spread across three different divisions of the book. Two of them had titles that gave no hint they were relevant. If you were choosing what to paste by hand, you would not have picked those two, and neither would I.

Break Two: You Cannot Check the Answer

When a chat assistant tells you the design live load is fifty pounds per square foot, you have two choices. Believe it, or go and find it yourself.

If you go and find it yourself, you have not saved much time. If you believe it, you are pricing a job on a number that has no address.

This is not really about the model making things up, although that does happen. It is about being able to prove where a number came from. When your estimate goes out and the customer questions a figure, the answer that ends the conversation is "page one hundred and two, section 35 50 20". The answer that starts a much longer conversation is "the AI told me".

In our software, every value carries the page and the sentence it came from, and then it goes back into the original file to check that the sentence is really there. If it cannot find it again, it flags the value instead of stating it as fact.

That check sounds like a small thing. It is actually what decides whether you can put the output in front of a customer or not.

Break Three: It Does Not Know Which Product Each Answer Belongs To

This one is easy to miss, and it is where most homemade setups quietly fall over.

One package often covers several structures at once. There might be a floating dock, a gangway and a set of ladders, all in the same document. Each one of them has a deck material. Each has a live load. Each has a width.

If you ask a chat window what the deck material is, it will give you an answer. There is a good chance it is the right answer for the wrong structure.

It gets worse if you ask it to list the contradictions. It will tell you that the deck material contradicts itself, because the dock says one thing and the gangway says another. That is not a contradiction at all. Those are simply two different products.

We had to build a way of separating this out, and on our first real package it took the number of reported conflicts from twenty six down to six. The twenty that disappeared were all the dock being compared against the gangway. A list of twenty problems where fourteen are imaginary is worse than having no list, because now somebody has to sit down and check all twenty.

Break Four: It Cannot Tell a Real Problem From a Deliberate One

Here is something we found in a real public package.

The specification described the floating dock decking as composite in one place, and as treated pine in another. That looks like a clear contradiction. It was not one. The bid form carried both as priced alternates, which means the owner wanted a price for each and planned to pick based on cost.

In the same package, the gangway decking was one product in the specification and a completely different product on the drawing sheet, and there was no alternate anywhere for it. That one was real, and somebody needed to ask a question before anybody priced anything.

Both of those look identical if you just list them out. One of them is the owner making a decision on purpose. The other is a mistake that will cost you money if you miss it.

Telling them apart means reading the commercial documents and the technical sections together, and understanding that an alternate on the bid form changes what a difference in the specification actually means. A chat window that has only been given one section at a time cannot do this, because it has never seen the bid form.

Break Five: Two Estimators, Two Different Readings

If three people in your company are quoting, and each one has their own way of asking questions, you will end up with three different readings of the same package. Not because anybody is careless, but because they asked different things.

Then the job is won or lost, and nobody can go back and work out what was assumed. Six months later you are trying to understand why the margin was thin, and there is no trail to follow.

Being consistent is not an exciting benefit to talk about, but it is what turns quoting into a process instead of a set of personal habits.

Break Six: The One That Is Not About Capability At All

Everything above is about whether the tool can do the work. This one is about whether you are allowed to hand it the work in the first place, and in my experience it is the break that actually stops companies.

Start with the obvious part. On the consumer versions of these assistants, what you type can be used to improve the model unless somebody has gone into the settings and turned that off. Most people have never opened that screen.

The business and enterprise plans do offer proper agreements, no training on your content, and real security certifications, and those are genuinely fine. So this is not a reason to be scared of the technology. It is a reason to know which door your estimator walked through.

Now the part almost nobody thinks about, and it is the one that matters.

The documents in a bid package are usually not yours to share. Look at the title block on a customer's drawing sometime. A lot of them carry a line saying the drawing is confidential and must not be disclosed to any third party without prior written permission.

I have read that exact sentence on a drawing for a defence system. The moment that file is pasted into any outside service, that is a disclosure, and it does not matter how good the service's privacy policy is. The obligation is yours, to your customer, under a contract you signed.

Then there is export control. If you touch aerospace or defence work, some of those files fall under ITAR or EAR, and the rules are not about where the file is stored. They are about who is allowed to see it, including which nationalities. A general purpose assistant with support staff and subprocessors around the world is not a question you want to be answering after the fact.

And the way this actually goes wrong is not dramatic. It is not the CTO deciding to feed customer drawings into a chat window. It is an estimator at four o'clock on a Friday with a bid due Monday, who pastes eleven pages of a spec into a browser tab because it is the fastest way to get an answer. Nobody logs it. Nobody finds out. Until a customer audit asks how their drawing ended up somewhere, and the honest answer is that nobody knows how often it happened.

So the question to ask any vendor, including us, is not "is it secure." Everybody says yes to that. Ask these instead, and ask for the answers in writing:

Where does my data physically live, and is it used to train anything?
Which of your people can see my files, and from which countries?
Who are your subprocessors, and can I have the list?
If I leave tomorrow, what gets deleted and how do you prove it?
Will you sign my customer's confidentiality terms, not just show me yours?

If a vendor cannot answer those in a paragraph each, that tells you something. And if the answer to any of them is a shrug, the cheapest tool in the world is expensive

And Then There Is the Gap Nothing Can Close

Everything above is a software problem. Given enough time, somebody could solve any of it.

This last one is different, and it is the real reason I am relaxed when that question comes up in a demo.

A chat assistant has never seen your past jobs.

It does not know that you quoted something almost identical three years ago. It does not know what you charged for it, what margin you carried, what went wrong in the shop, or that you lost it by nine points and why. It does not know that your fabrication hours on this kind of structure always run about twenty percent over the first estimate. It does not know that this customer has taken ninety days to pay you, twice.

All of that lives in your own history. And in every company I have looked inside, that history is a mess. Past quotes usually sit in some combination of:

Spreadsheets on somebody's desktop, with names like final_v3_REVISED.xlsx
PDFs in a shared drive, sorted by year if you are lucky
An ERP that holds the order but not the quote that won it
Emails, which is where the real negotiation actually happened
One person's memory, which is the best source you have and also the one that eventually retires

Almost nobody has a clean, organised record of what they quoted and why. If you wait until you do, you will be waiting a very long time.

That is the part we built for, and it is why my answer to the ChatGPT question is not really about reading at all.

Our software connects to your history in whatever state it is in today. Rough spreadsheets, scanned PDFs, inconsistent names, missing fields, three different templates across five years. It does not ask you to tidy anything up first, because if tidying up were realistic you would have done it years ago.

Once that history is connected, reading the package stops being the whole product and becomes the first step. The package comes in, gets read and cited, and then the questions that actually matter become answerable:

Have we done this before? Here are the three closest jobs, and here is why they are close. Similar span, similar deck, same load case, same type of customer.
What did we charge? Here is the price that went out, the margin you carried, and what it really cost once it was built.
What did we learn? Here is the one you lost, by how much, and to whom.
What should this one be? Here is the range your comparable jobs landed in, so the number you send out is based on evidence rather than instinct.

No model on earth can answer any of those without your data. That is not something a better version of the software fixes next year. It is just how it works.

So What Should You Actually Do

Here is my honest advice, including the part where you do not buy anything.

If you quote a few jobs a month and one experienced person reads them all, use a chat assistant, get comfortable with it, and spend your money on something else. You do not have a reading problem yet.

If you quote several a week and more than one person is reading, start by getting your history into one place, even if that place is ugly. Everything you might buy later depends on it, and it is the one piece nobody can do for you from the outside.

If your packages run into the hundreds of pages and the reading is eating your engineering time, then judge any tool, including ours, on three questions:

Can it show me the page for every number it gives me? If it cannot, it is guessing, and you cannot take a guess into a bid opening.
Does it know which of my products each requirement belongs to? If it does not, its list of contradictions will waste more of your time than it saves.
Does it work with my history the way it exists today? If the answer starts with a data cleanup project, that project will never finish.

The third question is the one most vendors will try to move past quickly. It is also the only one that decides whether you end up with anything more than a faster reader.

What Mavlon Does

Mavlon is an AI quoting platform for engineer-to-order manufacturers. It reads the package your customer sends, in whatever form it arrives, and turns it into a record where every requirement carries the page it came from. Then it connects that to your own past quotes, in whatever condition they are in, so the estimate that goes out is anchored to jobs you have actually built.

If you want to watch it work on a real public package before you speak to anybody, there is a four minute walkthrough here: Spec Says 48 Inches, Drawing Says 60. It reads a hundred and seventy nine page package in forty eight seconds and finds six places where the documents contradict themselves.

Two related pieces if this was useful:

Or Approved Equal: When to Bid and When to Walk Away, about what to do when a competitor is written into the specification
Reading Bid Packages: What Five Real Ones Taught Us, where we went through five public packages and counted what we found.

Want to see it read a package from your world? Send me a public bid you have quoted and I will run it. Book a 30-minute demo.

Book a 30-Minute Demo →