STATEMETHOD

Guide

AI for RFI and submittal management.

RFIs and submittals arrive as emails, portal notifications and attachments, and someone re-keys them into a project register. Most of that handling is checking, matching and routing, which software can structure. The answers and approvals are different work: they carry design, contractual and safety consequences and belong to named people.

This guide separates the two. It covers which steps a model can prepare, which checks should be fixed software rules, where a person decides, and how to test an intake workflow on past records before building it.

Author
Hugo Sequier
Published
10 October 2026
Reading time
5 min
Format
Practical guide

The handling problem

Where RFI and submittal time actually goes.

Before an RFI is answered or a submittal reviewed, it has to become a valid record. On many projects that preparation is manual and repeated for every message, across several inboxes and a portal.

  1. Identify whether the message is an RFI, a submittal, a re-submission or something else.
  2. Find the project, package, specification section or drawing it refers to.
  3. Check that the required attachments are present, readable and the right revision.
  4. Detect duplicates and re-submissions of an existing record.
  5. Create or update the register entry with the required fields.
  6. Route the record to the reviewer named in the responsibility matrix and track the due date.

Each of these steps has an observable correct result. That is what makes intake a good candidate for a controlled AI workflow, and answering or approving a poor one.

Model interpretation

Use the model to read, not to answer.

A language model is useful where the input is unstructured: free-text emails, inconsistent subject lines, references buried in attachments. Its output is a proposal that later steps check.

Classify the message

Propose whether the message is a new RFI, a submittal, a re-submission or out of scope, with the text that supports the classification.

Output A candidate record type with its evidence.

Extract references

Pull project numbers, package codes, specification sections, drawing numbers and revisions from the message and its attachments.

Output Candidate field values with source locations.

Summarize the question

Draft a short, neutral statement of what is being asked or submitted, so the reviewer can triage without opening every attachment.

Output A draft summary marked as model-generated.

Propose likely matches

Suggest existing register entries that may be the same subject, for a deterministic check and, where unclear, a person to confirm.

Output Candidate duplicates, never an automatic merge.

The model does not answer the RFI and does not set a submittal status. Those are professional decisions with contractual effect.

Deterministic checks

Let software enforce the register rules.

Rules that have one correct answer should not depend on a model’s judgement. Software checks the model’s proposal against the register and the project rules, and blocks the record when a check fails.

  • The project and package reference exists in the register.
  • Every required attachment is present and can be opened.
  • A submittal revision is later than the last recorded revision.
  • No open record already covers the same reference and subject.
  • The response due date is calculated from the contract rules, not guessed.
  • The reviewer is assigned from the responsibility matrix, not chosen by the model.

Human authority

Name who decides each consequential step.

“Human in the loop” is not specific enough. Each decision needs a named role, and the workflow must record who accepted, corrected or rejected each proposal. The exact roles come from the project’s responsibility matrix; the split below is a common starting point.

Document controller

Accepts the checked record into the register, resolves suspected duplicates and handles messages the workflow could not classify.

Design lead or engineer

Answers the RFI. The workflow can point to the relevant drawings and specification clauses, but the answer is theirs.

Package or technical manager

Reviews the submittal and sets its status. A specification cross-check can prepare evidence; it does not approve.

Project manager

Owns the routing rules, the due-date policy and the decision to change either.

Failure and recovery

Plan for the messages the workflow cannot handle.

An intake workflow is judged as much by what it refuses to register as by what it registers. Every failure should leave the case in a known state with a visible reason.

  • Missing or unknown reference: hold the record and request the reference from the sender.
  • Unreadable or missing attachment: route to manual handling with the reason recorded.
  • Suspected duplicate: send to the document controller instead of creating a second record.
  • Low-confidence classification: place in a review queue rather than guessing.
  • Register or portal unavailable: retry safely without creating a duplicate entry.

Evaluation

Test intake on past records before building.

The register already holds the correct outcome for past messages. That makes intake one of the easier construction workflows to evaluate honestly.

  1. Export a sample of past RFI and submittal messages with the register entries they produced, including exceptions and re-submissions.
  2. Record the current manual baseline: handling time per item and how often records are corrected later. If it has not been measured, say so and measure it on the sample.
  3. Write acceptance criteria before running anything, for example: no record created without a valid reference, and every suspected duplicate routed to a person.
  4. Run the workflow on the sample and compare each step with the known outcome.
  5. Decide: build, change the design, gather more evidence, keep the process manual or stop.

Build or buy

Check what your project platform already does.

Common construction management platforms include RFI and submittal modules, and some vendors add AI-assisted features. If the platform already covers the intake path your team uses, configuring it is usually the better choice.

A custom workflow is worth evaluating when a specific gap remains: messages that arrive outside the platform, company-specific routing rules, or checks against specifications and registers the platform does not read.

FAQ

Before the next decision.

Can AI answer RFIs automatically?

Not in a controlled workflow. A model can summarize the question and point to drawings or specification clauses that look relevant, but the answer is a design or contractual decision that belongs to the responsible person.

Does AI submittal review replace the reviewer?

No. It can prepare evidence, such as which specification requirements a product data sheet appears to meet or miss, with sources. The reviewer sets the status.

What data is needed to evaluate an RFI intake workflow?

A representative sample of past messages and attachments, the register entries they produced, the routing rules and responsibility matrix, and the current handling time if known.

Does it work with an existing construction management platform?

That depends on the platform’s API access and the project’s permissions. No integration is assumed: access is checked during assessment, and a Controlled Pilot uses a sandbox or staging environment where one exists.

Assessment / one intake workflow

Assess one intake workflow.

Describe the channels, register, routing rules and current handling effort. Share business context only, not project documents.