Submittal Reviews for Interior Scope: A Practical Review Sequence for Designers
Journal

May 27, 2026

Submittal Reviews for Interior Scope: A Practical Review Sequence for Designers

Submittal Reviews for Interior Scope: A Practical Review Sequence for Designers

Why submittal reviews slow down

Most submittal delays are not caused by missing information. They are caused by a missing review sequence.

When a submittal arrives without a clear path for checking it, the review becomes reactive. The designer scans for obvious problems, adds a few notes, and sends something back. The response is vague enough that the contractor has to follow up. Procurement stalls. The schedule slips.

A consistent review sequence fixes this. It does not mean reviewing everything at the same depth. It means knowing what to check first, what to compare it against, and what a complete response looks like before you start.


The four submittal types and what each one needs

Interior scope submittals generally fall into four categories. Each one has a different review focus.

Submittal typeWhat you are checkingCommon gap to catch
Product dataManufacturer specs, finish options, and compliance documentationSpec section mismatch, discontinued finish, or missing compliance data
Shop drawingsDimensions, configurations, and fabrication intentConflict with design drawings, missing clearances, or wrong material call-out
SamplesColor, texture, sheen, and material matchDrift from approved finish schedule or client selection
SubstitutionsWhether the proposed product meets design intentMissing equivalency argument or spec deviation not flagged

The review question is different for each type. Mixing them up is where reviews get slow.


A practical review sequence

For each submittal, work through this sequence before writing a response.

1. Identify the submittal type and the spec section it belongs to.

Before checking anything else, confirm what you are reviewing and where it lives in the documentation. A shop drawing for custom millwork and a product data sheet for a plumbing fixture need different reference documents.

2. Pull the relevant reference documents.

For product data: pull the spec section and the finish schedule. For shop drawings: pull the design drawings, the finish schedule, and any relevant RFI responses. For samples: pull the finish schedule and the approved sample log if one exists. For substitutions: pull the spec section and the original product data.

If the reference documents are not organized and accessible, the review will take longer than it should. This is where documentation gaps become procurement delays. On small studios managing multiple active projects, the principal is often the only person who knows where the current finish schedule lives. That is a bottleneck worth fixing before submittals start arriving.

3. Check against design intent, not just dimensions.

Dimensions and configurations matter, but the deeper question is whether the submittal reflects what the design actually requires. A shop drawing can be dimensionally correct and still miss the design intent if the material, finish, or configuration has drifted.

For substitutions, the review question is more specific: does the proposed product meet the performance, aesthetic, and specification requirements of the original? If the substitution request does not include a clear equivalency argument, return it before reviewing further. Reviewing a substitution without that comparison is slower than asking for it upfront.

4. Write a response that is specific enough to act on.

This is where vague responses create the most rework.

Consider the difference between these two responses to the same shop drawing:

  • Vague: "Revise and resubmit."
  • Useful: "Revise dimension at cabinet return to match elevation on sheet A-4.2. Confirm finish matches finish schedule item FF-12. Resubmit."

The first response sends the contractor back to guess what needs to change. The second response gives them exactly what to fix. The useful response takes slightly longer to write once. The vague response creates a follow-up cycle that takes longer to resolve.

5. Log the response and update the submittal record.

A submittal log does not need to be elaborate. At minimum it should track:

  • Submittal type and spec section
  • Date received
  • Date reviewed
  • Response given
  • Whether a resubmittal is expected

Without a log, the same question comes back in a different form, often weeks later when the project has moved on.


A simple checklist by submittal type

For small studios, a short checklist by type reduces the cognitive load of each review and makes it easier to delegate first-pass screening to a junior team member before principal review.

Product data

  • Spec section confirmed
  • Finish option matches finish schedule
  • Compliance documentation present (if required by spec)
  • No discontinued or substituted items flagged without a formal substitution request

Shop drawings

  • Design drawings pulled and current
  • Dimensions checked against design intent
  • Finish and material call-outs match finish schedule
  • No conflicts with RFI responses or design revisions

Samples

  • Finish schedule pulled
  • Sample compared against approved selection, not memory
  • Sheen, texture, and color checked under consistent lighting if possible
  • Sample log updated

Substitutions

  • Original spec section pulled
  • Equivalency argument present before review begins
  • Side-by-side comparison of original and proposed product reviewed
  • Any spec deviation explicitly flagged in response

Where the sequence breaks down

The most common breakdown is step two: the reference documents are not ready when the submittal arrives.

If the finish schedule is not current, if the drawing set has been revised but not distributed, or if the spec sections are not organized by submittal type, the review becomes a search exercise before it becomes a review. The designer who owns the documentation is usually also the one doing the review, which means the bottleneck compounds.

The practical fix is to treat documentation organization as pre-submittal work, not mid-review scramble. Before the contractor starts submitting, confirm that the finish schedule is current, the drawing set is distributed, and the spec sections are accessible by trade or submittal type.

The second common breakdown is substitutions arriving without an equivalency argument. Designers sometimes review them as if they were standard product data. A substitution that does not include a side-by-side comparison of the original spec and the proposed product is not ready to review. Returning it with a clear request for that comparison is faster than building the comparison yourself.


A note on review depth

Not every submittal needs the same depth of review. Product data for a standard specified product with no finish variation is a lighter check than a shop drawing for custom cabinetry.

The sequence above applies to all four types, but the time each step takes will vary. The goal is not to review everything at maximum depth. The goal is to make sure nothing important is missed because the review was rushed or unstructured.

For small studios, the checklist approach also creates a natural split between first-pass screening and principal review. A junior team member can confirm that the reference documents are present, the spec section matches, and the submittal type is correctly identified before the principal spends time on the substantive check.


Keeping procurement moving

Submittal review is not the most visible part of a design project, but it is one of the places where slow or unclear responses have the most direct impact on schedule and cost.

A consistent review sequence does not add overhead. It removes the guesswork that creates overhead. For designers managing multiple active projects, the difference between a structured review process and a reactive one usually shows up in procurement timing, not in the quality of individual responses.

For remodelers and contractors working with design partners on interior scope, Creo's contractor partnership support is built around this kind of production-side collaboration: helping design and build teams stay aligned through documentation, review, and handoff.

Ready to work with a studio that moves at your pace?

Get In Touch