RFI Loop

Designing a data request loop
that connects architects and manufacturers.

0→1 Design & Strategy · Design System · Stakeholder Alignment

Request, route, and resolve — without ever leaving the schedule.

RFI (Request for Information) is an in-platform way for architects to request product data from manufacturers, structured around the schedule which is a live table of architect's project material select itself, so the answer flows straight back into the field it came from.

Problem
Answers lived in inboxes
Email and spreadsheets, retyped by hand
→
What I did
One request loop, inside the schedule
As the only designer
→
Outcome
Live since Aug ’26
Six workstreams, more shipping Oct 14

How I lead this project from discovery to ship

PRODUCT

Request for Information (RFI) — a module of Acelab's Materials Hub

TIMELINE

Foundations Apr ’26 → Part 1 shipped Jul ’26 → full loop Aug ’26 → cancel + deadline requests Oct 14 ’26

Status: Shipped

MY ROLE

As the only designer on a surface this large, the job was as much about driving clarity across the team as it was about the pixels. I owned the design end-to-end and the flows to keep product and engineering aligned on one bar.

Ran discovery with both sides of the market, synthesized it into a journey map and jobs-to-be-done, and reframed a vague brief into a sharp design problem.

Defined the core objects, dual-track status model that every downstream surface is built on.

Designed the full hi-fi experience for both architect and manufacturer.

Created marketing brief, product launch plan and presented the design to Stakeholders pre-launch.

TEAM

Purti Hardikar - Lead Product Designer

Stephen Sandberg - Product Manager

Mayank Singh - Eng Lead

Bereket Abera - FE Developer

Ben Kuhn - Eng Intern

SCOPE & SURFACE

6 parallel workstreams.

Schedules, Conversations, and two new RFI dashboards (architect + manufacturer)

IMPACT

Built to move manufacturer data collection onto the platform. Early results are at the end of this page.

THE 30 SECOND VERSION

The problem with emails and spreadsheets for tracking requests

While architects trust Acelab schedules (a live data table) as their source of truth, the vital step of populating them with manufacturer data was taking place outside the platform.

The old process was an administrative nightmare. Driven by emails, spreadsheets, and paper trails, requesting manufacturer data meant leaving Acelab—and critical answers rarely made it back to the schedule.

To solve this gap

We created an end-to-end request loop that pulls manufacturer data straight into Acelab schedules. This feature directly targets the RFI bottleneck facing both architects and manufacturers.

The RFI loop, in one picture
no rep on file
Routes to AcelabManufacturer Connection
Onboards a manufactureruser, who answers
Closes the RFI,no response
sees it all, can't enter values or submit
rejoins the loop
loop closed
Material Specs cell in Schedules has a gap
RFI sent, routedper manufacturer
Delivered viaConversations
Manufactureranswers back
Answer writes liveinto that same cell
Schedule cellgap closed

The receipt in Conversations is confirmation — the schedule cell itself updates the moment the manufacturer submits.

DOMAIN CONTEXT

So, What is an RFI?

An RFI (Request for Information) is the formal way a project team resolves something the documents leave unclear, missing, or conflicting: a documented question and answer, with a clear owner and a deadline. In practice, it is rarely that simple.

Each one is a sign that information did not reach the right person in time, and left unresolved, it can stall a schedule or cost real money.

Four types come up most often on a typical project:

01
Material / product substitutionAcelab's focus
The specified product is out of stock, discontinued, or doesn't meet code.
02
Design clarification
The drawings or specs are ambiguous or incomplete.
03
Construction coordination
A field condition doesn't match what's on the documents.
04
Utility conflict
An existing utility or site condition the design didn't account for.

DEFINING THE BRIEF

We mapped how architects chase this data from Manufacturer's today

Before any solution work, I traced the actual path a question takes once it leaves the schedule — not the idealized version, the one with follow-up calls and retyped PDFs.


THE PROBLEM

Biggest Challenges of the RFI Process

