A question about a drawing goes out by email on Tuesday. By Friday, the project manager isn't sure if it was answered, answered with conditions, or just ignored. Checking means opening the thread, reading back through replies, and hoping nobody sent the response from a personal address or a site supervisor's phone. Meanwhile, the crew is either waiting or proceeding on a guess.
This is the ordinary cost of managing RFIs and submittals through email. The information exists. Finding it is the problem.
What an RFI and a Submittal Actually Are
Before getting into mechanics, it helps to be clear on what these documents do.
An RFI (Request for Information) is a formal question directed at an engineer, architect, or owner. The crew or project manager needs clarification before they can proceed: a dimension that conflicts between two drawings, a spec that doesn't match site conditions, an ambiguity in the scope of work.
A submittal is a document or product sample sent from the contractor to the design team or owner for approval before installation. Shop drawings, product data sheets, material samples. Nothing gets installed until the submittal is approved.
Both have something in common: they involve a question or a request going out, and a response coming back. Until the response arrives, something is on hold.
Why Email Is a Poor Home for These Documents
Email is designed to move messages between people. It is not designed to track the state of open questions across a project.
When your RFIs live in an inbox:
- Nobody knows the full list. Each RFI exists as a thread, not as a row in a log. Seeing all open RFIs means searching, filtering, and remembering which threads are still active.
- Ball in court is invisible. Is the engineer supposed to respond, or did you commit to sending a revised sketch first? The thread knows. Your project view does not.
- Status has to be reconstructed. "Draft," "sent," "responded," "under review," "accepted," "rejected" are states that should be tracked. In email, they're inferred from the thread history by whoever reads it last.
- New team members start from zero. A site super who joins mid project has no clean way to see what questions are outstanding. They read threads or they ask the PM, which costs the PM time.
This isn't a discipline problem. It's a structural problem. Email threads are the wrong data structure for managing a list of open items with statuses.
The Mechanic That Changes It: Logging Against the Project
PolarPath's RFI and submittal module does one thing that changes the day to day experience: it logs each RFI and each submittal directly against the project record, with a status and a clear ball in court.
That means the project manager doesn't open an inbox to see what's outstanding. They open the project and see a list. Each row shows:
- What the question or approval request is
- Who it was sent to
- What the current status is (draft, sent, responded, approved, rejected)
- Whose court it's in right now
The open list is a list. Not a search result. Not a reconstructed summary. A list.
Why Ball in Court Matters
"Ball in court" sounds like jargon, but the concept is simple: at any moment, one party is responsible for the next action. When that's visible on the project record, two things happen.
First, the project manager can look at Monday morning and immediately see which items need a follow up nudge from their side and which ones are waiting on someone else. That's a different scan than reading every email thread.
Second, accountability is visible without anyone having to argue about it. If an RFI has been sitting with the engineer for two weeks, the log shows that. You don't have to reconstruct it from timestamps in an email chain.
What the Open Log Looks Like in Practice
Picture the site trailer on a mechanical project. The monitor has the project open. The RFI log is on screen beside the drawings. Status colours show at a glance which items are resolved and which are open. The PM can see in thirty seconds whether the question about the rooftop unit placement has been answered before the crane shows up.
That's not a hypothetical benefit. It's what a structured list makes possible that a disorganized inbox does not.
How to Run RFIs and Submittals More Cleanly, Regardless of Your Tools
Even if you're not using PolarPath yet, the underlying discipline here is worth adopting:
- Assign a unique number to every RFI and submittal when it's created. RFI 001, RFI 002. Submittal S 01. Numbers make reference in meetings and emails unambiguous.
- Track status explicitly, not just "sent" or "not sent." Draft, issued, response received, closed. Add "on hold" if the response raised a new question.
- Record who has the ball at every step. When you send it, it's on them. When they respond with a question back, it's on you. Keep that visible somewhere other than your memory.
- Set a follow up date when you issue anything. If you haven't heard back in seven days, you follow up. The date goes on the log, not just in someone's head.
- Review the open log at every project coordination meeting. Not emails. The log. If your log lives in a spreadsheet, that's a reasonable start. If the spreadsheet lives on someone's laptop, that's a risk.
The goal is that anyone on the project team can answer "what's outstanding?" in under a minute without asking the PM.
Where PolarPath Fits
PolarPath builds this log structure into the project itself. RFIs and submittals sit alongside the Gantt, the change orders, the daily reports, and the rest of the project controls. The PM doesn't manage a separate spreadsheet or a separate app. The project record is the record.
For contractors running both reactive service calls and planned projects out of the same operation, keeping that operational truth in one place matters. A PM pulled into a service escalation can come back to the project and see exactly where things stand, without a debrief from whoever covered the desk.
The Practical Takeaway
Managing RFIs and submittals through email isn't wrong because email is bad. It's wrong because a list of open items with statuses and accountable parties is not what an inbox is built to show you. Move the log onto the project. Give every item a status and a ball in court. Your project coordination meetings get shorter, your follow ups get faster, and nothing gets lost in a thread nobody remembered to search.
If you want to see how PolarPath structures this inside a mixed service and project operation, you can take a look at polarpath.ca.