Zendesk vs Intercom for an Architecture Studio's CA Phase

During design development, questions are infrequent enough that a shared inbox or even a personal one works. Once construction administration starts, the same studio can see its correspondence volume triple almost overnight, and it stays elevated until substantial completion. A tool chosen for the quiet phase often buckles during the busy one, and a tool sized for CA can feel like overkill during design development. The honest answer is to pick based on the phase that actually strains your team, which for most commercial studios is CA, not design.

Intercom is built around a widget that greets a visitor and starts a conversation, which fits a studio's marketing site well but does little for the actual correspondence problem: a structural engineer asking whether a beam detail conflicts with the mechanical routing shown on a different consultant's sheet. That question needs to be logged against a specific drawing, assigned to whichever architect owns that detail, and tracked until it's answered, not chatted through in real time.

Zendesk's ticket model handles that better out of the box, with fields you can adapt to reference sheet numbers and consultant discipline, and a status view that shows every open coordination question across the project at once.

A contractor's request during CA is often urgent and field-driven, a detail that doesn't match conditions found on site, and it needs a fast turnaround because the crew may be waiting. A consultant's coordination question is usually less urgent but higher stakes if missed, since it can surface a conflict before it becomes a change order. Treating both the same way, first in first out, means the field question that's holding up work today sits behind a coordination question that could wait a week. Whichever tool you pick, build separate queues or priority tags for these two, because the studio's actual workflow depends on the distinction more than on which platform you chose.

A five or six person studio doesn't need shift coverage, service-level dashboards, or a proactive chat campaign on its marketing site. Both platforms will try to sell you into features built for a much larger support organization. The part worth paying for is the searchable, sheet-referenced correspondence history; the part worth ignoring is nearly everything else in the enterprise tier.

• Build the correspondence structure around active projects and their sheet sets, not around individual staff members
• Tag or route by discipline so a mechanical question reaches the person who actually knows the mechanical drawings
• Separate field-urgent contractor requests from lower-urgency consultant coordination questions
• Decide before CA starts who covers correspondence when the project architect is on-site or unavailable
• Export a full correspondence log at substantial completion, matched to the closeout set, before archiving the project

Not every question that reaches the studio during CA should reach the client's inbox. A contractor's field question about a detail that's genuinely ambiguous deserves a response the client sees, since it may affect cost or schedule. A minor clarification that any architect on the team could answer without a second thought doesn't need to become a client-visible thread, and treating it that way just adds noise to an owner's review of the project's progress.

Build that distinction into how you tag or route correspondence rather than deciding case by case under time pressure. A studio that copies the client on everything trains the owner to skim past updates, including the ones that actually matter; a studio that copies the client on nothing risks looking like problems are being hidden until they show up as a change order. The middle path takes a deliberate setup decision, not a default either platform ships with.

A reasonable rule many studios settle on: automatically copy the client on anything that touches schedule, cost, or a change to what was previously approved, and keep purely technical clarifications between consultants internal unless the answer changes what the client is expecting to see built. Write that rule down once rather than relying on each project architect to apply their own judgment consistently across every active job.