Support Triage
How customer support triages tickets, resolves bugs and escalates issues across Zendesk, Intercom and Linear.
Triaging an Intercom conversation by topic and intent
When a new conversation lands in the team Intercom inbox, the support rep opens it, reads the customer's opening message in full and applies one of a small set of intent tags (bug, billing, feature-request, login, onboarding, account-change). They then assign the conversation to the matching teammate or shared inbox and write a one-line internal note summarising what the customer is asking for. If the conversation already has more than three back-and-forth messages or includes a screenshot of an error, the support rep biases towards converting it into a Zendesk ticket rather than continuing to handle it inside chat.
Resolving an Intercom conversation with a help article
When the customer's question matches a known help-centre article (password reset, invite a teammate, change billing email, export a report, configure SSO basics), the support rep opens the team's saved-replies macro in Intercom, picks the macro that maps to the article, sends it inline with the article URL, then waits five minutes before closing the conversation. The reply pastes the relevant snippet into the chat itself rather than only linking to the article, and the conversation is tagged 'self-served' so the deflection shows up in weekly reporting.
Converting an Intercom conversation into a Zendesk ticket
When an Intercom conversation has crossed three back-and-forth messages, includes an error screenshot or carries the bug intent tag, the support rep uses Intercom's 'Create Zendesk ticket' integration to spin up a ticket from the conversation. They paste the customer's account email as the requester (looking it up if Intercom only shows an internal user ID), copy the Intercom conversation URL into the Zendesk internal note, set the ticket form to match the intent tag and reply once in Intercom with a single line telling the customer the conversation is moving to email so they have the new thread to follow.
Triaging a new Zendesk ticket and assigning a priority
When a new Zendesk ticket arrives in the unassigned queue, the support rep opens it, reads the body fully, then sets the ticket form (Bug Report, Billing, Account, Onboarding), the priority (P1, P2, P3 or P4) and the assignee group. Priority is set against an internal matrix: P1 for a paid customer who is fully blocked, P2 for blocking with a workaround, P3 for an annoyance and P4 for a feature ask. Customers on the enterprise plan or with a tenant ID matching the watchlist are automatically bumped one priority step. The support rep then leaves a one-line internal note explaining the priority choice so the next person who looks at the ticket understands the call.
Reproducing a customer-reported bug on a staging tenant
When a Zendesk ticket has been triaged as a Bug Report, the support rep reads the customer's reproduction steps, picks a staging tenant whose plan tier matches the customer's plan and walks through the steps in the same order. If the bug reproduces, they capture either a screenshot or a Loom recording (Loom for anything timing-related or interactive, screenshot otherwise) and paste the evidence into a Zendesk internal note. If the bug does not reproduce after roughly ten minutes, they stop and ask the customer for the missing details (browser, exact URL, tenant ID, time of last successful attempt) using a saved macro rather than guessing.
Searching Linear for a duplicate engineering issue
Before opening a new Linear issue, the support rep translates the customer's wording into engineering-style symptom keywords (e.g. 'I can't log in' becomes 'SAML 401 loop on cookie expiry') and searches Linear with those. They wrap exact error codes in quotes, filter by the engineering team most likely to own the area, restrict to issues created in the last sixty days and check the labels on any close match for 'support-blocking'. If a strong match exists in Backlog, Todo or In Progress, they record the issue identifier on the Zendesk ticket and skip the escalation. If no match exists, they proceed to escalate.
Escalating a confirmed bug to engineering through Linear
When no duplicate Linear issue exists, the support rep creates a new Linear issue from the Zendesk ticket. The title is in engineering-symptom language (not the customer's wording) so engineers can find it later. The description follows the team's fixed structure: customer impact, reproduction steps, expected vs actual, browser and device, tenant ID and a verbatim quote of the customer's own words. The issue is assigned to the engineering team's 'Triage' pseudo-user (never to a named engineer), priority is set against the team's escalation matrix, the 'support-blocking' label is added and the originating Zendesk ticket number is pasted into the description.
Linking a Zendesk ticket to its Linear issue and setting the customer expectation
Once a Zendesk ticket has a Linear issue (whether newly escalated or matched against an existing one), the support rep records the Linear identifier as a Zendesk tag in the form 'linear-eng-plat-4192', adds an internal note pointing to the Linear issue, then sends a public reply chosen from one of three canned templates keyed to the Linear priority. P1 and Urgent issues get the 'actively investigating, expect a daily update' template. P2 issues get the 'logged with engineering, no fixed timeline' template. P3 and lower get the 'added to backlog' template. The Linear URL is never shared in the public reply.
Holding a Zendesk ticket pending the Linear fix
After the customer expectation has been set, the support rep puts the Zendesk ticket on hold with a follow-up date keyed to the Linear status. In Progress issues get a one-week follow-up, Backlog issues get a one-month follow-up. The ticket is snoozed using Zendesk's follow-up feature so it returns to the inbox automatically on that date. A second internal note records the chosen follow-up date and the reasoning, and the support rep confirms the 'linear-{id}' tag is still attached so the post-fix sweep can find the ticket.
Sweeping linked Zendesk tickets when a Linear issue ships
Each Monday morning, the senior on-rotation support rep reviews the engineering teams' Done view in Linear for issues that shipped the previous week. For each shipped issue carrying the 'support-blocking' label, they search Zendesk by the canonical 'linear-{id}' tag, then open every matching ticket and reply using the 'eng-shipped-update' macro. The macro is personalised with the customer's first name, the release version if known and a one-line summary of what changed. Each ticket is then submitted as Solved (not Closed) so the customer can re-open if the fix turns out to be incomplete, and the 'linear-{id}' tag is left in place for record.
Speak to the founder
Get a demo. Watch a live capture, then an AI agent query the result.
Ask anything. Pricing, security or integrating with your stack.
No purchase obligation
Start capturing
Record in minutes. Install once and work as normal.
Plug AI agents in. One API call from any AI agent stack.
Refund on unused credits if you cancel