Why PolarPath Tracks RFIs and Submittals as a Log, Not an Inbox

When a project stalls, the reason is usually sitting in someone's email. A structural question sent to the engineer three weeks ago. A product submittal waiting on the architect's approval. A drawing clarification nobody knows is outstanding because the thread got buried under forty other messages.

This is the real cost of email based RFI and submittal management: not that it is slow, but that nobody can see the open list without digging. And if you cannot see the list, you cannot chase it.

This post is a build note about a design decision inside PolarPath's RFI and submittal module. Specifically, why we built it as a structured log tied to the project, rather than a more obvious alternative. The tradeoff is worth explaining, because the "obvious" approach is what most teams are already doing, and it is the source of the problem.

The Design Decision: Log vs. Inbox

The easy version of "RFI tracking" is a shared email folder or a notification that fires when someone submits a question. You see the message, you reply, and the thread becomes the record. Many project teams operate this way, and it feels workable right up until you need to answer the question: what is still open?

That question is the one that matters. An owner's rep asks on a site visit. A superintendent needs to know before ordering materials. A PM wants to confirm the project is clear before scheduling the next phase.

With an inbox or a thread, answering that question means searching. You reconstruct the list from memory and email, and the list is only as accurate as the last person who checked.

We made a different choice: every RFI and submittal is a discrete record on the project, not a message in a thread. Each record carries its status (open, under review, responded, closed), the date it was submitted, and the ball in court, meaning the specific person or role who needs to act on it next.

The open list is the log filtered to "open." No searching, no reconstructing from memory, no inbox archaeology.

Why the Obvious Alternative Was Worse

There is a version of this module we could have built that would have felt more familiar: a conversation interface, a threaded comment panel, something closer to email. Contractors know email. The learning curve would have been close to zero.

The problem is that threaded conversations are designed to communicate, not to track state. They are good at capturing what was said. They are bad at answering whether anything is still outstanding, and they give you no way to see the workload at a glance.

When an RFI lives in a thread, its status exists only in the last reply. If the last reply was a follow up question rather than a final answer, the thread is still open, but nothing marks it that way. Someone has to read it to know.

When an RFI lives in a log, its status is a field. You set it, you update it, and the log reflects it immediately.

The tradeoff we accepted: a log requires more discipline than an inbox. Someone has to open the record and update the status field instead of just replying to an email. That is a real cost. We think it is the right cost, because the payoff is a project manager who can sit in front of a monitor in a site trailer, look at the RFI log, and tell the superintendent exactly which questions are open, who is carrying them, and how long they have been waiting, without touching email.

How It Works in Practice

Here is the concrete mechanic.

When an RFI is raised:

1. The PM or field super creates a record on the project. They name the question, attach any relevant drawing or photo, and set the ball in court (engineer, architect, owner, GC).
2. The RFI appears on the project log with status: Open.
3. Everyone on the project can see it immediately.

When the response comes in:

1. The PM updates the record with the response and changes the status (Under Review, Responded, or Closed, depending on whether the answer is final).
2. The log updates in place. The record does not disappear; it stays, and the history is there if anyone needs it later.
3. If the response raises a follow up question, the ball in court updates to reflect who is carrying it next.

Submittals work the same way:

• A product or material submittal is a record on the project, with a status (Submitted, Under Review, Approved, Rejected, Resubmit Required) and the reviewer named.
• The PM sees the full submittal log alongside the RFI log on the same project screen.

The result is that on any given day, the open list for a project is an actual list. It has a known length. Each item has a named owner. Each item has an age.

What This Changes for a Project Team

The operational shift is not about speed. It is about visibility.

A PM managing four active projects in the GTA, each with its own set of engineers, inspectors, and owner reps, cannot hold the open RFI list for all four projects in their head. With email, they cannot see it at all without opening every thread.

With a structured log, the open items across all four projects are filterable and visible from one screen. The PM knows, without searching, which project has the oldest unanswered question. They can chase the right person before a delay compounds into a schedule problem.

That is also useful for the project owner or GM. If a project is behind and the reason is a three week old unanswered RFI, that fact is visible in the log. It is not buried in a thread.

The Practical Takeaway

If your team is managing RFIs and submittals by email today, the first thing worth doing is separate from any software: start keeping a manual log. A shared spreadsheet with columns for the item, the date raised, the ball in court, and the status will immediately show you what is open and what has been sitting too long. It requires discipline, but it makes the problem visible.

The reason PolarPath builds this log directly into the project is to remove the maintenance burden from that manual process. The records exist because the work exists, not because someone remembered to update a separate sheet.

If you are running mixed service and project work and you want to see how the RFI and submittal log fits into the broader project workflow, take a look at how PolarPath brings it together at polarpath.ca.