Historically, this meant sending flat 50-page PDF cut sheets across tools like Procore, forcing architects to manually compare technical specifications line-by-line across multiple spec books and BIM models.

This manual process leads to:

One request, over one week

Day 1

An architect emails the manufacturer's rep about a light fixture with no lead time on file.

Day 3

No reply yet. They follow up, this time cc'ing the PM to keep it moving.

Day 6

An answer finally comes back, as a reply-all PDF cut sheet, not a schedule update.

Day 7

Someone opens the PDF, finds the right field, and retypes the lead time into the schedule by hand.

Six tools for one answer

A single material question could mean opening Procore, email, a spec PDF, a BIM model, and a spreadsheet, just to find out who to ask.

The answer arrives too late & manual re-entry

By the time a manufacturer replies, the schedule has already moved on without them,
or the deadline has, and there is no time for the architect to manually enter the information

The answer doesn’t match the question

A reply comes back vague or partial, and the architect has to go back and ask again, restarting the whole chain.

LEARNING FROM DATA & USERS

Where architects actually lose time

“

“The moment the ask left the schedule,
it stopped being connected to it.”

Architects need pricing, lead times, and compliance docs that aren't published online. Every workaround — email chains, shared spreadsheets, manual copy-paste — happened outside the tool, breaking the link between request and schedule.

Average calendar days to resolve one RFI

Today’s manual process vs. the on-platform design target

0.0
Today

→

<0
On-platform goal

Source: workflow audits and industry benchmarks · goal reflects the design target, not yet a measured result

Some fields were requested far more than others, suggesting architects consistently need certain manufacturer data more than the rest.

What architects ask manufacturers for

Share of RFIs, by request type — representative distribution

Material / product substitution — 41%
Design clarification — 28%
Construction coordination — 19%
Utility conflict — 12%

Confirms the Acelab focus: material/product substitution is the single largest slice — and the one our schedule data already touches.

Two research passes, one conclusion

LIGHT USERS

Primary research

Have you left the tool to chase manufacturer data?

Yes

79.4%

Why did the request stall?

Busy — deprioritized it

68.2%

What got in the way most often?

No clear contact to send it to

14.3%

POWER USERS

Secondary research

Did the request journey feel painful?

Yes

58.8%

Where did friction concentrate?

Re-keying answers into the schedule

68%

What got in the way most often?

Finding the right product data

23.1%

Architects preferred managing RFIs from within Schedules, not a separate tool

Despite two decades of digital transformation and the widespread adoption of construction management platforms (such as Procore, Autodesk Construction Cloud, and Bluebeam Revu), architects consistently rank RFI processing as their most frustrating, least rewarding, and most anxiety-inducing task.

What we heard

Research evidence

Where the gap is

ProcoreConstruction RFI
Mature RFI workflow: create, route to a consultant, attach drawings, reminders, full audit history.
Request only
Construction · architect / consultant
Autodesk Construction CloudConstruction RFI
RFIs inside BIM Collaborate alongside document management and model coordination.
Request only
Construction · architect / consultant
Fieldwire · Bluebeam · NewformaField / doc tools
Mobile-first field RFIs, fast PDF markup, email-integrated info management.
Request only
Construction · field / office
Material Bank · ARCAT · ConcoraMaterial platforms
Rich manufacturer content, sampling, spec-doc generation.
Discovery only
Discovery · browse only
Acelab RFIThe white space
Structured request, tied to the live schedule, answers write back into the exact cells.
Full loop
Specification · architect ↔ manufacturer

How might we enable architects to request missing manufacturer data directly within the schedule, route it automatically to the right contact, and seamlessly populate the answers back into the cells?

CURRENT STATE

Building the connection: Acelab Schedules & RFIs

To see why this mattered, you have to see where architects live. Acelab's Materials Hub is where they research, compare, and specify building products — and at its core is Schedules, a live table of every specified product on a project, with fields, images, manufacturer data, and custom columns.

What we set out to do

1

Keep schedule work on the platform

Manufacturer data was being collected in email, outside Acelab.

2

Bring manufacturers onto the platform

