Make vs Zapier for Civil Engineering Firms Tracking RFIs

An incoming RFI needs to reach the engineer who actually owns that discipline or project area, not sit in a shared inbox until someone happens to open it. A basic rule, route by project, works fine in either tool for a firm with one engineer per active project.

Most firms aren't that simple. An RFI touching structural and civil scope on the same project needs to reach both, and one touching only a drainage detail needs to reach just the civil engineer assigned to that piece. Make's router can evaluate an RFI's tagged discipline against a project's assigned team and route to the right subset of people, which a chain of Zapier filters can approximate but becomes harder to maintain as project team structures vary.

A submittal review that sits too long can push back a contractor's procurement timeline, and on a project with a tight schedule that delay compounds fast. A scheduled check that flags any submittal approaching its review deadline, escalating to a project manager if it's not moving, catches this before it becomes a schedule problem the client notices.

This works reasonably in either tool for a single project. Rolling that check up across every active project into one internal view of at-risk submittals, so a principal can see firm-wide bottlenecks rather than checking each project separately, is where Make's ability to aggregate across multiple projects in one scenario earns its complexity.

Phase-based billing, schematic design, design development, construction documents, construction administration, ties an invoice to a milestone that a client or a project manager has to formally approve, not just a task getting marked done in your PM tool. Wiring the invoice trigger to the approval event, rather than to a task status that might not reflect that approval, matters for cash flow that depends on getting phase invoices out promptly.

Make's ability to check that every deliverable under a phase is both complete and approved, not just complete, before firing the invoice is a more accurate version of this than a Zapier flow triggered on a single task's status.

Tie phase billing to real approval with these rules:

• Tie the invoice trigger to an explicit approval event, not to a task status that may only mean internal completion.
• Have a client or project manager formally approve each phase, such as schematic design or construction documents, before an invoice can fire.
• Confirm that a task status genuinely reflects approval before you use it as a trigger for anything.
• Avoid invoicing unapproved work, which creates an awkward conversation with the client.

A typical project involves your firm alongside an architect, other engineering disciplines and a contractor, and a document revision often needs to reach several of those parties at once without flooding anyone's inbox with duplicate copies of the same notification routed through different channels.

Build a single notification point per document event, with the recipient list pulled from the project's actual team roster rather than a static distribution list that goes stale as team members change project to project. Either tool can do this, but Make's ability to check who's currently assigned before sending, rather than trusting a list built once at project kickoff, keeps notifications accurate over a project's full lifespan.

Time-to-fill for technical roles has been running long across the industry¹, which makes it tempting to lean on automation to cover gaps left by a stretched team. Resist letting that automation drift into anything resembling engineering judgment, an RFI response, a design decision, a stamped calculation, which has to come from a licensed engineer regardless of how much of the surrounding paperwork is automated.

The clearest line: automation should move information and enforce deadlines, never generate or approve the engineering content itself. A firm that keeps that boundary explicit avoids the slow drift where a convenient shortcut in a busy week becomes an unreviewed habit months later.

Put this in writing as a short internal policy rather than leaving it as an assumption everyone's expected to share. Name exactly which automated actions are fine to run unattended, routing, reminders, document distribution, and which always require a licensed engineer's direct review, so a new hire or a contract drafter joining a busy project has a clear line to follow instead of guessing where it sits.