An RFI and submittal log usually looks under control right up until one link falls out of the chain. One drawing reference, one due date, one answer that came back by email and never made it onto the register, and the whole log is suddenly suspect.
You have watched this happen. A subcontractor sends a question from the field. The design team needs more context before it can answer. A submittal package is three-quarters complete, waiting on one product data sheet. The answer decides what gets ordered, what gets fabricated, and whether the owner signs off in time. The official log says one thing, the latest email thread says another, and the coordination meeting turns into forty minutes of working out what is actually blocked and who is sitting on it.
If you run the project, the design coordination, or the owner relationship, this is how to make RFIs and submittals behave like work you can see on any given morning, instead of a weekly reconciliation you have learned to dread. The parts are almost certainly already in your project management platform. The problem lives in the space between them.
The status you need is who has the ball and what it is holding up
Before any tooling, get honest about what a working RFI and submittal process has to tell you at eight in the morning, without a phone call. Which items are open, overdue, or stuck, and whose turn it is to act on each one. Which drawing, spec section, or package the item touches, and what is still missing before anyone can answer it. Which of the open items could move procurement, field work, or the owner's next decision.
A log answers only the first half of one of those questions. It confirms an item exists and records a date. What it does not tell you is whose court the ball is in, what the item is waiting on, and what it will cost the schedule if it keeps waiting. That gap, between an entry on a register and a piece of work you can actually move, is where projects quietly lose days.
A quick test
Pick one overdue RFI and time yourself. Can you see the reviewer who owns it right now, the drawing or photo behind it, the exact information it is waiting on, and what it holds up downstream, without opening three systems? If that takes more than a minute, the status is not visible early enough to act on. By the time it becomes legible, it is already late.
How an RFI or submittal actually moves today
The delay is rarely inside any single tool. A project management platform holds the log. The drawing set lives in document control. The submittal register is its own module. Vendor data sits in email and shared folders. Each of those is fine on its own; the friction is in the handoffs, where an item changes hands and loses its context on the way.
Walk one item through the sequence it is supposed to follow:
- An item arrives: a field question, a vendor submittal, or a design query.
- Someone captures it and links the drawing, spec section, or photo it depends on.
- It is checked for missing information before anyone forwards it.
- It goes to the reviewer who can actually answer it, by discipline, package, or the owner.
- The reviewer answers, approves, rejects, or asks for a resubmission.
- The decision is logged against the item, and the impact on procurement or schedule is noted.
Written out, it looks orderly. In practice it stalls at steps three and four. Items get forwarded half-complete, so the reviewer receives a package they cannot act on while the clock keeps running. And items land with a reviewer nobody named clearly, so they sit because each person assumed someone else had the ball. Everything after those two steps, the answer, the log entry, the impact note, waits on them.
Where the routing quietly breaks
The breakpoints are predictable. They look slightly different on a fit-out than on a ground-up build, but the underlying pattern repeats.
The item gets forwarded before it is complete
A submittal goes to the architect missing a product data sheet, or an RFI goes to the engineer without the photo that shows the real condition. The review clock starts anyway. Days later it comes back marked revise and resubmit, and only then does anyone ask the sub for the piece that was missing at the start. The delay looks like slow review. It was actually an incomplete package that should never have been sent.
Nobody actually owns the review
An item lands in a shared inbox or a general queue, and each person assumes another discipline has it. A coordination RFI that touches both mechanical and structural is the classic case: it sits because neither consultant is sure it is theirs. Nothing feels overdue to anyone, and yet a week is gone.
Whose court the ball is in stays invisible
The log shows an item as open, but not whether you are waiting on the sub, the architect, a consultant, or the owner. Without that, the meeting cannot tell the difference between an item you can push and an item you are simply waiting on, so everyone chases the wrong things.
A finish sample and a structural RFI compete for the same attention
When every item looks the same on the log, a low-stakes sample selection and an RFI holding up steel fabrication get the same line and the same urgency. The team spreads its meeting evenly across items that do not deserve equal weight, and the schedule-critical one waits its turn.
The answer comes back by email and never reaches the log
The reviewer replies in a thread, work proceeds on the strength of that email, and the register is updated later, if at all. Now the official log and the real answer disagree, and the next person to open the item cannot tell which one to trust.
The response clock runs with nobody watching it
Many contracts set a review window for RFIs and submittals. When no one is tracking the clock per item, windows are missed quietly, and the first time it matters is when a delay claim turns on who was late. A stuck item is a schedule problem today and a contractual one later.
Follow a handful of real items before you redesign anything
The instinct is to design the perfect process first. Resist it. Take one active job and follow five or six real RFIs and submittals from the moment they arrive to the moment they are answered. Watch where each one actually stalls, who touched it, how long it sat, and what it was waiting on.
You will almost always find the same two stalls: an item forwarded before it was complete, and an item sitting with a reviewer nobody named. Following real items also shows you which facts people keep asking for in the meeting, the drawing behind the question, whose court the ball is in, and what the item blocks. Those become the columns your first queue needs. You are not inventing a process, you are writing down the one you already run, minus the parts that lose things.
What the first review queue should hold
You do not need a new platform to start. You need one queue that joins each open item to the few things people keep asking about in coordination. For each item, that is the type and the drawing, spec, or photo behind it; the named reviewer whose court the ball is in, the due date, and the exact information it is waiting on; and what it holds up, whether that is procurement, install, the schedule, or an owner decision.
Two habits keep the queue trustworthy. Check for missing information before an item is sent for review, so reviewers stop receiving half-packages they cannot act on. And separate the routine items from the ones carrying real cost or schedule risk, so the meeting spends its time where the schedule is actually exposed.
| Item | What backs it | Whose turn it is | Waiting on | What it blocks | Status |
|---|---|---|---|---|---|
| RFI on ceiling access detail | Drawing A-410, site photo | Architect | Confirmed revised detail | Ceiling install | Open, 9 days |
| Mechanical submittal package | Vendor upload, spec section 23 | Subcontractor | Missing acoustic data sheet | Procurement of long-lead unit | Incomplete, not yet sent |
| Finish sample approval | Meeting note, sample log | Owner | Owner selection | Owner decision | Escalate before Friday |
A worked example: four jobs and three hundred open submittals
To make this concrete, here is an invented but realistic situation. Say a design-build firm is running four active jobs and carrying around three hundred open submittals and forty live RFIs between them. There is no real client here, just the kind of load a busy project engineering team recognizes.
Follow one submittal. The mechanical subcontractor uploads a package for the rooftop air handling units, the long-lead item on the critical path. It looks complete. It is not: the vendor left out the acoustic data the spec section requires. Under the current setup the project engineer forwards it to the architect anyway, the ten-day review window starts, and eight days later the architect returns it marked revise and resubmit for a missing attachment. Two weeks are gone before anyone asks the sub for the one sheet that was missing on day one. The order for the units slips, and the slip does not surface until the procurement look-ahead flags it.
Now follow one RFI. A field superintendent on a different job asks how a ceiling access panel meets a revised duct run. The question sits in an email thread for three days because it is unclear whether the architect or the mechanical consultant owns the answer. When the answer finally lands, it changes the detail enough to become a change order, but the log still shows the RFI as simply open, so the cost and schedule impact stays invisible until the next owner meeting.
Neither of these is a people problem. In both cases a small completeness check at intake and one clearly named owner would have saved the two weeks. That is what a review queue is for.
Route each item to the reviewer who can actually answer it
Most of the ball-in-court confusion comes from not deciding, in advance, who the first reviewer is for each kind of item and where it goes next. You do not need a rule for every possibility, just for the common ones, so routine items move without a conversation and only the genuinely ambiguous ones need a decision. The table below is the sort of simple map that ends most of the "whose is this" delay.
| Item type | Where it usually starts | Who it has to reach | What to watch |
|---|---|---|---|
| Field RFI on a structural detail | Sub to project engineer | Structural engineer of record, sometimes the architect too | An answer that quietly becomes a change order |
| MEP coordination RFI | Sub to project engineer | Mechanical, electrical, or plumbing consultant, often more than one | A clash two disciplines must agree on before anyone installs |
| Shop drawing submittal (steel, curtain wall) | Fabricator to general contractor to architect | Structural engineer, then back with an approval status | Long-lead fabrication that cannot start until the stamp returns |
| Product data submittal | Sub to project engineer to architect | Specifier or the relevant consultant | A missing attachment that stalls the whole package |
| Material or finish sample | Sub to project engineer | Architect, then the owner for selection | An owner decision with no deadline attached to it |
| Owner-directed change query | Project manager to owner | Owner, then the design team to price and detail | Cost and schedule impact that has to be agreed before work proceeds |
Watch whose court the ball is in and how long the clock has run
Once items are moving to the right reviewer, the next thing the meeting needs is a single view of who is holding what and for how long, measured against the response window when the contract sets one. The point is not to name and shame. It is to surface the two or three items where the clock itself is the risk, before they turn into a schedule slip or a claim. The numbers below are illustrative.
| Item | Ball in court | Days open | Contract response window | Schedule exposure |
|---|---|---|---|---|
| RFI on ceiling access detail | Architect | 9 | 7 working days | Ceiling install slips if it stays open past this week |
| Mechanical submittal package | Subcontractor (missing attachment) | 4 | Not started, clock not yet running | Long-lead unit cannot be released to order |
| Structural shop drawings | Structural engineer | 12 | 10 working days, now overdue | Fabrication start date at risk |
| Finish sample approval | Owner | 6 | None specified | No hard deadline, quietly drifts |
The data and systems this touches
The information you need is spread across project management, document control, drawing registers, submittal logs, email, shared drives, and vendor folders. You will not connect all of it at once, and you should not try. Agree one thing first: for each field, which system is the source of truth, and who owns each change of status. When the queue says an item is with the architect, everyone has to trust that the queue, not a side email, is the current word.
For most teams the queue can start from exports and a shared tracker before any deeper integration. The rule that keeps it honest is that every row has an owner, a due date, a link to its source, and a plain reason it matters. Wiring the queue to the same source of truth as your change orders and field issues pays off quickly, because an RFI answer often turns into a change order and a field question often starts life as a site report or field issue.
Where AI helps, and where it must not
AI earns its place here when it prepares the work for the reviewer instead of standing in for the reviewer. It can summarize a long RFI thread down to the actual question. It can pull the drawing references, spec sections, and dates out of a submittal and drop them into the right fields. It can sort the routine items from the ones with schedule risk, flag a package that is missing an attachment before it goes out, and draft the reviewer-ready context so the engineer starts from something clean rather than a raw email.
What it must not do is answer the RFI, approve the submittal, or decide what is compliant. Those are engineering judgments that need source links, the right stamp, and an accountable person behind them. The working pattern is AI-assisted preparation followed by a real review, never an answer that cannot be traced back to a drawing or a spec.
Where the answer stays with the reviewer
It is worth being explicit about the line, because on a construction project the consequences are physical and contractual. AI can extract, sort, flag, and draft. Every engineering answer and every approval stays with the responsible reviewer.
A person still decides whether a revised detail works, whether a submittal meets the spec, whether an RFI answer carries a cost or schedule change that needs the owner's agreement, and whether two disciplines have genuinely resolved a clash or only appear to have. The queue exists to protect that judgment from being buried under chasing, searching, and version control, not to replace it. When the reviewer signs off, the queue records who signed and against which source, so the answer holds up later.
What tells you it is working
Watch a few numbers over the first month. The days an average RFI or submittal spends open before it is answered. The share of items overdue or stuck at any given moment. How many items were sent for review missing information, and whether that count falls week over week. If your contract sets response windows, track how often you are inside them, because an overdue response is not just a delay, it is exposure on a claim.
When those numbers move, the coordination meeting changes character. Instead of reconstructing what is blocked and arguing about who has it, the team walks a queue everyone already trusts and spends its time on the handful of items that actually threaten the schedule.
Traps that keep the log untrustworthy
A few mistakes tend to undo this work, and they are worth naming before you start.
The first is treating the log as the workflow. A log records that an item exists and stops there; the queue has to show whose court the ball is in and what the item is waiting on, or people drift back to their private trackers. The second is trying to integrate every system at once. The queue can and should start from exports; a six-month integration project before anyone sees value is how these efforts die. The third is over-automating the answer. The moment the tool appears to approve a submittal or resolve an RFI on its own, reviewers stop trusting it and the schedule risk moves somewhere you cannot see. The fourth is building a status view nobody helped design, so it lists items but not the one thing each reviewer needs in order to act. Keep the reviewer in the design, keep the answer human, and start small enough to be trusted.
A first few weeks that do not need a new platform
You do not have to boil the ocean to feel this working. A focused few weeks on one active job is usually enough to prove the queue and change how the coordination meeting runs.
| Period | Focus | What should exist by the end |
|---|---|---|
| Week 1 | Map one active job's RFIs and submittals from arrival to decision | A review queue showing item, source, whose court the ball is in, due date, impact, and status |
| Weeks 2 to 3 | Connect only the project management, document control, and submittal data needed to keep the queue current | A queue that updates from real data, with AI summarizing and flagging under a reviewer's eye |
| Week 4 | Run the coordination meeting off the queue | A status the whole team trusts, with response times and ball-in-court visible |
How Ubisar would build this with you
In week one, we would take one active job and map its RFI and submittal states from arrival to decision: the item, the drawing or spec behind it, what it is waiting on, whose turn it is, the due date, and what it holds up. The first thing you would have is a review queue that shows item type, source, whose court the ball is in, the response clock, the impact, and the status.
In weeks two and three, we would connect only the project management, document control, and submittal data needed to keep that queue current, then add AI to summarize long threads, pull references and dates out of packages, and flag the items missing an attachment, always under a reviewer's eye. By week four, the coordination meeting should run off the queue instead of a reconciliation.
We work month to month, one workflow at a time, as AI, data, and tech implementation for real estate and construction teams, starting from $4,000/month and cancel anytime. If your RFIs and submittals are where the schedule quietly slips, send us one live job and we will map its review queue with you.