Give them a real queue of asks from real architects.

3

Leave a reliable record

Who provided what, and when, so schedules stop drifting.

How we’d knowTime to dataSchedule fields completedResponses on platformProjects sending an RFI in 3 months

CURRENT STATE

How AI shaped the process, not just the output

Same loop this whole case study describes, applied to how it got built — ideate, design, decide, ship, with AI doing the heavy lifting on speed at each stage.

01 Ideate · PM + UX
Claude: discovery synthesis, journey map + JTBD
HTML prototype: testing the loop end-to-end
02 Design · UX
Dual-track status model
Hi-fi flows in Figma, both sides of the loop
Claude Code: stress-testing edge cases
03 Decide · PM + Eng
Written decision docs, no PRD, just defensible calls
Trade-off table: 3 options × 5 criteria
Data model locked: schedule cell writes
04 Build · Eng
Engineering handoff to Mayank + Bereket
Built against the same schedule cells
Shipped, Aug '26
An edge case found in testing sends the status model back for a revision
Screenshot placeholder
FIG. 05.2Showing our test prototypes in Claude & Claude Code which helpes us ship faster
Gap in schedule to RFI sent
No rep on file
Gap in schedule
RFI sent
Delivered
Manufacturer answers
Writes live
Gap closed

How does an architect actually send an RFI from Schedules?

We reduced the multi-faceted painful workflow to a 5-step flow

The architect starts in Schedules and selects the products they want to request data for.


Each RFI is grouped automatically by manufacturer, so the next steps are just choosing which fields the rep needs to fill in, setting a deadline and recipients, confirming the product details, and sending. Even after sending, the architect can cancel it until the manufacturer submits a response.

Confirm products
Review the selection, grouped by manufacturer.
Select fields
Choose which fields manufacturers should fill.
Recipients
Set a deadline and pick a recipient.
Details
Share project info, write the message.
Review & send
Preview exactly what each recipient sees.
Confirm products

PLATFORM STATE

Once an RFI is sent, the status reflects on both sides

Every RFI carries a status on both sides.

Most of it lines up step for step, with a few states that only make sense on one end. An architect can also cancel any RFI until it’s answered, and it stays on both dashboards as Canceled.

DraftSentIn ProgressOverdueCompleteCanceledanswered on timeany time before it’s answeredrequest acceptedAArchitect seesMManufacturer seesDraft—SubmittedNewIn ProgressIn ProgressOverdueOverdue, lockedCompleteCompleteCanceledCanceled
Canceling and deadline requests ship Oct 14 ’26.
The other chair, what a manufacturer sees when they open an RFI
FIG. 06.1The other chair, what a manufacturer sees when they open an RFI

PLATFORM STATE

How does a manufacturer rep receive and respond to an RFI?

The design had to hold up for the whole loop, not just the moment an architect hits send.


Every choice below maps to a specific UX principle, which solved the RFI loop.

ARCHITECT
MANUFACTURER
1Selects products from Schedules & sends the RFI
Jakob's Law people expect this to work like every other tool they already use.
2Delivered via the existing Conversation, a receipt is logged automatically
3Receives the RFI
4Sees a compact schedule, only sent products & fields
Visibility of status & recognition over recall always show where things stand, never make someone remember.
5Fills in requested info
6Sends the complete response
7Response delivered back to the architect as a receipt
8Receives a receipt of the manufacturer's response
Tesler's & Hick's Law complexity has to live somewhere; better in the system than on the person.
A detailed flow chart showing the entire loop, the edge cases and the messy middles
FIG. 05.2A detailed flow chart showing the entire loop, the edge cases and the messy middles

PLATFORM STATE

The conversation holds the receipt

Each RFI leaves two cards in the conversation: one when it is sent, one when the manufacturer answers.

Together they are a lasting receipt, and they update if the RFI goes overdue, is extended or canceled.

The card in context — not a separate inbox, a message in the thread you already had
FIG. 05.1The card in context — not a separate inbox, a message in the thread you already had

The conversation holds the receipt

