# What Is an RFI in Construction? Meaning, Process, and How to Write One

> Source: https://deviationcheck.com/guides/what-is-an-rfi-in-construction/

A detail on the drawings shows one thing, the spec section calls for another, and the sub on site cannot order material until someone says which one wins. That question, asked the right way, is an RFI.

A Request for Information is how a contractor gets a gap or a conflict in the contract documents resolved by the people who own the design, on the record, instead of guessed at in the field. A clear RFI comes back in days. A vague one - three questions buried in a paragraph, no drawing reference, no proposed answer - bounces, and the order waits while the schedule burns.

## What an RFI actually is

An [RFI](/glossary/rfi/), short for Request for Information, is a formal written question from the contractor to the design team, asking them to clarify or resolve something that is missing, unclear, or conflicting in the contract documents - the drawings and the [spec sections](/glossary/spec-section/).

The word formal is doing work. An RFI is not a phone call or a hallway question. It is numbered, logged, and tracked, and the written answer becomes part of the project record. If the response changes what gets built, that paper trail is what protects the contractor when the cost or schedule impact gets sorted out later.

Most RFIs start with a subcontractor who hits the problem first. The sub writes it up, the general contractor reviews it and forwards it to the [architect of record](/glossary/architect-of-record/), who answers it or routes the engineering parts to the right consulting engineer. The GC sits in the middle as the contractual conduit, which is why a sub pre-checking their own work and a PM screening what comes in both need to know what a good RFI looks like.

## Why RFIs happen

No set of drawings and specs is perfect, and RFIs are how the imperfections get resolved instead of guessed at. The common triggers:

- **A conflict between documents.** The floor plan gives one dimension, the detail gives another, or the spec names a product the drawings contradict.
- **A missing detail.** A real condition on site has no detail drawn for it.
- **A discontinued product.** The spec names a [basis of design](/glossary/basis-of-design/) the manufacturer no longer makes.
- **A field condition that does not match the drawings.** Existing construction is not where the as-builts said it would be.
- **Ambiguous language.** The spec can be read two ways, and the two readings cost different amounts.

Every one of these is a fork in the road. Resolve it with an RFI and the answer is on the record. Guess at it in the field and you have created a [deviation](/glossary/deviation/) that surfaces during submittal review or, worse, after the work is installed.

## What goes in a good RFI

A design team can answer a clear RFI fast and a muddy one slowly, or not at all. A strong one has:

- **A unique number.** So it can be logged, tracked, and referenced. One RFI, one number.
- **A specific reference.** The drawing sheet, the detail, and the spec section the question is about. Let the reviewer find it in seconds, not minutes.
- **One clear question.** Not three. Bundled questions get a partial answer and a round trip for the rest.
- **The context.** A sentence or two on the condition, with a photo or a clip of the drawing where it helps.
- **A proposed answer.** The single most useful thing you can add. When you suggest a resolution, the design team can often confirm it rather than build one from scratch, which is faster and keeps the solution close to what you wanted.
- **A need-by date.** State when you need the answer to hold the schedule, and flag if the item is on the critical path or is a [long lead item](/glossary/long-lead-item/).
- **A cost-impact flag.** If any likely answer changes cost, say so up front so it routes to the right people.

## The RFI process, step by step

The workflow is consistent even when the software is not:

1. **Identify and document the issue.** Whoever finds it, usually the sub, captures the conflict or gap with references.
2. **Write the RFI.** Number it, point to the exact documents, ask one question, and propose an answer.
3. **Submit it through the channel.** The sub sends it to the GC, who reviews it for clarity and forwards it to the design team. It goes into the RFI log, often the project's management software, so nothing falls through.
4. **The design team responds in writing.** They clarify, pick an option, or issue a sketch. There is no universal deadline. Many contracts build on the AIA A201 general conditions, which require the architect to respond with "reasonable promptness," then pin that to a set window in the contract or [Division 01](/guides/how-to-read-a-spec-section/), commonly one to two weeks.
5. **Log and distribute the answer.** The response goes back through the GC to the sub and into the record. The RFI itself does not change the contract sum or the schedule. If the answer does change the work, that is handled separately - a [change order](/glossary/change-order/) when cost or time moves, a supplemental instruction when neither does.

Step 2 is where most of the delay gets made or avoided. The goal is a question the design team can answer in one pass, without coming back to you for what you should have put in it.

## How an RFI differs from a submittal

RFIs and submittals are the two main review streams on a project, and they are easy to confuse because both are paperwork that flows to the design team. They do opposite jobs.

An RFI asks a question. A [submittal](/glossary/submittal/) proves an answer: it is the product data, [shop drawings](/glossary/shop-drawing/), and samples showing that the products and methods the contractor plans to use meet the spec. One seeks information, the other seeks approval. They are logged and tracked separately, but they feed each other, because an RFI that clarifies which product is acceptable changes what the next submittal has to show.

The full breakdown - who initiates each, what triggers it, and how an RFI answer reshapes a submittal - is in [RFI vs submittal](/guides/rfi-vs-submittal/).

## Common mistakes

- **Burying several questions in one RFI.** You get a partial answer and a delay on the rest. One question per RFI.
- **Skipping the proposed answer.** An RFI with no suggested resolution makes the design team do all the work, and it takes longer.
- **Using an RFI for the wrong job.** A request to use a different product is a [substitution request](/glossary/substitution-request/), not an RFI. A question about what the spec means is an RFI. Mixing them up routes the paperwork to the wrong process.
- **No need-by date.** If you do not state when you need the answer, do not be surprised when it lands after the order had to be placed.
- **Not logging it.** An RFI answered by email and never logged is an answer you cannot prove you got, and a decision the next person on the project cannot find.

When an RFI answer changes what a product has to be, the next submittal has to reflect it, and that hand-off is exactly where deviations slip in. Deviation Check compares a submittal against the spec it is held to and flags the differences in plain language. [Start a review](/#pricing) on a real package and see what it catches.

## Frequently asked questions

### What does RFI stand for in construction?

RFI stands for Request for Information. It is a formal written question from the contractor to the architect or engineer to clarify or resolve something unclear, missing, or conflicting in the contract documents.

### Who answers an RFI?

The design team answers it, usually the architect of record, who may route the engineering parts to the relevant consulting engineer. The response comes back in writing through the same log the question went out on and becomes part of the project record.

### How long does a design team have to respond to an RFI?

There is no universal deadline. The AIA A201 general conditions require the architect to respond with "reasonable promptness," and many contracts pin that to a set window, often one to two weeks. The clock matters: a late answer on a critical-path item is a frequent basis for a delay claim.

### What is the difference between an RFI and a submittal?

An RFI is a question asking the design team for information or a decision. A submittal is proof, such as product data, shop drawings, or samples, that the contractor's proposed products and methods meet the spec. One asks, the other proves, and they are logged and tracked separately.