Submittal Review That Does Not Slow the Job Down

A Submittal Is the Gate on Procurement

A submittal is the package a contractor or vendor sends for review to prove that what they intend to buy, fabricate, and install matches the contract documents: product data, shop drawings, samples, and certifications. It is a proactive quality-control step and does not change the contract. An RFI asks a question when the documents are unclear; a submittal proposes an answer for confirmation.

The part that makes it schedule-critical is what sits on the other side of approval. Nothing gets ordered until the submittal clears. That one hold backs up the purchase order, the factory slot, and the production run behind it, the longest-lead item on the job.

That means submittal dates have to be worked backward from the installation date. Take that date and back out shipping, the manufacturing lead time, and the review cycle, and you get the date the package has to be submitted. A fixture package with a 12-week build and a three-week review has to be in review roughly 15 weeks before it is needed on site. On a compressed retail schedule, that puts the biggest submittals in the first days after notice to proceed.

Retail Inverts Who Holds the Gate

On a one-off commercial project the flow follows the contract. The subcontractor submits, the general contractor reviews and stamps, the architect of record decides, and the owner is mostly a spectator, so the architect is the one holding the gate.

Retail rollout inverts that. The retailer runs a central design, brand, and construction function that is the authoritative reviewer for anything touching the prototype, the fixture program, or the brand standard. The architect at any given site is often executing the retailer's prototype the central team designed. So on a rollout that authority sits with the owner, and it is the same handful of people for every store in the program.

That structural difference is where most of the pain starts. A 10-business-day review that is comfortable on one project becomes the constraint on the whole portfolio when one brand director is reviewer of record for 30 simultaneous stores. The symptoms show up in sequence. Average turnaround creeps up first, then pending counts grow, and eventually a saturated reviewer moves faster and rejects more first passes. It surfaces as a schedule problem only after months of building as a capacity problem, and it usually gets written off as owner review delay and never diagnosed.

The Pass-Through Problem

The most common way a submittal cycle gets wasted is the general contractor treating its own review as a formality and forwarding an incomplete package straight through to the design team. The architect rejects it for missing data or an obvious coordination conflict, and two weeks are gone before anyone has looked at the actual technical question.

That step is not optional, and it is worth knowing exactly what it commits the contractor to. Under the AIA's A201 general conditions, section 3.12.5, submitting shop drawings, product data, and samples is a representation to the owner and architect that the contractor has reviewed and approved them, has determined and verified materials and field measurements, and has checked and coordinated the information against the requirements of the work and the contract documents. A package forwarded unread stakes that representation on work the contractor never did.

The reviewer's side has a boundary too, and teams get it wrong in the expensive direction. As the Engineers Joint Contract Documents Committee lays out in its series on submittal review liability, the design professional reviews for conformance with the design concept and the contract documents. That review does not assume responsibility for the contractor's means, methods, safety, or field dimensions. So an approved millwork drawing does not transfer the risk of a wall framed out of plumb. If the cash wrap does not fit, the party that failed to field-verify before fabrication still owns it, because the approval covered conformance with the design and left field verification to the contractor.

Sequential Routing Is the Cheapest Delay to Remove

Before changing anything structural, look at how reviews are ordered. Large programs commonly route a package through brand, signage, mechanical, and construction in sequence, each with its own service level.

The arithmetic makes it plain. Four reviewers at five business days each run to a 20-day minimum in sequence, even when every one hits their target. Reordered to run at the same time, the same four take five days. That gain comes purely from the reordering, with nobody reviewing faster.

Most packages do not need a sequence. A signage reviewer and a mechanical reviewer are not waiting on each other's opinion, and holding one behind the other buys nothing. Reserve sequence for the cases where one review depends on another's outcome, and put the rest in parallel, which is usually the largest turnaround gain available for the cost of a routing change.

• Route reviewers in parallel unless one review depends on another's outcome
• Give every reviewer a named service level, and measure against it by reviewer rather than by project
• Assign reviews to a role rather than a person, so a vacation does not silently stop the clock
• Escalate automatically once a package ages past its target, so it surfaces before it is late
• Track how many open reviews each person is carrying across the whole portfolio, counted across projects

What a Platform Adds Over an Inbox

Once the ordering is right, the next gain comes from taking the review off email and putting it on a record everyone can see. Routing is the core of it. A role-based chain decides who reviews each package and in what order, and it resolves to the actual people assigned to a project, so a brand reviewer and a structural engineer get pulled in by role, so nobody depends on whoever remembered to copy them. Set the chain once for a submittal type and every package of that type follows it, with room to adjust a single submittal when it needs another set of eyes.

Each reviewer records a decision of their own, Approved as Submitted, Approved with Comments, Needs revision, or Rejected, and a rejection has to carry a reason. The round closes on the combined result, so one Needs revision sends the package back without waiting on the reviewers who were already fine with it. If a reviewer goes quiet, a coordinator can skip them or close the round instead of letting the clock run.

The piece that maps straight onto the backward-scheduling math is the approve-by date. Set the date a package has to clear and the record carries the install need date and the lead times behind it, then warns you when a review needs more time than the date leaves. That warning arrives while there is still room to expedite, which is the whole reason to track the date. RolloutIQ™ runs submittals this way, on the submittals workflow inside each project, and it freezes the sent package once review starts, so an approval names the exact documents that were approved and a resubmit opens a fresh round with the prior reviewers and the history intact.

Where the Repetition Still Lives

The deepest inefficiency in retail submittals is repetition, and a tool only reaches part of it. The same standard product goes out for review at every store. The identical floor tile cut sheet gets reviewed at store 1 and again at store 40, by reviewers who have no signal that it cleared the same brand standard the last 39 times.

A shared platform leaves that repetition in place and changes the reviewer's starting point. The same routing chain applies at every store, so nobody rebuilds the review each time, and a reviewer's own open packages across every project they sit on show up as one list, without hunting store by store. The larger prize is a cross-project review queue and portfolio analytics that read every reviewer's load and every recurring rejection at once, which is where this is heading and why so many retailers still keep a spreadsheet next to a mature construction-PM deployment. A per-project tool shows where one package sits. The portfolio question, how many packages a reviewer is holding across every store this week and which are about to be late, sits outside its frame.

What to Measure

Submittal performance is measurable, and almost nobody measures it, because the data sits across projects and formats. A handful of numbers will tell you whether the workflow is healthy long before an opening date is at risk.

• First-pass approval rate, overall and by trade. A low rate in one trade usually means the documentation for that trade is the weak point.
• Average turnaround by reviewer, so you can see who is saturated before rejection rates start climbing.
• Revision-count distribution. What share of packages clear at the first revision, and what share take three or more.
• Rejection reasons, categorized. Uncategorized rejections mean a recurring root cause can hide for months.
• Open reviews per reviewer across the portfolio, which is the capacity signal a per-project view cannot give you.
• Submittal-originated change orders, which reveal the specification sections that quietly generate cost on every store.

Where to Start

None of this needs a new process document. Put the reviews that do not depend on each other in parallel, give each reviewer a role and a service level and measure against it, and set an approve-by date on every package so a slipping review surfaces before it costs you the opening.

The deeper move is to treat a submittal as a portfolio artifact that happens to touch a project, and to build the routing and the queue around that. The closer the tool gets to modeling it that way, the more the review turns into a quick confirmation step and drops off the critical path.