Texting RFIs from the field

The 70-second tax nobody puts on the schedule

A foreman is standing in front of a partition wall on the third floor. The framers are looking at him. He needs to know if RFI 142 came back — specifically whether the architect approved the 6′8″ header height or kicked it back. He pulls out his phone, opens Procore, waits for it to load, taps Project, scrolls to find the right job, taps RFIs, sorts, searches “142,” opens the record, scrolls past the original question, finds the response. If he’s lucky, that’s a minute. If the app force-closes or he’s on a bad LTE signal in a stairwell, it’s three. So instead he calls the PM. The PM is in an OAC meeting and doesn’t pick up. The framers stand around. Twelve minutes of crew time evaporates because nobody could pull a single field from Procore in under a minute.

That gap — between “the answer exists in Procore” and “the answer is in the foreman’s hand” — is the retrieval tax. And on a typical commercial job it’s the most expensive line item nobody bills for.

The number: 70 seconds vs 10 seconds

We timed 47 of the most common Procore queries field staff actually run — RFI status, latest drawing revision, spec section lookup, change order amount, submittal log status, daily log entry — using two flows. Flow A: a clean install of the Procore mobile app on a current iPhone, signed in, on a real LTE connection at a jobsite. Flow B: a text message to a Forward demo line.

Flow A averaged 70 seconds per query, measured from app icon tap to the answer being readable on screen. Flow B averaged 10 seconds, measured from sending the text to the reply landing in iMessage. That’s a 7x speedup, and it understates the real-world delta because Flow A assumes the app is installed, the user is logged in, and they remember their password. On a real jobsite, the bottom quartile of Procore lookups never finish — the worker gives up and calls someone.

How texting Procore actually works

The mechanics are simpler than they sound. There’s no new app. There’s no SSO portal. There’s no “field adoption rollout.”

1. The field worker texts a number. Plain SMS or iMessage to +1 (682) 300-6750. The question is in their own words: “status of RFI 142,” “what rev is the structural set,” “what’s the change order total on this job.” No syntax, no commands, no menus. If they can text their wife about dinner, they can text the bot about a submittal.

2. The bot reads Procore via API as a service account. Forward connects to your Procore instance once, at the company level, using a service account with read access to the projects you scope. The field worker doesn’t need a Procore seat, doesn’t need a login, doesn’t need to be added to a project’s directory. The bot does the lookup on their behalf and is bound by whatever permissions you set on the service account. Same model for Autodesk Construction Cloud and OneDrive — the bot reads drawings, specs, and project files from wherever your team actually keeps them.

3. The bot replies with a cited answer plus a link back to Procore. Every answer includes the source: “RFI 142 in Procore,” “Drawing S-203 rev 4,” “Spec 09 22 16, page 7.” The link drops the user straight into the underlying Procore record if they want to verify. This isn’t a chatbot guessing — it’s retrieval against your actual project data, with the receipt attached.

4. PMs see an audit log and an approval queue for any write-back. When a field worker asks the bot to do something — log a daily report, submit an RFI, mark a punch item complete — the action lands in a PM-side approval queue before it touches Procore. Nothing writes to your system of record without a human signoff. Every read and every proposed write is logged with timestamp, user, project, and source.

That’s it. No deployment. No training session. No change-management memo to the field.

Three lookups, three text exchanges

Use case 1: RFI status check

Foreman: Status of RFI 142?

Forward: RFI 142 was answered Tuesday by the architect:
the partition wall stays at 6'8" (see attached). Source:
RFI 142 in Procore.

The foreman gets the answer, the source, and the attachment in one bubble. Crew keeps framing. PM stays in the OAC meeting. Nobody calls anybody.

Use case 2: Drawing revision check

Super: What revision is the structural set on?

Forward: Latest structural set is rev 4, dated
2026-04-12. Drawings S-101 through S-410. Source:
Procore Drawings.

Half of all drawing-related rework on commercial jobs traces back to somebody building from a superseded sheet. A 10-second text confirmation is the cheapest insurance policy on the job.

Use case 3: Spec section lookup

Foreman: What's spec section 09 22 16?

Forward: 09 22 16 is Non-Structural Metal Framing.
Latest spec rev is dated 2026-03-08. Want me to pull
the relevant page?

Field workers don’t memorize CSI MasterFormat numbers. They don’t need to. They text the number, get the section name plus the rev date, and ask for the page if they want to read it. The bot will reply with a PDF page extract right in the thread.

Why this beats “just buy them Procore seats”

Every owner-side and GC IT team has tried the “give every foreman a Procore login” approach. It doesn’t stick. Here’s why texting wins on the four dimensions that actually matter:

• Cost. Procore licenses for a 200-person field roster add up fast, and most of those users will run fewer than five queries a month. You’re paying full freight for occasional retrieval. A service-account model means one license does the lookups for the whole crew.
• Training. Foremen, supers, and laborers do not open new apps. They’ve been told to for fifteen years. They still don’t. Texting requires zero training because they’ve been doing it since 2008. Procore field adoption stalls because the UI is built for PMs, not for someone wearing gloves and standing on a ladder.
• Permission complexity. Adding every field worker to every project’s Procore directory, with the right role, with the right tool permissions, is a part-time job for a project engineer. Service-account retrieval collapses that surface area to a single config.
• Language. A Spanish-speaking framing crew can text the bot in Spanish and get answers back in Spanish, with the underlying English Procore content translated on the fly. Procore’s UI doesn’t do that. Telling a Spanish-first foreman to navigate an English RFI log is a non-starter; texting in his own language is the same thing he already does with his family.

That’s the case for SMS as a retrieval layer over Procore. It’s not a replacement for the platform — it’s a thin, conversational front door for the 90% of the field who shouldn’t have to learn it.

What PMs actually want: control

The first question every PM asks is the right one: “What stops a foreman from texting the bot to close out an RFI he shouldn’t close out?”

Three things:

• Read by default, write only with approval. The bot reads anything the service account can see. It writes nothing without an explicit PM signoff in the approval queue.
• Full audit log. Every text in, every reply out, every proposed write-back. Filter by project, user, date, action type. Export to CSV. Same audit posture you’d want for any system of record.
• Scoped permissions. You decide which projects the bot can answer about, which Procore tools it can read from, and which users on your team have approval rights for write-backs. No rogue changes, no surprises in the next OAC.

The bot is a retrieval and proposal layer. Procore stays the system of record. The PM stays the gatekeeper.

Try it on your own project right now

Text any project question to +1 (682) 300-6750 right now and see what comes back. Real demo line, no signup. Ask it about RFIs, drawings, specs, change orders, code calcs — whatever you’d normally call your PM about. If the answer is wrong or slow, we want to know. If it’s right and it’s in your hand in 10 seconds, you’ve got a sense of what it would feel like to take the 70-second retrieval tax off your foremen’s day.