An RFI is a written request asking the design team to clarify something the contract documents do not answer. A submittal is the product data, shop drawing, or sample you send for review before installing. Both are clocks. A tracking system numbers each one, ties it to the spec section and drawing it came from, names who owes the next action, and escalates when a response runs past the review period the contract allows.
Why answers arrive after the work is built
The log is an email folder
Questions go out as emails with attachments. Replies land in different inboxes, sometimes to the superintendent and sometimes to the project manager. There is no single list of what is outstanding, so the answer to what are we waiting on depends on who you ask.
Nobody owns the next action
An RFI goes to the architect, who forwards it to the structural engineer, who sends a question back. Three parties each believe someone else has it. Without a ball-in-court field the item sits, and the first to notice is the foreman who cannot proceed.
Submittals stall on long-lead items
The stair package comes back marked revise and resubmit. The fabricator’s lead time does not start until approval, and nobody recalculated the delivery date. The impact shows up as a missed milestone rather than a submittal problem.
Cost impact never converts into a change order
An RFI response directs a different detail than the one bid. The field builds it, because that is what the answer says. It never becomes a change order request, because whoever read the answer was not the person who prices things.
The RFI log, response tiers, and the past-due ladder
Below is the log schema, field by field, with the tier rules and escalation rungs shown in the same list because they are part of the record rather than a separate process.
| Log entry | Format | Behavior |
|---|---|---|
| RFI number | Sequential per job, never reused, such as RFI-041 | A withdrawn RFI keeps its number and carries a void reason |
| Spec section and drawing reference | 09 51 00 and A-501 rev 3 | An RFI with no document reference returns to the asker before transmittal |
| Question, with a proposed answer | One paragraph plus a marked-up sketch | The log flags an entry submitted with no proposed answer |
| Cost or schedule impact flag | Yes, no, or unknown | A yes routes to the project manager and estimator, and lands on the weekly exposure list until it becomes a change order request |
| Priority tier | Tier 1 field stopped, Tier 2 upcoming work, Tier 3 informational | The asker proposes the tier and the project manager confirms it |
| Response window | Tier 1 one business day, Tier 2 five, Tier 3 ten | The contract review period overrides the internal default |
| Ball in court | A named person, not a company | Changes at every transmittal; the log shows only the current holder |
| Sent, due, and responded dates | System-set at transmittal and at receipt | Not hand-entered, which is what makes them hold up later |
| Rung one, at the due date | Reminder to the design contact, copied to the project manager | Sends without human action |
| Rung two, two business days past due | Item added to the owner-architect-contractor meeting agenda | The agenda assembles itself from past-due items before the meeting |
| Rung three, five business days past due | Drafted notice citing the number, sent date, and days outstanding | Drafted for a person to review and send, never sent automatically |
| Disposition | Answered, answered with cost impact, superseded by an ASI, or withdrawn | An answer that changes scope opens a linked change order request |
Running the log day to day
One entry point for the whole team
The superintendent raises an RFI from a phone with a photo and a sketch. The project engineer raises one from the office. Both land in the same numbered log, so there are no two lists to reconcile.
Transmittal generates the document and the clock together
Sending produces the formatted transmittal, attaches it to the record, sets the sent date, and calculates the due date from the tier and the contract review period. Nothing is dated by hand.
Responses land back on the record
A reply attaches to the entry instead of sitting in an inbox, and ball-in-court flips. Where the design team uses their own portal, we record the transmittal reference so the log stays the single source of dates.
The submittal register is built from the specs at the start
Before the first submittal goes out, the register is populated from the specification sections with required submittal types, responsible subcontractor, and target dates worked back from the schedule. This is the step small general contractors most often skip.
Past-due items surface where people already look
The past-due list appears on the project dashboard and in a weekly digest to the project manager and superintendent, sorted by tier and days outstanding. It is the same list that becomes the meeting agenda.
What feeds the log and what reads it
- document workflow and transmittal generation — Formatted RFI and submittal transmittals are produced from the log entry and stored against the record.
- field forms for raising an RFI from the site — A superintendent opens an RFI with a photo and a marked-up sketch without going back to the office.
- approval routing across parties — Tier rules, ball-in-court changes, and the escalation rungs run on their own schedule.
Is this a fit for your business?
A good fit when
- You run commercial or public work with a real specification book and an architect of record
- Your RFI count on a job runs past what one person can hold in their head
- You have been on the wrong end of a delay conversation with no dated record
- You self-perform and coordinate subcontractor submittals at the same time
Probably not a fit when
- You build residential remodels where the owner answers questions by text the same day
- The general contractor above you requires their own platform and gives you a seat
- You want a project management suite with scheduling and cost control in one tool
What to have ready
- The specification table of contents from one active job
- The review periods your contracts state for RFIs and submittals
- Your current log, in whatever form it exists
Questions we get asked
The architect uses their own portal. Does this still help?
Yes, and this is the common case. Their portal tracks what they have received; it does not track your internal readiness, your subcontractors’ submittal obligations, or your own dates. We keep your log as the record of what you sent and when, and reference their transmittal numbers so the two reconcile.
Who sets the priority tier?
The person raising the item proposes it and the project manager confirms it. That two-step matters, because when the asker sets the tier alone, everything becomes Tier 1 within a month and the tiers stop meaning anything. Confirmation keeps the escalation ladder credible with the design team.
Does the system send the delay notice automatically?
No. It drafts one from the log entry with the number, the sent date, the due date, and days outstanding filled in, and puts it in front of the project manager. A written notice to an owner or design team carries contractual weight, and software should not decide to send it.
Can we track submittals if we never formally logged them?
Yes, and starting mid-job is normal. We build the register from the specification sections for scope not yet submitted, and enter already-approved items as historical records so the closeout package is complete.
Related
- change order approval workflow
- punch list and project closeout tracking
- document automation services
- workflow automation for construction companies
Tell us what the process looks like now and we will map what a system would need to do. No obligation, and you keep the map either way.