Zendesk vs Intercom for a Civil Engineering Firm's RFI Log

A support ticket usually resolves in one exchange. An RFI is a formal question with a reference number, a response deadline tied to the project schedule, and an answer that may need a professional engineer's review before it goes back to the contractor. The tool has to hold a due date that means something contractually, not just a service-level target the software invented on its own.

Zendesk's ticket fields can carry your firm's own RFI number instead of a generic ticket ID, and its due-date field can be set from the response-time clause in the contract rather than a default. That distinction matters more here than it does for most support queues, because a late RFI response can become someone's argument on a delay claim months later.

Submittal review is slower and more procedural than RFI response: a shop drawing comes in, gets checked against the spec, gets marked up, and goes back out as approved, approved as noted, or rejected. That's a multi-day cycle with a paper trail, not a conversation. Intercom's strength is proactive, in-the-moment messaging, which is a poor match for a review that takes a structural engineer several days and produces a marked-up PDF as the actual deliverable.

Zendesk's ticket-and-macro model handles this better: a submittal ticket can sit open with a clear status, move to the reviewing engineer, and close with the marked-up file attached. Intercom can technically do the same thing with its own ticketing layer, but you're using it against its natural strength rather than with it.

If your firm runs a public-facing proposal portal, say for design-build teams submitting qualifications ahead of an RFQ deadline, Intercom's chat widget can field quick eligibility questions before they turn into a formal RFI to your business development lead. That's a genuinely different kind of traffic than construction-phase correspondence, and it's the one place a proactive chat tool outperforms a ticket queue for a firm like this.

Every civil or structural project ends with a closeout binder, and the RFI and submittal logs are part of it. Before you commit to either platform, confirm you can export a complete log, numbered in your firm's own convention, with every attachment and revision intact, in a format the owner's team can actually open without your login. A tool that stores everything beautifully but exports poorly creates a real problem the one time a year you need the whole record at once, usually under a deadline of its own.

• Confirm ticket numbering can mirror your firm's existing RFI and submittal log convention, not a new one
• Set due-date fields from the actual response-time clause in each contract, not a platform default
• Verify attachment version history survives export, including stamped PDFs
• Decide upfront whether a project engineer or a shared intake role owns first triage
• Test the export format with a real closeout binder before your first live project depends on it

On larger civil or structural projects, the design side often includes several firms working for the same owner: your firm as engineer of record, a geotechnical subconsultant, and sometimes the owner's own reviewing engineer, each needing visibility into some but not all of the correspondence. Set access per project rather than assuming one level fits every job. A geotechnical subconsultant typically needs to see the RFIs that touch their scope, not the full project log, and the owner's reviewer often needs read access without the ability to close items themselves.

Getting this wrong in either direction creates a real problem. Too much access and a subconsultant sees pricing or liability-sensitive discussion that was never meant for them. Too little and they're excluded from a coordination question that actually affects their own design, which is how conflicts resurface later as change orders instead of getting caught during review. Review access levels at the start of each project instead of reusing whatever the last project happened to have configured, since team composition rarely repeats exactly, and a subconsultant from one job may not be involved in the next at all.

The same logic applies to the owner's own facilities or capital projects staff, who often want visibility into schedule-driving correspondence without needing to see every routine exchange. Build a role for that kind of limited, read-heavy access rather than defaulting them into full project-team permissions, since an owner representative flipping through unrelated internal back-and-forth erodes trust faster than simply not having access at all.