An RFI asks a question about the contract documents. A submittal proves what you intend to furnish complies with them. Sending the wrong one wastes a review cycle, and on a tight schedule a wasted cycle is real time.
The difference in one line
An RFI, a request for information, asks a question about the contract documents. Something is unclear, missing, contradictory, or does not match the field conditions, and you need the design team to resolve it before you can proceed correctly.
A submittal goes the other direction. It presents what you propose to furnish or install so the design team can confirm it complies with the design intent: shop drawings, product data, samples, mix designs, and similar. You are not asking a question, you are proposing an answer and asking for confirmation.
The reason the distinction matters practically is that they follow different routes, different review periods, and different contractual consequences. Burying a design question inside a submittal is a common way to get a stamped submittal back with the question unanswered, having lost the review cycle.
When you actually need an RFI
Legitimate triggers: the drawings and specifications conflict, a dimension does not close, a detail does not exist for a condition that occurs on the job, the field condition does not match what is shown, a specified product is discontinued or unavailable in the schedule, or two disciplines occupy the same space.
Weaker triggers, which get a reputation and slower responses: asking a question the documents already answer plainly, asking for permission to do something the contract already allows, or using an RFI as a substitute for coordination among subcontractors that you should be running yourself.
An RFI is also not the vehicle for pricing a change. Where the answer will cost time or money, say so in the RFI, but the change itself moves through the change order process. Treating an answered RFI as authorization to perform extra work is a common and expensive mistake.
Writing an RFI that gets answered on the first pass
Ask one question per RFI. A single RFI containing four questions gets one answer covering two of them, and now the log shows it as closed.
Cite exactly what you are looking at: sheet number, detail, revision, and specification section and paragraph. The reviewer should not have to hunt for the condition you are describing.
State your own interpretation and propose an answer. "Detail 5/C-502 shows the pipe at 36 inches of cover and the profile on C-201 shows 28 inches at Sta 22+50. We intend to proceed per the profile unless directed otherwise" is far more likely to get resolved in one pass than "Please clarify cover." It also puts a reasonable position on the record.
Give the impact and the date you need an answer, tied to the schedule activity that is waiting. Attach a marked-up sketch or a photograph where the condition is easier to see than to describe. And number them in a single sequence so that referring back to one is unambiguous.
Building the submittal register from the specifications
The submittal register is built from the specifications, section by section. Nearly every technical section has a submittals article listing what has to be furnished, and that list is the register. Building it from the specs at the start of the job rather than discovering requirements as procurement gets to them is the difference between a controlled process and a running emergency.
For each item, record the specification section, what is required, who is responsible, when it needs to be submitted to protect the procurement and fabrication lead time, and the review period the contract allows. Then work backward from the date the material has to be on site, through fabrication and delivery, through the review period, and through the possibility of one rejection and resubmittal, to get the date it actually has to be submitted. That backward pass is the whole point of the register, and it is what turns long-lead items from a surprise into a schedule item.
Understand what the review stamps mean on your job, because they vary. Approved, approved as noted, revise and resubmit, and rejected have specific consequences, and "approved as noted" in particular requires that somebody actually implement the notes.
What a log has to track to be useful
Any log can record what was sent. A log that is actually useful records two more things: how long each open item has been sitting, and what is waiting on it.
Aging is what turns a log into a management tool. Sorted by days outstanding, it tells you in one look which items to push this week. Without it a log is an archive and everything on it looks equally urgent.
Linking to the affected schedule activity is what makes an escalation credible. "RFI 47 is 19 days old and the storm line at Sta 22+00 cannot proceed until it is answered" gets a different response than a reminder that RFI 47 is open. It is also the record that supports a time extension request later, since an unanswered RFI only becomes a delay argument if somebody wrote down what it was holding up while it was happening.
Where IAOIntel fits
IAOIntel keeps RFIs, submittals, documents, and field records on the same project record, with AI-assisted spec and blueprint analysis to find the section and sheet a question belongs to rather than searching the set by hand.
For smaller general contractors and self-performing teams without a dedicated document control group, that matters most in the aging: knowing what is outstanding and what it is holding up, while there is still time to do something about it.