Support and engineering teams almost never break because the people on them are bad at communicating. They break because the tools they live in are built for two different jobs, and the natural workflow each tool encourages does not connect to the other one. Support reps live in HubSpot, where every record is a customer with an SLA and a conversation history. Engineers live in Linear, where every record is an issue with a project, a status, and a cycle. The same bug looks like two completely different things in those two systems, and the seams between them are where most of the daily friction shows up.
This guide is about the working rhythm between those two teams: how to hand off a ticket without losing context, how to keep status moving without anyone playing messenger, and how to decide which channel a conversation belongs in. It is the soft layer that sits on top of any Linear HubSpot integration, and it is the difference between a tool that gets used and a tool that gets quietly bypassed.
In this article
1.
2.
3.
4.
5.
6.
Why Support and Engineering Teams Talk Past Each Other
Before any process advice, it helps to be honest about why this is hard in the first place. HubSpot and Linear are not just different tools. They optimize for different definitions of a "good outcome". HubSpot wants the ticket closed, the customer happy, and the SLA honored. Linear wants the issue scoped well, the work shipped on cycle, and the codebase clean. Those goals are not in conflict, but they are not the same, and the people who live in those tools all day end up speaking slightly different languages because of it.
The most common version of this shows up in the way each team describes a bug. Support describes it from the customer in: "Acme Corp cannot export their report and they are pushing on us because the board meeting is Thursday." Engineering describes it from the code in: "Export endpoint is timing out at 30 seconds for tenants over a certain row count." Both descriptions are true. Neither is sufficient. When the ticket and the issue are kept apart, each team works from its own version of the story, and the customer-impact context that determines priority for support is invisible to the engineer estimating the fix.
The second source of friction is timing. Support is a real-time job. A ticket that sits unanswered for an hour is a problem. Engineering is a cycle-based job. A bug that lands on Tuesday gets triaged on Wednesday and started next week, and that is the system working as designed. The mismatch is real, and pretending it is not is how you end up with support reps Slacking engineers individually because the ticket they care about is two weeks from being looked at.
The Handoff That Breaks Most Teams
The single biggest failure point is the moment a HubSpot ticket becomes a Linear issue. Done well, this is a five-minute step that turns a customer report into a tracked, ownable piece of engineering work. Done poorly, it is the place where 80 percent of the day-to-day pain comes from.
A bad handoff looks like this. Support copies the customer's words into a Linear issue with no rewriting. Engineering opens the issue, has no idea what the user was actually trying to do, asks a clarifying question in a Linear comment, and the comment dies because the support rep does not have Linear open. Two days later the rep follows up because the customer is asking for an update. The engineer has not started because the question was never answered. The customer hears nothing, the rep is frustrated, and the engineer is annoyed. Multiply by ten tickets a week and that is most of the bandwidth your two teams have for each other.
A good handoff looks like this. The support rep triages the ticket, decides it is engineering work, and writes a short summary that includes what the customer was trying to do, what happened instead, and any reproduction steps. They link the issue to the ticket through the integration so status updates flow back automatically. Engineering opens a clean, scoped issue with enough context to start, and any clarifying questions get asked once and answered in a place where both teams can see the answer. The customer-facing thread stays in HubSpot. The engineering-facing thread stays in Linear. The integration is what makes it look like one conversation instead of two.
The simplest way to make this routine is a triage template the support team fills in before sending an issue to Linear. Three fields: customer impact in one sentence, the user's actual goal in one sentence, and reproduction steps if known. That is enough to scope the work and enough for the engineer to estimate. Anything more belongs in the customer-facing ticket, not in the engineering issue.
Ground Rules for Living in Two Tools
Process is only worth as much as the rules that hold it together. Three rules cover most of the distance.
The first rule is that support owns the customer thread for the life of the ticket. Even when engineering writes the technical detail, the rep is the one who delivers the message to the customer, in the right tone, on the right timeline. This is not about gatekeeping. It is about consistency. Customers should hear about their bug from the same place they reported it, with the same voice that has been answering them throughout. Engineering replies directly to a customer almost never end well, because the engineer is calibrated to the codebase, not to the relationship.
The second rule is that engineering owns the technical work for the life of the issue. Once a Linear issue exists, support does not chase the engineer in Slack to nudge it forward. The integration is the channel for status. If status is not moving, the conversation is between the support lead and the engineering manager, not between the rep and the engineer. This rule sounds obvious and is constantly broken, because individual reps under pressure go around the system to ask the engineer they trust. Each time it happens, the system gets weaker.
The third rule is that any conversation that affects how the bug gets fixed belongs in Linear, and any conversation that affects what the customer hears belongs in HubSpot. There is some overlap, and the integration is what handles it. When an engineer adds a comment in Linear about the root cause, the rep sees a summary on the HubSpot ticket. When a rep adds a note in HubSpot about a workaround they sent the customer, the engineer sees it on the Linear issue. Neither team has to leave the tool they live in to get the context they need.
Stop chasing engineering for ticket status
IssueLinker keeps HubSpot tickets and Linear issues in sync, so support sees status updates the moment they happen and engineering gets the customer context they need to scope the work.
The Weekly Routine That Replaces the Slack Ping
The day-to-day status check should not require any meetings. The weekly routine should.
A short triage between the support lead and the engineering manager, once a week, is enough to handle the strategic side of the relationship. The agenda is the same every week. Review any new tickets that look like they should be Linear issues but have not been sent over yet. Walk through anything in Linear that has been open more than two weeks. Flag any patterns from the past week that suggest a deeper bug or a missing feature.
The reason this works is that it removes ambiguity from the daily flow. Reps are not making case-by-case decisions about whether to escalate, because escalation is a Tuesday morning conversation, not a real-time judgment call. Engineers are not pinged about slow tickets, because the slow tickets are reviewed at a known time with the right people in the room. The volume of one-off Slack messages drops sharply once people trust the routine.
For the routine to hold, the integration has to be doing its job. If the support lead has to chase down status from Linear by hand, the meeting becomes a status meeting, which is the failure mode you are trying to avoid. The integration should produce a clean view of "what is open, where is it in the cycle, and what changed since last week" with no manual prep.
When the Customer Should Hear From You
The single best signal of a healthy support and engineering workflow is that customers hear about fixes from support, not the other way around. The path is short. The Linear issue closes. The integration marks the HubSpot ticket as ready for a final reply. The support rep writes the customer-facing message, with the technical detail engineering already wrote in the issue, in the rep's tone and with whatever account context matters. The customer reads one message at one moment that says the bug is fixed, here is what changed, here is what to do next.
The failure mode is the customer asking for an update and the rep having to either guess or ask the engineer. That is the situation a good integration is built to prevent. If it happens regularly, the integration is not the issue. The team rules around it are.
The other failure mode is the customer hearing nothing because everyone assumed someone else would close the loop. This is why the support rep stays the owner of the customer thread for the whole life of the ticket. The integration tells them the moment the work is done. They are the ones who decide when and how the customer hears about it.
When the workflow is healthy, the customer always hears from support, the engineer always hears from Linear, and neither team has to ask the other for a status update.
What Good Looks Like, Six Months In
The clearest sign that the working relationship between these two teams is healthy is what stops happening.
Support reps stop pinging individual engineers in Slack to ask about ticket status, because the status is in HubSpot already. Engineering stops getting interrupted by drive-by questions about a ticket they have never seen, because the questions are scoped during triage and answered in the issue. Customers stop being told "we are looking into it" three weeks in a row, because the integration is making "we are looking into it" cost more than just writing a real update.
What you are left with is two teams working in the tools they prefer, on the parts of the problem they are good at, with a thin layer of process and a real integration carrying everything between them. That is the goal.