Zendesk or Intercom for a Custom Software Shop

A client emails about a broken checkout flow two weeks after launch. In Zendesk, that email becomes a ticket tagged to the project, assigned to whichever engineer owns that codebase, with an SLA clock tied to the warranty terms in the contract. The project manager can see the ticket age at a glance without pinging the engineer directly.

In Intercom, the same message likely arrives as a conversation in a shared inbox, easy to reply to fast, but without the same built-in sense of "this belongs to project X" unless you build tagging conventions yourself. For a shop running many concurrent client codebases, that structure is worth setting up on purpose rather than leaving to whoever answers first.

Dev shop clients aren't browsing a live product with a chat widget open; they're emailing, or messaging in a shared Slack channel, days or weeks after a deployment. That's closer to Zendesk's native shape than Intercom's. The in-app chat bubble Intercom is built around doesn't have much to attach to when the "app" is a client's own internal tool, not something your company runs and controls.

Intercom still works fine as a shared inbox for email-based support; it just isn't using the feature that makes it worth the extra cost over a simpler tool. If chat inside your own delivered product isn't part of the engagement, you're paying for a capability you won't use much.

The trickiest part of dev shop support isn't the tool, it's the client asking for a small change and calling it a bug. Whichever platform you pick, build a visible field or tag for "in scope" versus "change request," and route change requests to a different queue with a different owner: usually whoever handles the account relationship, not the engineer on call.

Without that distinction, warranty support quietly turns into free feature work, and nobody notices until a project's margin looks wrong at the end of the quarter.

A shop this size rarely needs a dedicated support agent. What it needs is a clear rule for who checks the inbox and how fast: same-day acknowledgment, with a real fix timeline set separately once an engineer has actually looked at the report. A full-time operations lead who owns this process, among other things, typically earns more than $100,000 a year in base pay at a company this size, so most shops fold the responsibility into an existing project manager role instead of hiring for it directly¹.

Day one: create a project tag for every active engagement and a required field for bug versus change request. Day two: write three macros covering the questions that show up on nearly every project, deployment status, how to request access, and how to report an issue with a screenshot. Day three: set the SLA, same-day acknowledgment, a realistic fix window agreed with engineering, and tell clients what to expect in the project kickoff, not after the first ticket.

By the end of the first week, the goal isn't a polished tool; it's a queue where nothing sits untouched for more than a day and nobody has to guess which project an email belongs to.

A starting setup for the queue looks like this:

1. Create a project tag for every active engagement and add a required field that separates bug reports from change requests.
2. Write macros for questions that show up on nearly every project: deployment status, how to request access, and how to report an issue with a screenshot.
3. Set a same-day acknowledgment target and a realistic fix window agreed with engineering, tied to the warranty terms in each contract.
4. Route anything flagged as a change request to the account owner, not the engineer, before it reaches a developer's queue.

If your team already lives in email and a shared project tracker, and clients rarely if ever touch a product surface you control, start with the ticket-first tool. If a meaningful share of your delivered work is a product clients log into directly, and you want a chat widget inside it for ongoing support after launch, Intercom's conversational model earns its keep. Most custom software shops fall into the first group, which is part of why ticket-first tools are the more common default in this kind of business.