RFI and submittal tracking: how to stop items slipping through the cracks

RFIs and submittals: what they are and why they matter

An RFI (request for information) is a formal question from the contractor to the design team or owner about something unclear, missing or conflicting in the drawings or specs. A submittal is a package the contractor sends for review to show exactly what will be installed: shop drawings, product data sheets, samples, mockups, test reports.

Both are paper trails with real consequences. An RFI answer can change scope, which is how many change orders begin. A submittal approval is often the trigger to release fabrication or place an order, so a late approval on a long-lead item, such as switchgear, elevators, storefront or custom millwork, can push the schedule by weeks. And when there is a dispute later, the logs are usually the first thing everyone reaches for.

Submittal reviews typically come back with a stamp such as "approved," "approved as noted," "revise and resubmit" or "rejected." The exact wording varies by firm. The last two mean the clock restarts, which is why resubmittals are where tracking most often breaks down.

Why RFIs and submittals slip through the cracks

Items slip because the system relies on someone remembering. On a busy job with dozens of open items across several parties, memory doesn't scale.

• Conversations happen everywhere. The formal RFI is in the project platform, the clarification is in an email, and the real answer came by phone and was never written down.
• No due date. Items are logged with a sent date but no "response required by" date, so nothing ever looks overdue.
• No clear owner. Is the submittal waiting on the sub to send it, the PM to review it, the architect to stamp it, or the engineer of record? If the log doesn't say, nobody chases.
• Resubmittals get lost. A "revise and resubmit" goes back to the sub, and the item quietly drops off everyone's radar.
• The register is built late. Required submittals are discovered piecemeal as the job goes, instead of being pulled from the specs on day one.
• No link to the schedule. The log says an item is "open," but not that the material needs eight weeks of lead time and has to be on site in ten.
• Cost impact isn't flagged. An RFI answer that adds scope gets built without anyone pricing it, and the right to a change order gets weaker as time passes.

What a good tracking log contains

A good log answers four questions at a glance: what is it, who has it, when is it due, and what does it affect. Here are the fields that matter for each.

Field	RFI log	Submittal register
Number	Sequential RFI number	Usually spec section plus sequence (and revision number)
Description	Subject and the question	Item and type (shop drawing, product data, sample)
Reference	Drawing sheet, detail or spec section	Spec section and paragraph requiring it
Responsible party	Who asked, who must answer	Sub or supplier preparing it, reviewer(s)
Ball in court	Who has the next action now	Who has the next action now
Key dates	Sent, response required, answered	Required submit date, sent, returned, needed-on-site date
Status	Open, answered, closed	Not submitted, under review, approved, approved as noted, revise and resubmit, rejected
Impact	Cost or schedule impact (yes/no), linked change order	Lead time, linked schedule activity

The "ball in court" and "required by" fields do most of the work. With just those two, you can sort the log into a daily chase list.

How to set up a tracking system that works

Set up the register before work starts, give every item one home, and review it on a fixed rhythm. The steps below work whether you use a spreadsheet or a project management platform.

1. Build the submittal register from the specs. Go through each specification section and list every required submittal. This is tedious on day one and saves you every week after.
2. Work backward from the schedule. For each submittal, note when the material or work is needed, subtract fabrication and delivery lead time and the contract review period, and that gives you the date the submittal has to go out. Flag long-lead items.
3. Check the contract for response times. Look in the general conditions and Division 01 sections for required review periods for submittals and response times for RFIs, and use them to set "required by" dates on every item you send.
4. Pick one system of record. All RFIs and submittals get a number and a row in one place. Email and phone conversations are fine, but the outcome gets recorded in the log.
5. Assign ball in court on every change. Every time an item moves, update who has it. If you only update one field, update this one.
6. Mark cost and schedule impact on every RFI answer. If the answer adds work, start the change order process right away and link the two.
7. Review open items weekly. Sort by days overdue and by schedule impact, and walk through them in the weekly OAC or sub meeting.
8. Close the loop on resubmittals. A "revise and resubmit" creates a new revision row with its own due date, not a note in the old one.

Response times, review periods and notice requirements for claims are set by your contract. This is general information, not legal advice. Read your general conditions and talk to your attorney if a delay may become a claim.

What to automate, and what to keep with the team

Automate the logging, reminders and reporting. Keep the technical writing and judgment with the people who know the building.

Good candidates for automation:

• Drafting the initial submittal register by reading the specification book, for the PM to review and correct.
• Logging new RFIs, submittals and responses that arrive by email, with the attachment filed in the right place.
• Calculating due dates from the contract review period and the schedule.
• Sending reminders to whoever has the ball in court, on a set cadence, with escalation to the PM when an item goes past due.
• Flagging long-lead submittals that are at risk of missing their order date.
• Flagging RFI answers that mention added work, so someone decides whether to price a change order.
• Producing the weekly open-items report for the owner or the OAC meeting.

Keep with the project team: writing the RFI question clearly, deciding whether a submittal complies with the spec before it goes to the architect, interpreting answers, deciding on change orders, and anything relationship-sensitive with the owner or design team. This is the same human-in-the-loop split we recommend for automating draw requests: software handles the follow-through, people make the calls.

Spreadsheet, platform or AI agent?

The right tool depends on how many jobs you run and how many systems the conversations already live in.

• A spreadsheet is fine for a handful of small jobs, as long as it has the fields above and someone reviews it every week. It won't chase anyone for you.
• A construction project management platform gives you structured RFI and submittal workflows, numbering and reminders. It works best when the architect, engineers and subs actually use it. When half of them reply by email anyway, someone still has to copy everything in.
• An AI agent works across your email, file storage and platform. It can read incoming messages, update the log, send the reminders and assemble the report, flagging anything it isn't sure about. It is most useful when your team is already stretched and the bottleneck is follow-through rather than software.

Illustrative example: a PM running two jobs has 40 open RFIs and submittals between them. If chasing, logging and updating the weekly report takes 15 minutes per item per week, that is 10 hours a week, a quarter of a full-time role, spent on follow-up rather than building. Even cutting that in half gives back a day a week. These figures are invented to show the math; time your own team for a week to get the real number.

RFI and submittal follow-up is one of the paperwork processes Tarvora automates for construction teams. To weigh what that is worth against what it costs, see how much AI implementation costs a small business. If your crunch is weekly prevailing wage reporting, our guide to certified payroll automation covers that workflow.

Frequently asked questions