Each RFI leaves two cards in the conversation: one when it is sent, one when the manufacturer answers. Together they are a lasting receipt, and they update if the RFI goes overdue, is extended or canceled.

Untouched
12 weeks
no change
Typed
12 weeks
saved
Placeholders
At send
→
At submission
forever
Snapshot PDFs
Answers overwrite live schedule cells
☐ Don’t show againSend
Write warning
Sep 15 overdue→Reopen requested→Oct 2 extended
was Sep 15
Deadlines
Cancel this RFI?
Manufacturer has started a response
KeepCancel RFI
Cancel after opening
Extension requestedbefore deadline
Reopen requestedafter
Notices
Canceling and deadline requests ship Oct 14 ’26.

PLATFORM STATE

Now that the RFI has been recieved, how does a MFR fill in information?

The response view is a schedule, not a form.


Rather than build a separate submission form, a manufacturer fills in an RFI from a scoped copy of the same schedule the architect works in — the same grid, the same cell-editing behavior, narrowed to just the products and fields that were actually requested.


Comments and edits work the way they already do in Schedules, so there's no second interaction model for either side to hold in their head.

The other chair, what a manufacturer sees when they open an RFI
FIG. 06.1The other chair, what a manufacturer sees when they open an RFI

EDGE CASES & BUSINESS OPPORTUNITY

But what happens when there is no MFR on Record?

Routing assumes there’s a named rep or brand admin on file.


Plenty of manufacturers don’t have one yet, and that can’t be a dead end for an architect waiting on an answer. When there’s no rep on record, the RFI routes instead to an internal Acelab role, the Manufacturer Connection, who works it directly on the platform: reaching out to the manufacturer, then either onboarding a user to own the response or closing the RFI out.

RFI, no rep on file

→

Manufacturer Connection

(Alisa) — non-authoritative proxy

↗

Onboards a manufacturer user & hands off the RFI

↘

Closes the RFI with no response

The constraint that makes this defensible: the Manufacturer Connection can see everything a manufacturer would, but can’t enter values, submit the RFI, or overwrite the schedule. It’s a proxy for reach, not for authority.

What onboarding a manufacturer user actually involves

Invite sent to a manufacturer contact

→

Manufacturer creates an account

→

Lands directly on the RFI waiting for them

Not a generic dashboard signup. The account gets created directly into the RFI conversation that triggered the invite.

Screenshot placeholder
The Manufacturer Connection's internal queue, RFIs waiting on a rep who doesn't exist yet
FIG. 06.2Working the queue with no rep on file

Early results

Measured against the four signals above.

placeholder
[XX%]
of active projects sent an RFI within 3 months of launch
placeholder
[X days]
median time to data, down from [X days] by email
placeholder
[XX%]
of manufacturer answers submitted on platform, not by email
Key Takeaways

What this project confirmed about how I design

Five things this project made non-negotiable, not just true for RFI.

Constraints are material, not obstacles
The strongest decisions here came from designing with engineering and business limits, not around them. Per-manufacturer batching won because it worked within real constraints, not despite them.
Most of the work happens before the screen exists
Defining what a status means, who owns a decision, what happens on failure — that's where this actually got designed. The interface just had to stay out of the way of good decisions already made.
Trust is the metric, not speed
Users forgive a wait. They don't forgive silence. Every decision here optimized for the system visibly proving it did what it said, not just doing it fast.
Knowing what to defer is part of the craft
Shipping an approval gate before there was data to justify it would have been solving a problem that didn't exist yet. Restraint is a design decision too.
Iteration got cheap. Judgment didn't.
When testing a data shape takes an afternoon instead of a week, "we didn't have time to check" stops being a valid excuse. AI removed the excuse — it didn't remove the job of knowing what's worth checking.
iClick
itravel
iRead
iHike

Beyond Work or
know more About Me! :)

Copyright © 2026 Purti Hardikar. Brewed with Matcha 🍵 Claude Code & Framer, 📍 Sunnyvale, Bay Area, USA.