Our Zendesk-to-Linear Handoff Was a Black Hole. An Agent Fixed the Loop.
The customer had been waiting eleven days. Their Zendesk ticket was marked "Pending" because Diana, our support lead, had escalated the bug to engineering. Kenji's team had fixed the bug on day four, shipped it on day five, and moved the Linear issue to "Done." Nobody told Diana. Nobody updated the Zendesk ticket. The customer followed up twice, got no response, and churned.
This happened in February. By the time I found out, the customer was already gone. When I traced the timeline, the failure wasn't negligence. It was a broken loop between two systems that don't talk to each other.
The Handoff Problem
Here's how the process was supposed to work. A customer reports a bug through our help center. Diana's support team triages it in Zendesk. If the bug requires engineering work, a support agent creates a Linear issue with the bug details and links the Zendesk ticket URL in the issue description. The support agent then sets the Zendesk ticket status to "Pending" and tells the customer that engineering is investigating.
Engineering picks up the Linear issue, fixes the bug, and marks the issue as Done. At that point, someone is supposed to go back to Zendesk, update the ticket, let the customer know the fix is live, and close the ticket.
That last step is where the loop broke. Consistently.
Kenji's engineers live in Linear. They don't check Zendesk. When they close a Linear issue, their mental model is: the work is done. They're right, from their perspective. But from the customer's perspective, nothing has happened. The ticket is still pending. Nobody has communicated.
Diana's support team lives in Zendesk. They don't check Linear. When a ticket is pending, they assume engineering is still working on it. They're right too, from their perspective. They have no visibility into whether the Linear issue has been picked up, is in progress, or was shipped last week.
Rafael tracked this over a month. Of the 34 Zendesk tickets that got escalated to Linear in March, 21 had a gap of three or more days between the Linear issue being closed and the Zendesk ticket being updated. The average gap was 4.7 days. Seven tickets were never updated at all. Those seven became the customer complaints that hit our monthly NPS numbers.
What We Tried First
The obvious solution was process discipline. We added a step to the engineering workflow: "When closing a bug that came from support, update the Zendesk ticket." We added it to our definition of done. Kenji mentioned it in standup.
It worked for about two weeks. Then sprint pressure kicked in, and engineers stopped doing it. Not because they didn't care, but because switching from Linear to Zendesk, finding the right ticket, composing an update, and changing the status is a four-minute interruption at the exact moment an engineer feels done with a task and wants to move on to the next one. The cognitive switch from "I just fixed a database query" to "Now I need to write a customer-facing update in Zendesk" is larger than it sounds.
We tried a Zapier integration next. The trigger was a Linear issue changing status to "Done." The action was supposed to update the linked Zendesk ticket. The problem: the Zendesk ticket URL was in the Linear issue description as free text. Sometimes it was a full URL. Sometimes it was just a ticket number. Sometimes the support agent forgot to include it at all. Zapier couldn't reliably extract the Zendesk ticket ID from unstructured text in a Linear description, so the integration misfired more than it worked. We turned it off after three weeks.
We tried a shared Slack channel where engineers would post when they closed a support-related issue. Diana's team was supposed to monitor the channel and update Zendesk. This worked better than the other approaches, but it added manual work on both sides. Engineers had to remember to post. Support had to monitor the channel and cross-reference with their tickets. It reduced the average gap from 4.7 days to 2.1 days, which was an improvement but still meant customers waited two days after a fix shipped to hear about it.
The Actual Problem
After three failed attempts, I realized we were treating the symptom instead of the cause. The symptom was that Zendesk tickets didn't get updated when Linear issues closed. The cause was that we were asking humans to be the sync layer between two systems, and humans are bad at being sync layers.
The handoff between support and engineering isn't just a status update. It's a translation. When engineering closes a Linear issue with an internal note like "Fixed race condition in payment webhook handler, deployed to prod," that's not something you can paste into a Zendesk reply. The customer needs to hear: "The issue causing duplicate charges has been resolved. You should see correct billing going forward."
And the handoff goes both ways. When a support agent creates a Linear issue from a Zendesk ticket, engineering needs context. Not just "customer reports duplicate charges" but which customer, what plan they're on, how many times it happened, what the support conversation looks like, whether this is a known issue or a new report. That context exists in Zendesk but often doesn't make it into the Linear issue because the support agent is summarizing under time pressure.
The loop has two translations: support context into engineering context (Zendesk to Linear), and engineering resolution into customer communication (Linear to Zendesk). Both translations require reading, interpreting, and writing. Neither is a simple field mapping.
Closing the Loop
We set up a bug tracker agent that monitors both systems. When a Linear issue linked to a Zendesk ticket changes status, the agent reads the Linear issue's activity, understands what was done, and drafts an appropriate update for the Zendesk ticket. Diana's team reviews the draft and sends it. When a new Zendesk ticket gets escalated to engineering, the agent reads the full Zendesk conversation history and creates a Linear issue with structured context: customer name, account tier, reproduction steps extracted from the conversation, related past tickets, and a severity assessment.
The difference from our Zapier attempt is that the agent handles the unstructured parts. It doesn't need the Zendesk URL in a specific format. It reads the Linear issue, identifies which Zendesk ticket it corresponds to, and makes the connection. It doesn't need a template for the customer update. It reads the engineering resolution, understands what changed, and writes an appropriate customer-facing message.
The results after three months: the average gap between Linear issue closure and Zendesk ticket update dropped from 4.7 days to 0.3 days. That 0.3 is the time Diana's team takes to review and approve the agent's draft update. Twenty-three of the last 25 drafts were sent without edits. The other two needed minor wording changes.
On the inbound side, Kenji noticed that Linear issues created by the agent had better context than the ones created manually by support agents. "The agent includes the full reproduction path from the Zendesk conversation," he said. "Our support team used to summarize that into one sentence. Now I get the actual steps the customer described, which makes the bug faster to reproduce."
What the Integration Actually Looks Like
The daily flow works like this. A customer submits a ticket. Diana's team investigates in Zendesk. If they determine it's a bug, they tag the ticket with a "needs-engineering" label. The agent picks up tagged tickets, reads the conversation, and creates a Linear issue with structured details. It posts the Linear issue link back to the Zendesk ticket as an internal note so the support team has visibility.
When an engineer picks up the issue, the agent doesn't intervene. Engineers work in Linear the way they always have. When the engineer moves the issue to "Done" and adds a resolution note, the agent reads the note, drafts a customer-facing update, and posts it as a draft reply on the Zendesk ticket. It also changes the Zendesk ticket status to "Solved (pending review)" so Diana's team sees it in their queue.
Diana or one of her agents reviews the draft, makes any needed edits, and hits send. The customer gets a response that explains what happened in terms they understand, within hours of the fix being deployed instead of days.
The process handles edge cases that our manual process never did. When an engineer adds a comment on a Linear issue saying "blocked on infrastructure, expected fix next week," the agent posts a proactive update to the Zendesk ticket: "Our team has identified the issue and is working on a fix. We expect to have this resolved next week." Customers get progress updates without anyone on the support team manually checking Linear.
The Numbers
Before the agent: 34 escalated tickets per month, average resolution communication gap of 4.7 days, 7 tickets with no engineering-to-support communication at all, 3 churned customers attributed to support silence.
After the agent: 38 escalated tickets per month (volume grew), average resolution communication gap of 0.3 days, zero tickets with missing communication, zero churn attributed to support silence in the three months since.
Rafael calculated the time savings. Support agents used to spend about 25 minutes per day monitoring the Slack channel, cross-referencing Linear issues, and writing Zendesk updates. That dropped to about 8 minutes per day reviewing the agent's drafts. Engineers used to spend about 10 minutes per day (on average, across the team) on Zendesk-related status updates. That dropped to zero.
The less quantifiable improvement is Diana's confidence. She told me in a one-on-one: "I used to dread looking at the pending tickets queue because I never knew which ones were actually fixed and just waiting on communication. Now I trust the system. If a ticket is pending, engineering is genuinely still working on it."
That trust between support and engineering was the real thing that broke when the loop was open. Fixing the loop didn't just speed up customer communication. It rebuilt a relationship between two teams that had started to distrust each other's responsiveness.
Try These Agents
- Linear Bug Tracker -- Sync bug lifecycle between Zendesk and Linear with automated status updates and customer communication
- Linear Issue Triage Agent -- Auto-categorize and route incoming issues to the right engineering team
- Linear Sprint Status Reporter -- Sprint progress reports with completion rates and trend analysis