Your RFI Log Shouldn't Live in Your Sent Folder

The question comes up on every project: "Who's waiting on an answer from the engineer?" And for most mechanical, electrical, and HVAC contractors running active projects, the honest answer is: "Let me check my email."

That answer costs more than it sounds like.

Why Email Is the Wrong Place to Track RFIs and Submittals

An RFI submitted is not a problem solved. It is a clock started. Until the answer comes back, that question is sitting on someone's desk, and your crew may be sitting, too, or worse, proceeding without the answer and creating rework.

The same is true for submittals. A submittal sent to a consultant for review is a hold placed on downstream work. If it takes 12 days to get a response and you didn't notice until day 9 that nobody had replied, that's three days of schedule compression you absorbed silently.

The problem isn't that contractors are disorganized. It's that email is structurally bad at answering the question "what is currently open, and who has it." Email is a chronological river. Finding the status of a specific RFI means fishing upstream through a thread, checking if you sent a follow-up, and remembering whether you got a verbal answer that never made it back into writing.

That process isn't tracking. It's archaeology.

What a Real RFI and Submittal Log Actually Needs to Do

Before you look at any tool, it helps to be clear on what "managing RFIs and submittals" actually means operationally. It is not filing. It is not sending. It is answering three questions at any moment:

1. What is currently open? (RFIs and submittals with no final response.)
2. Who has the ball? (Is it with the architect, the consultant, the owner, your sub, or is it sitting in your own queue waiting for you to send something?)
3. How long has it been sitting there?

Everything else, the content of the RFI, the attached drawings, the full thread, matters when you need it. But the dashboard question is always: open, closed, or stalled, and whose problem is it right now?

A good log is a list that answers all three in one glance, not a folder you have to search.

What That Screen Looks Like in Practice

Picture the site trailer on a mid-size mechanical project. On the monitor beside the drawings, there is an RFI and submittal log open. Every open item is on it: each one tagged with its number, a one-line description, where it sits in the review chain, and a colour-coded status so you can see at a glance what is answered, what is pending, and what is overdue.

The column that matters most isn't the RFI number. It's ball-in-court: whose name is next to each open line.

If it says "Structural Engineer," your PM knows to follow up with the structural engineer. If it says "Your firm," you know something is in your queue before you leave for the day. Nothing falls through because nobody looked for it, the log surfaces it automatically.

The drawings are right there beside it. You don't need to open a separate folder to see what the RFI refers to. The context and the status live together.

How PolarPath Handles RFIs and Submittals

PolarPath's project controls module logs every RFI and every submittal directly against the project. When you create an RFI, it goes into the project record with a status and a ball-in-court field. When you send a submittal for review, it sits in the log as pending review with the reviewer named.

The result is one screen: all open items, colour-coded by status, with ball-in-court visible on every row. No inbox search. No thread archaeology. You open the log and you can answer the "what's open and who has it" question in under a minute.

This matters differently depending on your role:

• Project managers stop spending mental energy remembering what they're waiting on. The list remembers for them.
• Owners and GMs can look at any active project and see whether there are stalled items with no follow-up, without calling anyone.
• Field leads know when a drawing question is still waiting on an answer before they commit a crew to a scope that might change.

PolarPath coexists with QuickBooks and the rest of your existing stack. It doesn't replace your accounting. It owns the operational execution layer, the place where RFIs and submittals actually happen, where schedule impacts start, where the ball gets dropped.

A Simple Way to Tighten Your RFI Process Right Now

Even if you're not ready to change tools, tighten your current process around these three habits:

• Assign a ball-in-court label every time you send. When you send an RFI, note explicitly whose court it's in. A shared spreadsheet is better than an inbox for this.
• Review open items weekly, not reactively. Set a standing 15-minute agenda item: what is open, how long has it been open, what needs a follow-up today?
• Log responses immediately, not later. When a verbal answer comes in, get it in writing and update the status the same day. Verbal answers that never get logged are the ones that cause disputes later.

These habits reduce the damage email does to project visibility. They don't eliminate the problem, but they make the problem smaller while you work out a better system.

The Takeaway

An unanswered RFI is a schedule risk with nobody's name on it. An unreviewed submittal is a hold on downstream work that nobody is tracking. When both of those live in your email, the only way to know what's open is to look, and looking takes time nobody has.

The fix is a log that does the tracking for you: open items listed, ball-in-court named, status visible without digging. If you want to see what that looks like on your own active projects, book a walkthrough at polarpath.ca.