RFI and Submittal Log Follow-Up Automation for Construction Teams

What the problem looks like on site

Most projects already have an RFI log. The trouble is what happens between entries. A question is raised on site, a message goes to the designer, a reply arrives days later in a different thread, and the log is updated only when someone remembers. A 2013 study by the Navigant Construction Forum, covering 1,362 projects worldwide, put the average turnaround for a single RFI at about 9.7 days. The same study found that 21.9 percent of RFIs received no response at all. Those gaps are rarely caused by a lack of effort. They come from a log that nobody checks against the due dates every day.

Submittals have the same weakness. Shop drawings and product data move between the subcontractor, the general contractor and the designer, and each handoff is a chance for an item to stall. A submittal that sits for two weeks in someone's inbox can hold up procurement, fabrication and the trade that follows.

Who this is for

The service fits any firm that runs RFIs and submittals on projects and wants the follow-up done consistently. That includes a general contractor managing a few dozen open items on a single building, a subcontractor who needs timestamped proof of when a question was raised, and a project controls group handling several sites at once. Firm size does not decide the fit. What matters is whether the log is kept, and whether someone chases open items on a fixed rhythm.

What is included

• A single register for RFIs and submittals, with a sequential number, the subject, the discipline, the date raised, the response due date and the named owner for each item.
• Routing rules that send each item to the designer, engineer or consultant responsible for that discipline, with a copy to the project manager.
• A reminder schedule, set during the audit, that runs before each due date, for example a set number of days ahead of the deadline.
• An escalation rule that moves any overdue item to the project manager, with the age of the item shown in the message.
• Forwarding of each answer to the subcontractor who raised the question, with the answer attached and the log updated the same day.
• A weekly summary of open, overdue and newly answered items, sorted by the affected schedule activity so the oldest and most urgent items are seen first.
• A short written procedure for the project team describing who does what at each stage, and a walkthrough for the people who use it.

How the work runs

The engagement follows five stages. Each stage ends with a decision by the client before the next one starts.

1. Audit. The current log, email habits and approval routes are reviewed. The audit measures how many items are open, how long they have been open, and where they stall. This is the stage where the free automation audit is used.
2. Process map. The steps from raising an item to closing it are mapped, with each owner named. Routing rules, reminder timing and escalation points are agreed here.
3. Build. The register, routing, reminders and escalation are set up on the tools the team already uses, starting from an export of the current log where one exists.
4. Run. The system operates alongside the team for a period, and the project manager checks its output against the real state of the log each week.
5. Support. Changes to the process, new projects and new users are handled, and the rules are adjusted when the team finds a gap.

Why the rules matter more than the software

A reminder only helps if the item has a real due date and a real owner. Many logs have neither. The first useful output of the audit is often a clean list of items with no owner, no due date, or a due date copied from the wrong schedule activity. Fixing those records is part of the build, and it is the part that most teams find most useful.

Procore, a construction management platform, describes reminders for delayed RFI responses on its own RFI product page. Tools of that kind already do parts of this work. The reason to set up a dedicated follow-up process is usually the gap between what the tool can send and what a team has agreed to do.

What the client provides

• Access to the current RFI and submittal logs, as spreadsheets, exports or read access to the project platform.
• A named project manager for each project, who receives escalations and approves the escalation rules.
• The contact list for designers, engineers and consultants, with the disciplines they answer for.
• The contract response periods that apply to RFIs and submittals on each project, so that due dates follow the agreed terms rather than a guess.
• Time from one team member for the process mapping session and the walkthrough.

Typical timeline

The durations below are planning ranges. The audit confirms the final plan for each project, and the number of projects, the number of disciplines and the state of the existing log all change the length.

What this does not cover

This service does not write design answers, approve submittals, or decide whether a change affects cost or time. Those decisions stay with the designer, the engineer and the project team, who remain responsible for their content. The service also does not interpret the contract, assess a delay claim, or replace the judgement of the person who owns the answer. It moves items to the right person and records what happened. It does not make the person respond.

Results depend on the data the project team enters. An item that is logged late, without a due date, or with the wrong owner will be followed up late or not at all. Where a project keeps no digital log and the team does not want one, the service is not worth setting up. A small project with a handful of items can often be managed with a weekly review of a shared sheet, and the audit will say so.

Next step

The first step is a look at your current log, the email threads that feed it and the people who answer it. Book a free automation audit to see which items are open, which have no owner, and whether this service is worth building for your projects.