Submittal Packages Are the Busywork Contractors Remember You For

It’s 3:40 on a Tuesday. A mechanical contractor’s project manager calls your inside salesperson. The engineer won’t release the order until the submittal package is approved, and the general contractor wants it by Thursday morning. The quote has 26 lines. Could you send the cut sheets?

So your salesperson stops quoting. They open manufacturer websites one by one, download data sheets, find out two of them are an older revision, hunt for the warranty documents, highlight the exact model number and options on each page, build a cover sheet in a word processor, and merge it all into one PDF. Two and a half hours later it goes out. Three quotes that came in during that time are still sitting.

The contractor won’t remember the price you gave them on fittings. They’ll remember who got them a clean package the same day, and who made them wait.

I’ve never built a submittal for a living. I ran a digital agency, Infographic World, for almost 18 years, and these days I use AI to fix problems inside businesses. My expertise is narrower than yours: how a document moves through an office, and how much of a skilled person’s day goes to copying, finding and formatting. Submittals are almost all of that.

Where the two hours go

Break one package into its real steps and the pattern is obvious. Very little of it requires judgment.

1. Read what’s needed. The contractor sends the quote number, a spec section, sometimes an equipment schedule. Somebody works out which lines need documents and which kinds.
2. Find the documents. Product data sheet, cut sheet, installation instructions, warranty, and whatever listing or compliance certificate the spec asks for. Each one lives on a different manufacturer site, in a shared drive folder somebody named years ago, or in an email from a rep.
3. Check the revision. Manufacturers update sheets. The one in the folder may not match what ships today.
4. Mark it up. Highlight the model, size, voltage, finish or option that applies, so the engineer doesn’t have to guess which row of the table you mean.
5. Build the cover sheet. Job name, spec section, contractor, distributor contact, a line index, and notes.
6. Flag substitutions. If the spec names one manufacturer as the basis of design and the quote carries another, that has to be stated clearly. Burying it is how a package gets rejected, or worse, approved by mistake.
7. Assemble and send. Merge, bookmark, name the file sensibly, and send it.
8. Resubmit. When it comes back marked “revise and resubmit,” do part of it again.

Steps two, three, five and seven are hunting and formatting. Step six is the only one where getting it wrong does real damage, and it’s the one that gets rushed because the clock ran out on the others.

What an AI-assisted submittal desk looks like

It starts from the quote or the order

The system reads the quote or sales order lines, the items, the quantities and the manufacturer model numbers. If the contractor sent a spec section or an equipment schedule, it reads that too and lines it up against what you quoted.

It pulls documents from your library, not from memory

For each line, it pulls the data sheet, warranty and any compliance documents from a document library you keep, tagged by item and by revision date. Anything older than the window you set gets flagged, so a person checks the manufacturer’s current version before it goes out. Anything missing gets flagged too. It never invents a document or fills a gap with a similar product’s sheet.

It drafts the cover sheet and marks the pages

It builds the cover sheet from your template, writes the line index, and points to the exact model and options on each data sheet. It looks like your best person’s work, because it uses their template.

It flags every substitution for the engineer

Where the quoted item differs from the basis of design, the cover sheet says so in plain words: specified item, proposed item, and the differences the documents show. It doesn’t claim the substitute is equal. That’s the engineer’s call, and the package says the engineer decides.

A person checks it and sends it

Your salesperson opens a draft package, checks the flags, fixes what needs fixing and sends it. Their experience goes into the flags, not into merging PDFs.

Run the numbers

There are two pieces of value here: the hours, and the orders that depend on the package.

The formula for hours is packages per month times hours per package times the loaded hourly cost of the person building them. The formula for orders is the number of orders a year you lose or see delayed because a package was late, times the average gross margin on those orders.

Say, for the sake of the math, a supply house builds 30 packages a month at 2.5 hours each. That’s 75 hours a month. At a made-up loaded cost of $40 an hour, that’s $3,000 a month of inside sales time spent hunting and merging. If review takes 40 minutes instead, about 55 of those hours go back to quoting.

Now the orders. Keep the same made-up example and say one job a quarter slips to a competitor, or stalls for weeks, because the package was late or came back incomplete. If those jobs average $40,000 in material at a 22 percent gross margin, that’s $8,800 a quarter, or $35,200 a year, on four orders. The orders are usually the bigger number.

To run it for real, pull three numbers:

1. Packages built in the last 12 months, from your sent mail or job files.
2. Hours per package. Time the next five with a stopwatch, start to send.
3. Orders lost or delayed over a late or rejected package last year. Ask your inside and outside salespeople. They’ll remember.

Picture a Monday, before and after

This is a made-up scene. Monday morning, three package requests came in over the weekend, one marked urgent. The salesperson who usually builds them is out until Wednesday. The urgent one waits. Tuesday afternoon, somebody else starts it, sends an outdated warranty document, and the engineer sends it back on Friday.

Same Monday with the new setup. By 8 AM, three draft packages are waiting in a review queue, each built from its quote, each with a cover sheet and a list of flags: two documents past their revision window, one substitution against the basis of design, one line with no warranty on file. A second salesperson clears the flags, calls the manufacturer rep about the missing warranty, and sends the urgent package before lunch.

Nobody’s judgment got skipped. The searching and the merging did.

What has to be in place first

• A document library for the items you actually sell on submittals. Start with the top 100. Each file tagged by item number, manufacturer, document type and revision date.
• Model numbers in the item master that match the manufacturer’s, including the option codes. If your item description says “2x4 troffer, LED” and nothing else, the system can’t find the right sheet and neither can a new hire.
• A cover sheet template your best person likes, with fields for substitutions and notes.
• One owner for the library, who refreshes it on a schedule and when a rep says a sheet changed.

The quoting article makes the same point from a different angle: clean item data pays off in every downstream document, and submittals are one of the most visible.

Guardrails worth keeping

• The engineer rules on substitutions. The package states differences. It never claims equivalence.
• Revision dates get checked. An outdated sheet is worse than a missing one, because nobody notices it.
• A person sends every package. Nothing goes to a contractor or engineer unreviewed.
• Contractor plans stay private. Specs and drawings from a job belong to the job. Use business-grade tools that don’t train on your files, and keep access limited.

How you’ll know it’s working

• Hours per package, from request to sent.
• Share of packages sent the same business day they were requested.
• Packages returned for missing or outdated documents, as a share of all packages.
• Substitution flags raised versus substitution problems found by the engineer. You want the system to catch them first.
• Orders tied to a submittal that were released versus lost.

Where I’d start

Pull every submittal package from the last year and list the items that appear most often. Build the document library for the top 50 to 100 of them, with revision dates. Then let the system draft the next ten packages while your best person reviews each one and writes down what they changed.

If this sounds like your week, send me a note through the contact page.