Before buying RFI software, ask a vendor to run one representative question through six checks: document context, change authority, action permissions, project visibility, revision retrieval and performance measurement. A polished register is not enough to demonstrate those behaviors.
This is a procurement acceptance checklist, not another guide to running an RFI coordination meeting. Use a permitted, nonconfidential sample and record what the vendor actually demonstrates, which actions require another system and which behaviors remain unverified.
Check 1: Keep clarification separate from change authorization
An RFI requests information or clarification. It is not automatically permission to change the work, price or completion date. AIA’s G716–2004 instructions state that neither the RFI nor its response authorizes work that increases project cost or time; follow the contract’s separate authorization process. The applicable contract determines who may authorize a change and how that authorization is documented.
For example, imagine a detail that conflicts with a specification. A response may clarify the designer’s intent, but a resulting commercial change may still require a separate process. This is an illustrative scenario, not an Ezelogs customer case. Ask a vendor to show how the original question and response remain distinguishable from any later scope or cost decision.
Check 2: Retrieve the document context before testing reminders
A useful review starts with the information attached to each question:
- A clear question, with one decision or clarification to resolve.
- The relevant drawing number, revision, specification section and location.
- The requesting party and the person responsible for responding.
- A response-needed date related to the work, not an unexplained deadline.
- The response and its attachments, together with identifiable revision history.
- An explanation of what closure means and who can close the record.
A reminder cannot compensate for missing context. If a reviewer must search email to find the cited drawing revision, the system has not yet demonstrated a complete handoff.
Check 3: Test action permissions
Ask who may prepare a draft, issue the question, change its recipient, answer it and close it. These are different actions. A field contributor’s ability to suggest a question should not be presented as authority to issue an official instruction.
Check 4: Test project visibility
Then check visibility. Can the permitted project team see the response without granting access to unrelated projects? Can an administrator explain who changed the record? Do not accept a demonstration of a list filter as proof of access control; the permission behavior needs its own verification.
Check 5: Retrieve the current record and its earlier version
Run one question through preparation, issue, response, revision and closure. Ask the team to retrieve the current response and earlier version, explain who acted, and identify any separate change authorization. Record exceptions instead of converting them into a success score.
Check 6: Define what a performance measurement would mean
If you measure performance during a permitted pilot, distinguish time to first response from time to a usable resolution. Record the sample, dates and exclusions. Do not assume a vendor’s reminder feature delivers a particular percentage improvement.
Discuss your workflow with Ezelogs
Bring the checklist to an Ezelogs demo and ask the team to demonstrate the actions and permissions your project requires. Explore the construction platform, or contact the team about a specific coordination requirement. Confirm the demonstrated scope before making a procurement decision.
Related reading
For the operational workflow, see RFI coordination and response accountability. This checklist covers procurement verification; it does not rely on performance claims in that article.
Reference
AIA: Instructions for G716—Request for Information. Contract-specific responsibilities and authority should be checked against your executed agreement.