Why your RFIs sit unanswered — and how trade contractors fix it
Slow RFI cycles cost trades schedule, cash, and reputation. Most of the delay is happening on the GC side, but there's a lot you can do from your seat to move the needle.
By Biltix Team
If you ask a project manager at a specialty trade what eats their week, "chasing RFIs" lands in the top three. The data backs them up: across a sample of commercial projects we analyzed, the average RFI took 9.7 days from submission to a usable answer.
The frustrating part for trades: the actual answer usually takes the GC or designer minutes. Everything else is process drag — and a lot of that drag is happening upstream of you.
You can’t fix the GC’s inbox. But you can change how you ask, track, and escalate, and pull a meaningful chunk of that 9.7 days back.
Where the days actually go
We broke down a sample of slow-cycle trade-issued RFIs and found the time distribution looked roughly like this:
- Drafting (15%) — pulling drawings, writing the question, attaching context
- Routing (10%) — getting it from your PM into the GC’s system
- GC waiting (50%) — sitting in a queue without an SLA
- Designer waiting (15%) — out for clarification
- Re-loops (10%) — clarifications, missing context, re-asks
The GC waiting bucket is what you can’t directly control. But the drafting, routing, and re-loop buckets — those are yours, and they’re where most teams leak time.
The three things that actually move the number
1. Make the question impossible to misread
RFIs that include the right drawing snippet, the right spec reference, and a specific question get answered roughly 3x faster than RFIs that don’t. That’s a tooling problem more than a discipline problem — if it takes 15 minutes to draft a well-scoped RFI, your foreman will text the PM instead and the question never officially gets logged. If it takes 30 seconds because the tool pre-attaches the drawing region you pinned, it does.
2. Tag schedule impact at submission
The single highest-leverage change you can make this week: require every RFI to declare what it’s blocking. “Blocks ceiling rough-in, scheduled May 14” is a different RFI than “clarification on devices in conference rooms.” They should not sit in the same GC queue. They should not have the same SLA. They should not show up in the same dashboard view. GCs that won’t prioritize on schedule impact will at least let you escalate the high-impact ones — but only if you’ve tagged them.
3. Close the loop on context, not just the answer
When an RFI gets answered with a sentence and a sketch, that answer needs to land back on the drawing — not just in the RFI log. Otherwise the next foreman who looks at sheet A-302 has no idea the detail was clarified two weeks ago, and the question gets re-asked. Every RFI that ends without updating the source document is a future RFI.
What we built into Biltix
A few of the patterns we baked in directly because of the above:
- Pin-to-ask — pin a question to a drawing region, the snippet auto-attaches
- Schedule impact required — RFIs declare what they’re blocking on submit, your foreman sees the deadline
- AI draft answers — the AI pulls from spec PDFs and prior answers to draft a likely response so you can decide if you actually need to ask
- Drawing back-references — answered RFIs surface as annotations on the source sheet so the next person to look at it sees the resolution
It’s not magic. It’s just removing the parts of the process that don’t need to be slow on your side of the question.
If you want to see what your RFI cycle would look like with this kind of tooling on a real job, we run free 30-minute working sessions on your own drawings. Book one here.